RosettaNet PIP Templates

 

BEA WebLogic Collaborate includes two PIP templates with which you can immediately implement RosettaNet-based solutions. This section includes descriptions of both the contents of each PIP template and the information required to implement the PIP. Versions of both PIPs are provided for both RNIF 1.1 and RNIF 2.0.

 

---

PIP0A1: Notification of Failure

This PIP is a system-level RosettaNet PIP required for all implementations. It is used to transmit information in the event a process failure occurs. Normally, it does not require significant customization. Rather, data is passed to it from calling PIP workflows. For this reason, the appropriate workflow variables must be set in the calling workflow before the PIP0A1 workflow is called. Specifically, the variables listed in the following table must be set and imported to the PIP0A1_Admin template. All input variables must be initialized when the workflow is called. All other workflow variables should be referenced from Table 3-1.

Table 4-1 Required PIP Workflow Variables

Workflow Variable	Type	Description	Usage
attachmentDescriptorInput	xml	The XML description of the attachments for a message	Input (optional)
fromContactName	string	The sender's contact name	Input (mandatory)
fromDUNS	string	The DUNS of the sender	Input (mandatory)
fromEMail	string	The sender's email	Input (mandatory)
fromLocation	string	The location of the sender	Input (mandatory)
fromPhone	string	The sender's phone number	Input (mandatory)
fromSupplyChain	string	The supply chain code of the sender: Information Technology or Electronic Components	Input (mandatory)
globalUsageCode	string	The global usage code: either Test or Production	Input (mandatory)
PIPInput	xml	The PIP message content to be sent; must match the PIP specification	Input (mandatory)
toDUNS	string	The DUNS of the receiver	Input (mandatory)
toLocation	string	The location of the receiver	Input (mandatory)
toSupplyChain	string	The supply chain code of the receiver: Information Technology or Electronic Components	Input (mandatory)
validateServiceContent	boolean	Flag to indicate whether the service content should be validated against the schema: True—validation required False—no validation required	Input (mandatory)
validateServiceHeader	boolean	Flag to indicate whether the service header should be validated against the schema: True—validation required False—no validation required	Input (mandatory)
NOF0A1Party1	string	The party name to be used for OA1 failure notification	Input (mandatory)
NOF0A1Party2	string	The party name to be used for OA1 failure notification	Input (mandatory)

The NOF0A1Party1 and NOF0A1Party2 variables must be set, but you are not required to set them in any particular order.

 

---

PIP3A2: Query Price and Availability

PIP3A2 is provided in template form as an example of how to implement a PIP. There are two versions of this PIP (one implemented for RNIF 1.1, and one for RNIF 2.0), and each version is modeled using WebLogic Process Integrator for both the sender and receiver roles. Use the PIP template version appropriate for the version of RosettaNet that you are using.

When implementing PIP3A2, you must set the mandatory input variables, all of which are listed in the following table. These variables can be set from within the PIP workflow, or they can be set by a calling workflow. All input variables must be initialized when the workflow is called. All other workflow variables should be referenced from Table 3-1.

Table 4-2 PIP3A2 Required Input Workflow Variables

Workflow Variable	Type	Description	Usage
attachmentDescriptorInput	xml	The XML description of the attachments for a message	Input (optional)
fromContactName	string	The sender's contact name	Input (mandatory)
fromDUNS	string	The DUNS of the sender	Input (mandatory)
fromEMail	string	The sender's email	Input (mandatory)
fromLocation	string	The location of the sender	Input (mandatory)
fromPhone	string	The sender's phone number	Input (mandatory)
fromSupplyChain	string	The supply chain code of the sender: Information Technology or Electronic Components	Input (mandatory)
globalUsageCode	string	The global usage code: either Test or Production	Input (mandatory)
PIPInput	xml	The PIP message content to be sent; must match the PIP specification	Input (mandatory)
toDUNS	string	The DUNS of the receiver	Input (mandatory)
toLocation	string	The location of the receiver	Input (mandatory)
toSupplyChain	string	The supply chain code of the receiver: Information Technology or Electronic Components	Input (mandatory)
validateServiceContent	boolean	Flag to indicate whether the service content should be validated against the schema: True—validation required False—no validation required	Input (mandatory)
validateServiceHeader	boolean	Flag to indicate whether the service header should be validated against the schema: True—validation required False—no validation required	Input (mandatory)
NOF0A1Party1	string	The party name to be used for OA1 failure notification	Input (mandatory)
NOF0A1Party2	string	The party name to be used for OA1 failure notification	Input (mandatory)
attachmentDescriptorOutput	xml	The XML description of the attachments for a message.	Output
reason	string	Contains the reason for PIP exit: SUCCESS—if it was successful. Otherwise the reason description. If PIP 0A1 Notification of Failure is invoked, the failure reason will be returned in this field.	Output
PIPOutput	xml	The PIP message content received	Output

 

---

Modeling Other PIPs

The PIP3A2 templates are provided to demonstrate how a RosettaNet PIP is put together under WebLogic Collaborate. Because of the complexity of the PIP, BEA recommends that when creating a new PIP, you copy the PIP3A2 source files and modify the copies to create your new PIP.

You should note the following points when modeling other PIPs:

• Use input and output workflow variables to transport data between this PIP and other processes. Use input variables for the PIP to receive data from another workflow, and use output variables to send data to another workflow. You must remember to initialize all mandatory input variables when you start a PIP workflow.

• Other workflows may initiate a PIP workflow. To configure this type of initiation, choose Actions—>Collaborate—>Start Public Workflow. Use this method when you are the trading partner initiating a PIP transaction. When you use this method, remember that you must manually enter all of the PIP workflow variables listed in Table 4-1.

• PIP workflows may initiate other workflows, such as private workflows. To configure this type of initiation, choose Actions—>Start Workflow. Use this method when you are the trading partner receiving a PIP transaction, and you want to pass that data to a private workflow. Use the private workflow to connect, for example, to a back-end ERP system.