Form Models

Form models are used to simplify that process of passing values between the workflow variables and the form. Form models enable the specification of a Map through which a set of variables can be handed to the form by the workflow. The model is defined in the workflow (or predefined model is used), enabling the workflow and form to pass a collection of variables at one time through the specified model. The form renderer is set up to use the model so form fields can name the desired attribute directly without having to reference the model name as well.

Since actions in workflows often center around Identities, a map for the identity object, called IdentityModel, is prebuilt in IdentityIQ. A workflow library method, getIdentityModel, can be called by a workflow step to create an IdentityModel map to use in a subsequent step that renders a form. To create an empty map, call this method with no arguments. To prepopulate the map with an identity's current values, specify an identity name or ID as an argument to the step. This method is used with no arguments in the new self-service registration workflow to prepare to create a new identity from the data the user enters on the form.

For an example of the simplification offered by a form model: A workflow form needs to display and permit the user to edit 10 identity attributes. Without form binding, all 10 would have to be defined as individual business process variables and all 10 would have to be sent to and returned from the approval in the workflow. The form would also require all 10 to be defined as form arguments. With a model, the whole Identity can be automatically stored in a single business process variable with a single method call, only one variable (identityModel) must be passed to and returned from the form, and no form arguments need to be defined at all.

Use these steps to use the IdentityModel in a workflow form:

  1. Go to Setup > Business Process > Process Variables tab.

  2. Define a process variable in the workflow (identityModel).

  3. In an early step in the workflow, initialize and populate the identityModel by calling the getIdentityModel method in the IdentityLibrary workflow library. Specify the identityModel process variable as the Result Variable for that step.

    To pass an identity name or ID to the method, specify it as an argument to the step (identityName or identityId).

  4. In the approval that contains the form, create an argument called workItemFormBasePath and specify the identityModel process variable as its value. The form base path is understood by the form renderer and is automatically applied to permit the form access to the map fields. This enables the passing of the model to and from the form.

  5. Reference the components of the identityModel in the form as though they were passed as individual variables, for example, as "firstname," not as "identityModel.firstname."

    6. Note: When a base path is specified as a form argument, the form renderer assumes all fields on the form are accessed through that base path, so all attributes to be included in the form or returned from it must be included in the model.

    Copy 
    <Section>
    <Field displayName="user_name" name="name" required="true" type="string"/>
    <Field displayName="first_name" name="firstname" required="true" type="string"/>
    <Field displayName="last_name" name="lastname" required="true" type="string"/>
    <Field displayName="email" name="email" required="true" type="string"/>…

  6. (Optional) To provision changes to the identity based on the form, call the buildPlanFromIdentityModel() method in the Identity Library. This examines the versions of the model passed to the form and back from it, identifies differences between them, and creates a provisioning plan to make the required changes.

Refer to the LCM Registration workflow, which ships with IdentityIQ Lifecycle Manager, for a full example of implementing the identityModel.

No other models currently ship with the product, but custom models can be created through some manual coding in the initialization stage.

  1. Declare the model variable as a process variable (same as the identityModel), for example appModel.

  2. Initialize the model manually, since no library method exists to populate custom models. Instead of a method call in the initialization step, the step executes a script or rule written to populate the desired data into a HashMap that is stored in the custom model variable.

  3. Specify the custom model variable as the workItemFormBasePath argument to the workflow's form step.

  4. Reference components in the custom model by name in the form. As with identityModel, no reference to the base path should be specified in the form field names.