EventBasedContextProcessing
Sample workflow for handling a change event for a context entry.
EventBasedContextProcessing reacts to change events published for context entries
(dxrContext) in the Identity Store. When a client creates, modifies or deletes a context
business object, the Java-based Server passes the event to the join activity, which applies
the consistency rules from consistencyrulesroot to the changed context and propagates the
effects to related entries in the domain.
Deploying this workflow allows you to react to context changes in real time instead of waiting for a scheduled consistency check.
The workflows in this reference are delivered as factory data and are loaded into the Connectivity configuration database during the initial configuration. They are samples: use the Identity Manager to copy a workflow into your own scenario and adapt the copy. Do not change the delivered objects, because a product update can replace them.
At a Glance
Name |
|
Category |
Identity Store |
Technology |
Java-based real-time workflow |
LDAP object class |
|
Workflow type |
|
Connected system / controller type |
|
Configuration wizard |
|
Active in the factory data |
FALSE |
Factory data version |
8.0 |
Factory data path |
|
Prerequisites
-
The Identity Store domain event policy must be configured to publish events for
dxrContextentries. -
The consistency rules referenced by
consistencyrulesrootmust exist in the Identity Store. -
Copy the workflow into your scenario, set
tsclusterandtsresourceto match your server and domain root, and activate the copy in the Java-based Server.
Workflow and Activities
| Activity | Type | Component description | Description | Ports |
|---|---|---|---|---|
|
|
|
Error Activity |
|
|
|
|
Activity for processing a change event for a context business object. |
- |
Ports
| Activity | Port | Component description | Connector | Connected directory | Bind profile | SSL |
|---|---|---|---|---|---|---|
|
|
|
|
- |
- |
not set |
Configuration Parameters
| Parameter | Default value |
|---|---|
|
P0Y0M4DT0H0M0S |
|
<server-name> |
|
cn=My-Company |
| Parameter | Default value |
|---|---|
|
LDAP |
|
3 |
|
P0Y0M1DT0H0M0S |
|
P0Y0M0DT2H0M0S |
| Parameter | Default value |
|---|---|
|
dxmPassword |
| Parameter | Default value |
|---|---|
|
cn=domain_name,cn=Rules,cn=Policies,cn=domain_name |
|
cn=My-Company |
|
Event_Maintenance |
|
3 |
|
TRUE |
|
cn |
|
P0Y0M1DT0H0M0S |
|
P0Y0M0DT0H30M0S |
A Java-based real-time workflow runs as a permanently loaded configuration in the Java-based Server (IdS-J). It is triggered by a request or an event rather than by a schedule. Each workflow consists of activities; an activity opens one port per system it talks to, and each port uses a connector to reach that system.
Most provisioning workflows contain a join activity that performs the actual work and an error
activity that receives requests which still fail after all retries and sends a notification about
them. The retrylimit, waitbeforeretry and timeout parameters of an activity control how often
and how long a failed request is retried before it is handed to the error activity.
The event port publishes change events over JMS, and the notify port sends e-mail notifications.
Neither port is bound to a connected directory.
The workflow has two activities. The join activity uses the resolutionActivity component to
apply the consistency rules from consistencyrulesroot to the changed context entry and
propagate any follow-on effects to related objects in the domain. Failed requests are retried up
to retrylimit (3) times; persistent failures are passed to the error activity, which sends
a notification by e-mail through the Message port.
Operation
-
A client creates, modifies or deletes a context entry in the Identity Store and the event policy publishes a
dxrContextchange event. -
The Java-based Server matches the event against the
tsclusterandtsresourceparameters of this workflow and passes the request to thejoinactivity. -
The activity applies the consistency rules from
consistencyrulesrootto the changed context entry and propagates the effects to related entries in the domain. -
Failed requests are retried up to three times; requests that still fail are handed to the
erroractivity for e-mail notification. -
The workflow is delivered inactive (
dxmActiveisFALSE). Copy it into your own scenario, configuretscluster,tsresourceandconsistencyrulesroot, and activate the copy.