ebXML Transport, Routing
and Packaging
Proof of Concept Proposal - Working
Draft
Version
ebXML POC Proposal v0.85
Author
Marc Breissinger <[email protected]>
Prasad Yendluri <[email protected]>
Contributors
Nick Kassem <[email protected]>
Chris Ferris <[email protected]>
Philippe De Smedt <[email protected]>
Jim Hughes <[email protected]>
Sanjay Patil <[email protected]>
*** DRAFT ***
.
.
.
.
.
Overview
.
.
This document
. is a draft proposal whose purpose is to convey the current state of the
ebXML Transport, Routing and Packaging Proof of Concept definition and to solicit
Last saved by Marc Breissinger
Last saved 7/28/2017 9:36:00 PM
81895043
additional input.
The purpose of the Proof of Concept is to build the appropriate, interoperable, ebXML
TRP infrastructure that enables ebXML participants to:

Prove the viability of the ebXML TR&P specification to enable dynamic trading
networks

Highlight the applicability of ebXML TR&P for point-to-point, hub and spoke and
federated models of B2B communication

Dynamically create demonstration scenarios from different ebXML constituent
industries using different payload types (e.g., OTA, GCI, etc.) quickly and easily
The approach is to create a simulated trading network in which each vendor represents a
trading partner within the network. Each trading partner can take on one of four roles
within the network:

Requester – an initiator of the demonstration business process

Responder – the target of the message sent from the initiator

Requester/Responder – a trading partner that is able to both initiate a
demonstration business process and receive the message from another initiator

Hub – an intermediate entity that routes documents between source and target
Requesters can communicate to responders via the hub or directly. That flexibility allows the
demonstration environment to simulate point-to-point, hub and spoke and federated models of
communication. Additionally, trading partners can be dynamically added to the network and participate
in processes by declaring which roles they will fulfill. The following diagram represents the topology of
the proposed trading network:
Req/
Resp
Req
Resp
Hub
Req/
Resp
Resp
Req
Figure 1
2
.
.
.
.
This topology will enable the environment to support multiple business process scenarios
.
across different vertical industries by simply overlaying the target business process onto
.
the topology. Participants in the demonstrations can assume different roles in different
.
business processes.
.
Last saved by Marc Breissinger
Last saved 7/28/2017 9:36:00 PM
81895043
RosettaNet Demo Scenario
The initial proof of concept demonstration scenario involves the execution of RosettaNet
PIP3A4 (Create Purchase Order business process) among the participants in the
environment. Specifically, the appropriate RosettaNet action and signal messages as
defined in the PIP specification will be transported within the ebXML TR&P framework.
The RosettaNet PIP3A4 scenario was chosen because it is a well defined and understood
business process that is in use in production today. The selection of PIP3A4 does not
represent an endorsement of the RosettaNet process or message definitions by the
ebXML TR&P working group. Future demonstration scenarios will likely feature processes
and messages from other standards and industries.
Business Process
The business process to be modeled will initially be limited to the Create Purchase Order
transaction of RosettaNet PIP3A4. The Cancel Purchase Order and the Change
Purchase Order transactions will not be demonstrated due to the time constraints before
the initial demonstration. They may be added as extensions in the future. The following
diagram (figure 2) depicts the message flow of the transaction:
Requester
Responder
1. 3A4 PO Request
2. Receipt Ack
3. 3A4 PO Acceptance
4. Receipt Ack
Figure 2
For the sake of simplicity, this diagram does not include the hub role. It is assumed that
the hub is inserted into each message path.
It is critical to note that the acknowledgements depicted in the business process scenario
above (steps 2 and 4) are business process level acknowledgements as defined in the
RosettaNet specification and are not transport level acknowledgements. They are
therefore treated as business process level messages within the demonstration
environment (acknowledgement data is carried within the payload of the ebXML
message). Transport level acknowledgements are discussed in the section “Reliable
Messaging” below.
3
.
.
.
.
It is recommended that responders introduce a configurable delay between steps 2 and 3
.
to simulate back-end processing of payloads.
.
The diagram .above (figure 2) also depicts only the positive scenario, where requests and
. are sent and received as expected. Due to the nature and time
acknowledgements
Last saved by Marc Breissinger
Last saved 7/28/2017 9:36:00 PM
81895043
constraints of the proof of concept, it is unlikely that that there will be a need to model the
possible errors that may occur in the scenario.
Vendor Roles
The following table details the roles that individual participants will play within the demo
environment for the RosettaNet PIP3A4 Create Purchase Order scenario.
Participant
Role
Fujitsu
Requester
Sun Microsystems
Responder
NetFish
Requester/Responder
Viquity
Hub
Vitria
Requester/Responder
webMethods
Requester/Responder
Figure 3
The following actions must be supported by each vendor assuming each role:

