Implementing OAGIS within the RosettaNet Implementation Framework Version 2.0

Transcription

1 The Open Applications Group and RosettaNet Implementing OAGIS within the RosettaNet Implementation Framework Version 2.0 Kurt Kanaskie, Lucent Technologies, Introduction There are many industry efforts developing XML messages, transport mechanisms and business processes for application integration and B2B integration. The OAGI (Open Applications Group) has developed the largest set of business messages and integration scenarios for enterprise application integration and B2B integration. OAGI does not define process specifications or a message transport framework. RosettaNet has developed process definitions targeted solely for B2B supply chain integration. The RosettaNet specification consists of process definitions, message definitions and industry specific content. RosettaNet also defines an implementation framework for message exchange, which is essential for interoperability among different vendor solutions. The OAGI policy is to be technology sensitive and to use existing open standards when possible. This white paper provides a detailed recommendation of how to transport OAGI BODs (Business Object Documents) (Version dated November 25, 2000) using the RNIF (RosettaNet Implementation Framework: Core Specification Version: Release Date: 3 January 2001). A high level comparison of the OAGI and RosettaNet specifications, solution approaches, message exchange scenarios and explicit message mapping guidelines are provided. The reader is expected to have a thorough understanding of the OAGI BOD structure and the RNIF. The reader is encouraged to read the OAGI BOD Architecture documents (Section 1 Chapters 1 and 2) and the RNIF Specification. These documents can be freely obtained from the OAGI and RosettaNet web sites. The Open Applications Group The OAGI Integration Specification includes a broad set of BODs and general integration scenarios that can be used in different business environments (e.g. A2A, B2B). BODs are message definitions that can be used broadly across many different industries (e.g. telecommunications, automotive) and aspects of Supply Chain Automation (e.g. Ordering, Catalog Exchange, Quotes, etc.). OAGI also defines the OAMAS (Open Application Middleware API Specification) which is an API (application programmer interface) for application integration that provides an abstraction from specific vendor solutions. RosettaNet RosettaNet defines industry specific process exchange sequences called PIPs (Partner Interface Process), data dictionaries for specific industries (i.e. IT Supply Chain, Electronic Components) and an implementation framework for Supply Chain Automation in a B2B environment. RosettaNet PIPs define business messages and transactions that cover many aspects of the B2B Supply Chain Automation (e.g. Ordering, Product Catalog, Quotes, etc.). Rationale The OAGI strives to adopt existing technology where possible and will benefit from the use of RosettaNet as an implementation framework. An implementation framework defines how Version 2.0 Page 1 of 33 Last Modified: 2/21/2001

2 messages are communicated over a particular transport medium (e.g. HTTP) and enables infrastructure level interoperability among different vendor solutions. The OAGI BOD structure defines message control information that is deemed sufficient for application-to-application integration. OAG also specifies OAMAS, an API that can be implemented by different middleware solution providers or developers and used to transport BODs. OAMAS does not define a transport protocol which means different implementations might not be interoperable. Although it is feasible to provide an OAMAS implementation in an HTTP based communications protocol, none have been provided to date. This leaves OAGI developers in a quandary with respect to a B2B implementation framework. The OAGI lacks a precise definition of how to exchange OAGI BODs over an HTTP based communications infrastructure and how to use the BOD message control information. The RNIF explicitly defines a mechanism for secure exchange of XML messages over an HTTP based infrastructure using the Internet standard MIME based encoding and related technologies (See RNIF specification for complete references). RosettaNet PIPs define Action Messages and transactional exchange sequences. An Action Message in RosettaNet terminology is analogous to an OAGI BOD. The RNIF was designed to support the exchange of third party content such as OAGI BODs. Scope This document addresses the relationship among and the mapping between RosettaNet and OAGI message sets. It includes explicit rules for the use of each RosettaNet message type (Preamble, DeliveryHeader, ServiceHeader and ServiceContent). It also describes the relationship between the infrastructure level messages (Signal Messages) used by RosettaNet and OAGI (ConfirmBOD) to identify message receipt or exceptions. Details on message packing, transport protocol, and security are not described since these aspects can be used as defined in the RNIF specification. The use of OAGI s OAMAS which defines a programmer interface to the communication infrastructure is also out of scope. Requirements The primary requirements for the use of OAGI over RNIF:?? Use existing OAGI BODs without modification.?? Provide capability to exchange all OAGI BODs.?? Allow existing OAGI based systems to operate with little or no change. Overall Approach The overall approach is to use the architecture of the RNIF as is and to transport OAGI BODs in their entirety in the ServiceContent area of the RNIF message. The intent is to support the following system models: Consolidated system model: ERP(OAGI) - - ERP(OAGI) Discrete system model: ERP(OAGI) - B2B(RNIF) - - B2B(RNIF) - ERP(OAGI). Unfortunately, a one-to-one relationship does not exist between OAGI and RosettaNet messages (see Appendix 4 - RosettaNet Action Message and OAGI BOD Alignment; Appendix 5 List of OAGI BODs), resulting in two different perspectives on the use of RNIF: 1. Transport only those OAGI BODs that can be associated with RosettaNet PIPs. 2. Use RNIF to transport any and all Version 2.0 Page 2 of 33 Last Modified: 2/21/2001

