Parameter naming in activities


#1

Thinking about it… shouldn’t the name of that argument be ReleaseName then? Because that’s basically what it is and it corresponds to odata/Releases -> Name


How to Start a job using Start Job activity
#2

The Processes in Orchestrator were called Releases in the earlier versions of UiPath. Since 2016.2 we have Processes, so i consider it would be more confusing to have it as ReleaseName(like many people don’t understand what to set as Release in API calls).

Anyways, it’s in plan to change it to odata/Processes.


#3

That’s not really an argument :wink: Most UiPath users don’t know what SendWindowMessages does and it’s still a good name.

So a Process will be a deployed package (package name + environment)? I don’t understand the logic behind that change, but that might be good for a separate discussion.


#4

That’s exactly what is it. From the user guide: A process represents the association between a package and an environment.

That’s debatable also. I don’t know if it’s good from a UX experience.

That’s why i moved the naming discussion separately, so we can all understand this stuff.


#5

Interesting.
I might be stuck in a weird bubble, but I don’t think I’ve ever called that association a Process in a conversation. It was always a Release.

To be clear - I’m not against redefining words based on context/domain, but what bothers me is that in RPA context a Process already exists.

I know it’s all semantics, but it just doesn’t seem right and doesn’t correspond to basically every other lifecycle for software or to the meaning of that word in conversations with customers.
It also doesn’t fit into sentences too well, because it redefines the meaning of a Process that is very commonly used.

(rest of the rant deleted, do what you will)

Sidenote - in the Guides, it might help with readability if terms that have specific meaning would be capitalized (contract style), f.e.:
“A project becomes a package when it is published to Orchestrator.”
->
“A Project becomes a Package when it is Published to Orchestrator.“
That way, the text itself puts front and center that these are terms that have specific definitions and could be expanded as such with a help of a glossary:
“Project -> set of workflows bla bla bla”
“Package -> Published Project”
”(to) Publish -> act of packaging a Project into a Package”
“Process -> association of Package to Environment” <- (still doesn’t fit…)

I don’t know, I might just be weird, but I really don’t understand what’s wrong with using “Release” in what essentially is a software lifecycle…


#6

Not debating, just asking:
What is a process to you? Isn’t it a set of actions that together achieve a particular goal?
What entity in UiP would you call a process, if any?

(And a total sidetrack, but since you struck a chord :grin: : “Most UiPath users don’t know what SendWindowMessages does and it’s still a good name”. I’d say that’s actually the textbook definition of a bad name.


#7

To me it’s a textbook definition of “most users don’t care as long as it works”.
There was a whole discussion back then about it, and the best alternative (Background + Background Turbo for Simulate) gathered the same amount of interest (as in - basically noone cared enough to express their opinion outside of the usuals).
Maybe I should’ve said “most users don’t realize that ‘SendWindowMessages’ is a literal description of what that activity will do”.

It’s exactly that. And “an association of a package and an environment” is definitely not that :wink:

Probably none, at least for me.
Closest one would probably be related to project content/package - since it’s a executable representation of a process, I could see calling it that.
It also easily fits into mental models of RPA:
“What’s the status of [automating] XYZ [business] process?”
“I deployed that [robotic] process to QA environment yesterday.”
"It passed, let’s put that [robotic] process to production."
This is a conversation very similar to what I’m having on a daily basis. Outside of the last sentence, you could substitute project there as well.

In RPA context, a Process could be defined as a “executable set of actions that together achieve a particular goal”, or a robotic equivalent of a Business Process. It then becomes a natural extension of a dictionary definition of a process, just set to automation context.

Taking what basically is a release definition and calling it a process breaks expectations from both sides - from business terminology it’s not a process, from software perspective it’s not a process either.

If a process is that association of package + environment, then that would also mean that if I connect the same package with 3 environments, I now have 3 processes. Which is a serious “umm… what?” moment, because in reality it’s the same process - just deployed to 3 environments. This is the thing that breaks it for me, rest would be just an adjustment (with possible conflict of meaning…), but this one is just too easy to convey a completely wrong message.

“Did you run that process in Test?” seems legit and (IMHO) to most people would mean the same as “Did you start a Job in Test environment that executed that process [set of actions]?”.
“Did you run Test process for that [what to even put here?]?” falls apart. Package? Project? Help me out :slight_smile:

There’s a good way of checking definitions - write a sentence with that word and substitute the defintion for that word and check if a) it’s still understandable, b) if it conveys the same meaning.
"Yesterday I created 2 Processes."
To anyone not familiar with the defintion from Guide, it would mean that “Yesterday I created 2 sets of actions that achieve a particular goal” or something along those lines.
WIth the Guide definition it’s “Yesterday I linked a package with 2 environments”. Which is a completely different thing.
And if you say “Yesterday we created Test Process and QA Process” meaning the latter to a customer… a funny look might ensue (or a horrible misunderstanding).

So going around… I think in common terms, sentences like “I updated the process on Prod to use version XYZ” are being said on a daily basis.
But I’d say that they’re a misuse of the term, or a colloquialism/short-hand for "Based on Release Definition [ProcessName]_[EnvironmentName] I created a new Release using Package version XYZ and Orchestrator will Deploy it to each of the Robots next time a Job is started for them."
It’s just that that set of actions is 3 clicks away and that’s why people don’t know what a Release is…

Corresponding to traditional software development:
Project -> Source Code
Publish -> Build
Package -> Build Artifact
Environment -> Environment
"Process" (or a current definition of it) -> Release Definition
Update Process -> Create and allow auto-Deployment of that Release based on a Release Definition (also happens automatically when creating a “Process”)

Or I’m wrong on all of this and I’m the only one for whom it sounds weird and I need to relearn :wink:

I’d love to hear an opinion from someone who had a “Release Manager” role/job title on this :slight_smile:


#8

I get what you’re saying.
I don’t really go by the guide’s definition, but instead I go by what makes sense to associates.
Process => Tasks to be achieved via Robot
Robot => Humanoid to perform tasks
Environment => List of Robots available for Process
Job => The specific run of the Process

If I say I created/provisioned a Process in Orchestrator, I don’t mean that I associated a Package to an Environment; I mean that I created a name that describes the Process (series of tasks to achieve a goal) that a Robot will run scheduled or adhoc.

I don’t see the Environment making a Process different. Like Process1_Env1 = Process1_Env2, except that one has a different set of Robots available for whatever reason.

Thanks.