bea.com | products | dev2dev | support | askBEA

Download Docs | Site Map | Glossary
Search

Implementing RosettaNet

Using Workflows with RosettaNet

The following sections explain how to develop workflows to implement RosettaNet Partner Interface Processes (PIPs).

- Understanding RosettaNet

- Understanding PIP Workflow Instances

- Getting Started

- Coordinating Public and Private Workflows

- RosettaNet Workflow Variables

- Receiving a RosettaNet Message

- Sending a RosettaNet Message

- Validating a Message

- Message Attachments

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 the 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:

- Creating Workflows for B2B Integration

- The following documents are available in the "Standards" section at the RosettaNet Web site (http://www.rosettanet.org):

- RosettaNet Implementation Framework v1.1 (RNIF 1.1) —The RNIF is an open, common networked-application framework designed to allow RosettaNet supply chain and solution partners to collaborate in executing RosettaNet PIPs.

- RosettaNet Implementation Framework v2.0 (RNIF 2.0)

- RNIF Technical Advisories—RNIF Technical Advisories are updates and additional information for RNIF 1.1 and RNIF 2.0.

- RNIF Technical Recommendations—Technical Recommendations describe features or enhancements not yet available in a published version of the RNIF v1.1. Implementation of Technical Recommendations is optional.

- RNIF Business Signals, Service Header & Preamble—The RNIF business signals, service header & preamble document contains message guidelines and XML document type definitions (DTDs) for the RNIF business signals, service header, and preamble.

- Understanding a PIP Blueprint—reference for PIP blueprint components and evaluation. Available under Supporting Documents in the Standards Section.

- PIPs of interest—PIPs are specialized system-to-system, XML-based dialogs that define business processes between supply chain companies. Each PIP includes a technical specification based on the RosettaNet Implementation Framework (RNIF), a Message Guideline document with a PIP-specific version of the Business Dictionary, and XML document type definitions (DTDs) for PIP-specific messages.

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:

1. A customer private workflow initiates a RosettaNet message. Data is retrieved and formatted into a RosettaNet message structure, the appropriate PIP is determined, and the message is forwarded to the public workflow that implements the customer role in the PIP.

2. The public workflow process creates the appropriate RosettaNet message. The message is sent to the public workflow implementing the product supplier role in the PIP via the B2B engine.

3. The product supplier public workflow receives the message, processes the header information, and then passes validated customer information and message content to the appropriate private workflow process.

4. The product supplier private process resolves message content and generates a reply. The reply is processed into a RosettaNet message structure and passed back to the product supplier public process.

5. The product supplier public process creates a RosettaNet reply message and sends it to the customer public process via the B2B engine.

6. The customer public process receives the reply message, processes header information, and then passes validated product supplier information and message content to the appropriate private process.

7. The private process resolves content of the reply message.

Getting Started

While most of the tasks required to develop a RosettaNet workflow are identical to those used for developing other 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.

Coordinating Public and Private 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:

- Provide raw source and recipient data

- Structure data into standard RosettaNet message body forms

- Process received data

- Initiate public workflows to send data

- Provide an interface to private applications

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:

- Input variables are used to receive data into the workflow. The content of a variable is set by the calling private workflow.

- Output variables are used to send data out of the workflow. The content, created by the PIP when it completes, is passed back to the calling workflow.

- System variables are used to track assorted data within the workflow that are required for a RosettaNet workflow to operate properly.

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

- Workflow Variables for RNIF 2.0

- Workflow Variables for RNIF 1.1

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:

- Input—Value Mandatory
  The value for these variables must be set by the calling workflow.

- Input—Value Optional
  The value for these variables may be provided by the calling workflow. Although the value is not required, the variable must exist.

- Output—Value Optional
  The value for these variables may be set when the workflow ends. Although the value is not required, the variable must exist. A value is not required for any Output variable.

- System—Value Mandatory
  These variables are used by the B2B engine to generate the RosettaNet message. The value must be provided by the calling workflow or assigned at the workflow start node.

- System—Value Optional
  These variables are used by the B2B engine to generate the RosettaNet message. Although the value is not required, the variable must exist.

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

Name | Type | Usage and Description
--- | --- | ---
actionCode | string | System—value mandatory Maps to: ServiceHeader/ProcessControl /ActivityControl/MessageControl /Manifest/ServiceContentControl /ActionIdentity/GlobalBusinessActionCode
actionCodeVersion | string | System—value mandatory Maps to: ServiceHeader/ProcessControl /ActivityControl/MessageControl /Manifest/ServiceContentControl /ActionIdentity/VersionIdentifier
attachmentDescriptorInput | xml | Input—value optional Contains the descriptor of files to be used as attachments.
attachmentDescriptorOutput | xml | Output—value optional Contains the descriptor of files that may have been received as attachments.
businessActivityID | string | System—value mandatory Maps to: ServiceHeader/ProcessControl /ActivityControl /BusinessActivityIdentifier
DOC_TYPE | string | System—value optional Contains the doctype string for the XML message. This sting is inserted into the service content if the content does not contain a doctype string.
exceptionError | boolean | System—value optional Indicates if an exception error was received.
fromDUNS | string | Input—value mandatory The DUNS of the sender. Must match the business id defined in the repository for the trading partner. Maps to: DeliveryHeader /messageSenderIdentification /PartnerIdentification /GlobalBusinessIdentifier ServiceHeader/ProcessControl /KnownInitiatingPartner /PartnerIdentification /GlobalBusinessIdentifier
fromLocation | string | System—value mandatory Maps to: DeliveryHeader /messageSenderIdentification /PartnerIdentification /locationID/FreeFormText
fromRole | string | System—value mandatory Maps to: ServiceHeader/ProcessControl /MessageControl/fromRole /GlobalPartnerRoleClassificationCode
fromService | string | System—value mandatory Maps to: ServiceHeader/ ProcessControl/MessageControl/ fromService/GlobalBusinessServiceCode
globalUsageCode | string | Input—value mandatory Set to either Test or Production. Maps to: ServiceHeader/ProcessControl /GlobalUsageCode
gotMessage | string | System—value mandatory Indicates if a RosettaNet message was received. True if a message was received. False if a timeout had occurred
isSignal | boolean | System—value optional Indicates if a signal was received.
messageCode | integer | System—value optional Contains the code returned by the message send.
messageTrackingId | string | System—value optional Message ID used to populate the message content for a PIP0A1 notification.
NOFParty1 | string | Input—value mandatory The party name of the PIP Failure Notifier role. Used to start the Notification of Failure Error process (PIP0A1).
NOFParty2 | string | Input—value mandatory The party name of the PIP Failure Report Administrator role. Used to start the Notification of Failure Error process (PIP0A1)
PIP | string | System—value mandatory Must match the conversation name. Maps to: ServiceHeader/ProcessControl /pipCode/GlobalProcessCode
PIPInput | xml | Input—value mandatory The service content of the message.
PIPOutput | xml | Output—value optional The service content of the received message.
PIPVersion | string | System—value mandatory Must match the conversation version. Maps to: ServiceHeader/ProcessControl /pipVersion/VersionIdentifier
reason | string | System—value optional Contains the reason for the workflow finishing.
retryCount | integer | System—value mandatory Counter to store the retry attempts.
rnProcessInstanceId | string | System—value optional The process id of the PIP instance. Used to populate the message content for 0A1 notification.
rnSystem | object | System—value optional An object used internally to hold application data state. See Consolidated rnSystem Variable.
SERVICE_CONTENT_SCHEMA | string | System—value mandatory Contains the name of the xsd schema to validate the service content against.
timeStamp | string | System—value optional If the retry count is 1 (that is, if this is the first attempt), the timestamp is generated internally. Maps to: DeliveryHeader/messageDateTime /DateTimeStamp
toDUNS | string | Input—value mandatory The DUNS of the receiver. Must match the business ID defined in the repository for the trading partner. Maps to: DeliveryHeader /messageReceiverIdentification /PartnerIdentification /GlobalBusinessIdentifier
toLocation | string | Input—value mandatory Maps to: DeliveryHeader /messageReceiverIdentification /PartnerIdentification /locationID/FreeFormText
toRole | string | System—value mandatory Maps to: ServiceHeader/ProcessControl /MessageControl/toRole /GlobalPartnerRoleClassificationCode
toService | string | System—value mandatory Maps to: ServiceHeader/ProcessControl /MessageControl/toService /GlobalBusinessServiceCode
useDTDValidation | boolean | System—value optional If set to true, DTD validation is used instead of XSD. If set to false or the variable does not exist, XSD schemas will be used for validation. Whether validation is performed at all is dependent on the values of validateServiceContent and validateServiceHeader.
validateServiceContent | boolean | Input—value mandatory Flag to indicate if the service content should be validated against the schema. True - validation required False - no validation required
validateServiceHeader | boolean | Input—value mandatory Flag to indicate if the service header should be validated against the schema. True - validation required False - no validation required
validationError | boolean | System—value optional Indicates the result of the validation.

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

Name | Type | Usage and Description
--- | --- | ---
actionCode | string | System—value mandatory Maps to: ServiceHeader/ProcessControl /TransactionControl/ActionControl /ActionIdentity/GlobalBusinessActionCode
actionCodeVersion | string | System—value mandatory Maps to: ServiceHeader/ProcessControl /TransactionControl /ActionControl/ActionIdentity /VersionIdentifier
attachmentDescriptorInput | xml | Input—value optional The descriptor of files to be used as attachments.
attachmentDescriptorOutput | xml | Output—value optional Contains the descriptor of files that may have been received as attachments.
businessActivityID | string | System—value mandatory Maps to: ServiceHeader/ProcessControl /ProcessIdentity /GlobalProcessCode
DOC_TYPE | string | System—value optional Contains the doctype string for the XML message. This string is inserted into the service content if the content does not contain a doctype string.
docId | string | System—value optional Used to create the acknowledgment message. Maps to: ReceiptAcknowledgement /receivedDocumentIdentifier /ProprietaryDocumentIdentifierReceiptAcknowledgmentException /theOffendingDocumentIdentifier /ProprietaryDocumentIdentifierException /theOffendingDocumentIdentifier /ProprietaryDocumentIdentifier
exceptionError | boolean | System—value optional Indicates if an exception error was received.
fromClass | string | System—value mandatory Maps to: ServiceHeader/ProcessControl /TransactionControl/ActionControl /PartnerRoute/fromPartner/PartnerDescription /GlobalPartnerClassificationCode ServiceHeader/ProcessControl /TransactionControl/SignalControl /PartnerRoute/fromPartner/PartnerDescription /GlobalPartnerClassificationCode
fromContactName | string | Input—value mandatory Used to construct the XML content for the `Notification of Error' message.
fromDUNS | string | Input—value mandatory The DUNS of the sender. Must match the business ID defined in the repository for the trading partner. Maps to: ServiceHeader/ProcessControl /TransactionControl/ActionControl /PartnerRoute/fromPartner /PartnerDescription/BusinessDescription /GlobalBusinessIdentifierServiceHeader /ProcessControl/TransactionControl /SignalControl/PartnerRoute/ fromPartner/PartnerDescription /BusinessDescription/GlobalBusinessIdentifier
fromEmailAddress | string | Input—value mandatory Used to construct the XML content for the `Notification of Error' message. The email address of the sender.
fromPhone | string | Input—value mandatory Used to construct the XML content for the `Notification of Error' message. The phone number of the sender.
fromRole | string | System—value mandatory Maps to: ServiceHeader/ProcessControl /TransactionControl/PartnerRoleRoute /fromRole/PartnerRoleDescription /GlobalPartnerRoleClassificationCode
fromService | string | System—value mandatory Maps to: ServiceHeader/ProcessControl /ServiceRoute/fromService /BusinessServiceDescription /GlobalBusinessServiceCode
fromSupplychain | string | Input—value mandatory Used to create message acknowledgment. Maps to: ReceiptAcknowledgement /fromRole/PartnerRoleDescription /PartnerDescription/BusinessDescription /GlobalSupplyChainCode ReceiptAcknowledgmentException /fromRole/PartnerRoleDescription /PartnerDescription/BusinessDescription /GlobalSupplyChainCode Exception/fromRole /PartnerRoleDescription/PartnerDescription /BusinessDescription/GlobalSupplyChainCode
functionCode | string | System—value mandatory Maps to: ServiceHeader/ProcessControl /TransactionControl/ActionControl /GlobalDocumentFunctionCode
globalUsageCode | string | Input—value mandatory Set to either Test or Production. Maps to: Preamble/GlobalUsageCode
gotMessage | string | System—value mandatory Indicates if a RosettaNet message was received. True - message received. False - a timeout occurred
isSignal | boolean | System—value optional Indicates if a signal was received.
messageCode | integer | System—value optional Contains the code returned by the message send.
messageTrackingId | string | System—value optional Message ID used to populate the message content for a PIP0A1 notification.
NOFParty1 | string | Input—value mandatory The party name of the PIP Failure Notifier role. Used to start the Notification of Failure Error (PIP0A1)
NOFParty2 | string | Input—value mandatory The party name of the PIP Failure Report Administrator role. Used to start the Notification of Failure Error (PIP0A1)
PIP | string | System—value mandatory Must match the conversation name. Maps to: ServiceHeader/ProcessControl /ProcessIdentity/GlobalProcessIndicatorCode
PIPInput | xml | Input—value mandatory The service content of the message.
PIPOutput | xml | Output—value optional The service content of the received message.
PIPVersion | string | System—value mandatory Must match the conversation version. Maps to: ServiceHeader/ProcessControl /ProcessIdentity/VersionIdentifier
reason | string | System—value optional Contain the reason for the workflow finishing.
retryCount | integer | System—value mandatory Counter to store the retry attempts.
rnProcessInstanceId | string | System—value optional The process id of the PIP instance. Used to populate the message content for 0A1 notification.
rnSystem | object | System—value optional An object used internally to hold application data state. See Consolidated rnSystem Variable.
SERVICE_CONTENT_SCHEMA | string | System—value mandatory Contains the name of the xsd schema to validate the service content against.
timeStamp | string | System—value optional Maps to: ReceiptAcknowledgement /receivedDocumentDateTime/DateTimeStamp ReceiptAcknowledgmentException /theOffendingDocumentDateTime /DateTimeStamp Exception/theOffendingDocumentDateTime /DateTimeStamp
toClass | string | System—value mandatory Maps to: ServiceHeader/ProcessControl /TransactionControl/ActionControl /PartnerRoute/toPartner/PartnerDescription /GlobalPartnerClassificationCode ServiceHeader/ProcessControl /TransactionControl/SignalControl /PartnerRoute/toPartner/PartnerDescription /GlobalPartnerClassificationCode
toDUNS | string | Input—value mandatory The DUNS of the receiver. Must match the business id defined in the repository for the trading partner. Maps to: ServiceHeader/ProcessControl /TransactionControl/ActionControl /PartnerRoute/toPartner/PartnerDescription /BusinessDescription /GlobalBusinessIdentifier ServiceHeader/ProcessControl /TransactionControl/SignalControl /PartnerRoute/toPartner/PartnerDescription /BusinessDescription /GlobalBusinessIdentifier
toRole | string | System—value mandatory Maps to: ServiceHeader/ProcessControl /TransactionControl/PartnerRoleRoute /toRole/PartnerRoleDescription /GlobalPartnerRoleClassificationCode
toService | string | System—value mandatory Maps to: ServiceHeader/ProcessControl /ServiceRoute/toService /BusinessServiceDescription /GlobalBusinessServiceCode
toSupplyChain | string | Input—value mandatory Used to create message acknowledgment. Maps to: ReceiptAcknowledgement/toRole /PartnerRoleDescription/PartnerDescription /BusinessDescription/GlobalSupplyChainCode ReceiptAcknowledgmentException /toRole/PartnerRoleDescription /PartnerDescription/BusinessDescription /GlobalSupplyChainCode Exception/toRole/PartnerRoleDescription /PartnerDescription /BusinessDescription/GlobalSupplyChainCode
transactionCode | string | System—value mandatory Maps to: ServiceHeader/ProcessControl /TransactionControl/TransactionIdentity /GlobalTransactionCode
useDTDValidation | boolean | System—value optional If set to true, DTD validation is used instead of XSD. If set to false or the variable does not exist, XSD schemas will be used for validation. Whether validation is performed at all is dependent on the values of validateServiceContent and validateServiceHeader.
validateServiceContent | boolean | Input—value mandatory Flag to indicate if the service content should be validated against the schema. True - validation required False - no validation required
validateServiceHeader | boolean | Input—value mandatory Flag to indicate if the service header should be validated against the schema. True - validation required False - no validation required
validationError | boolean | System—value optional Indicates the result of the validation.

Consolidated rnSystem Variable

In WebLogic Integration 2.0, the following variables were also required.

>     signalCode
>     signalCodeVersion
>     inReplyToActionCode
>     inReplyToMessageId
>     initiatingPartnerDUNS
>     inReplyToActionCodeVersion (RNIF2.0 only)

In subsequent releases, these variables are replaced by the consolidated rnSystem variable (workflow variable type: Java Object), the use of which reduces 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 methods of receiving RosettaNet messages: Start nodes and Event nodes. Which type is used depends on the circumstances under which a 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 Customer workflow), you must create a separate timeout path to wait for the response. This path, illustrated in the 3A2 Customer 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:

1. Initiator—>(request)—>Recipient

2. Recipient—>(receipt acknowledgment)—>Initiator

3. Recipient—>(response)—>Initiator

4. Initiator—>(handling acknowledgment)—>Recipient

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:

1. Initiator—>(request)—>Recipient

2. Recipient—>(response)—>Initiator

3. Recipient—>(receipt acknowledgment)—>Initiator

4. Initiator—>(receipt acknowledgment)—>Recipient

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 sends a RosettaNet message using the following nodes:

- Send Business Message task

- Event node of type RosettaNet Status Event

- Wait for HTTP Status task

A portion of a PIP3A2_Customer_RN2 workflow is shown in the following figure.

Figure 2-2 Workflow Nodes Used to Send a RosettaNet Message

The transmission of a RosettaNet message begins when the Send Business Message task sends the message. An event node (RosettaNet Status Event) waits for notification of the http status f the message. When it receives such status notification, the event node marks the Wait for HTTP Status task node as done, and the workflow proceeds to the next node in the workflow.

The Send Business Message task is asynchronous; it does not wait for an http status reply before proceeding to the next node in the workflow.

To send a RosettaNet message:

1. Right-click the Send Message task, and then select Properties from the shortcut menu.

   The Task Properties dialog box is displayed.

2. Click the Add button to display the Add Action dialog box.

3. Choose Integration Actions—>B2B Integration—>Send Business Message, as shown in the following figure:

   Figure 2-3 B2B Integration Actions

4. Click OK to display the Send Business Message dialog box as shown in the following figure.

   Figure 2-4 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 for which you are prompted by message type.

   Table 2-3 Message Types and Options

   Message Type | Field Name | Description
   --- | --- | ---
   Action | Message Type—Action | Indicates that a RosettaNet Action Business Message is to be sent.
   Input Content Value | A workflow XML variable containing the XML data to represent the service content. See the PIPInput variable in Table 2-1 (RNIF 2.0) or Table 2-2 (RNIF 1.1).
   Attachment Descriptor Value | A workflow XML variable containing the XML data for describing the attachment(s) to be sent as part of the RosettaNet message. (See Message Attachments and the attachmentDescriptorInput variable in Table 2-1 (RNIF 2.0) or Table 2-2 (RNIF 1.1).
   Receipt Acknowledgment | Message Type—Receipt Acknowledgment | Indicates that a RosettaNet Receipt Acknowledgment signal is to be sent. No other data values are required.
   Exception | Message Type—Exception | Indicates that a RosettaNet Receipt Exception Acknowledgment signal is to be sent.
   Error Code | The Error Code (as defined by RosettaNet) to be sent.
   Error Description | A brief description of the error.

5. Right-click the Status Event node, and then select Properties from the shortcut menu.

   The Event Properties dialog box is displayed, as shown in the following figure.

   Figure 2-5 Event Properties Dialog Box for RosettaNet Status Event

   The type of information required depends on the Event Type you select. The following table summarizes the information for which you are prompted when defining a RosettaNet status event.

   Table 2-4 RosettaNet Status Event Options

   Field

   Description

   Description

   A description of the event. The description appears as the label of the event node in the workflow.

   Type

   The type of event to be configured. Select RosettaNet Status Event from the menu.

   Output Status Variable

   The variable in which the send status of the message can be stored.

6. Select the Actions tab and click the Add button to display the Add Action dialog box.

7. Choose Task Actions—>Mark Task as Done. Then click OK to display the Mark Task as Done dialog box.

8. Select the Wait for Http Status task to be marked as done and click OK.

9. Right-click the Wait for Http Status task, and then select Properties from the shortcut menu.

   The Task Properties dialog box is displayed.

10. Click the Add button to display the Add Action dialog box.

11. Choose Task Actions—>Set Task Due Date. The Set Task Due Date dialog box is displayed, as shown in the following figure.

    Figure 2-6 Set Task Due Date Dialog Box

12. In the Set to expression field enter a formula for defining the amount of time you want your application to wait before it times out. Then select the applicable business calendar from the Business Calendar menu. Click OK. The Task Properties dialog box is displayed

13. Click OK in the Task Properties dialog box. The portion of the workflow used to send a RosettaNet message is now complete.

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

- Recommended 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:

- None—No validation is performed if validateServiceHeader and validateServiceContent are set to false.

- Validate Service Header—If validateServiceHeader set to true, the service header of all messages sent and received for a template are validated. The type of validation performed is dependent on the setting for the useDTDValidation variable.

- Validate Service Content—If validateServiceContent set to true, all service content of all messages sent and received for a template are validated. The type of validation performed is dependent on the setting for the useDTDValidation variable.

- DTD—DTD validation is performed if useDTDValidation is set to true. The DTD files are supplied as part of the PIP specification and can be obtained from www.rosettanet.org.

- XSD Schemas—XSD schema validation is performed if useDTDValidation is set to false, or is absent from the workflow template. In order to use XSD validation, you must create your own schema files from the DTD for the PIP.

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:

- Information about XML schema tools, usage, specifications, and development is available at the following URL:

>     http://www.w3.org/XML/Schema

XML Schema Part 0: Primer provides good descriptions of the features and capabilities of XML schema.

- Information about the Xerces implementation of the XML Schema specification is available at the following URL:

>     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-5 RosettaNet Attachment Elements

Element | Description
--- | ---
Description | An optional description of the attachment.
Type | The MIME type qualifier code of the attachment.
ID | The Universal Resource Identifier for the attachment.
LocalLocation | On sending: Contains the full path (on the local system) of the file for sending as an attachment. On receiving: Contains the full path (on the local system) of the file attachment that was received.

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