3 OAGI BODS. so both perspectives will be addressed. The two general approaches that can be followed: A. Use existing PIP definitions to transport OAGI BODs. B. Define payload neutral solution for any BOD communication. Each will be described although only approach A is recommended by RosettaNet. RosettaNet Support for Third Party Content New to RNIF 2.0, RosettaNet provides support for transporting third party content in the ServiceContent part of the RosettaNet message. However, RNIF imposes the following restrictions: 1. RosettaNet must approve the use of third party messages. This document will serve as the sole specification for the use of OAGI messages within RNIF 2.0. Part of this specification includes non-standard use of RNIF. RosettaNet may choose to approve only the part that follows RNIF guidelines, demarcated in Approach A below. 2. Third party messages must be exchanged within the context of existing PIPs. Since there are more OAGI BODs than there are corresponding RosettaNet Action Messages, a PIP neutral approach is provided to support all OAGI messages (see Appendix 4 - RosettaNet Action Message and OAGI BOD Alignment; Appendix 5 List of OAGI BODs). From RosettaNet s perspective this is a non-standard use of RNIF, demarcated in Approach B below. 3. RNIF Signal Messages must be used as is; no third party content can be included in these messages. Signal Messages are directly analogous to OAGI s ConfirmBOD and supplant its use within RNIF. However, to support existing OAGI based applications that rely on ConfirmBOD, a relationship is defined such that a ConfirmBOD can be mapped to and from a Signal Message. Version 2.0 Page 3 of 33 Last Modified: 2/21/2001

4 Background High Level Comparison of RosettaNet and OAGI Specification Elements A brief comparison of the elements within the two specifications is provided below. The shaded area indicates areas of overlap between the two organizations. Table 1: Specification Level Comparison of RosettaNet and OAGI RosettaNet Specification Element RosettaNet dance scenarios cover integration scenarios that span multiple transactions. Not formally part of the specification. Partner Interface Processes (PIPs) are collections of business Transactions for a specific trading partner exchange (e.g. Order Management, Quote and Order Entry). They define aspects of the message exchange such as security, non-repudiation and response time. Transaction defines explicit Action message exchange sequences (e.g. Purchase Order Request - Purchase Order Acceptance). Action defines the XML message that is exchanged (e.g. Manage Purchase Order Request) Implementation Framework defines the communication and transport mechanisms for exchanging messages. No corresponding element OAGI Specification Element Vendor Challenge Business Process is an explicit business process that includes three transactions (ProcessPO/AcknowledgePO, ShowShipment, ProcessInvoice). Not currently part of the specification, although this scenario will be added to a future release of OAGIS. Scenario Diagrams are abstract business system collaboration diagrams that describe the possible interaction among business systems or components. Scenario Diagrams indicate possible request and response sequences but are not always explicit (e.g. ProcessPO - AcknowledgePO). Business Object Document (BOD) defines the XML message that is exchanged (e.g. ProcessPO) No corresponding element Open Applications Middleware API Specification (OAMAS) defines a technology neutral API for message exchange. PIPs define how Action Messages are exchanged and are rigid definitions that must be adhered to in order to be compliant. PIP transactions are low-level process exchanges; they are not long running transactions such as that defined by OAGI s Vendor Challenge scenario. Although not currently part of the OAG specification, the Vendor Challenge Scenario is included to show the scope of PIPs. RosettaNet Action Messages identified in the PIP specification are directly analogous to an OAGI BOD. PIPs also define message exchange requirements for secure transport, non-repudiation of origin and receipt, message response times and number of message transmission attempts. OAGI defines general scenario diagrams that suggest how BODs are exchanged. They are not rigid and not required for compliance. Certain BODs can control response messages such as the ProcessPO and AcknowledgePO messages. However, most have an implied message exchange sequence such as the Get/Show and GetList/List combinations of BODs. (e.g. GetPO - ShowPO, GetListPO - ListPO). OAGI does not define any message exchange requirements. Version 2.0 Page 4 of 33 Last Modified: 2/21/2001

5 Message Structure Comparison The diagram below compares the RosettaNet and OAGI message structures. RosettaNet OAG MIME multipart related message Preamble Header Delivery Header Service Header Service Content Attachment 1 XML documents BOD Control Area Data Area XML document Attachment n Payload Figure 1: Message Structure Comparison Both RosettaNet and OAGI messages are XML based, however, there is significant implementation differences. RosettaNet separates its messages into separate XML documents consisting of a Preamble, DeliveryHeader, ServiceHeader and ServiceContent, which are packaged as a MIME encoded message. The header documents define explicit infrastructure level content that is used for all message exchanges. This is roughly analogous to OAGI s Control Area section. The ServiceContent document, synonymous with the Action Message, contains application level data that varies based on the particular business context. It is analogous to OAGI s Data Area. The ServiceContent document is also used to carry the Signal Response message. In addition, RosettaNet supports sending attachment documents of any type, as part of the message. In contrast, OAGI defines a single XML message that contains a message header, (CNTROLAREA) and message data (DATAAREA) area. Table 2 shows a detailed comparison (in psuedo-xml format for readability) of the RosettaNet Preamble, Delivery and ServiceHeader documents and the OAGI header (CNTROLAREA). Version 2.0 Page 5 of 33 Last Modified: 2/21/2001

