Verwendung des Request Context in vCD Service Library Workflows

Seit vCloud Director 9.1 steht die Service Library zur Verfügung, mit deren Hilfe vRealize Orchestrator Workflows an Tenants und/oder Service Providers veröffentlicht werden können.

Es gibt wohl tausende Anwendungsfälle, die sich hieraus ergeben können und viele davon benötigen eine Limitierung des erlaubten Aktionsradius (scope). Als einfaches Beispiel, gehen wir davon aus, wir möchten einen Workflow zur Verfügung stellen, welcher VM-Informationen sammelt, einen schicken Bericht erstellt und diesen dann per Email an den Anforderer  sendet. Der Anforderer sollte dabei auswählen können, für welche vApp der Bericht erstellt wird.

Diese beiden Sätze liefern bereits einige interessante Anforderungen:

1. Der Bericht darf nur Daten von VMs enthalten, welche vom Anforderer verwaltet werden
2. Der Workflow benötigt die Email-Adresse des Anforderers
3. Bevor der Workflow startet, wird eine Auswahl von gültigen vApps angezeigt

Punkt 3 ist interessant, denn er erfordert den Zugriff auf den Request Context noch bevor der Workflow selbst startet.

Startet man über die Service Library einen Workflow, welcher alle in ihm enthaltenen Parameter ausgibt, sieht man Folgendes:

_vdc_isAdmin: true
_vdc_userName: administrator
_vcd_orgId: d5ad40bd-1a94-4a7c-8732-85f4cb4058a7
_vcd_sessionToken: ein langer langweiliger String
_vcd_apiEndpoint: https://vcd-01a.corp.local/api
_vcd_isAdmin: true
_vcd_orgName: tsiegl
_vcd_userName: administrator

Nicht schlecht, doch diese Informationen werden noch vor der Workflow-Ausführung benötigt.
Was passiert nun, wenn man dem Workflow Inputs hinzufügt, deren Namen mit den eben aufgelisteten übereinstimmen?
Das hier:

Wie man sieht, ist diese Information nun im Workflow verfügbar.
Um nun den Workflow aus meinem Beispiel zu erstellen, würde man wie folgt fortfahren:

1. Den Workflow Input _vcd_orgId in der Workflow Presentation als unsichtbar konfigurieren
2. Dem Workflow einen weiteren Input für die vApp hinzufügen
3. Eine Action erstellen, welche als Input eine Organization Id erhält und ein Array von vApps liefert, welche sich in dieser Organization befinden
4. In der Workflow Presentation konfigurieren, dass der vApp Input über ‘predefined list of elements’ über die Action aus 3. Daten erhält.
   Als Input für die Action dient _vcd_orgId.
5. Der User kann über die Organization Id und seinen Namen gefunden werden um dessen Email-Adresse zu ermitteln
6. Die Logik für die Erstellung des Berichtes entwickeln

Und das war es auch schon. Nun kann der Aktionsradius eines Benutzers eingeschränkt werden indem ihm nur Objekte präsentiert werden, welche sich in seiner jeweiligen Organization befinden.