Getting JobID

I want my robots to be able obtain, from Orchestrator, the JobID they are running. It’s the thing that appears at the top of the transaction item detail page in the Orchestrator queue. Looks like a GUID. I need a unique common element that all transactions executed by all robots participating in a job, that we can save to a SQL database and then query on to identify all items belonging to a specific job run at a specific date and time.

I’m finding a lot of topics asking for the same thing, along with a lot of replies to replies saying “Thanks but that only gives me the ProcessName. I need the JobID.” Along with some suggestions that this can be done via the Orchestrator API but no usable examples of how to do this.

Any suggestions appreciated.


@rabbit_rebozo Yes you can get the JobId from Orchestrator API. Below is the example.
You can use Swagger UI {orchestratorURL/swagger/ui/index#!/Jobs/Jobs_GetJobs} to test it

Thanks Arpit. I don’t know a lot about API stuff. Is this something I can run using the ‘Orchestrator HTTP Request’ activity?

Many of the posts I’ve seen discuss similar API approaches. But many if not all of them look to me like they’re offering to get lists of jobs, optionally with a filter applied, for example ‘jobs that are currently running’. What I’m needing is a way for the robot to get information about the job it is running itself at that moment.

All told what I want to compile might be expressed something like:

“Right now I, robot1, am running process ‘AmazingProcess’ under Job ID ‘2345234523452345235’ in Environment ‘Test’.”

I’ve looked at the Get Jobs activity, which certainly returns a lot of this (not the ID, unfortunately) but I can’t figure out how to narrow the list it returns down to the specific job I am currently executing.


In the end time limits and deadlines meant that we dropped pursuit of the JobID thing. Volumes are not so high (usually a process only runs once per day, and even if it does run more than once some days, a typical run is only a dozen or two transactions) so granularity down to process name and date is sufficient for our reporting purposes… at least for the moment. May need more detail further along the line which would bring us back to needing something like the JobID.


To read and insert in SQL you can consider using functions in the below package. It will call API from SQL and get you desired data.