6 Table 2: Detailed Comparison between RosettaNet and OAGI Message Headers RosettaNet OAGI ---- MIME part boundary - Preamble ---- <Preamble> <BOD#_VERB_NOUN_REVISION> <standardname> <CNTROLAREA> <GlobalAdministeringAuthorityCode> <BSR> <standardversion> <VERB> <VersionIdentifier> <NOUN> ---- MIME part boundary - DeliveryHeader ---- <REVISION> <DeliveryHeader> <SENDER> <issecuretransportrequired> <LOGICALID> <AffirmationIndicator> <COMPONENT> <messagedatetime> <TASK> <messagereceiveridentification> <REFERENCEID> <PartnerIdentification> <CONFIRMATION> <domain> <LANGUAGE> <GlobalBusinessIdentifier> <CODEPAGE> <locationid> <AUTHID> <messagesenderidentification> <DATETIME qualifier = <PartnerIdentification> "CREATION" > <domain> <YEAR> <GlobalBusinessIdentifier> <MONTH> <locationid> <DAY> <messagetrackingid> <HOUR> <InstanceIdentifier> <MINUTE> ---- MIME part boundary - ServiceHeader ---- <SECOND> <ServiceHeader> <SUBSECOND> <ProcessControl> <TIMEZONE> <ActivityControl> <DATAAREA> <BusinessActivityIdentifier> <NOUN_VERB_REVISION> <MessageControl> <!-- business content --> <fromrole> <GlobalPartnerRoleClassificationCode> <fromservice> <GlobalBusinessServiceCode> <Manifest> <Attachment> <description> <GlobalMimeTypeQualifierCode> <UniversalResourceIdentifier> <numberofattachments> <ServiceContentControl> <ActionIdentity> <GlobalBusinessActionCode> <messagestandard> <standardversion> <VersionIdentifier> <VersionIdentifier> <torole> <GlobalPartnerRoleClassificationCode> <toservice> <GlobalBusinessServiceCode> <GlobalUsageCode> <KnownInitiatingPartner> <PartnerIdentification> <domain> <GlobalBusinessIdentifier> <locationid> <partnerdefinedpippayloadbindingid> <ProprietaryReferenceIdentifier> <pipcode> <GlobalProcessCode> <pipinstanceid> <InstanceIdentifier> <pipversion> <VersionIdentifier> ---- MIME part boundary - ServiceContent---- <PIP#_Noun_Action> <!-- business content --> Version 2.0 Page 6 of 33 Last Modified: 2/21/2001

7 Highlighted areas identify the RNIF defined fields to be used when transporting non-rosettanet content. The ServiceContent section in the RosettaNet message and the DATAAREA in the OAGI message are not expanded. These areas carry the business data (RosettaNet Action Message, OAGI BODs), which is different for each message. RosettaNet s Preamble section is rather innocuous and contains basic organization and version identification. The DeliveryHeader is straightforward and contains message identification information such as a date and time stamp, message tracking identifier, plus the sender and receiver identification. The ServiceHeader on the other hand provides specific information that is directly related to the PIP specification and the RosettaNet architecture. The key elements are the Activity Control, Initiating Partner and PIP identification. The Activity Control section further defines the from/to Roles and Services, the Message Manifest and the Action Identity. The Action Identity contains special fields (messagestandard, StandardVersion/VersionIdentifier) to identify the non-rosettanet standard which are used in addition to the GlobalBusinessActionCode and VersionIdentifier to identify the third party message. In addition the special PIP identification field (partnerdefinedpippayloadbindingid) is used when transporting non-rosettanet messages. The use of these fields is covered in detail below. The OAGI message header (CNTROLAREA) is less specific than RosettaNet s headers. It consists of three sections, the BSR (Business Service Request), the SENDER and a date and time stamp. It does not include destination information. The BSR identifies the business data that is exchanged in the DATAAREA. This is directly analogous to RosettaNet s ActionIdentity. The SENDER area identifies aspects of the sending system such as the name (LOGICALID), subsystem (COMPONENT) and authorization ID (AUTHID). It also contains a REFERENCEID which is used to uniquely identify the message. This is directly analogous to RosettaNet s message tracking identifier. OAGI further indicates that the combination of the SENDER fields is used to uniquely identify the message. The OAGI CNTROLAREA functionality is a subset of RosettaNet s Preamble, DeliveryHeader and ServiceHeader. Therefore its use is not needed in a composite system model. However, in a discrete system model where system components have already been developed, the CNTROLAREA should continue to be used. In this case a relationship between the OAGI and RosettaNet fields should be established. Although the structure is different, the date-time stamps in RosettaNet DeliveryHeader and OAGI s SENDER are directly analogous and define the time when the message was created. Implementation Guidelines In each of the approaches described below, OAGI specification material and OAGI header fields are used to populate fields within the RNIF message sections. The means by which this information is associated (i.e. directory service, API arguments) is implementation specific. For example RosettaNet includes destination information and transaction control information in message header areas, while OAGI places responsibility for this information on the communications infrastructure. Detailed Approaches The overall approach is to use the structure of the RNIF as is and to transport OAGI BODs in their entirety in the ServiceContent area of the RNIF message. The intent is to support the following system models: Consolidated system model: ERP(OAGI) - - ERP(OAGI) Discrete system model: ERP(OAGI) - B2B(RNIF) - - B2B(RNIF) - ERP(OAGI). and to support the following requirements: 1. Use existing OAGI BODs without modification. 2. Provide capability to exchange all OAGI BODs. Version 2.0 Page 7 of 33 Last Modified: 2/21/2001

