-
Notifications
You must be signed in to change notification settings - Fork 36
Lookups
The Workflow Parameter Lookups (aka Lookup Parameters, Lookup Expressions or simply Lookups) are used to extract a value for a field or attribute from one of the parameters passed to the workflow when it is launched. Lookups act as a token or variable that is evaluated when the Workflow is processed. Lookups consist of a Workflow Parameter and a Parameter Attribute.
In addition to supporting and extending the capabilities of Lookup Parameters that are supported by the product, viz. Request, Requestor, WorkflowData, Target RequestParameter and Delta, WAL also supports Approvers, ComparedRequest, Effective, Queries and Value lookups. These are described below.
- Approvers
- ComparedRequest
- Delta
- Effective
- Request
- Queries
- Requestor
- RequestParameter
- Target
- Value
- WorkflowData
Note: The WAL Variables are not supported for use in Lookups.
The Approvers lookup is used to retrieve a list of all approvers for the current request, in order of the date/time at which they approved it.
This is a WAL-only lookup parameter and not part of the FIM / MIM lookup grammar.
[//Approvers][//Approvers/DisplayName][//Approvers/Manager/DisplayName]
The ComparedRequest lookup is used in the Verify Request activity when doing request conflict identification. It is used when specifying a match condition and refers to the request currently being evaluated. The lookup behaves exactly like the WAL Request lookup, with additional support for the [//ComparedRequest/Delta] grammar which gives access to the request parameters of the compared request.
This is a WAL-only lookup parameter and not part of the FIM / MIM lookup grammar.
[//ComparedRequest][//ComparedRequest/Creator/DisplayName][//ComparedRequest/Delta/DisplayName][//ComparedRequest/Delta/Manager/DisplayName]
The WAL offers full support for the delta parameter and leverages it to provide access to request parameter data. Any attribute populated/modified by a request can be accessed via the Delta lookup. Additionally, modifications to any multivalued attribute can be accessed using the [//Delta/Attribute/Added] and [//Delta/Attribute/Removed] grammar. The deep resolution against the multi-valued references is also supported.
The WAL extends the Delta lookup by supporting any available attribute on a resource, not just ExplicitMember/Added and ExplicitMember/Removed.
In an AuthZ workflow that is triggered on the creation request of a resource, the a WAL Target lookup is automatically substituted with the equivalent WAL Delta lookup since the newly created resource is not yet committed at this stage.
Note that if an attribute is deleted / cleared during a request, it will not appear in the Delta lookup. Hence using Delta lookup it will not be possible to differentiate a deleted attribute in a request and an existing attribute with no value in the target. If there is a need to know if the attribute is deleted, perform a ParametersContain([//Request/RequestParameter], "<AttributeName>") check.
[//Delta/DisplayName][//Delta/Manager][//Delta/Manager/DisplayName][//Delta/ExplicitMember/Added][//Delta/ExplicitMember/Removed][//Delta/ExplicitMember/Added/DisplayName][//Delta/ExplicitMember/Removed/DisplayName][//Delta/ExplicitMember/Added/Manager/DisplayName][//Delta/ExplicitMember/Removed/Manager/CostCenter/CostCenterCode]
When running an activity in an authorization workflow, the Effective lookup will return the value of a single-valued attribute as if the request is committed. If the attribute was changed as part of the request, this will match its Delta equivalent. If not, it will match its Target equivalent. When running in an action workflow, Effective will always match Target.
This is a WAL-only lookup parameter and not part of the FIM / MIM lookup grammar. For clarity of purpose, use a Delta or Target lookup syntax unless you really mean you need the Effective value.
Use of Effective lookup is currently not supported for multi-valued attributes in AuthZ workflows. In this case, use appropriate Delta and Target lookups instead.
[//Effective][//Effective/DisplayName][//Effective/Manager/DisplayName][//Effective/Manager/Manager/DisplayName]
For activities with built-in query capabilities, the Queries lookup parameter is used to access the results of specified queries. Queries are run once and then accessible within the context of the same activity.
This is a WAL-only lookup parameter and not part of the FIM / MIM lookup grammar.
For a query named Leavers with XPath search filter defined as /Person[EmployeeStatus = 'Leaver'], the results can be accessed as:
[//Queries/Leavers][//Queries/Leavers/DisplayName][//Queries/Leavers/Manager/DisplayName]
The Request lookup is used to access the attributes of the current request.
The WAL extends the Request lookup by supporting any attribute on the current request (i.e. those that are defined in Request resource schema), not just the CreatedTime. The deep resolution against the multi-valued references is also supported.
It should be noted that most fields populated / modified by submitting a request are not part of the Request resource schema. They are part of the schema of the Target resource (and hence accessible via Target, Delta, etc. lookups). In the scenarios where you want to check if any Target attributes are populated / deleted via the submission of the current request, use [//Request/RequestParameter] in conjunction with Parameter* WAL functions. e.g. if an attribute is deleted / cleared during a request, it will not appear in the Delta lookup. Hence using Delta lookup it will not be possible to differentiate a deleted attribute in a request and an existing attribute with no value in the target. If there is a need to know if the request has deleted an attribute, perform a ParametersContain([//Request/RequestParameter], "<AttributeName>") check.
[//Request][//Request/CreatedTime][//Request/Creator/DisplayName][//Request/Creator/Manager/DisplayName][//Request/RequestParameter]
The Requestor lookup is used to access the attributes of the submitter of the request.
Resolution behaviour of Requestor lookup the is similar to MIM's native behaviour, with added support for deep resolution against multivalued reference values.
[//Requestor][//Requestor/DisplayName][//Requestor/Manager/DisplayName]
Resolution behaviour for RequestParameter is identical to MIM's native behaviour. Only AllChangesAuthorizationTable and AllChangesActionTable are valid lookups.
The use of RequestParameter lookup is discouraged / deprecated in WAL activities in favour of [//Request/RequestParameter] lookup.
[//RequestParameter/AllChangesAuthorizationTable][//RequestParameter/AllChangesActionTable]
The Target lookup is used to access the attributes of the resource that is currently being created, modified or deleted.
The WAL extends the Target lookup by supporting create requests, not just update or delete requests.
In an AuthZ workflow that is triggered on the creation request of a resource, a WAL Target lookup is automatically substituted with the equivalent WAL Delta lookup since the newly created resource is not yet committed at this stage.
The deep resolution against the multi-valued references is also supported.
[//Target][//Target/DisplayName][//Target/Manager/DisplayName][//Target/Manager/Manager/DisplayName][//Target/ExplicitMember/DisplayName][//Target/ExplicitMember/Manager/DisplayName]
The Value lookup is used in conjunction with the Iteration feature of the WAL activities to access the current instance value of the collection over which the activity is iterating. It is also used in the Generate Unique Value activity to access the current generate value candidate for uniqueness testing.
This is a WAL-only lookup parameter and not part of the FIM / MIM lookup grammar. The Generate Unique Value activity does not support deep resolution of [//Value] lookup.
[//Value][//Value/AccountName]
The WorkflowData dictionary is a temporary storage location for information that may be required by other downstream activities within the same sequential workflow. Variables of standard types can be created on the fly here and retrieved as easily. There is no need to specify the data type during creation; it is derived from the data on-hand. Data in the dictionary is persisted along with the entire workflow during dehydration and is available again after rehydration.
The WorkflowData lookup is used to read and write to the WorkflowData dictionary.
The WorkflowData lookup resolution behaviour is similar to MIM's native behaviour, with added support for deep resolution against multivalued and single-valued reference values.
[//WorkflowData/Key][//WorkflowData/Key/DisplayName][//WorkflowData/Key/Manager/DisplayName]
- MIMWAL Site - http://aka.ms/MIMWAL
- MIMWAL Releases - http://aka.ms/MIMWAL/Releases
- MIMWAL Documentation Wiki - http://aka.ms/MIMWAL/Wiki
- MIMWAL FAQ - http://aka.ms/mimwal/faq
- MIMWAL GitHub Code Repo - http://aka.ms/MIMWAL/Repo
- MIMWAL TechNet Q&A Forum (now read-only) - http://aka.ms/MIMWAL/Forum