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>"[e-mail]"</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:[e-mail]
	</UniversalResourceIdentifier>
</Attachment>

Listing 2-4 Sample MIME Header

Content-Type: application/pdf; name="myfile.pdf"
Content-ID: <[e-mail]>
Content-Description: Product user guide in PDF