64 Configuring Event Notification

This chapter provides instructions on configuring event notifications. Event notifications keep Content Integration Platform administrators informed about the synchronicity of source and target systems as changes to content are made on either system.

This chapter contains the following sections:

64.1 Overview of Event Notification

Event-driven notices are delivered to administrators in a simple workflow process which can be enabled globally or selectively for specific events (such as item creation) and for specific types of items.

Note:

If you choose to configure CIP for event notification, you must do so before publishing objects to WebCenter Sites or archiving assets to Documentum. For instructions, see Section 64.2, "Configuring Event Notification Workflows for WebCenter Sites" and Section 64.3, "Configuring Event Notification Workflows for EMC Documentum."

64.2 Configuring Event Notification Workflows for WebCenter Sites

In the CIP publishing model, event notification is the process of informing CIP administrators of actions that occur on WebCenter Sites when changes are made to monitored workspaces - cabinets or folders - on Documentum.

Monitoring of a workspace begins once its metadata and associated objects are first published to WebCenter Sites via the cipcommander publish command. The synchronization engine starts listening to the workspace for changes to content and automatically replicates them to WebCenter Sites, where they are treated as events. If event notification is configured, the events invoke WebCenter Sites workflows to send notices confirming the events. Failed events also trigger notices if the associated workflows are configured. Table 64-1, "Default workflows for WebCenter Sites" lists the supported events and default workflows.

Table 64-1 Default workflows for WebCenter Sites

Event in WebCenter Sites Workflow Process

Asset creation

CIPAssetCreated . Invoked when an object is created in a monitored cabinet or folder and the counterpart asset is created in WebCenter Sites.

Asset deletion

CIPAssetDeleted . Invoked when an object is deleted from a monitored cabinet or folder and the counterpart asset is deleted from WebCenter Sites.

Asset deletion failure

CIPAssetDeletionFailed . Invoked when:

  • An object that was deleted from the monitored cabinet or folder is checked out on the WebCenter Sites system.

  • An object that was deleted from the monitored cabinet or folder has dependencies that would become unresolved on the WebCenter Sites system if the counterpart asset were to be deleted.

Asset modification

CIPAssetModified . Invoked when an object in the monitored cabinet or folder is modified and the counterpart asset is created in WebCenter Sites.

Asset modification failure

CIPAssetModificationFailed . Invoked when an object in the monitored cabinet or folder is modified, but its counterpart asset is checked out in WebCenter Sites.


Default workflows have the following properties:

  • Default workflows consist of one state and two steps. When an event occurs, only the first step of the corresponding workflow is taken. If the option Assign from list of participants is selected, all members with the selected roles are assigned the first task.

  • All supported events trigger notices to users with role CIPAdmin . Tasks may or may not be assigned, depending on the event:

    • A task is assigned for the following events: creation, deletion failure, modification, and modification failure. The task is simply a way of notifying the user whether an event occurred or failed on WebCenter Sites. The task can be removed; there is no obligation to take a step.

    • For deletion events, no task is assigned (the asset no longer exists).

Note:

Although workflows related to the publishing processes can be created, it is typically more convenient to use workflows that are provided with CIP. If you wish to create your own workflows, refer to Chapter 10, "Creating and Managing Workflow Processes."

This section contains the following topics:

64.2.1 Installing Default Workflows on WebCenter Sites

To install default workflows

  1. Run catalogmover.bat (or catalogmover.sh on Linux) from the WebCenter Sites installation directory.

  2. Go to Catalog, then Auto Import Catalog(s) .

    1. Select workflows.zip (in the same directory or level as all cs_*_schema.zip files).

    2. In the import dialog, fill in the fields as shown below:

      Catalog Data Directory: Leave the default value

      Catalog ACL List: Browser, SiteGod, xceleditor, xceladmin

  3. Create the default workflows by invoking the following URL:

    http://<host>:<port>/<context_path>/ContentServer?pagename=OpenMarket/Xcelerate/Installation/CIPCreateWorkflows&username=<username>&password=<password>

    where:

    • <host> is the address of the WebCenter Sites installation

    • <port> is the port of the WebCenter Sites installation

    • <context_path> is the context path where the WebCenter Sites web application is deployed

    • <username> is the WebCenter Sites administrator's user name

    • <password> is the WebCenter Sites administrator's password

    For example, the URL of the default configuration is:

    http://localhost:8080/cs/ContentServer?pagename=OpenMarket/Xcelerate/Installation/CIPCreateWorkflows& username=fwadmin&password=xceladmin

    When the workflows are created, the following message is displayed:

    "Workflows for Content Integration Platform were created successfully"

64.2.2 Verifying the Installation of Default Workflows

When the default workflows are created, associated items (such as roles and email objects) are also created in WebCenter Sites.

To verify default workflows and their associated items

  1. Log in to the WebCenter Sites Advanced interface as a general administrator (default credentials: fwadmin / xceladmin ).

  2. Verify that the following items have been created:

    • CIPAdmin role, which will be used as the management role in all CIP workflows. All users with the CIPAdmin role will be notified of all CIP events in the default workflows.

    • Workflow processes:

      CIP Asset Created, CIP Asset Deleted, CIP Asset Deletion Failed, CIP Asset Modified, and CIP Asset ModificationFailed

    • Workflow states:

      CIP Asset Created, CIP Asset Deleted, CIP Asset Deletion Failed, CIP Asset Modified, and CIP Asset Modification Failed

    • Workflow step action:

      CIP Asset Deleted, which results in an email notice to the CIP administrators.

    • Email object: CIP Asset Event

64.2.3 Enabling Default Workflows

Default workflows are pre-configured in the default mappings.xml file. Each listed asset type contains a commented workflow configuration section.

To enable a CIP workflow

  1. Open mappings.xml (on the Content Integration Agent host), go to the section <mapping id= "documentum2cs"> and uncomment the required workflows (below) for each asset type that must be enabled for event notification:

    <param name="assetCreatedProcess">CIPAssetCreated</param>
    <param name="assetModifiedProcess">CIPAssetModified</param>
    <param name="assetDeletedProcess">CIPAssetDeleted</param>
    <param name="assetDeletionFailedProcess">CIPAssetDeletionFailed</param>
    <param name="assetModificationFailedProcess">CIPAssetModification Failed</param>
    
  2. Assign the CIPAdmin role to CIP administrators. Verify that CIP administrators are able to receive email. For instructions, see Section 5.5.1, "Creating and Editing a User Profile."

  3. If a relatively large number of events occur on the source system, it is best to use workflow groups, as they allow you to resolve tasks in bulk. Workflow groups are not packaged by default. They must be created manually. For instructions, see Chapter 10, "Creating and Managing Workflow Processes."

Note:

If a workflow group has the name of the invoked workflow process, the workflow process will be automatically added to the group.

64.3 Configuring Event Notification Workflows for EMC Documentum

In the archival model, event notification is the process of informing CIP administrators of actions that occur in Documentum folders when changes are made to monitored CS DataStores.

Monitoring of a CS DataStore begins when its metadata and associated files are first archived to Documentum via the cipcommander publish command. The synchronization engine starts listening for changes to the content of the CS DataStore and automatically replicates them to the Documentum target folders, where they are treated as events. If event notification is configured, the events invoke Documentum workflows to send notices confirming the events. Table 64-2, "Event Notification Workflows for the Archival Process" lists the supported events.

Table 64-2 Event Notification Workflows for the Archival Process

Event in Documentum Workflow

Object creation

Invoked when a new asset is created in the CS DataStore and its counterpart object is created in Documentum.

Object modification

Invoked when an asset is modified in the CS DataStore and its counterpart object is created in Documentum.


Note:

Event notification related to the archival process requires you to create or reuse Documentum workflows.

To enable notification workflows for archival events

  1. Create your own workflow processes in Documentum or re-use workflow processes. Define the packages as necessary.

  2. Open mappings.xml and go to <mapping id= "csds2documentum"> .

    1. Uncomment the required workflow processes and packages (below) for each asset type that must be enabled for event notification:

      <param name="objectCreatedProcess">ProcessName</param>
      <param name="objectModifiedProcess">ProcessName</param>
      <param name="objectCreatedPackage">PackageName</param>
      <param name="objectModifiedPackage">PackageName</param>
      
    2. Replace ProcessName with the name of the workflow process that should be automatically started.

    3. PackageName is an optional parameter. If PackageName is not specified, an asset will be placed into the first available package.