|
|
Using Workflows with RosettaNet
The following sections explain how to develop workflows to implement RosettaNet Partner Interface Processes (PIPs).
The procedures in this section refer to workflow diagrams as they appear in the WebLogic Integration Studio. To access a workflow diagram, start Studio as described in "Starting Studio" in WebLogic Integration Administration and Design Tools in Starting, Stopping, and Customizing BEA WebLogic Integration. For information about defining collaborative workflows for use in B2B applications, see Creating Workflows for B2B Integration.
Understanding RosettaNet
The following RosettaNet documents are required reading if you want to implement your own PIP using the support for RosettaNet provided by WebLogic Integration, and recommended reading if you want to fully understand the sample RosettaNet PIP implementations:
Understanding PIP Workflow Instances
WebLogic Integration implements standard RosettaNet PIPs through public workflows (also know as collaborative workflows). A public workflow provides the interface to other trading partners, while private workflows are used to interface to back-end systems in order to generate and respond to messages.
The following figure shows the process by which PIP workflows pass messages between trading partners.
Figure 2-1 Message Workflow
Generally speaking, RosettaNet-oriented workflows process messages as follows:
Getting Started
While most RosettaNet workflow development tasks are identical to those used for developing standard XOCP-oriented workflows, there are some differences. The standard procedures are documented in Creating Workflows for B2B Integration; you should refer to them before creating RosettaNet workflows.
WebLogic Integration includes full implementations of PIP0A1 and PIP3A2 for both RosettaNet 1.1 and 2.0.These templates provide a useful template base that you can use when creating additional PIP workflows.
The remainder of this section discusses issues involving the creation of RosettaNet-specific workflows.
Working with Workflows
In WebLogic Integration, RosettaNet PIPs are public workflows that implement a trading partner's role in the exchange of messages via the B2B engine. These workflows are designed to work with private workflows that:
The procedures you need to configure a private workflow to start a public workflow, or to configure a public workflow to start a private workflow, are provided in Starting Collaborative Workflows in Creating Workflows for B2B Integration.
RosettaNet Workflow Variables
RosettaNet workflows implemented in the WebLogic Integration Studio require a number of workflow variables to operate. These variables are used in three ways:
All RosettaNet workflows, regardless of the PIP role implemented, must include the same basic set of System, Input, and Output variables. The required variables are organized into tables by RNIF version in the following sections:
Using the Workflow Variable Tables
For each workflow variable, the name and type (boolean, string, integer, xml, or object) are identified. In addition, variable usage and description are provided as described in the following sections.
Usage
The workflow variables are organized into the following usage categories:
An important point to note when using these workflow variables is that all input variables must be initialized when you start a public workflow. The values used to initialize the input variables do not need to be exposed or transmitted.
The required workflow variables include specification of the NOF parties. These parties are the trading partners that will handle the PIP exceptions. An NOF party may be a participant in the original PIP or a 3rd party.
Description
A brief description of the variable is provided. Where relevant, the variable description includes the element of the RosettaNet Object (RNIF 1.1) or RosettaNet Business Message (RNIF 2.0) to which the variable maps. For example, the Input variable GlobalUsageCode maps to:
ServiceHeader/ProcessControl/GlobalUsageCode
Here, the slashes indicate position in the hierarchical element structure as follows:
<ServiceHeader>
<ProcessControl>
<GlobalUsageCode>Value</GlobalUsageCode>
. . .
</ProcessControl>
. . .
</ServiceHeader>
Workflow Variables for RNIF 2.0
Table 2-1 describes the required template variables for RNIF2.0 PIP workflows. Additional, PIP-specific Input and Output variables may also be required. Refer to the message guideline and XML document type definition (DTD) for the specific PIP.
Table 2-1 Template Variables for RNIF2.0
Workflow Variables for RNIF 1.1
Table 2-2 describes the template variables for RNIF1.1 PIP workflows. Additional, PIP-specific Input and Output variables may also be required. Refer to the message guideline and XML document type definition (DTD) for the specific PIP.
Table 2-2 Template Variables for RNIF1.1
Consolidated rnSystem Variable
In WebLogic Integration 2.0, the following variables were also required.
signalCode
signalCodeVersion
inReplyToActionCode
inReplyToMessageId
initiatingPartnerDUNS
inReplyToActionCodeVersion (RNIF2.0 only)
These variables have been replaced by the consolidated rnSystem variable (workflow variable type: Java Object), to reduce the number of system variables exposed in a workflow template.
If you have PIP workflows that were developed for WebLogic Integration 2.0, you can remove invocations or definitions of these variables from existing workflow templates and replace them with rnSystem.
Receiving a RosettaNet Message
WebLogic Integration supports two different methods of receiving RosettaNet messages-----Start nodes and Event nodes. These two different node types are used depending on the circumstances under which the message is received.
Start Nodes
You can configure a workflow so that WebLogic Integration starts it automatically when WebLogic Integration receives the first message for a PIP instance. To configure this action, declare received PIPs as Start node events. Your receiving workflow starts and processes the incoming PIP. For an example, see the Participant Workflow discussion in Starting Collaborative Workflows in Creating Workflows for B2B Integration.
The PIP3A2 Supplier workflow template serves as an example of how to configure a workflow template definition to be started by an incoming message. In this example, the starting event is set as a Business Message Event. The workflow is automatically started and the output and system variables are set when a RosettaNet message has been received.
Event Nodes
Workflows can contain events that are triggered when a message is received for the PIP instance associated with the workflow. For an example, see the Initiator Workflow discussion in Starting Collaborative Workflows in Creating Workflows for B2B Integration.
Implementing Timeouts
Workflows can use an optional timeout path to wait for an incoming RosettaNet message. If the workflow waits for a response to a sent message (for example, the 3A2 Buyer workflow), you must create a separate timeout path to wait for the response. This path, illustrated in the 3A2 Buyer workflow template, consists of a timer, set for the appropriate timeout period, and a stop node.
Out of Sequence Reception of Signals
RNIF 1.1 and RNIF 2.0 define different standards for reception of signals and replies. These differing standards affect how your PIP workflow resolves these messages.
RNIF 1.1 specifies that replies must always follow signals. Thus, you might see a signal/response pattern as follows:
RNIF 2.0 allows out-of-sequence receipt of signals. For example, a workflow might receive a reply before the receipt acknowledgment. Thus, RNIF 2.0 allows a signal/response pattern such as the following:
This pattern must be processed accurately in your workflow design. The PIP3A2 Customer workflow template provides a useful example of how to handle this. The RNIF 1.1 version of the PIP template processes the signal, followed by the response. The RNIF 2.0 version provides logic to process the signal and the response separately.
Sending a RosettaNet Message
A workflow task can send a RosettaNet message by invoking an integration action called Send Business Message. To add this action to a task:
The Task Properties dialog box is displayed.
Figure 2-2 B2B Integration Actions
Click OK to display the Send Business Message dialog box as shown in the following figure.
Figure 2-3 RosettaNet 2.0 Send Business Message Dialog
The information required is dependent on the Message Type (Action, Exception, or Receipt Acknowledgment) you select. The following table summarizes the information you are prompted for by message type.
Table 2-3 Message Types and Options
Validating a Message
The message validation process uses the Xerces 1.3 DOM parser, which supports an alpha implementation of the XML Schema specification. The Xerces 1.3 DOM parser is packaged with the WebLogic Server 6.1 software.
The following sections describe how WebLogic Integration validates RosettaNet messages and provide a bibliography for further reading about message validation:
RosettaNet Message Validation
WebLogic Integration provides message validation services for both RNIF 1.1 and RNIF 2.0 messages. The validation performed is dependent on the values specified for the validateServiceContent, validateServiceHeader, and useDTDValidation workflow variables. You have the following validation options:
For an explanation of the exception handling process, see the RNIF specification at the following URL:
http://www.rosettanet.org
Example XML schema files and document type definition (DTD) files are located on your WebLogic Integration installation at:
WLI_Home/lib/xmlschema/rosettanet
Recommended Reading About Message Validation
The following information is recommended reading to fully understand the example XML schemas; it is required reading if you are planning to implement your own XML schemas:
http://www.w3.org/XML/Schema
XML Schema Part 0: Primer provides good descriptions of the features and capabilities of XML schema.
http://xml.apache.org/xerces-j/schema.html
Performance Tuning and Message Validation
Message validation is used primarily while setting up and configuring your system with a partner. Once you are satisfied that invalid message generation issues have been removed from the system, you may optionally turn off message validation to boost performance. As noted in the preceding section, there is no requirement for message validation to be performed during message processing.
Message Attachments
Both RNIF 1.1 and RNIF 2.0 include support for optional message attachments in the RosettaNet action message. Attachments are not file-type-specific, and may contain binary data. Examples of possible attachments include Word documents, GIF images, PDF files, and so on. The information for each attachment is contained in the service header of the message.
WebLogic Integration supports attachments by allowing a user application (for example a private workflow) to provide a description of the attachment, contained in a BEA-specific structured XML file, as an input to the PIP workflow. The XML file is a description of the file attachment. It is not the actual attachment. It only specifies which files should be attached by WebLogic Integration.
The following is the DTD information describing the attachments:
Listing 2-1 WebLogic Integration Attachment DTD Information for RosettaNet
<!ELEMENT WLCRosettaNet ( Attachment+ )>
<!ELEMENT Attachment (
description?,
Type,
Id,
LocalLocation
)>
<!ELEMENT description ( FreeFormText ) >
<!ELEMENT FreeFormText ( #PCDATA ) >
<!ATTLIST FreeFormText xml:lang CDATA #IMPLIED >
<!ELEMENT Type ( #PCDATA ) >
<!ELEMENT Id ( #PCDATA ) >
<!ELEMENT LocalLocation ( #PCDATA ) >
The following table describes the elements used in the DTD.
Table 2-4 RosettaNet Attachment Elements
When the message is received, any attachments are stored locally in the WLI_Home/config/domain_name/rnattachments directory. The filename of the stored attachment is prefixed with a timestamp. For example, you might use the following XML description for an attachment.
Listing 2-2 Sample XML Attachment
<?xml version ="1.0"?>
<!DOCTYPE WLCRosettaNet SYSTEM "WLCRosettaNet.dtd">
<WLCRosettaNet>
<Attachment>
<description>
<FreeFormText>Product user guide in PDF</FreeFormText>
</description>
<Type>application/pdf</Type>
<Id>"001801236324xyz@xyz.test.com"</Id>
<LocalLocation>c:\pdf\myfile.pdf</LocalLocation>
</Attachment>
<Attachment>
...
</Attachment>
</WLCRosettaNet>
This sample would generate the following data in the service header and in the MIME header.
Listing 2-3 Sample Service Output
<Attachment>
<description>
<FreeFormText>Product user guide in PDF</FreeFormText>
</description>
<GlobalMimeTypeQualifierCode>PDF
</GlobalMimeTypeQualifierCode>
<UniversalResourceIdentifier>
cid:Attachment.001801236324xyz@xyz.test.com
</UniversalResourceIdentifier>
</Attachment>
Listing 2-4 Sample MIME Header
Content-Type: application/pdf; name="myfile.pdf"
Content-ID: <Attachment.001801236324xyz@xyz.test.com>
Content-Description: Product user guide in PDF
|
Copyright © 2001 BEA Systems, Inc. All rights reserved.
|