13.2 Common Application Rule Types

Common Application Rule Types

Objective 5.5 asks you to understand common application rule types. These are selected on an application's Rules tab. Unlike connector rules (section 13.3), they apply to all application types. examplerules.xml in WEB-INF/config contains an example of each.

Where Application Rules Fit in Aggregation

The documentation's key ordering fact: aggregation rules run after the connector has created valid ResourceObjects, which in turn happens after the connector rules have run.

Aggregation Rules

Customization rules on some objects may run more than once for the same ResourceObject, for example for the provisioning result, the plan, and the account request. Write them so that running twice gives the same result.

Provisioning Rules

Schema Rules

Some connectors support schema-level rules, separate rules for account objects and group objects. They let you keep account logic and group logic apart, instead of checking inside one rule whether a ResourceObject is an account or a group.

Related Rules Set Elsewhere

• Account Aggregation task: an optional rule to assign capabilities or perform other processing on new identities.
• Account Group Aggregation task: a Group Aggregation Refresh rule to set owners or change groups when they are created or refreshed.
• Identity Mappings: application or global rules as attribute sources (section 16.3).
• Provisioning policies: FieldValue, AllowedValues, Validation, and Owner rules (section 4.2).

Worked Example: One Application, Four Rules

An ERP application has messy data, and four rules solve four different problems:

1. Customization rule: the ERP reports locked accounts as STATUS=L. The rule sets the IdentityIQ locked flag on the ResourceObject, trims whitespace from user IDs, and returns the object.
2. Correlation rule: ERP user IDs are not stored on identities, but the ERP holds an employee number and a company code. The rule returns identityAttributeName = employeeId and identityAttributeValue = the company code plus the employee number.
3. Managed Entitlement Customization rule: new ERP roles discovered by aggregation are set to non-requestable, with the ERP owner workgroup as owner, until someone reviews them in the catalog.
4. BeforeProvisioning rule: the ERP requires a cost-center attribute on every Create request. The rule adds it from the identity when a provisioning policy cannot, for example because the value depends on the requested role.

Each rule does one job at the right point in the pipeline, and none of them duplicates work that configuration could do. That is the design the exam rewards.

Debugging Application Rules

• Turn on a logger for the rule and write log.debug statements that show the key inputs and the decision (section 14.1).
• Reproduce the problem with a single-account aggregation from the account's page, or by aggregating a small test file.
• Check the aggregation task result. Selected detail actions, such as Correlate New Account or Create New Identity, show what the rules decided.
• Watch for exceptions in Syslog (section 14.2). A rule that throws an exception can make the account fail or the task end with errors.

Choosing the Right Rule

Performance and Safety

The documentation warns that complex rules that act on every record can seriously slow aggregation. Keep per-record rules lean, cache lookups (for example, in a Custom object), avoid database queries for every account, and never commit transactions inside aggregation rules. Test in a sandbox first. A faulty correlation rule can attach accounts to the wrong identities, which is a governance incident.