Overview for creating actions in variable workflow

When the inbound workflow path is completed, the appropriate variable workflow path is determined by referencing the Participant Connection This workflow path, or Action, is specified in the Console configuration process. For more information on using the Console to configure Participant Connections and variable workflows, see the Hub Configuration Guide.

An action is a number of steps, arranged in a sequence. WBI-C ships with 11 predefined actions. Should other options be required, users can customize variable workflow by defining new actions, either by developing an entirely new set of steps, placed into a new sequence or by copying an existing action and modifying it by adding a step, deleting or replacing a pre-existing step, or modifying the order of the steps.

Note: Not all WBI-C delivered steps can be used in new, user-defined actions, as they may be used for internal WBI-C specific purposes. See WBI-C supplied actions and their status as templates for more detailed information.

Actions consist of sequences of steps. Typically steps may include the following types:

Note: These steps are typical examples only. Variable workflow is designed to implement business processing logic. The logic will dictate the actual steps required.

Creating steps

Creating a step is a two part process. The actual processing logic resides in a class that implements the BusinessProcessInterface interface. But the BPE gets one of these objects by calling the getBusinessProcess method on another user-supplied class, a Factory class which implements the BusinessProcessFactoryInterface interface and takes care of constructing the processing logic object. A step is defined by a single Factory class.

Once steps have been defined, they are ordered into named sequences using the Community Console. For more information, see the Hub Configuration Guide.

As in the case of the fixed inbound handlers, fatal variable workflow processing errors should cause an update in the business document, with its state set to fail and an event set. A BCGUserException or a BCGException should also be thrown. Other events may be set as well, as needed. A listing of events available for logging issues in the Workflow stage is presented in the following API chapter.

WBI-C supplied actions and their status as templates

WBI-C ships with 11 pre-defined actions. Some, but not all of these actions, and the steps that make them up, are available for user customization. Below is a list of the supplied actions and the degree they may be utilized for user customized actions.

1. Pass through

This action can be copied and modified. The two individual existing steps may not be modified, but an additional step (for example, an XML validation step) can be prepended to the action sequence.

2. HubOwner cancellation of RN process

This action cannot be copied and modified. It is specific to the RosettaNet protocol. The ValidationFactory step in it, however can be reused in user actions.

3. RN pass through with process logging

This action can be copied and modified. As delivered, this action provides for the logging of RosettaNet document flow. It can be modified for the logging of user defined protocol document flow by replacing the initial step (ProcessLoggingFactory) with a user-defined step.

4. Bi-directional translation of RN and RNSC

This action cannot be copied and modified. It is used for RNIF messages. The ValidationFactory step can be reused in user actions.

5. Bi-directional translation of RN and XML

This action cannot be copied and modified. It is used for RNIF messages.However the ValidationFactory and the OutboundValidationFactory steps can be reused in user actions.

6. Bi-directional translation of Custom XML with validation

This action can be copied and modified. User defined steps can be substituted for the following three supplied steps: ValidationFactory, XSLTTranslationFactory, and OutboundValidationFactory.

The ValidationFactory step validates the received Custom XML document. A replacement step needs to set X_PAYLOAD_ROOT_TAG (x-aux-payload-root-tag) to the XML document name on exiting, and, if successful, place a validation successful event.

The XSLTTranslationFactory transforms the received XML document into its outbound XML format. A replacement step needs to set TRANSFORMED_DOC attribute to 'true' and return the transformed document to the business document upon exiting.

The OutboundValidationFactory validates the transformed document.A replacement step needs to set X_PAYLOAD_ROOT_TAG (x-aux-payload-root-tag) to the XML document name on exiting, and, if successful, place a validation successful event.

All of the substitutable steps above can also be used in user actions.

7. Bi-directional translation of Custom XML with duplicate check and validation

This action can be copied and modified. User defined steps can be substituted for the following three supplied steps: ValidationFactory, XSLTTranslationFactory, and OutboundValidationFactory.

The ValidationFactory step validates the received Custom XML document. A replacement step needs to set X_PAYLOAD_ROOT_TAG (x-aux-payload-root-tag) to the XML document name on exiting, and, if successful, place a validation successful event.

The XSLTTranslationFactory transforms the received XML document into its outbound XML format. A replacement step needs to set TRANSFORMED_DOC attribute to 'true' and return the transformed document to the business document upon exiting.

The OutboundValidationFactory validates the transformed document.A replacement step needs to set X_PAYLOAD_ROOT_TAG (x-aux-payload-root-tag) to the XML document name on exiting, and, if successful, place a validation successful event.

All of the substitutable steps above can also be used in user actions.In addition, the ContentDuplicateProcessFactory can also be used in user actions.

8. Bi-directional translation of Owner Custom XML to RN with duplicate check and validation

This action cannot be copied or modified. It is specific to RNIF messages. However the ValidationFactory and the ContentDuplicateProcessFactory steps can be used in user actions.

9. Custom XML pass through with duplicate check and validation

This action can be copied and modified. A user-defined step may be substituted for the ValidationFactory step.

The ValidationFactory step validates the received Custom XML document. A replacement step needs to set X_PAYLOAD_ROOT_TAG (x-aux-payload-root-tag) to the XML document name on exiting, and, if successful, place a validation successful event.

The contained ValidationFactory step and the ContentDuplicateProcessFactory step can be used in user actions.

10. Custom XML pass through with duplicate check

This action cannot be copied and modified. However the ContentDuplicationProcessFactory step can be used in user actions.

11. Custom XML pass through with validation

This action can be copied and modified. A user-defined step may be substituted for the ValidationFactory step.

The ValidationFactory step validates the received Custom XML document. A replacement step needs to set X_PAYLOAD_ROOT_TAG (x-aux-payload-root-tag) to the XML document name on exiting, and, if successful, place a validation successful event.

The contained ValidationFactory step can also be used in user actions.

Copyright IBM Corp. 2003, 2004