Configuring custom plug-ins

You can write your own code that WSRR calls automatically during standard processing. You implement your code in a Java™ class referred to as a WSRR custom plug-in.

About this task

Custom plug-ins are called whenever any of the following actions take place:

Creating an object
Updating an object
Deleting an object
Transitioning an object from one lifecycle state to another
Making an object governable
Removing governance from an object

The following plug-in types can be installed in WSRR:

Validation plug-ins are called before certain registry operations take place and provide hooks for you to validate and potentially modify the content and properties of objects stored in the registry; avoid creating new objects from a validation plug-in unless absolutely necessary. You can also return errors from a validation plug-in to prevent registry operations from completing. In the case of a document creation operation, the validation plug-in is called before any logical objects have been derived from the document content and does not, therefore, have access to these objects.
Modification plug-ins are called after the WSRR database updates associated with the original action have been committed, but before the associated transaction has been committed. You can therefore modify objects in the registry. If a modification plug-in reports a failure then the transaction is rolled back. This means that neither changes made by the modification plug-in, nor changes made by the original action, will take effect. In the case of a document creation operation, the modification plug-in is called after any logical objects have been derived from the document and therefore has access to these objects.
Notification plug-ins are called after certain registry operations have taken place and provide hooks for you to record or act on the results of those operations. Do not create or update objects from a notification plug-in. A notification plug-in cannot roll back the associated transaction.
WSDL parser extension plug-ins are called during the processing of a WSDL document when WSDL extensibility elements are encountered. They allow information associated with those elements to be stored in the registry.

The following sequence diagram shows the order in which custom plug-ins are called when any client initiates an action:

Note that the entire sequence described in the diagram takes place in a single transaction.

If you configure two or more plug-ins of the same type, they are called in the order in which they are listed in the corresponding plug-in properties file, reading from left to right.

If your modification plug-in initiates another action, the creation of a new object for example, this will trigger a nested plug-in calling sequence. For example, you configure the following plug-ins:

Plug-in	Plug-in type	Description
StoreValidationDate	Validation	Adds a property to a new object, or updates a property on an existing object, whose value is the date and time at which the validation occurs.
CreateBusinessObject	Modification	If the action is the creation of a new WSDL document object, this plug-in creates a new business object that has a relationship referencing the WSDL document. For any other action, the plug-in does nothing.
LogActivity	Notification	Records the action in an activity log file.

If a client then loads a new WSDL document into WSRR, the following sequence occurs:

StoreValidationDate is called; this adds a property to the WSDL document object.
CreateBusinessObject is called. This creates a new business object, with a relationship to the WSDL document. The creation of the new object triggers a nested plug-in calling sequence as follows:
1. StoreValidationDate is called; this adds a property to the business object.
2. CreateBusinessObject is called; this does nothing.
3. LogActivity is called; this logs the creation of the business object.
LogActivity is called; this logs the creation of the WSDL document object.

There are two stages in implementing a WSRR plug-in:

Procedure

Write the plug-in class. This is described in Developing plug-ins by using the System Programming Interfaces.
Deploy the plug-in. This is described in the following subtopics: