Initialization Script or Rule

The initialization script and rule allow the report developer to customize a report to address an installation's unique reporting requirements. These scripts/rules are fairly open-ended and should generally be considered tools for expert-level report creation.

Most often, initialization scripts and rules are used to customize the forms presented to the user for filter specification. For example, several standard reports use an initialization rule to build dynamic forms to present all of the installation's configured Identity attributes - both standard and extended - as filter options on some forms. Another form customization usage might be to change the set of filters available based on other filter selections; for example, a report might present a "privileged" account filter option only when the application selected for the "Application" filter has privileged accounts.

For an overview of developing and using rules in IdentityIQ, see Rules and Scripts in IdentityIQ.

An InitializationScript is specified inline within a <Source> element:

Copy

<InitializationScript>
   <Source>
     import sailpoint.object.*;
     import sailpoint.reporting.ReportingLibrary;
     … (initialization code goes here; see rule example below)
   </Source></InitializationScript>

An InitializationRule is specified as a rule reference with the code encapsulated in the named rule:

Copy

<InitializationRule>
    <Reference class="sailpoint.object.Rule" id="4028460238ed9b8e0138ed9bf6130000" name="Identity Report Form Customizer"/>
</InitializationRule>

The rule shown below is used in several of the standard reports (such as the User Detail Report and Identity Roles Report) to customize a form based on the standard and extended Identity attributes configured for the installation. Similar rules exist to create custom forms for other reports.

Copy

<Rule language="beanshell" type="ReportCustomizer" name="Identity Report Form Customizer">
 <Description>
    This rule populates a form with fields for the standard and extended identity attributes.
  </Description>
  <Signature returnType="Map">
    <Inputs>
      <Argument name="locale">
        <Description>
          The current user's locale
        </Description>
      </Argument>
      <Argument name="report">
        <Description>
          The base report
        </Description>
      </Argument>
    </Inputs>
    <Returns>

    </Returns>
  </Signature>
  <Source>
     <![CDATA[
     import sailpoint.object.*;
     import sailpoint.reporting.ReportingLibrary;

     ObjectConfig identityConfig = ObjectConfig.getObjectConfig(Identity.class);
     // Add standard attributes to the form

     List standardAttributes = new ArrayList();
     standardAttributes.add(identityConfig.getObjectAttributeMap().get("firstname"));
     standardAttributes.add(identityConfig.getObjectAttributeMap().get("lastname"));
     standardAttributes.add(identityConfig.getObjectAttributeMap().get("displayName"));
     standardAttributes.add(identityConfig.getObjectAttributeMap().get("email"));
     standardAttributes.add(identityConfig.getObjectAttributeMap().get("manager"));
     standardAttributes.add(identityConfig.getObjectAttributeMap().get("inactive"));

     ReportingLibrary.addAttributes(context, report, Identity.class, standardAttributes, null, "Identity Attributes", locale);

     // add extended attributes to the form (multi-valued and regular)

     List extendedAttrs = new ArrayList();
     for(ObjectAttribute att : identityConfig.getSearchableAttributes()){
       if (!att.isStandard())
         extendedAttrs.add(att);
     }

     for(ObjectAttribute att : identityConfig.getMultiAttributeList()){
         extendedAttrs.add(att);
     }

     ReportingLibrary.addAttributes(context, report, Identity.class, extendedAttrs, null, "Identity Extended Attributes", locale);

    ]]>
</Source>
</Rule>

The methods in the ReportingLibrary (like the one used in this example rule) are documented in the IdentityIQ Javadocs. The addAttributes method, for example, does the following:

Determines the form page where the attributes should be displayed (selects by section name, creates a new page based on the section name if not found, or selects the first page after Standard Properties if no section is specified)
Adds each attribute as an extended argument to the LiveReport object
Adds each attribute to the datasource QueryParameters list as a Parameter
Defines a Field object for each attribute and adds it to the Section

These methods can be used in custom report development, but note that it is possible that they could change in future versions of IdentityIQ, requiring those reports that rely on them to be revisited and modified. Alternatively, the code to add the attributes to the query parameters and form fields list can be explicitly written by the datasource developer.

Note: When an initialization script/rule is in place, if any of the functionality depends on the value of a specific form field, that field must be specified with the postBack attribute set to true (postBack= "true"); this causes the form to submit and reload when that value changes, and causes the initialization rule or script to execute again, picking up the new value for the field.

Signature Extended Arguments

When the initialization script or rule adds new fields to a report form, the values must be saved for any report instance for which they were specified, and they must be passed to the report at runtime to be used as report filters. This is done by adding them as extended arguments in the report definition; from there, they are automatically stored in the report instance's argument map when the report instance's TaskDefinition is saved. Even though these arguments do not exist in the report template's signature, they are generated at runtime by the initialization script and the values from the template's argument map are applied for the report's execution.

Note: This only works for these initialization-generated attributes; all static form fields must be explicitly specified in the report template's signature for them to be used in the report generation. Attributes that are included in the report instance's attribute map that do not exist in the report signature and are not generated by the initialization script or rule is not applied to the report as filters at runtime.


	You are here: