Orchestrator CE StartJob API

Hello,
I’m using the Orchestrator CE APIs. This is my request to Start a job. I’ve got the Release Key of the Process that I need to run as a job via the /Releases API, and the Robot ID using the /Sessions API call.

Further, the Robot Role has Create+Edit permissions on the Jobs, and View Permissions on Process and Environment.

However, I’m constantly getting 400 (Bad request) errors. Please see my API request below and let me know what’s wrong in this request.

Thanks!

Any suggestions folks?
Anywhere I’m going wrong?:confused:

Hi @AndyMenon

Could you try two things:

  • remove the NoOfRobots value from the JSON
  • add this header, just in case:
    X-UIPATH-FolderPath: Default
    

For comparison, here’s a tested JSON:

{
  "startInfo": {
    "ReleaseKey": "xxxx-zzzz-xxxx-yyyy-zzzz",
    "Strategy": "Specific",
    "RobotIds": [
      yyzxyyz
    ],
    "Source": "Manual"
  }
}
3 Likes

I got dragged into another crisis this whole day.

I’ll copy-paste your code and apply the values on my end and run it to see if it that fixes it.

Will post an update at first opportunity.

Thanks!

2 Likes

Ok - I’m flummoxed right now! :astonished: - reproducing the steps I just followed here below. Kindly let me know where this is falling apart.

:warning: To confirm the obvious before I proceed - The Robot exists and is licensed. The Process exists and works!

Step 1: Get the Robot Id from the /Sessions API

In response, I get the correct folder name and the Robot ID as shown below:

Step 2: Get the Process Id from the /Releases API

*The response to this request is the key of the Process and also the right version currently deployed to the Orchestrator: *

Step 3: Use information from Step 1, Step 2 and information from @loginerror above to start the job

  1. Folder header info has been added on the left
  2. New JSON as suggested by @loginerror has been submitted on the right
  3. The ReleaseKey is from Step 2
  4. The Robot ID is from Step 1
And yet, I get an Invalid Robot ID error.
How can this be? If the Robot ID is invalid why is it being returned in Step 1? 

Hi @AndyMenon

You are almost there. But instead of using the /Sessions endpoint which returns the ID of the session, you should get the Robot ID from the /Robots endpoint.

I switched over to the /Robot endpoint . Yes, this time it’s giving me a different Robot Id.

That said, I'm back to square 1 with the 400 Bad Request error after making all these changes. The response body is completely empty!

The result is the same even after I repeat the test between two completely different Orchestrator instances. Every other API call up to this point is working except this one.

The following have been confirmed:

  1. Bearer token works with other API requests including /Releases and /Robot endpoints
  2. Studio Robot is online, connected and licensed
  3. Robot Role has Create + Edit perms on Jobs, and View perm on Processes and Environments
  4. Process exists and works
  5. All headers have been added to request
  6. StartJobs API URL has been generated using swagger

Not sure what else is missed or needs confirmation.

Thanks ,
Andy

I hate to post these many updates for such a simple issue. Something is really flaky here.

I came back home and repeated the experiment that had failed earlier. And it worked perfectly! The job kicked off and successfully completed.
That’s the good news!

Ten minutes later I repeated the whole series of steps and this time, it crashed and burned with a 400 error!

To my defense, the test scripts have been saved in Talend as a project. It’s not that I’m manually typing in these API requests every time.

Is there some limit in the CE version that the StartJob API cannot be called twice in under 15 minutes?

Hi @AndyMenon

This should not normally happen, I don’t think.

Does it still happen? Maybe there was some malfunction that our Platform team already fixed in the meantime.

Yes, I made a couple more attempts and there was no change.

One significant observation:

Once the 400 error is hit, no matter how many times you try, the API end point does not recover from it. Even submitting a brand new request with a newly refreshed token and trying to start a different job has no impact. It still throws a 400 error.

I feel something is wrong with this endpoint because all others work consistently without any issues.

I gave this a shot 2 days after my last failure attempt and it’s working. I used the exact same API call scripts, with a newly acquired token. I ran 3 tests. Started the same job twice within the first 5 minutes.
And then after a few minutes, I got the release key for a second job and started it via the API.

All three tests succeeded and the jobs ran successfully. I feel that the StartJob end point was in flux over the past few days I've been struggling with this. That said, I will run these tests for a different Orchestrator CE instance from a different Robot machine so that I can confirm consistency and reliability.

Test results with timestamps of the current tests below:

1 Like

