Identity Manager 8.1 Deployment Reference

This section contains new information and documentation corrections for Oracle Waveset 8.1.1 Deployment Reference.

Issues Common to Both Workflows and Forms

The Forms and Workflow chapters of this guide are missing the following discussion about assigning scope to <Variable> elements: (ID-14915)

Identity Manager assigns a scope to all <Variable> elements when the element is declared. If you do not assign a value to the scope attribute, Identity Manager assigns it a value of local, which means that the variable can be accessed only within the XPRESS section that is declared in.

Additional Variable attributes that define scope include:

input -- Declares that the <Variable> element has local scope and that the value can be initialized by the caller.

output -- Declares that the <Variable> element has local scope but can be returned to the caller.

external -- Declares a <Variable> that has non-local scope - that is, assignments to this variable will result in assignment to this variable in the scope it was first declared in.

The following discussion of the Identity Manager whitelist feature is missing from this chapter. (ID-19474)

The Identity Manager whitelist feature makes it possible to check forms and workflows that use the SaveNoValidate action against a list of IDs or form names. Identity Manager checks the whitelist for either form names or form-owner IDs.) The list of IDs, called saveNoValidateAllowedFormsAndWorkflows, is located in the security attribute in the System Configuration object. If the form name or owner ID is on the whitelist, the form or workflow can use the SaveNoValidate action. If the form name or the owner ID is not on the list, the form or workflow is processed using a Save action. If the list is not present, all forms and workflows can be processed as SaveNoValidate.

To implement this feature in your deployment, you must add any forms or workflows using SaveNoValidate to the saveNoValidateAllowedFormsAndWorkflows list in the System Configuration object. To see the IDs or form names that you must add, check the syslog or turn trace level 4 on for com.waveset.ui.util.GenericEditForm and submit any custom forms or workflows that use SaveNoValidate. A warning including the ID will be logged. If you are getting “null” form names in the syslog, confirm that the form in the TaskDefinition that was run has a name attribute.

Workflow-Related Issues

The Workflow chapter is missing the following discussion of the handleNativeChangeToAccountAttributes workflow (ID-3275):

Whenever Oracle Waveset detects a native change (that is, a change not performed through Oracle Waveset) to the values of an auditable attribute of a resource account, it responds by running the handleNativeChangeToAccountAttributes workflow, which is associated with this System Configuration object attribute:

<Attribute name='process'>
  <Object>
    <Attribute name='handleNativeChangeToAccountAttributes' value='Audit Native
      Change To Account Attributes'/>
  </Object>
</Attribute>

This workflow logs the native change events to the event log if you have enabled the Changes Outside Lighthouse audit filter. Otherwise, Identity Manager ignores the event. Warning: Be careful which methods you call from any workflow that replaces the default workflow listed above.

Because Identity Manager launches this workflow whenever a resource account fetch reveals a native change, it must not invoke any method or workflow that would trigger another fetch of the same resource account. For example, an infinite loop will result if you call any WorkflowServices method that assembles the user view: getView(User),checkoutView(User) and possibly checkinView(User).

The fact that Identity Manager handles each native change by running a workflow allows you to hook the native change event, and to handle that native change however you see fit by replacing or adding to the default native change workflow. For example, you might choose to send email to an administrator or a user, to record the event in a database, to queue an update that would back out the native change, or even to pull that native change into and push it back out to the other resources.

The Workflow chapter of this guide is missing the following description of how to specify the subject or administrator of a source adapter task. (ID-19694).

You can assign a subject or administrator to a Source adapter task and designate the server on which it runs by editing the following attributes of the system configuration object. source.subject specifies the login name of administrator designated as the owner of this task. sources.host specifies the server on which the task runs. The new values in the configuration object are by default:

<Attribute name='sources'>
           <Object>
             <Attribute name='hosts'/> <!-- any host is the default -->
           <Attribute name='subject' value='Configurator'/>
         </Object>
         </Attribute>