In practice, a company with either type of B2B
gateway process (push vs. pull) can exchange data with companies
that have either type of B2B gateway process.
Many standards can be traded via the internet.
Some have specific requirements for transport and routing, and others
are "transport-neutral", meaning that the standard addresses
only payloads which can be sent using any transport protocol.
The business content standards that can be traded via the internet
include:
| Step |
Description |
| In this example, both
buyer and seller support the same B2B business content standard,
and the same messaging standards, including security and transport
protocols. |
| A. |
At start state A, preorder
and planning processes have occurred and the buyer is ready
to create a Purchase Order (PO). The trading partners
have a relationship already established; all applications and
parties involved in the exchange have the correct configurations
established, including registration of the trading partnership
in both B2B gateways. |
| 1. |
The buyer creates a
discrete (standalone) PO in the back-end application.
The buyer may save it if it is not ready to send, or may mark
it as ready to be transmitted and/or printed. |
| 2. |
The EAI software or
other B2B gateway application extracts the PO data.
The data may be extracted into a proprietary or application-specific
format such as SAP IDOC, Oracle data file, Baan EDI file, and
so on, or it may be extracted into a standard XML format. |
| 3. |
If needed, the B2B gateway
application maps (translates) the data into the standard format
used by the recipient. The target format may be any one
of several B2B business content standards, including ASC X12,
UN/EDIFACT, OAGIS XML, RosettaNet XML, or another XML business
content standard. |
| 4. |
The document is packaged
for transmission to the seller (a/k/a wrapping, enveloping).
- Just about all XML standards organizations agree on converging
to the ebXML standard for transport and routing. The
ebMXL TR is payload-neutral - payload for any standard can
be contained in an ebMXL package.
- OAGIS XML is transport-neutral. OAGI has
published white papers describing how to send and receive
OAGIS payloads using ebXML's Transport and Routing, the
BizTalk™ Framework, or the RosettaNet Implementation Framework
version 2.0.
- RosettaNet Implementation Framework (RNIF) version 1.1
requires RosettaNet-specific packaging that results in the
creation of a package called a "RosettaNet Object"
(RNO); only a RosettaNet payload can be contained in the
package.
- RosettaNet Implementation Framework (RNIF) version 2.0
is a step towards converging on the ebXML TR. It uses
a more standard enveloping (S/MIME), and allows the inclusion
of attachments containing non-RosettaNet payloads.
- The legacy EDI standards, X12 and EDIFACT, are transport
neutral, and like OAGIS XML, can be exchanged using any
standardized protocol.
|
| 5. |
EIDX recommends that
a sender validate their own outbound documents for compliance
with the standards before sending the documents to a trading
partner. |
| 6. |
The business document
is authenticated electronically through the attachment of a
digital signature, and is encrypted in preparation for secure
transporting. |
| 7. |
Purchase orders are
sent to the trading partner. Typically, the buyer's B2B
gateway is given a secure login to a directory on the seller's
gateway server, where the buyer deposits documents intended
for the seller. Buyers can access only their own directories,
and no buyer can access another buyer's directory. |
| B. |
Start state B indicates
that the seller's gateway is checking the server for deposited
files independently from the PO process. Typically, the
seller's B2B gateway polls trading partner directories every
n seconds to n minutes to see if any files have
been received. |
| 8. |
When files have been
received, the B2B gateway routes the files to a another directory.
The presence of files in this other directory invokes the appropriate
processing. |
| 9. |
The data is decrypted. |
| 10. |
The seller opens the
data file. Data is often received in one large file and
the recipient must parse it into separate files for each group
or document, so that the data can be translated. |
| 11. |
The seller checks the
incoming document for compliance against the standard. |
| 12. |
If required by the buyer,
the seller creates a receipt acknowledgment, which indicates
that the seller received the PO document at their gateway, and
whether or not it passed the compliance check. Just like
the PO document, the receipt acknowledgment needs to be packaged
and validated before being sent. Unlike the PO, which
is a document, the receipt acknowledgment is classified as a
service transaction.
- RosettaNet requires the use of a receipt acknowledgment.
|
| 13. |
If necessary, the B2B
gateway application maps (translates) the file into the format
expected by the back-end application. |
| 14. |
The seller processes
the PO to load it into their back-end application. |
| 15. |
The TPAdocuments the
buyer's expectation turnaround time on response documents.
Typically, a buyer expects a PO response to be sent in 24 to
72 hours. The seller should send a response within the
required time limit, indicating that the order was either accepted
or rejected. If the seller cannot confirm their ability
to meet the buyer's requirements for delivery, the seller should
indicate in the response that the commitment to requested dates
and quantities is pending, and then follow-up with another PO
response as soon as the commit information is available.
While the receipt acknowledgment (step 11) indicates that
the PO transmission made it to the seller's gateway, the PO
response tells the buyer that the order made it all the way
to the seller's back-end application.
|
| 16. |
Application software
extracts the PO response into a data file for transmission to
the B2B gateway. Assumption for this example: Back-end
interface generates proprietary format or application-specific
format such as SAP IDOC, Oracle data file, or Baan EDI file. |
| 17. |
The seller translates,
envelopes and validates the PO response before sending it.
These are the same activities the buyer performed for the PO
in steps 3, 4 and 5. |
| 18. |
PO responses are encrypted
and signed as in the buyer's step 6 above. |
| 19. |
The documents are transferred
as in the buyer's step 7 above. |
| C. |
Start state C is the
buyer's counterpart to the seller's start state B. |
| 20. |
When files have been
received, the B2B gateway routes the files to a another directory.
The presence of files in this other directory invokes the appropriate
processing. |
| 21. |
If it is used, the buyer
decrypts and opens and validates the receipt acknowledgment.
Unlike the PO, which is a document, the receipt acknowledgment
is classified as a "service" transaction. A
receipt acknowledgment is never created in response to
an receipt acknowledgment! |
| 22. |
The status of the PO
transmission is updated in the gateway to indicate that the
transmission was received by the seller. |
| 23. |
The buyer decrypts,
unwraps, validates and translates the data file just as in the
seller's steps 9, 10, 11, and 13. |
| 24. |
The buyer processes
the PO response to load it into their back-end application. It
indicates that the seller either accepts or rejects the PO.
|
| 25. |
If required by the seller,
the buyer creates and wraps a receipt acknowledgment, which
indicates that the buyer received the PO response document at
their gateway, and whether or not it passed the compliance check.
|
| 26. |
The buyer validates,
encrypts and signs the outbound receipt acknowledgment and then
transports it to the seller. |
| 27. |
When files have been
received, the B2B gateway routes the files to a another directory.
The presence of files in this other directory invokes the appropriate
processing. |
| 28. |
Seller decrypts, opens
and validates the receipt acknowledgment if it is used. |
| 29. |
The status of the PO
response transmission is updated in the gateway to indicate
that the transmission was received by the buyer. |
| D. |
At end state D, the
legal commitment to do business exists. The order is in
an open state until it has been entirely fulfilled. Some
orders are fulfilled immediately. Orders that remain open
for any length of time are subject to both buyer-initiated and
seller-initiated changes, and changes to the status of delivery
schedules per the main Order Model 1. |
| E. |
End state E is the seller's
counterpart to the buyer's end state D. |
contact
us 