8 3. Allow existing OAGI based systems to operate with little or no change. There are two approaches that can be followed: A. Use existing PIP definitions to transport OAGI BODs. B. Define payload neutral solution for any BOD communication. In each of the approaches described below the Preamble and DeliveryHeader documents are the same (see Mapping 1 Preamble and Mapping 2 DeliveryHeader). An example is provided in Appendix 1 Preamble Mapping Example and Appendix 2 DeliveryHeader Mapping Example. The Mapping for the ServiceHeader is different depending on the approach (see Mapping 3A ServiceHeader for Approach A and Mapping 3B for Approach B). In both approaches the message exchange sequences are the same. A. Use existing PIP definitions to transport OAGI BODs This approach requires a conceptual alignment between OAGI BODs and RosettaNet Action Messages (see Appendix 4 - RosettaNet Action Message and OAGI BOD Alignment). Here, the existing PIP transactions are used as is and the OAGI BODs are carried in the ServiceContent part of the message in place of the RosettaNet Action Message. For example OAGI s ProcessPO and AcknowledgePO align with RosettaNet s PurchaseOrderRequest and PurchaseOrderAcceptance messages. Although these messages are different in structure and content, they are conceptually appropriate for the PIP. An advantage to this approach is that it uses the existing RosettaNet process definitions which are an essential part of a non-negotiated integration model. RosettaNet process definitions restrict the message transactions to those defined by the PIPs. Currently OAGI BODs can be used in different transaction sequences. For example, a ProcessPO may or may not result in an AcknowledgePO response. Whereas the RosettaNet PIP dictates that it must have an AcknowledgePO response. Since the current set of PIPs is narrower in scope than the current set of OAGI BODs, this approach does not satisfy requirement 2 above and not all OAGI BODs can be used in integration scenarios. This approach has a limited impact on OAGI users. Although it restricts the transactions that can be used with to those that RosettaNet has defined it takes advantage of RosettaNet s rigid process definitions. The ServiceHeader is used as defined by RosettaNet for each PIP and the special fields provided to support third party content are used as defined below (see Mapping 3A Normative ServiceHeader Mapping). A complete example for the RosettaNet Manage Purchase Order (PIP 3A4) using the OAGI ProcessPO BOD is provided in Appendix 3A Example Normative ProcessPO and PIP 3A4. Appendix 4 - RosettaNet Action Message and OAGI BOD Alignment lists the current RosettaNet PIPs with their Action Messages and identifies the corresponding OAGI BOD. B. Define payload neutral PIP for any style of BOD communication This approach is not recommended by RosettaNet. It defines rules for mapping OAGI content to fields within the ServiceHeader and is used to transport any OAGI BOD. It ignores the business process information and message exchange requirements defined in RosettaNet PIPs and relies on the implied message transaction sequences of OAGI BODs. In this way the ServiceHeader can be reused in different message exchange environments. Rather than define a specific PIP for a specific business transaction (e.g. ProcessPO to AcknowledgePO or GetPO to ShowPO) rules for mapping OAGI content to the RosettaNet ServiceHeader document are defined. The advantage to this approach is that OAGI BODs can be transported in the same context as they currently are, that is, without rigid transaction definitions. It is important to note that some Version 2.0 Page 8 of 33 Last Modified: 2/21/2001

9 OAGI BODs have built in transaction control (ProcessPO and AcknowledgePO) and some have an implied transaction (e.g. Get/Show and GetList/List). The disadvantage is that by introducing a generic PIP, the message exchange requirements that are specified in each PIP are lost. Therefore, this information must be specified and agreed to by both trading partners for each message exchange sequence in a so called Trading Partner Agreement. RosettaNet does not specify the use of any particular standard or structure for a Trading Partner Agreement. The following table summarizes the PIP specified exchange requirements: Table 3: Summary of PIP Specified Exchange Requirements RosettaNet PIP Requirement Element Value Description and comments Secure Transport Y or N Indicated by the <<Secure Flow>> stereotype in PIP diagrams, this indicates the use of SSL. Value is contained in issecuretransportrequired field of DeliveryHeader Non-repudiation of receipt Y or N Requires signed AcknowledgementOfReceipt signal response. Requires recipient to store the sent message for an agreed upon time period. Time to acknowledge receipt Number of hours >0 The time by which the AcknowledgementOfReceipt signal must be returned. Retry count Number of times to re-send the message if AcknowledgementOfReceipt signal is not returned in specified time. Time to perform Number of hours >0 The time by which the response message in a two-action PIP must be returned. Authorization Y or N Used to ensure sending partner is authorized to send the message. Requires use of Digital Certificates. Non-repudiation of origin and content Y or N Requires originator to store the sent message for an agreed upon time period. This approach has the least impact on the OAGI methodology. To adopt this approach the ServiceHeader content is replaced with OAGI content information (see Mapping 3B: non- Normative ServiceHeader Mapping). A complete example for the RosettaNet Manage Purchase Order (PIP 3A4) using the OAGI ProcessPO BOD is provided in Appendix 3B Example non- Normative ProcessPO and PIP 3A4. Message Exchange Sequences The sequence diagram shown below indicates the sequence of messages from an OAGI originator, through a RosettaNet B2B integration server (depicted in blue boxes), and finally to an OAGI recipient. The diagram depicts a typical, but not required, discrete system model where an OAGI system (OAGI Buyer) sends a message to a logical destination (OAGI Seller) in another system. In this topology the originating OAGI system is unaware that the message is transported over RNIF to the destination system. Version 2.0 Page 9 of 33 Last Modified: 2/21/2001

10 Sequence Diagram 1: Generic Sequence Diagram One Action PIP Generic Sequence Diagram One Action PIP with ConfirmBOD OAG Buyer : OAGAdapter RN B2B Buyer : RNAdpater RN B2B Seller : RNAdpater OAG Seller : OAGAdapter 1: BOD 6: ConfirmBOD 2: RN wrapped BOD 5: RN Signal Response 3: BOD 4: ConfirmBOD Sequence Diagram 2: Generic Sequence Diagram Two Action PIP Generic Sequence Diagram Two Action PIP with Confirm BOD OAG Buyer : OAGAdapter RN B2B Buyer : RNAdpater RN B2B Seller : RNAdpater OAG Seller : OAGAdapter 1: GetBOD 6: ConfirmBOD 2: RN wrapped BOD 5: RN Signal Response 3: GetBOD 4: ConfirmBOD 9: ShowBOD 10: ConfirmBOD 8: RN wrapped BOD 11: RN Signal Response 7: ShowBOD 12: ConfirmBOD Sequence Diagrams 1 and 2 represent the generic relationship between the OAGI BODs and the RosettaNet messages in one-action and two-action message exchanges for the discrete system model. In a composite sytem model the OAGAdapter and the RNAdapter on each side are collapsed into a single adapter and the ConfirmBOD is not used. Version 2.0 Page 10 of 33 Last Modified: 2/21/2001

