Deferred Attributes

A deferred attribute is an attribute that derives its value from an attribute value on a different account. You declare the deferred attribute in a view (and the WSUser model), and the provisioning engine performs this substitution immediately before calling the adapter.

If the deferred attribute derives its value from another resource’s GUID attribute, the source adapter does not need to take action. However, if the source attribute is not the GUID, the adapter must return the attribute in the ResourceInfo._resultsAttributes map as a side effect of the realCreate operation. If the adapter does not return the attribute, the provisioning engine will fetch the account to get the value. This is less efficient than modifying the adapter to return the value.

When to Use Deferred Attributes

Use deferred attributes when creating new accounts to specify that the value of an account attribute is to be derived from the value of an attribute on a different account that will not be known until the source account has been created. One common example is to set an attribute to the value of the generated unique identifier.

Using Deferred Attributes

There are two main steps to defining a deferred attribute:

To Define a Deferred Attribute

1. Ensure that the account is created on the source resource before the second account is created. Do this by creating an ordered Resource Group that contains both resources and assigning the Resource Group to the user.

2. Set the special attributes in the User view for the accounts that are to be created as indicated by the following sample scenario. Each deferred attribute requires two view attributes: one that identifies the source account, and one that identifies the source attribute. Set these using paths of the following form:

   accounts[<resource>].deferredAttributes.<attname>.resource accounts[<resource>].deferredAttributes.<attname>.attribute

   where <resource> would be replaced with an actual resource name and <attname> replaced with an actual attribute name.

   For example, assume a scenario in which the following two resources are created: 1) a resource named LDAP that generates a uid attribute when an account is created; 2)a resource named HR, which contains a directoryid attribute named directoryid, whose value is to be the same as uid in the LDAP resource.

   The following form fields set the necessary view attributes to define this association.

   <Field name=’accounts[HR].deferredAttributes.directoryid.resource’> <Expansion><s>LDAP</s></Expansion> </Field> <Field name=’accounts[HR].deferredAttributes.directoryid <Expansion><s>uid</s></Expansion> </Field>

Debugging the User View

When debugging the User view, you might find it useful to dump the contents of the view into a new file. To create a dump file, add the following Derivation statement to the User view:

<Field name=’DumpView’>
   <Derivation>
      <invoke name=’dumpFile’>
         <ref>form_inputs</ref>
            <s>c:/temp/view.xml</s>
      </invoke>
   </Derivation>
</Field>

This Derivation expression invokes the dumpFile method, which generates the file after the User form is displayed for the first time. The form_inputs variable is automatically bound to the view that is being used with this form.

In the preceding example, the String argument to the dumpFile method is a file system path, where you substitute a valid path for c:/temp/view.xml.