Overview for creating actions in variable workflow
When the inbound workflow is completed, the appropriate variable workflow path is determined by referencing the participant connection. This variable workflow, or action, is specified in the console by the hub administrator while creating the interactions. 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. WebSphere
Partner Gateway ships with 11 predefined actions. If other options are required, you can customize a variable workflow by defining new actions. You can do this in either of two ways:
- Developing an entirely new set of steps, placed into a new sequence
- 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 steps delivered by WebSphere Partner Gateway
can be used in new, user-defined actions. Some are used by WebSphere Partner Gateway for
internal purposes. For more detailed information, see Actions
supplied by WebSphere Partner Gateway
Actions consist of a series of steps, the sequence of which is
configured through the console, as shown in Figure 8.
The steps can be reused across the actions.
Figure 8. Creating an action by configuring a sequence of steps
You can also create multiple actions by using the same set of
steps but by specifying a different sequence. Note that reusability
of steps depends on their intended use and their dependency on other
steps.
While running the action (the variable workflow), BPE runs these
steps one after the other in the sequence these steps are specified
for this action. Steps of an action implement the BusinessProcessInterface class. BPE runs the process method of the steps. After running each step, BPE logs the
events generated by this process method. BPE then checks the status of the business document.
If its status is marked as failed, BPE fails the flow of business
document. The next step is run only if the business document status
is not marked as failed.
Typically steps include the following types:
- Validation
- Checking the form of the business document. For example, an
XML document can be validated against an XML schema.
- Transformation
- Changing the form of the business document. For example, an XML document can be transformed into a different XML document using XSLT.
- Translation
- Changing the entire format of a business document from one
type to another. For example, an XML document can be transformed into CSV (comma separated value) format.
Note: These steps are typical examples only. The actual
steps depend on your business protocol requirements.
Creating steps
To create a step:
- Create a class that implements BusinessProcessFactoryInterface. This class is factory class for constructing objects of
type BusinessProcessInterface, which represents the steps of variable workflow.
- Implement the BusinessProcessFactoryInterface.getBusinessProcess method. This method constructs an object of type BusinessProcessInterface, which can process the business document.
- Implement the BusinessProcessFactoryInterface.returnBusinessProcess method. This factory may reuse or discard the BusinessProcessInterface object that is being returned.
- Create a class that implements BusinessProcessInterface. This class is the actual step.
- Implement the BusinessProcessInterface.process method. Implement the processing logic of the step here.
This method should also perform following actions:
- Add events to the BusinessDocumentInterface object. You can do this by calling the addEvent method. These events will be visible in the console with this
business document. For a list of events that you can add in this
step, see Events.
- Update the status of the BusinessDocumentInterface object. If there were any errors, mark BusinessDocumentInterface as failed by calling the setDocumentState method with the BCGDocumentConstants.BCG_DOCSTATE_FAILED argument.
- Implement the BusinessProcessInterface.reset method. If this factory is caching BusinessProcessInterface objects, it may call this method to reset the state of a BusinessProcessInterface object. Then you can reuse the BusinessProcessInterface object.
- Create a deployment descriptor for this step. For information
on how to deploy your step, see Development and deployment.
- Upload your step by using the console.
Figure 9. Using the console to upload a step
Now you can use this step for creating your actions.
Actions
supplied by WebSphere Partner Gateway
WebSphere Partner Gateway ships with 11 predefined actions.
Some, but not all, of these actions and the steps that make them
up are available for you to customize. 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. Steps can be pre-pended
or appended to the action sequence.
2. HubOwner cancellation of RN process
This action cannot be copied and modified. It is specific
to the RosettaNet protocol.
3. RN pass through with process logging
This action can be copied and modified. You can append steps to the action sequence.
4. Bidirectional translation of RN and RNSC
This action cannot be copied and modified. It is used
for RNIF messages.
5. Bidirectional translation of RN and XML
This action cannot be copied and modified. It is used
for RNIF messages.
6. Bidirectional 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. Additional steps can be pre-pended or appended. The supplied steps perform the following actions:
- ValidationFactory
- Validates the received custom XML document.
- XSLTTranslationFactory
- Transforms the received XML document into its outbound XML format.
- OutboundValidationFactory
- Validates the transformed document.
The steps cannot be used in other user actions outside of the
context of a copied action.
7. Bidirectional 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. Additional steps can be pre-pended or appended. The supplied steps perform the following actions:
- ValidationFactory
- Validates the received custom XML document.
- XSLTTranslationFactory
- Transforms the received XML document into its outbound XML format.
- OutboundValidationFactory
- Validates the transformed document.
The steps cannot be used in other user actions outside of the
context of a copied action.
8. Bidirectional 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.
9. Custom XML pass through with duplicate check and validation
This action can be copied and modified. Additional steps
can be pre-pended or appended.
10. Custom XML pass through with duplicate check
This action cannot be copied and modified. Additional
steps can be pre-pended or appended.
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.