11 The RosettaNet Signal Response messages, carried in the ServiceContent section, only exist within the RNIF infrastructure. The narrow rectangles indicate focus of control, showing that messages 1 through 6 are within the same context. This does not imply synchronous communication. Loops on the message exchanges indicate messages that are time sensitive. This is an aspect of RosettaNet that is specified in the PIPs. It is recommended that the B2B infrastructure (RNAdapter) validates the message parts, including the OAGI ServiceContent, as per the RosettaNet validation guidelines. Once they are validated and the ServiceContent section is extracted, the Signal Response, either AknowledgementOfReceipt or Exception, is returned. This implies that the RNAdapter can detect that the OAGI BOD (3) has been delivered to the OAGAdapter before sending the RN Signal Response (5) back to the originating RNAdapter. This is done through the use of OAGI ConfirmBOD (4) as shown, to indicate reciept of the OAGI BOD. Note that in a consolidated system model the RNAdpater and OAGAdapter will be one and the same. In this case the Confirm BOD is not used. Notice that in the two-action PIP the response Show BOD (7) is sent asynchronously sometime after the BOD (3) is received. Synchronous communication is also supported in RNIF. The use of asynchronous or synchronous communication is a transport level protocol and does not affect the message sequences at this level. This is covered in detail in Section 2.4 of the RNIF specification. Relationship between RosettaNet Signal Control messages and OAGI ConfirmBOD RNIF specifies separate signal control messages (AcknowledgementOfReceipt and Exception) that are used for reliable messaging over unreliable asynchronous communication channels, transaction integrity, syntactic and structural integrity, exception handling, and application level integrity. The later is also referred to as content level validation. RNIF specifies that these Signal Message must be used. Signal messages are transported in the ServiceContent part of the message. The ServiceHeader document contains an inreplyto section that uniquely identifies the originating message. In contrast OAGI s ConfirmBOD carries this information. OAGI further requires that the originating message s CNTROLAREA be included in the content of the ConfirmBOD. The AcknowledgementOfReceipt message is a positive response indicating receipt and proper validation of the message according to RosettaNet s base level validation rules described in section 2.1 of the RNIF specification. The use of this message is controlled by the PIP definition and is almost always required. Exception messages are used to indicate negative responses such as a failure to validate, failure to unpack the message or content level errors. RosettaNet further qualifies the Exception message as either Receipt-Acknowledgement-Exception or General-Exception. It is important to note that in a two-action message exchange (request and response) it is possible for the originating system to receive both an AcknowledgementOfReceipt message and an Exception message (see Sequence Diagram 6 below). This would be the case when the receiver of the message validates the message but later encounters an error when processing the message content. OAGI uses the single ConfirmBOD message to indicate both positive and negative responses, and does not differentiate between the types of exceptions. Rather a status field (STATUSLVL) field is used to indicate success or failure. The ConfirmBOD is used for transaction integrity, syntactic integrity, exception handling and content level integrity. In a consolidated system model the ConfirmBOD is not used and RosettaNet Signal Messages are used as per the RNIF specification. In a discrete system model the ConfirmBOD is used to indicate success or failure of the message receipt. To support an existing OAGI based application that expects to use ConfirmBOD, a mapping between the OAGI ConfirmBOD and the RosettaNet Signal Messages must be defined (see Mapping 4 Signal Message and Confirm BOD Mapping below). Version 2.0 Page 11 of 33 Last Modified: 2/21/2001

12 Message Validation Failure Sequence Diagrams and Guidelines The following diagrams show message exchange sequences for the use of RosettaNet Signal Messages for specific error conditions. In a discrete system model when a ConfirmBOD is used, the STATUSLVL field value determines which RosettaNet Signal Message is used. The use of the ConfirmBOD is controlled through the CONFIRMATION field in the CNTROLAREA and should be coordinated with the PIP requirements for the use of AcknowledgementOfReceipt. Sequence Diagram 3: No Error - AcknowledgementOfReceipt OAG Buyer : OAGAdapter RN B2B Buyer : RNAdpater RN B2B Seller : RNAdpater OAG Seller : OAGAdapter 1: BOD 6: ConfirmBOD 2: RN wrapped BOD 5: AcknowlegementOfReceipt 3: BOD 4: ConfirmBOD Receiving RNAdapter (Seller) passes parser level validation, OAGAdapter validates content and generates a ConfirmBOD with STATUSLVL= 00 resulting in an AcknowledgementOfReceipt message as per RNIF. Sending RNAdapter (Buyer) generates ConfirmBOD from Signal Message. Sequence Diagram 4: Syntax Error Exception: Receipt-Acknowledgement-Exception OAG Buyer : OAGAdapter RN B2B Buyer : RNAdpater RN B2B Seller : RNAdpater OAG Seller : OAGAdapter 1: BOD 5: ConfirmBOD 2: RN wrapped BOD 4: Exception 3: Validation Error Receipt Acknowlegement Exception Receiving RNAdapter (Seller) detects parser level error and generates Exception: Receipt - Acknowledgement-Exception. Sending RNAdapter (Buyer) generates a ConfirmBOD with STATUSLVL= 99 to indicate the error. Version 2.0 Page 12 of 33 Last Modified: 2/21/2001

13 Sequence Diagram 5: Content Error Exception: General--Exception OAG Buyer : OAGAdapter RN B2B Buyer : RNAdpater RN B2B Seller : RNAdpater OAG Seller : OAGAdapter 1: BOD 6: ConfirmBOD 2: RN wrapped BOD 5: Exception 3: BOD 4: ConfirmBOD General Exception Content Error Receiving RNAdapter (Seller) passes parser level validation, OAGAdapter detects OAGI content error and generates a ConfirmBOD with STATUSLVL= 99. The receiver side RNAdapter (Seller) creates an Exception: General-Exception as per RNIF. Sending RNAdapter (Seller) re-creates a ConfirmBOD with STATUSLVL= 99 to indicate the error. Sequence Diagram 6: Syntax Correct, Content Error OAG Buyer : OAGAdapter RN B2B Buyer : RNAdpater RN B2B Seller : RNAdpater OAG Seller : OAGAdapter 1: BOD 6: ConfirmBOD 2: RN wrapped BOD 5: AcknowlegementOfReceipt 3: BOD 4: ConfirmBOD 9: ConfirmBOD 8: Exception 7: ConfirmBOD General Exception Content Error Receiving RNAdapter (Seller) passes parser level validation, OAGAdapter acknowledges message receipt, but not content, and generates a ConfirmBOD with STATUSLVL= 00 resulting in an AcknowledgementOfReceipt message. Subsequently OAGI content error is detected. A new ConfirmBOD is generated with STATUSLVL= 99 and sent to receiver side RNAdapter (Seller) which generates Exception: General-Exception as per RNIF. Sending RNAdapter (Seller) recreates a ConfirmBOD with STATUSLVL= 99 to indicate the error. Version 2.0 Page 13 of 33 Last Modified: 2/21/2001

