Using Request Context in vCD Service Library Workflows

The Service Library was introduced in vCloud Director 9.1 and allows you to publish vRealize Orchestrator Workflows to your Tenants and/or Service Providers.

There must be a thousand use cases for this scenario and many of them would require one thing: scope limitation. To keep it simple, let’s say you want to provide a Workflow which collects VM data, generates a fancy report and sends it via email to the requestor. The user should be able to select the vApp for which the report will be created.

That short sentences already deliver some interesting requirements:

1. The reports must only include data of VMs that are managed by the requestor
2. The Workflow must be aware of the requestors email address
3. Before Workflow execution, the requestor can select one of his managed vApps

Number 3 is the interesting one because it requires the Workflow to make use of the request context before the Workflow itself is running.

If you create a Workflow that only logs out all available parameters, you will see this when running it from the Service Library:

_vdc_isAdmin: true
_vdc_userName: administrator
_vcd_orgId: d5ad40bd-1a94-4a7c-8732-85f4cb4058a7
_vcd_sessionToken: a long and boring string
_vcd_apiEndpoint: https://vcd-01a.corp.local/api
_vcd_isAdmin: true
_vcd_orgName: tsiegl
_vcd_userName: administrator

Not bad, but we need this information before execution.
So what happens if you add a Workflow Input Parameter that matches one of those names? This:

As you can see, when starting the Workflow from the Service Library, the information is already in there.
In order to create a Workflow for my example use case, the following steps would be necessary:

1. Make the Input Parameter _vcd_orgId hidden in the Workflow Presentation
2. Add another Input Paramter for the vApp
3. Create an Action that receives an Organization ID as input and returns an Array of vApps which are within that Organization
4. In the Workflow Presentation, set the vApp Input Parameter to show a predefined list of elements and bind the Action to it.
   The Actions input will be _vcd_orgId.
5. Get the User object via Organization Id and username to get the mail address
6. Implement the reporting stuff, which is not relevant for this article

And that’s it. You can now limit the scope by presenting only objects that exist within the requestors Organization.