Highlighted
Contributor
Contributor

Can't figure out uname/pwd parameters for Workflow.execute

In vRealize Orchestrator 7.4, I have a case where I need to execute a workflow as another vRealize Orchestrator user in an automated fasion. According to the API Explorer, Workflow.execute supports three parameters: properties (Object), uname (Object), and pwd (string). I have the following code:

var wf = Server.getWorkflowWithId( 'work-flow-identifier-uuid' );
var wfParams = new Properties({ param1: 'value1' });
var user = 'myUser@domain.com'; // have also attempted with the administrator@vsphere.local account
var pass = 'myPassword';
var token = wf.execute( wfParams, user, pass );

However, this throws the following error:

Cannot execute workflow : SSO server error

What am I doing wrong? My suspicion is that it does not want a string for the uname parameter, but am unsure what else I can provide as an argument here. Or if there's a better way I can achieve running a workflow as a different user programatically, I'm all ears.

0 Kudos
7 Replies
Highlighted
VMware Employee
VMware Employee

Hi,

uname parameter should be a string. Your code looks fine to me. Here are few things to check:

  • Does this user account myUser@domain.com / myPassword have enough permissions in vRO? For example, are you able to login with ithis account in vRO Java client and run the same workflow manually?
  • After you get this error, could you open the vRO server log file at /var/log/vco/app-server/server.log and check if there are some errors logged around the same time? Usually, there are some useful info like Java stack traces, etc., that can be helpful for troubleshooting.
0 Kudos
Highlighted
Contributor
Contributor

I actually have not tried logging into the vRO client with the intended user so that will be something I'll need to check later, but I have also tried with the "administrator@vsphere.local" account which has permissions to do anything.

I'll see if I can find anything in the log you mentioned above and reply back.

0 Kudos
Highlighted
Contributor
Contributor

Alright, so I'm not seeing any additional errors coming through in server.log when running my action test workflow (the action is what calls the other workflow as a different user). However, I do see this above, before my Javascript starts to run. Although I've seen this before and it doesn't seem to affect anything when using vRO day to day:

2018-12-20 14:50:33.628-0600 [http-nio-127.0.0.1-8280-exec-8] ERROR {} [VRAAuthorizationQueryService] Failed while finding roles for principalId: '{Name: myAccount, Domain: companydomain.com}', tenant: 'VSPHERE.LOCAL'. Granting an Operator role.
org.springframework.web.client.HttpClientErrorException: 404 (followed by a large stacktrace)
2018-12-20 14:50:33.628-0600 [http-nio-127.0.0.1-8280-exec-8] ERROR {} [VRAAuthorizationQueryService] Failed while finding roles for principalId: '{Name: albale01-pa, Domain: csgidev.com}', tenant: 'VSPHERE.LOCAL'. Granting an Operator role.
org.springframework.web.client.HttpClientErrorException: 404
0 Kudos
Highlighted
VMware Employee
VMware Employee

OK, so it seems your vRO is configured with vRA authentication. There is some logic that is supposed to map vRA roles to vRO permissions, for example, the tenant admins in vRA are considered admins also in vRO. The error message suggests that the roles for this account cannot be resolved.

0 Kudos
Highlighted
VMware Employee
VMware Employee

I would also check that used account is available in vRA.

In vRA you configure set of users/groups to be synchronized from the configured identity provider. So not all users from given AD are immediately available in vRA

0 Kudos
Highlighted
Contributor
Contributor

Thing is, I've also attempted to run as the default tenant admin, administrator@vsphere.local, which can log into both vRA and vRO. I ended up opening an SDK support case since the consensus here looks to be that I've coded this properly, and something else is going on. Hopefully next week we can get to the bottom of what happened and I can report back here with a solution.

0 Kudos
Highlighted
Contributor
Contributor

Wanted to update that it looks like something may have been introduced with the new multi-tenancy feature in 7.4 that might have broken this. Still waiting on the final word from VMware Engineering as to what the issue might be.

0 Kudos