14 Relationship between RosettaNet Notification of Failure message and OAGI ConfirmBOD RosettaNet s Notification of Failure message is part of the Process Control PIPs. Its use is dependent on the type of message exchange (one-action or two-action) and the state of the message exchange sequence. There are number of situations when a Notification of Error PIP must be used rather than an Exception Signal Message: 1. In a one-action PIP where there is no application level response message, when an AcknowledgementOfReceipt message has already been sent and a subsequent processing error is encountered. 2. In a one-action PIP when an AcknowledgementOfReceipt is not required and a processing error is encountered. 3. In a two-action PIP, when an AcknowledgementOfReceipt was sent followed by an application level response message and a subsequent processing error is encountered. This could occur at either the originator or receiver ends of the message exchange. 4. Sent by the originator when an AcknowledgementOfReceipt is required from the recipient and not received within the specified timeout and retry limits. In these cases a Notification of Failure PIP must be used to indicate the error. Otherwise the error is indicated with an Exception Signal Message. RNIF specifies that a Notification of Failure PIP is primarily used to indicate process level errors. For example, a timeout error occurs when the message cannot be delivered in the specified time and after the specified number of retries (specified in individual PIPs). In this case, since OAGI does not have process definitions, the use of this PIP is not directly applicable to the OAGI application. However, it is still required from the RNIF perspective. In a discrete system model it may be desirable to indicate to the originating OAGI system that the message was not delivered, in which case an appropriate ConfirmBOD can be generated. Message Communication Failure Sequence Diagrams and Guidelines The following diagrams depict potential error conditions that will result in the creation of a ConfirmBOD that is returned to the originating OAGI system in a discrete system model. This is not necessary in a composite system model. It also assumes that the use of a ConfirmBOD is enabled in the originating OAG message. In a pure RNIF implementation these error conditions are reported through the use of PIP 0A1 Notification of Failure. This is required for RosettaNet aware implementations but is not appropriate for RNAdapter to OAGAdapter communication. Rather a ConfirmBOD with STATUSLVL= 99 is used to indicate the error. OAG Buyer : OAGAdapter RN B2B Buyer : (RNAdapter) RN B2B Seller : (RNAdapter) OAG Seller : OAGAdapter 1: ProcessPO 2: Failed Transport 3: ConfirmBOD Version 2.0 Page 14 of 33 Last Modified: 2/21/2001

15 OAG Buyer : OAGAdapter RN B2B Buyer : (RNAdapter) RN B2B Seller : (RNAdapter) OAG Seller : OAGAdapter 1: ProcessPO 2: RN wrapped ProcessPO 3: Failed Delivery 4: Failed Acknowledgement 5: ConfirmBOD Sequence Diagram 7: Communication Level Failures The diagrams in Diagram 7 show the message sequence when the RNIF infrastructure fails to transport the RosettaNet wrapped message or fails to deliver the message to the OAGI based recipient. This may be a result of transport level errors or timeout conditions as defined in the RosettaNet PIP. In the case of a timeout condition as a result of Failed Delivery (3), no message is returned by the RNAdapter because it is the responsibility of the sending RNAdapter to determine that the timeout and retry limits have been exceeded. This is indicated by Failed Acknowledgment (4) psuedo-message. Message Header Mappings Mapping 1: Preamble Mapping The Preamble contains general reference and version information and requires no changes to support OAGI (see Appendix 1 Preamble Example). The following table describes the elements. RosettaNet field names are shown as XPath expressions relative to Preamble. An example is provided in Appendix 1 Preamble Mapping Synopsis. RosettaNet Preamble Element Related OAGI Area Description and comments Recommended Action StandardName/ GlobalAdministeringAuthorityCode Instance from set of codes identifying administrating authority (e.g. RosettaNet) Use per RNIF (e.g. RosettaNet) StandardVersion/ VersionIdentifier Identifies version number of standard. When Standard Name is RosettaNet, for a message compliant with RNIF this value MUST be Legend: Green indicates no action required Yellow indicates a one-time action such as specifying a static value Blue indicates run-time action such as value translation Use per RNIF (e.g ) Mapping 2: DeliveryHeader Mapping The DeliveryHeader contains route and message instance information (see Appendix 2 DeliveryHeader Example). The following table describes the relationship for all approaches. RosettaNet field names are shown as XPath expressions relative to DeliveryHeader. An example is provided in Appendix 2 DeliveryHeader Mapping Synopsis. Version 2.0 Page 15 of 33 Last Modified: 2/21/2001

