Sun Identity Manager 8.1 Resources Reference

Defining Actions

An action has the following structure:

<ResourceAction name=’Name’>
    <ResTypeAction restype=’ResourceType’ actionType=’Language’ timeout=’Milliseconds’>


The <act> element defines the action. It contains code that is executed on the resource. For example, the following XML defines an action for a Solaris resource:

<?xml version=’1.0’ encoding=’UTF-8’?>
<!DOCTYPE Waveset PUBLIC ’waveset.dtd’ ’waveset.dtd’>
    <ResourceAction name=’after-create’>
       <ResTypeAction restype=’Solaris’ timeout=’60000’>
          echo "$WSUSER_accountId says Hello World!"
          # exit $DISPLAY_INFO_CODE if there is not a failure, but you want
          # the output to be propagated to the UI
          #exit 0
          exit $DISPLAY_INFO_CODE

Note –

The code contained within the <act> elements is the same as seen in a UNIX script (ksh or sh) or a Windows batch script.

Using Environment Variables

Environment variables are exported and available to actions. These comprise any one of the schema-mapped attributes that have values on the user (defined in the resource schema map in the Identity System Resource Attribute column), prefixed by WSUSER_. For instance, the preceding example uses the environment variable WSUSER_AccountId, formed by preceding the AccountId attribute defined in the Solaris resource schema map by WSUSER_. These variables should be identified as environment variables within the respective shell, so that in Solaris, the variable name is preceded by $ (dollar sign).

Because OS/400 does not have variable substitution in its command language, the resource adapter looks for variable names, and carries out the substitution before transmitting the command line to the resource. To make recognition of variables possible, you must add a $ before and after a variable. Specifically, to use WSUSER_AccountId in an OS/400 script, enter the following text in the command line: $accountId$. Note the exclusion of “WSUSER”.

Example usage:

<ResTypeAction restype="OS/400" timeout="6000">

Implementing After Actions

Identity Manager only pushes changed attributes to a resource on an update. An action cannot access any attributes that have not changed. If you write an after action that requires an attribute that might be unchanged, consider the following workaround:

ProcedureAccessing Unchanged Attributes

  1. Add an extra attribute to the resource’s schema map that mimics the account attribute that you need to access. For example, if you need to access the fullname account attribute, you could create an attribute named shadow_fullname. In the Resource User Attribute column of the schema map, add the value IGNORE_ATTR. for this new attribute to prevent the adapter from trying to use it.

  2. Set the value in your user form so that the attribute is populated:

    <Field name=’accounts[ResourceName].shadow_fullname’>
  3. Reference %WSUSER_shadow_fullname% in your action so that it can get the value.

    Identity Manager never retrieves an attribute that is set to IGNORE_ATTR. As a result, Identity Manager considers the contents of an attribute such as shadow_fullname as a new value. The attribute is always pushed to the adapter and is available to after actions.

Creating an Action File

Keep the following items in mind when creating an action file.

Loading the Action File into Identity Manager

Follow these steps to import the action into Identity Manager:

ProcedureImporting the Action File

  1. Log in to the Identity Manager Administrator Interface.

  2. From the menu bar, select Configure, then Import Exchange File.

  3. Enter or browse for the XML file containing the action, and then click Import.