We have already had a look at the return values of the REST plugin, but there are also the return values of the SOAP and PowerShell plugin to look at. All of them are a bit more complex than just a string. A lot of the return values are either JSON, XML, or Arrays of Properties. In the JavaScript complex variables recipe in Chapter 6, Advanced Programming, we showcased how to harness them.

The most important thing to figure out is the information you really need for your workflow and whatnot. A request returns a lot of different values that you may or may not really need. What you need is to sort out what values you need and in what format you need them. Then select these values and reformat them into something you can pass back to your workflow.

For example, you may only need to know if an operation you performed worked, so passing back a boolean to your workflow would be enough. On the other hand, you may need several strings, so you could pass on an array of strings back.

If you have to pass on more complex information, it might be a good idea to parse the return values and extract the information you need. Then you could build a brand new JSON or XML string or a property and pass this more complex information back.

When dealing with REST, PowerShell, SOAP, and SQL, you need to provide credentials. When you need to provide credentials you are mostly asked if you would like to use a Shared Session or a Per User Session.

It's an important decision that needs to be thought about early on. The differences between methods are as follows.

With a Shared Session you define one user that is used to facilitate all actions that are used. For example, you connected to an SQL server using a user called srv-dbuser. The user srv-dbuser is a DBO and system administrator on the database. Now a user, for example, James, starts a workflow that uses the SQL connection you have defined, meaning that James will use the user rights of srv-dbuser to run the workflow.

Per User Session means that the user credentials of the logged-in (or executing) user are used to facilitate the connection. However, there is a bit of a problem with this. If you are not using LDAP as the external authentication method, then Per User Session will not necessarily work. This is due to the way that SSO/vIDM work. For example, if you are using the vRealize Automation integrated Orchestrator you can't (at the time of writing) use a Per User Session to connect to vCenter. This is because vRA uses vIDM and vSphere uses SSO, and they are currently not compatible.

I personally prefer using a service account and Shared Session to connect services to Orchestrator. The reason is that I want to keep users out of systems. Instead of adding a ton of users to for example SQL so that they can use the database workflows, I just add one user and make sure that all the other users only use the workflows that they should. This, in my opinion, reduces the amount of administering and reduces the attack vectors.

However, there are cases where a Per User Session is a better fit. For example, when you are using the vRealize Automation plugin (see Chapter 13, Working with vRealize Automation), a given user can only interact with the elements that they are entitled to interact with.