16 RosettaNet DeliveryHeader Element Related OAGI Area Description and comments Recommended Action issecuretransportrequired/ AffirmationIndicator Affirmative value indicates secure message transfer. Use per RNIF messagedatetime/ DateTimeStamp CNTROLAREA/ DATETIME The data and time the message was created. RosettaNet uses ISO 8601 standard for encoding. OAGI uses explicit fields. Translate to and from OAGI and RosettaNet formats. messagereceiveridentification/ PartnerIdentification/ domain PARTNER/ DUNSNUMBER "DUNS" is currently the only valid entry. OAGI does not specify a partner identification domain. If DUNS is not acceptable, use Other to indicate proprietary domain. messagereceiveridentification/ PartnerIdentification/ GlobalBusinessIdentifier PARTNER/ DUNSNUMBER A unique business identifier. The DUNS number is specified by RosettaNet. Use DUNS number to identify partner. If not acceptable use proprietary identification number. messagereceiveridentification/ PartnerIdentification/ locationid CNTROLAREA / SENDER/ LOGICALID Identifies a logical business location associated with the trading partner. Directly analogous to OAGI field. Optionally associate with the OAGI CNTROLAREA/ SENDER/ LOGICALID messagesenderidentification/ PartnerIdentification/ domain PARTNER/ DUNSNUMBER "DUNS" is currently the only valid entry. OAGI does not specify a partner identification domain. If DUNS is not acceptable, use Other to indicate proprietary domain. messagesenderidentification/ PartnerIdentification/ GlobalBusinessIdentifier PARTNER/ DUNSNUMBER A unique business identifier. The DUNS number is specified by RosettaNet. Use DUNS number to identify partner. If not acceptable use proprietary identification number. messagesenderidentification/ PartnerIdentification/ locationid CNTROLAREA / SENDER/ LOGICALID Identifies a logical business location associated with the trading partner. Analogous to OAGI field. Optionally associate with OAGI CNTROLAREA/ SENDER/ LOGICALID messagetrackingid/ InstanceIdentifier CNTROLAREA/ SENDER/ REFERENCEID A unique alpha-numeric identifier that represents a specific instance of a business process, business transaction, business action or business signal. The instance identifier must be unique for a particular instance of a business process, business transaction, business action and business signal. Use per RNIF best practices. A one-to-one relationship between REFERENCEID and InstanceIdentifier is required. VersionIdentifier A field indicating the overall release number for the RNIF. Legend: Green indicates no action required Yellow indicates a one-time action such as specifying a static value Blue indicates run-time action such as value translation Use per RNIF The use of the DeliveryHeader only poses minor implications, that of the use of DUNS number to identify the partner. Since RNIF allows the specification of a domain value, the OAGI can use this field as it was intended, obviating the requirement that DUNS is the only valid value. Version 2.0 Page 16 of 33 Last Modified: 2/21/2001

17 Approach A: Normative ServiceHeader Guidelines Approach A follows the RosettaNet recommendation for the use of third party content in RNIF. In addition to defining the content for the necessary fields, a one-to-one mapping between RosettaNet Action Messages and OAGI BODs is required (see Appendix 4 RosettaNet Action Messages and OAGI BOD Alignment). Mapping 3A: Normative ServiceHeader Mapping This table describes the mapping between the RosettaNet ServiceHeader and the OAGI BOD architecture to support communication of OAG BODs that align with RosettaNet PIP Action Messages. Only those fields that require mapping or explanation are listed. Fields from the RosettaNet ServiceHeader that are not explicitly discussed are expected to be used as per the RNIF. RosettaNet field names are shown as XPath expressions relative to ServiceHeader. An example is provided in Appendix 3A - Example Normative ProcessPO and PIP 3A4. RosettaNet ServiceHeader Element Related OAGI Area Description and comments Recommended Action ActivityControl/ MessageControl/ Manifest/ ServiceContentControl/ ActionIdentity/ GlobalBusinessActionCode CNTROLAREA/ BSR/VERB CNTROLAREA/ BSR/NOUN BOD name Code identifying a business action defined from values identified in PIPs. Defines the message for the third party content. Use Per RNIF Use OAGI BOD name which includes the BOD version number (e.g. 003_process_po_005) ActivityControl/ MessageControl/ Manifest/ ServiceContentControl/ ActionIdentity/ messagestandard Standards Organization Name A value only needs to be specified for non- RosettaNet entities. The name of the third party standards organization. Use Per RNIF Use Open Application Group, Inc. ActivityControl/ MessageControl/ Manifest/ ServiceContentControl/ ActionIdentity/ StandardVersion/ VersionIdendifier The major version number of the OAGI specification A value only needs to be specified for non-rosettanet entities. Use version number of the third party standards organization messages. Use Per RNIF Use OAGI version number (e.g ) ActivityControl/ MessageControl/ Manifest/ ServiceContentControl/ ActionIdentity/ VersionIdentifier CNTROLAREA/ BSR/ REVISION Identifies the version number of the Action Message. Use OAGI BOD version number (e.g. 005). partnerdefinedpippayloadbindingid/ ProprietaryReferenceIdentifier A value only needs to be specified for non-rosettanet entities. No explicit instructions from RNIF. No explicit instructions from RNIF. Identifies the binding between the third party content and RosettaNet PIP. Use Per RNIF Use OAGI and PIP identifier as per the formula OAGI_PIP (e.g. OAGI_3A4). If more than one BOD for the PIP append with OAG BOD noun (e.g. OAGI_1A1_Customer) Note: The areas highlighted in gray are the RosettaNet defined fields for use with third party content. Version 2.0 Page 17 of 33 Last Modified: 2/21/2001