Requester. As the initiator of the PIP3A4 process, the requester must be able to :
1. Send (3A4) Purchase Order Request Action messages
2. Receive Receipt Acknowledgement messages for sent (3A4) Purchase
Order Request Action messages
3. Receive (3A4) Purchase Order Acceptance Action messages for sent
(3A4) Purchase Order Request Action messages
4. Send Receipt Acknowledgement messages for received (3A4) Purchase
Order Acceptance Action messages

Responder. As the target of the initating message from the initiator, the
responder must be able to:
1. Receive (3A4) Purchase Order Request Action messages
2. Send Receipt Acknowledgement messages for received (3A4) Purchase
Order Request Action messages
3. Send (3A4) Purchase Order Acceptance Action for received (3A4)
Purchase Order Request Action messages
4. Receive Receipt Acknowledgement messages for sent (3A4) Purchase
Order Acceptance Action messages
4
.
.
.
.
Requester/Responder. The requester/responder must support all actions defined
.
above for the requester and the responder.
.
Hub.. As an intermediary between requester and responder, the hub must be
able .to route all defined messages between requester and responder without
Last saved by Marc Breissinger
Last saved 7/28/2017 9:36:00 PM


81895043
altering the header or payload of the messages.
Business Data
The successful implementation of the demonstration is nearly independent of the
information contained in the message payloads. However, certain business data is
required in order to populate the message header appropriately. Specifically, a partner ID
scheme must be agreed upon to identify the trading partners involved in a transaction. It
has been agreed among the participants that a DUNS number will be assigned to each
participant in the environment for identification. The following table represents the current
participants and their assignments:
Participant
DUNS Number
Fujitsu
111111111
NetFish
222222222
Sun Microsystems
333333333
Viquity
444444444
Vitria
555555555
webMethods
666666666
Figure 4
Payloads generated for the messages should adhere to the appropriate RosettaNet PIP
3A4 DTD specifications.
ebXML Technical Details
Hub Routing
As noted earlier, the topology of the demonstration environment allows for point-to-point,
hub-spoke and federated models of communication. This proof-of-concept will utilize a
hub-spoke model. The restriction place upon those participants who assume the role of
“Hub,” is that the inclusion of the hub should not cause any alteration of the header or
payload of the messages. The only difference between the hub and the point-to-point
scenarios should be the transport level destinations of the messages (e.g., URL for HTTP
post).
Packaging
The most recent version of the ebXML TR&P Packaging specification (v0.6 as of 27-July00) should be followed for demonstration communications. Values in bold italic blue are
generated dynamically by the participant according to the pattern shown. Values in bold
are fixed for a particular message, but may change for different messages. Values in
normal text are fixed and common to all messages. An example is shown below:
5
.
.
.
.
Content-Type: multipart/related;
. type=”application/vnd.eb+xml”;
. charset="iso-8859-1";
. version=0.1;
. boundary=unique-string-within-message
Content-Length:
int-length
Last saved by Marc Breissinger
Last saved 7/28/2017 9:36:00 PM
81895043
--unique-string-within-message
Content-ID: uid@originator-domain
Content-Length: int-length [units based on content-transfer-encoding]
Content-Type: application/vnd.eb+xml
<?xml version="1.0" encoding="UTF-8"?>
<ebXMLHeader>
....
</ebXMLHeader>
--unique-string-within-message
Content-ID: uid@originator-domain
Content-Length: int-length [units based on content-transfer-encoding]
Content-Type: application/xml
<RN-Action-Message> or <RN-Signal-Message>
--unique-string-within-message--
Header
The most recent version of the ebXML TR&P Header specification (v0.63 as of 27-July00) should be followed for demonstration communications. The following sections show
the header values for each of the four messages within the Create Purchase Order
scenario. Values in bold italic blue are generated dynamically by the participant
according to the pattern shown. Values in bold are fixed for a particular message, but
may change for different messages. Values in normal text are fixed and common to all
messages. Note that the term “originator” refers to the creator and sender of an individual
message instance and does not necessarily correspond to the “requester” role in the
process.
3A4 PO Request
<?xml version ="1.0"?>
<!DOCTYPE ebXMLHeader SYSTEM "...">
<ebXMLHeader xmlns = “http://www.ebxml.org/namespaces/messageHeader"
Version = "1.0"
MessageType = "Normal">
<Manifest>
<DocumentReference>
<DocumentLabel>Purchase Order Request Action</DocumentLabel>
<DocumentId>
cid:uid@originator-domain [C-ID of the payload MIME part]
</DocumentId>
</DocumentReference>
</Manifest>
<Header>
<From>
<PartyId context = "DUNS">requester-DUNS-number</PartyId>
</From>
<To>
<PartyId context = "DUNS">responder-DUNS-number</PartyId>
</To>
<TPAInfo>
<TPAId context = "tpadb">
/requester-DUNS-number/responder-DUNS-number/PIP3A4/1.1
</TPAId>
<ConversationId context = “CreatePurchaseOrder">
6
Last saved by Marc Breissinger
Last saved 7/28/2017 9:36:00 PM
.
.
.
. uid@requester-domain
. </ConversationId>
. <BusinessServiceInterface>
Seller Service
. </BusinessServiceInterface>
. <Action version=”1.1”>Purchase Order Request Action</Action>
81895043
</TPAInfo>
<MessageData>
<MessageId>uid@requester-domain</MessageId>
<TimeStamp>CCYYMMDDThhmmss.sssZ</TimeStamp>
<RefToMessageId>Not Applicable</RefToMessageId>
</MessageData>
<ReliableMessagingInfo DeliverySemantics = "Unspecified"/>
</Header>
</ebXMLHeader>
3A4 PO Request Receipt Acknowledgement
<?xml version ="1.0"?>
<!DOCTYPE ebXMLHeader SYSTEM "...">
<ebXMLHeader xmlns = “http://www.ebxml.org/namespaces/messageHeader"
Version = "1.0"
MessageType = "Normal">
<Manifest>
<DocumentReference>
<DocumentLabel>
Purchase Order Request Acknowledgement
</DocumentLabel>
<DocumentId>
cid:uid@originator-domain [C-ID of the payload MIME part]
</DocumentId>
</DocumentReference>
</Manifest>
<Header>
<From>
<PartyId context = "DUNS">responder-DUNS-number</PartyId>
</From>
<To>
<PartyId context = "DUNS">requester-DUNS-number</PartyId>
</To>
<TPAInfo>
<TPAId context = "tpadb">
/requester-DUNS-number/responder-DUNS-number/PIP3A4/1.1
</TPAId>
<ConversationId context = “CreatePurchaseOrder">
uid@requester-domain [from request message]
</ConversationId>
<BusinessServiceInterface>
Buyer Service
</BusinessServiceInterface>
<Action version=”1.1”>
Receipt Acknowledgement
</Action>
</TPAInfo>
<MessageData>
<MessageId>uid@responder-domain</MessageId>
<TimeStamp>CCYYMMDDThhmmss.sssZ</TimeStamp>
<RefToMessageId>
uid@requester-domain [from request message]
</RefToMessageId>
</MessageData>
<ReliableMessagingInfo DeliverySemantics = "Unspecified"/>
</Header>
</ebXMLHeader>
7
.
.
.
.
.
.
3A4 PO Acceptance
.
. ="1.0"?>
<?xml version
Last saved by Marc Breissinger
Last saved 7/28/2017 9:36:00 PM
81895043
<!DOCTYPE ebXMLHeader SYSTEM "...">
<ebXMLHeader xmlns = “http://www.ebxml.org/namespaces/messageHeader"
Version = "1.0"
MessageType = "Normal">
<Manifest>
<DocumentReference>
<DocumentLabel>Purchase Order Acceptance Action</DocumentLabel>
<DocumentId>
cid:uid@originator-domain [C-ID of the payload MIME part]
</DocumentId>
</DocumentReference>
</Manifest>
<Header>
<From>
<PartyId context = "DUNS">responder-DUNS-number</PartyId>
</From>
<To>
<PartyId context = "DUNS">requester-DUNS-number</PartyId>
</To>
<TPAInfo>
<TPAId context = "tpadb">
/requester-DUNS-number/responder-DUNS-number/PIP3A4/1.1
</TPAId>
<ConversationId context = “CreatePurchaseOrder">
uid@requester-domain [from request message]
</ConversationId>
<BusinessServiceInterface>
Buyer Service
</BusinessServiceInterface>
<Action version=”1.1”>Purchase Order Acceptance Action</Action>
</TPAInfo>
<MessageData>
<MessageId>uid@responder-domain</MessageId>
<TimeStamp>CCYYMMDDThhmmss.sssZ</TimeStamp>
<RefToMessageId>
uid@requester-domain [from request message]
</RefToMessageId>
</MessageData>
<ReliableMessagingInfo DeliverySemantics = "Unspecified"/>
</Header>
</ebXMLHeader>
3A4 PO Acceptance Receipt Acknowledgement
<?xml version ="1.0"?>
<!DOCTYPE ebXMLHeader SYSTEM "...">
<ebXMLHeader xmlns = “http://www.ebxml.org/namespaces/messageHeader"
Version = "1.0"
MessageType = "Normal">
<Manifest>
<DocumentReference>
<DocumentLabel>
Purchase Order Acceptance Receipt Acknowledgement
</DocumentLabel>
<DocumentId>
cid:uid@originator-domain [C-ID of the payload MIME part]
</DocumentId>
</DocumentReference>
</Manifest>
8
.
.
.
.
<Header>
.
<From>
. <PartyId context = "DUNS">requester-DUNS-number</PartyId>
</From>
.
<To>
. <PartyId context = "DUNS">responder-DUNS-number</PartyId>
Last saved by Marc Breissinger
Last saved 7/28/2017 9:36:00 PM
81895043
</To>
<TPAInfo>
<TPAId context = "tpadb">
/requester-DUNS-number/responder-DUNS-number/PIP3A4/1.1
</TPAId>
<ConversationId context = “CreatePurchaseOrder">
uid@requester-domain [from request message]
</ConversationId>
<BusinessServiceInterface>
Seller Service
</BusinessServiceInterface>
<Action version=”1.1”>
Receipt Acknowledgement
</Action>
</TPAInfo>
<MessageData>
<MessageId>uid@requester-domain</MessageId>
<TimeStamp>CCYYMMDDThhmmss.sssZ</TimeStamp>
<RefToMessageId>
uid@responder-domain [from acceptance message]
</RefToMessageId>
</MessageData>
<ReliableMessagingInfo DeliverySemantics = "Unspecified"/>
</Header>
</ebXMLHeader>
Payload
The payloads for the messages to be exchanged should conform to the appropriate
RosettaNet DTD specifications. Receipt Acknowledgement messages should be
populated with information from the TPA and the ebXML Message Header of the received
message in the manner described below. Values in bold italic blue are generated
dynamically by the participant according to the pattern shown. Values in bold are fixed for
a particular message, but may change for different messages. Values in normal text are
fixed and common to all messages. Note that the term “originator” refers to the creator
and sender of an individual message instance and does not necessarily correspond to the
“requester” role in the process.
<?xml version ="1.0"?>
<!DOCTYPE ReceiptAcknowledgement SYSTEM
“ReceiptAcknowledgementMessageGuideline.dtd">
<ReceiptAcknowledgement>
<fromRole>
<PartnerRoleDescription>
<ContactInformation>
<contactName>
<FreeFormText xml:lang = "EN">
TPA:Originator/Contact/LastName
</FreeFormText>
</contactName>
<EmailAddress>TPA:Originator/Contact/Email</EmailAddress>
<telephoneNumber>
<CommunicationsNumber>
TPA:Originator/Contact/ContactTelephone
</CommunicationsNumber>
</telephoneNumber>
</ContactInformation>
9
Last saved by Marc Breissinger
Last saved 7/28/2017 9:36:00 PM
.
.
.
.
.
.
.
.
81895043
<GlobalPartnerRoleClassificationCode>
Buyer | Seller
</GlobalPartnerRoleClassificationCode>
<PartnerDescription>
<BusinessDescription>
<GlobalBusinessIdentifier>
TPA:Originator/MemberId-DUNS
</GlobalBusinessIdentifier>
<GlobalSupplyChainCode>
Information Technology
</GlobalSupplyChainCode>
</BusinessDescription>
<GlobalPartnerClassificationCode>
Manufacturer
</GlobalPartnerClassificationCode>
</PartnerDescription>
</PartnerRoleDescription>
</fromRole>
<receivedDocumentDateTime>
<DateTimeStamp>
recvd ebXML:/Header/MessageData/TimeStamp
</DateTimeStamp>
</receivedDocumentDateTime>
<receivedDocumentIdentifier>
<ProprietaryDocumentIdentifier>
recvd ebXML:/Header/MessageData/MessageID
</ProprietaryDocumentIdentifier>
</receivedDocumentIdentifier>
<thisMessageDateTime>
<DateTimeStamp>
CCYYMMDDThhmmss.sssZ
</DateTimeStamp>
</thisMessageDateTime>
<thisMessageIdentifier>
<ProprietaryMessageIdentifier>
uid@originator-domain [must match ebXML header]
</ProprietaryMessageIdentifier>
</thisMessageIdentifier>
<toRole>
<PartnerRoleDescription>
<ContactInformation>
<contactName>
<FreeFormText xml:lang = "EN">
TPA:Receiver/Contact/LastName
</FreeFormText>
</contactName>
<EmailAddress> TPA:Receiver/Contact/Email </EmailAddress>
<telephoneNumber>
<CommunicationsNumber>
TPA:Receiver/Contact/ContactTelephone
</CommunicationsNumber>
</telephoneNumber>
</ContactInformation>
<GlobalPartnerRoleClassificationCode>
Buyer | Seller
</GlobalPartnerRoleClassificationCode>
<PartnerDescription>
<BusinessDescription>
<GlobalBusinessIdentifier>
TPA:Originator/MemberId-DUNS
</GlobalBusinessIdentifier>
<GlobalSupplyChainCode>
Information Technology
</GlobalSupplyChainCode>
</BusinessDescription>
<GlobalPartnerClassificationCode>
Manufacturer
10
.
.
.
.
</GlobalPartnerClassificationCode>
. </PartnerDescription>
.</PartnerRoleDescription>
</toRole>
.
</ReceiptAcknowledgement>
.
Last saved by Marc Breissinger
Last saved 7/28/2017 9:36:00 PM
81895043
Transport
The ebXML TR&P specification is transport independent. Therefore, the demonstration
environment will allow communication via multiple protocols. Allowing multiple protocols
(a) follows the spirit of the ebXML TRP specification; (b) enables broader
participation from the member base; and (c) provides a more compelling
demonstration. It must be noted that the most common protocol to be used at this
time is HTTP. Participants deviating from that protocol must ensure that other
participants are able to communicate via the selected protocol in order to participate
in the demonstration scenario. Current “Hub” participants can process only the HTTP
protocol.
It is suggested that, for the HTTP protocol, a minimal header should be utilized within the
transport envelope. The example HTTP header within the specification contains multiple
non-required fields. The following header is proposed for use in the demonstration
environment with the extraneous information proposed for removal struck-through:
POST destination-server-URI HTTP/1.1
Accept: multipart/related
Accept-Language: en-us
Accept-Encoding: gzip, deflate
User-Agent: Group 8760 InsideAgent
Host: destination-server-domain:destination-server-port
Connection: Keep-Alive
Content-Type: multipart/related;
type=”application/vnd.eb+xml”;
charset="iso-8859-1";
version=0.1;
boundary=unique-string-within-message
Content-Length: int-length
--unique-string-within-message
Security
In the interest of simplicity, it is recommended that security not be implemented within the
initial demonstration environment.
Document Validation
The RosettaNet specification requires that DTD validation be done on message payloads
before its business process level receipt acknowledgement is sent. Because of the
relative independence of the demonstration from payload contents, validation is not strictly
required for the success of the demonstration. Therefore, it is left up to the individual
participant whether or not payload validation actually occurs. It is critical, therefore, that all
payloads generated by any participants conform to the appropriate RosettaNet PIP3A4
DTD to ensure appropriate processing by those service providers that implement
validation. Note that the actual transmission of the well-formed receipt acknowledgement
messages is still required by the demonstration scenario even if validation is not
implemented.
11
.
.
.
. Agreements
Trading Partner
.
.
Each participating vendor must declare certain critical connectivity information in order to
.
help ensure interoperability and ease of demonstration assembly. Although planned for
.
the future, the current (as of 1-Aug-00) preliminary state of the integration of the tpaML
Last saved by Marc Breissinger
Last saved 7/28/2017 9:36:00 PM
81895043
specification with the TR&P specification prohibits its use for the initial demonstration.
Therefore, the information in the following tables will be used for connectivity until a tpaML
compatible TPA can be created. This information represents the minimum set of
information required to connect to a partner, populat the ebXML Header and populate the
RosettaNet Receipt Acknowledgement payload.
webMethods
Element
Value(s)
DUNS
666666666
Contact/Last Name
Breissinger
Contact/Email
[email protected]
Contact/Telephone
703-460-2500
Transaction Info
webMethods B2B handles all transactions over the same
delivery channels. Therefore, there is no differentiation of
connectivity information by transaction.
Connectivity Info
HTTP is the preferred protocol.
HTTP
http://ebxml.webmethods.com/invoke/wm.b2b.ebxml/receive
SMTP
[email protected]
FTP
hostname=ebXML.webmethods.com
port=8021
username=Default;password=<none>
path=/ns/wm/b2b/ebxml/receive
file extension=ebx
Fujitsu
NetFish
Sun Microsystems
Viquity
Vitria
12
.
.
.
.
.
. and Issues
ebXML TRP Caveats
.
.
Reliable Messaging
Last saved by Marc Breissinger
Last saved 7/28/2017 9:36:00 PM
81895043
The reliable messaging portion of the ebXML TR&P specification was not ready in time for
incorporation into the demonstration environment. That specification will include the
definition of any required transport level acknowledgement requirements. It should be
added in time for the November meeting. Therefore, the initial POC will not incorporate
transport level acknowledgements.
13