Let me preface this by saying that we’re scoured the forums and documentation, and can’t seem to find what we are looking for. At the same time, this seems like such a basic requirement, that we’re hard-pressed to imagine it not being here.
Simply put: We need to pass arguments into a Job.
For example, let’s say we want to scrape a website to retrieve the current temperature by location. For this, we would need to pass in as an argument, the desired zip code (US).
We know that there are assets that can be defined globally as well as per-robot, but this means they would need to be updated for each job. This is hardly sustainable.
Instead, we’d like to know how we can supply InArguments at the time we create a job.
It really doesn’t matter whether this is exposed in the UI, as we will be running against the Orchestrator API in production.
I agree, there should be an input parameter(s) when starting a job.
You could create a .xaml file for each user or zip code that passes your main workflow those parameters like from a text file or just a variable, then publish each one to create a different process for each user or location.
Or even use the text file as your input and change it each time you start the job, which then you would only need one process.
Hi,
Can you clarify your point?
Your suggestion is to duplicate your process X times for each zip code you have? For maintenability, you have to re duplicate each time your process evolve… it can be crappy very fast. And if you have a new area to manage, you have X jobs to create.
Second one, can be very fastidious, if you have sequentially the job running once per half hour, with a different parameter all long day, each day…
Is there someone have others idea to contextualize the job, to define which config file to use?
I was looking to define environment for each context (here zip code), but you can’t deploy a process on several environment containing the same robots. It would be fine if you had one robot per configuration, but in this case, the local config file would be enough.
That was almost a year ago, but to clarify, I believe I was saying that you can have a Project for each job where the parameters change.
For example,
Person A has a job called Process1_A_Environment
and
Person B has a job called Process1_B_Environment
-EDIT: type corrected-
Person A uses a different source and output file than Person B as example.
So, the projects are duplicated, however, the Process is NOT duplicated. Each project just has 1 activity: Invoke Workflow, where you call the Process workflow and pass different values as arguments or configuration text/excel file. Essentially, it shares the same Process workflow so by using the fullpath, you can update that workflow without need to publish each project.
Now, that’s just an idea that my RPA team at my company has used to separate Processes for our Ad hoc users that require different files but use same workflow.
Maybe in the future I will discover better solutions like it can tell who is running the job and dynamically chooses the parameters based on that information.
this is really a big issue. We need to download several times reports from a system (a few reports per action but different reports per actions).
So normally there should be n process with its on input file. We solved this by creating a configurator file that is picked up every time when this job starts and based on current time and robot name it points to an input file. This is OK if there is no delay or no need for manual ad-hoc start. But this is just firefighting.
But you can keep it simple: an integer value or a keyword in a string is enough to pass to a job (when manually started and when scheduled too) to tell to the process what to do. Based on it the input can be evaluated by the code.
ashokkarale
MD_Farhan1
Ajay_Mishra
postwick
Dheerendra_vishwakarma
Anil_G
chandreshsinh.jadeja
Gautham_Pattabiraman
vrdabberu
aravindbalineni123