18 Legend: Green indicates no action required Yellow indicates a one-time action such as specifying a static value Blue indicates run-time action such as value translation Approach B: Non-Normative ServiceHeader Guidelines Approach B does not follow the RosettaNet recommendation for the use of third party content. It is necessary to support the communication of all OAG BODs. Currently there are more OAGI BODs than there are RosettaNet PIPs (see Appendix 5 List of OAGI BODs). This approach usurps the ServiceHeader by defining rules to map OAGI content to RosettaNet fields. The result is the definition of a PIP -independent ServiceHeader. Whether or not a message exchange is one-action or two-action is determined by the implications of the OAGI message set. Mapping 3B: Non-Normative ServiceHeader Mapping This table describes the mapping between the RosettaNet ServiceHeader and the OAGI BOD architecture to support communication of all OAG BODs. Only those fields that require mapping or explanation are listed. Fields from the RosettaNet ServiceHeader that are not explicitly discussed are expected to be used as per the RNIF. RosettaNet field names are shown as XPath expressions relative to ServiceHeader. A complete example is provided in Appendix 3B Example non-normative ProcessPO and PIP 3A4. RosettaNet ServiceHeader Element Related OAGI Area Description and comments Recommended Action ActivityControl/ BusinessActivityIdentifier CNTROLAREA / SENDER/ TASK PIP defined value (e.g. Create Purchase Order). Generally a one-to-one relationship with message. Analogous to OAGI field. Associate with the OAGI CNTROLAREA/ SENDER/TASK field. ActivityControl/ MessageControl/ fromrole/ GlobalPartnerRoleClassificationCode PARTNER/ PARTNRROLE PIP defined values are directly analogous to OAGI s PARTNRROLE field for which OAGI also defines values. (e.g. Buyer) Use existing OAGI values from DATAAREA/ PARTNER/ PARTNRROLE field definition. ActivityControl/ MessageControl/ fromservice/ GlobalBusinessServiceCode CNTROLAREA / SENDER/ COMPONENT PIP defined values generally related to the Role (e.g. Buyer Service). Roughly analogous to the components shown in OAGI s scenario diagrams, but OAGI makes no explicit relationship between the s cenario diagrams and the COMPONENT field. Use values from the OAG defined list of components (see Appendix 6). Associate with the OAGI CNTROLAREA/ SENDER/ COMPONENT field. ActivityControl/ MessageControl/ Manifest/ ServiceContentControl/ ActionIdentity/ GlobalBusinessActionCode ActivityControl/ MessageControl/ Manifest/ ServiceContentControl/ ActionIdentity/ messagestandard ActivityControl/ CNTROLAREA/ BSR/VERB CNTROLAREA/ BSR/NOUN BOD name Standards Organization Name The major version number Code identifying a business action defined from values identified in PIPs. Defines the message for the third party content. A value only needs to be specified for non- RosettaNet entities. The name of the third party standards organization. A value only needs to be specified for non-rosettanet Use Per RNIF Use OAGI BOD name which includes the BOD version number (e.g. 003_process_po_005) Use Per RNIF Use Open Application Group, Inc. Use Per RNIF of the OAGI entities. Version 2.0 Page 18 of 33 Last Modified: 2/21/2001

19 MessageControl/ Manifest/ ServiceContentControl/ ActionIdentity/ StandardVersion/ VersionIdendifier of the OAGI specification entities. Use version number of the third party standards organization messages. Use OAGI version number (e.g ) ActivityControl/ MessageControl/ Manifest/ ServiceContentControl/ ActionIdentity/ VersionIdentifier CNTROLAREA/ BSR/ REVISION Identifies the version number of the Action Message. Use OAGI BOD version number (e.g. 005). ActivityControl/ MessageControl/ torole/ GlobalPartnerRoleClassificationCode PARTNER/ PARTNRROLE PIP defined values are directly analogous to OAGI s PARTNRROLE field for which OAGI also defines values. (e.g. Buyer) Use existing OAGI values from DATAAREA/ PARTNER/ PARTNRROLE field definition. ActivityControl/ MessageControl/ toservice/ GlobalBusinessServiceCode CNTROLAREA / SENDER/ COMPONENT Although OAGI does not use destination COMPONENT. PIP defined values generally related to the Role (e.g. Buyer Service). Roughly analogous to the components shown in OAGI s scenario diagrams, but OAGI makes no explicit relationship between the scenario diagrams and the COMPONENT field. Use values from the OAG defined list of components (see Appendix 5). Associate with the OAGI CNTROLAREA/ SENDER/ COMPONENT field. GlobalUsageCode Defines deployment usage from either Test or Production Use per RNIF KnownInitiatingPartner/ PartnerIdentification/ domain/ FreeFormText Identifies the value domain for the partner identification field GlobalBusinessIdentifier. Currently RosettaNet specifies that this must be DUNS. OAGI does not specify a partner identification domain. If DUNS is not acceptable and no other existing domain is used, use Proprietary KnownInitiatingPartner/ PartnerIdentification/ GlobalBusinessIdentifier PARTNER/ PARTNRID PARTNER/ DUNSNUMBER Directly analogous to PARTNRID field. OAGI also has an explicit and optional DUNS NUMBER field. If DUNS number is used, both OAGI fields should contain the same value. Use DUNS number to identify partner. If not acceptable use identification number of other domain identified above. KnownInitiatingPartner/ PartnerIdentification/ locationid/ FreeFormText CNTROLAREA / SENDER/ LOGICALID Identifies a logical business location associated with the trading partner. Analogous to OAGI field. Optionally associate with OAGI CNTROLAREA/ SENDER/ LOGICALID partnerdefinedpippayloadbindingid/ ProprietaryReferenceIdentifier A value only needs to be specified for non-rosettanet entities. No explicit instructions from RNIF. No explicit instructions from RNIF. Optional field, not used in this non-normative approach. Identifies the binding between the third party content and RosettaNet PIP. pipcode/ GlobalProcessCode The numerical identifier for the PIP (e.g. 3A4). Required field, identifies fictitious PIP code in this nonnormative approach. Use 0A0. Version 2.0 Page 19 of 33 Last Modified: 2/21/2001

20 pipinstanceid/ InstanceIdentifier CNTROLAREA / SENDER/ REFERENCEID A unique alpha-numeric identifier that represents a specific instance of a business process, business transaction, business action or business signal. The instance identif ier must be unique for a particular instance of a business process, business transaction, business action and business signal. Use per RNIF best practices. Associate with the OAGI CNTROLAREA/ SENDER/ REFERENCEID if it meets requirements. pipversion/ VersionIdentifier Version number of the PIP (e.g ) Required field, identifies PIP version (e.g ) Version 2.0 Page 20 of 33 Last Modified: 2/21/2001