And indeed, the tests after an hour have magnificently failed! The only differences was an addition to the JSON to pass in arguments to the job I was testing.

{
  "startInfo": {
    "ReleaseKey": "..........................................................................",
    "Strategy": "Specific",
    "RobotIds": [
      xxxxxxx
    ],
    "Source": "Manual",
    "InputArguments": "{\"in_EnablePrimedLog\":\"N\"}"
  }
}

Once the test failed, I tried running the job under default state with the original JSON, but despite refreshing the token the job did not run. And just like 2 days ago, the StartJob API endpoint seem to be paralyzed by a 400 error and has become unresponsive !

I’m discontinuing the use of these APIs as spending anymore time on this will only delay further progress.

1 Like

Hello @AndyMenon,

I was able to replicate a similar behavior using Postman and doing some changes in the request. The problem seems to be the invalid forgery token sent by the app. After restarting Postman the issue was solved. I am not familiar with Talend but it should allow cookie or CSRF token regeneration.

1 Like

Hi @alexandru,

I was in the meantime going through this article that was a lead from the Talend forums:

https://community.talend.com/t5/Design-and-Development/Using-OAuth-2-0-with-Talend-to-Access-Google-APIs/m-p/133568#M587

This article exemplifies accessing Google APIs using “Client ID” and “Client Secret”. But isn’t that what we do each time we refresh tokens for the CE APIs? Fetch the Client ID from the API Access dialog and use that to get a new token?

Or is this article suggesting that we do something more?

thanks,
Andy

Using the credentials from API Access and POST https://account.uipath.com/oauth/token you should retrieve the access token (valid 24h). You do not have to do this for every call, you only need to retrieve the access_token when it expires.

Can you try to use postman instead ? At least we isolate the problem (Talend or Orchestrator CE).

I have shared an example so all you have to do is to populate the variables for oauth/token with your credentials (taken from cloud portal - API Access) and update the StartJobs Body with your IDs.

platform API.postman_collection.json (4.0 KB)

Yes, but I tried to refresh my token so that I could repeat the test from scratch once I ran into the 400 error. Otherwise it would be every 24 hours. FYI: We have other non-RPA Cloud integrations where tokens expire every hour and we have to check for token expiry before we make the actual call for data.
I tried to avoid installing yet another executable on my laptop, but it looks like that’s unavoidable. I will experiment with postman and keep you posted.

Side bar question: I see that the User-Key changes each time I bring up the API Access dialog. How do we manage this every 24 hours? Do we have to write another process to acquire the User-Key in an automation fashion before we make a call to refresh the token?

Thanks,
Andy

Postman is very light and has a good reputation. Also is fast and easy to test API calls.

You do not have to change the user-key. Once you have it generated you can use it until you revoke access (for all previous generated keys). This can be seen only once as a security measure and the next time you request API access a new key is generated (but the old one is still valid). Also the user-key should be treated as a password and kept secret.

Understood.

Before I observed the User Key changing, I was planning to store the User-Key in the WCM of the Robot machine as a quasi-password. Meaning, the user name would be the logical Account+Logical name and the password would be the User Key. I would retrieve the User Key by providing a credential name during run time for the purposes of refreshing the token, or for normal use.

This way, the User Key would not be a hard-coded artifact, and the application would seamlessly move from DEV to UAT/PROD.

Thanks,
Andy

Here are the test results. The Creation times published below are the responses received to the StartJob API Requests.

Summary: Over the Span of 3 hours, 4 tests were conducted. Postman tests succeeded whilst the exact same test (and only test) repeated in Talend failed.

Postman, StartJob Test #1 >> Success!

“CreationTime”: “2019-12-25T18:50:12.4182491Z”,

Postman, StartJob Test #2 - Same token, different Job, 15 minutes later >> Success

“CreationTime”: “2019-12-25T19:06:28.2694346Z”,

Talend, StartJob Test #1 after successful Postman tests #1 and #2 above

Job #2 was repeated exactly as above, but refreshing a token, 4 minutes later
date: Wed, 25 Dec 2019 19:10:04 GMT
FAILED: 400 Error

Back to Postman 3 hours later, StartJob, Repeat Test #2 exactly without any changes! >> Success!
“CreationTime”: “2019-12-25T22:01:06.569073Z”

I’m not sure now if Talend is the problem, aren’t the APIs supposed to work client-agnostic?

thanks,
Andy

To this problem I change https://cloud.uipath.com/ to https://platform.uipath.com/ and it found