Getting Started with Oracle SOA B2B Integration: A Hands-On Tutorial

5 (1 reviews total)
By Krishnaprem Bhatia , Alan Perlovsky , Scott Haaland
  • Instant online access to over 7,500+ books and videos
  • Constantly updated with 100+ new titles each month
  • Breadth and depth in over 1,000+ technologies
  1. B2B Overview

About this book

Enterprises engaging in B2B communications with their trading partners are facing increased pressure to increase automation and reduce costs. Increased compliance requirements and globalization of economies is fueling B2B adoption in every industry. Gateway solutions in Oracle SOA B2B enable these enterprises to connect easily with external trading partners.

Getting Started with Oracle SOA B2B Integration: A Hands-On Tutorial will show you how to use Oracle B2B platform to extend your current business processes to connect with your external trading partners in an automated, secure fashion, using industry standard B2B protocols. It will show you how to set up documents, partners and agreements and manage your B2B transactions end-to-end, all the way from application to trading partners and vice versa

Starting with an introduction to the B2B industry you then be introduced to Oracle B2B and SOA platforms. You will then begin creat document definitions and get you started with trading partner management. Once you have a solid grounding you will then be taken into the more complex topic of SOA. Integration, reporting, and monitoring will all be covered in detail.

Then you will be shown how to secure your B2B distribution, security is an essential part of all businesses and B2B is no different. Finally you will be introduced to advanced topics that should give you the skills and knowledge to easily go out and do all of this again with next to no guidance.

Utilizing the combined experienced of one of the most knowledgeable Oracle B2B author teams assembled this step-by-step practical guide provides you with the essential information required to implement Oracle B2B solutions including multiple hands-on tutorials that will help you get up and running quickly.

Publication date:
July 2013


Chapter 1. B2B Overview

Business-To-Business (B2B) electronic document exchange refers to transactions conducted between enterprises, and within an enterprise via the proprietary networks called Value Added Networks (VAN), or via the Internet. These transactions involve sending an electronic version of documents in a standardized format. B2B allows companies to achieve significant operational savings by reducing the costs of doing business, and enhancing the relationship between the trading partners. B2B also enables companies to comply with government mandated regulations, such as HIPAA and Sarbanes-Oxley. In this chapter we will learn about the following:

  • B2B Architecture

  • B2B Gateway

  • B2B Standards


A brief history of B2B electronic document exchange

The need to ensure the secure and reliable exchange of business documents between trading partners has been the driving force behind B2B emergence. Whether it was the East India Company in the XVII century, when the only means of communication was a letter by boat, or, almost 300 years later, during the Berlin Airlift of 1948, when the lack of a common format created the enormous logistical headaches. The demand for an efficient communication system between the trading partners' disparate systems, data formats, and communication protocols grew stronger and stronger. So when a professor of Arts and Design at New York University, Samuel Morse on May 24, 1844, sent the message "What hath God wrought?" from the old Supreme Court chamber in the United States Capitol to his partner in Baltimore, we can say that this was the first step for electronic exchange to become reality.

However, only in the 1960s, when the rail line and transportation industries began transmitting data electronically, electronic data exchange was officially born. While the telegraph made transmission paperless and allowed sending multiple messages on a single wire, it did not eliminate the human error factor, nor did it introduce common standards for trading partners to comply to. Only the emergence of Electronic Data Interchange (EDI) was able to finally provide a mechanism for standardized electronic exchange. The first EDI steps were costly to implement and nearly impossible to deploy across a large number of organizations. Recognizing this, the American National Standards Institute (ANSI) moved to standardize the EDI space. As a result, the ANSI ASC X.12 (ANSI X12) standard was established. This standard was the first to define the cross-industry data formats, and encoding rules required for a multitude of business transactions, such as order placement and processing, shipping/receiving, invoicing, and payment, among many others. As the first implementations of X12 standards were being deployed in North America, the European community was implementing its own EDI standard called Electronic Data Interchange For Administration, Commerce and Transport (EDIFACT). While EDIFACT became very popular in Asia and Europe, for a long time it has been almost non-existent in the United States. However, lately it has begun to make some inroads specifically after the US government adopted the use of EDIFACT. In the 1980s, VANs, a private network dedicated to the secure exchange of EDI traffic, emerged as a way to connect supply chain participants using EDI. They offered store-and-forward mailboxes that provided protocol conversion, security, and guaranteed delivery. However, EDI VANs proved to be too costly for most businesses. Only the largest of supply chain participants could afford the expensive setup fees associated with the EDI implementation, not to mention the sometimes exorbitant per-transaction fees. This meant that many small and midsize firms couldn't afford to join the new wave of automated electronic supply chains. Since the smaller companies couldn't partake in this new technology, the larger corporations that continued to do business with them continued to fall victim to the burden of traditional, paper-based processes.

When the Internet matured, the B2B technology paradigm fundamentally changed. Internet protocols such as HTTP, FTP, and SMTP opened up a possibility of sending and receiving transactions over the Internet. Thus the Internet spawned the creation of a massive industry, collectively called e-commerce. In the late 1990s, the new technology called EDI over Internet (EDIINT) with Application Statement 1 (AS1) was released. The AS1 protocol used an Internet e-mail protocol called Simple Mail Transport Protocol (SMTP) as the foundation for exchanging documents, which for the first time enabled the large companies to become securely connected to each other over the Internet.

Despite initial promises and enthusiasm, the companies were reluctant to adopt it. The main concerns were the fears of IT departments, believing that EDI traffic would overload enterprise e-mail servers. To mitigate these concerns, the next incarnation of EDIINT emerged in 2001 with the new AS2 protocol superseding the predecessor. The major distinction was that AS2 was based upon the HTTP protocol instead of AS1′s reliance on the e-mail based SMTP protocol. However, despite a significant interest, AS2 was initially still unable to reach mainstream wholesale adoption from large corporate enterprises. All this changed when Wal-Mart announced, in September 2003, that it would implement EDIINT AS2 with suppliers, instead of using a VAN. This was a signal that EDI over the Internet was ready for heavy-duty corporate use after years of development.

Although X12 and EDIFACT had been the accepted standard for a long time, the EDI data was not self-describing, and thus, hard to understand by a human. Hence, the companies were looking for alternatives, and emergence of XML gave hopes to the B2B community. New groups of non-profit organizations were formed to provide an alternative to EDI. Dozens of new XML-based standards were developed to satisfy the needs of different verticals. For example, RosettaNet became widely spread in global semiconductors, electronic components, consumer electronics, and telecommunication and logistics. Another XML-based standard, electronic business XML (ebXML) was released in 1999 with the objective that any business of any size in any industry could do business with any other business anywhere in the world. Despite a slow start, it has recently gained more and more popularity. What is promising is that, while RosettaNet, despite introducing important technical innovations, failed to attract participants outside the semiconductor industry, ebXML was adopted by the companies across multiple industries. Although EDI still holds 80 percent of the B2B market, XML is on its way to become commonplace.

Today B2B is no longer business commerce only. Medical records, catalogs, and even engineering drawings can be sent electronically. With the states passing the laws allowing the use of electronic seals and signatures, documents such as contracts and applications can be signed electronically, and sent across the wire.


B2B market and technical trends

The business climate for B2B e-commerce has shifted dramatically in the last several years. Many factors are responsible for this change. Compliance has become an important point in many companies. Every industry in any part of the world is struggling to maintain compliance due to a myriad of new regulations.

In this tough economic climate, businesses are forced to do more with less, while trying to find ways to improve their bottom line. This in turn has prompted many enterprises to consider moving from traditional but an expensive EDI over VAN exchanges, to the Internet-based implementations. Nevertheless, high costs are not the only concern. It takes a lot of time to modify an existing X12 EDI standard-based document. Some implementations require these changes to be made on the regular basis. This process could quickly become a maintenance nightmare. It forces many businesses to re-evaluate their existing B2B implementation. The new emerging B2B standards, such as RosettaNet and ebXML, could offer a more manageable solution.

These changes in business climate inevitably trigger technology changes. The most noticeable trend is an increased demand for multi enterprise/B2B solutions. At the same time, the number of features from integration software vendors has been extended to include process visibility, service bus, and adapters, to name a few. The net effect of this development is that distinction between B2B technology and integration software is blurring. As a result, B2B capabilities will simply be a feature of integration middleware providing the eventual externalization of the integrated data. It will provide easier integration of ERP applications with external partners, end-to-end visibility, improved maintenance, and governance using a common tool. Increased maturity of standards such as XML, RosettaNet, ebXML, and SOA will trigger their use in B2B exchange, thus, avoiding a tightly coupled point-to-point integration. Finally, the proliferation of cloud and Software as a Service (SaaS) based services will provide opportunities to minimize management overhead while increasing efficiency.


B2B architecture and implementation patterns

B2B is a system-to-system integration, based on partners sending and receiving standard business documents. There are multiple factors such as Service Level Agreements (SLA), B2B document types being used, and security, that the companies must consider when establishing a relationship with their trading partners.

To lay the groundwork, following three questions must be answered:

  • Who do you want to trade with?

  • What documents do you want to exchange? Trading Partners must agree on what B2B specification to use (EDI, EDIFACT, HL7, Custom, and so on).

  • How will your B2B transaction get to your partner? Trading partner must agree what transportation medium (HTTP, FTP, and so on), what messaging protocol they are going to use (AS1, AS2, ebMS, and so on.), how to secure data, and so on.

Once these questions are answered and the sequence of communication steps is understood, the next issue is to look at the mode of communication between B2B participants.

B2B message processing patterns

Two trading partners can communicate through a message either synchronously or asynchronously. In synchronous message processing, the message sender is expecting a reply (or a fault) from a recipient. So to speak, the sender is blocked until a response is received from the recipient. This type of invocation is sometimes referred to as request/reply.

The advantage of the synchronous communication is its immediacy. The sender should expect to get back the transmission results in a timely matter. The down side of the synchronous message processing is that the recipient of the message must be available (reachable) at the moment the message is sent. The transmission of large files can take a long time to process by the recipient, and be a cause of connection time out.

Conversely, in asynchronous processing, the sender doesn't have to wait for a reply from the recipient. After the message is send, the sender can continue normal execution. This type of invocation is sometimes referred to as fire and forget. As an example, the host trading partner, transfers an electronic document to a shared server available to a remote partner using FTP protocol. After the transfer is completed, the host trading partner can resume normal execution. However, asynchronous processing doesn't come without cost. By having an intermediary, asynchronous transmission introduces additional message passing overhead into the transmission mechanism, thus, the speed of asynchronous transmission tends to be slower than that of synchronous data transfer.

B2B connection models

Trading partners can connect with each other using different connection models. The most popular are as follows:


This model reflects a traditional EDI design where buyer and seller are connected directly to each other. The big advantage of this model is the simplicity. The drawback is tight coupling between sender and recipient. This type of collaboration implies dependency between trading partners' systems, that requires both trading partners to be available for the transaction to be processed.

One-To-Many (Peer-To-Peer)

In this type of collaboration, a single trading partner is the controlling entity, and the other trading partners are integrated within it. A one-to-many model might be used to integrate an enterprise with its suppliers in a supply-chain arrangement.

In our use case (shown on the following figure), an aircraft manufacturer (channel master buyer) broadcasts a Query for Pricing and Availability (QPA) of a particular item. After receiving the query, the suppliers send the buyer a reply with quotes, each of which contains the price and availability of the requested items. Communication between suppliers and the buyer represent a point-to-point communication. When the buyer selects the supplier, it sends a Purchase Order (PO) to the selected supplier.

The benefit for the buyer is that the purchase price can be lowered from working with competing suppliers. The chief advantage for the suppliers is potential increase of revenue from working with an established buyer.

Hub and Spoke

In a Hub and Spoke collaboration, the sending trading partner application (spoke) determines the target remote partners, and provides this information either in the message header, or in the message body. The hub reads this information and after transformation, transfers the message to the target spoke. In this type of configuration, the hub mediates the exchange of messages between the other trading partners enlisted in the conversation. In fact, the hub trading partner plays traffic cop role—routing and filtering messages, or providing customized services to the other trading partners in the conversation.

In the example shown in the following figure, the parent of the several health insurance companies called Plans is a hub, while the insurance companies are spokes in the B2B exchange, created to comply with the government mandated HIPAA (Health Insurance Portability and Accountability Act) standard. In this collaboration, the process is initiated by a health care provider, who enters patient insurance information using a Plan 1 web application. The web application determines what Plan the patient belongs to, inserts this information into the message header, and forwards it to the Plan 1's B2B Gateway (spoke). The Gateway converts the message into a Request for Eligibility 270 Transaction, and sends the message to the hub. The hub verifies that the incoming document is correct, reads the message header, and redirects the transaction to a spoke (in our case, Plan 2). The Plan 2's B2B Gateway forwards the request to the local application to access the patient history. After completing the query, the Response for Eligibility 271 Transaction (not shown on the figure) is sent back to the hub for validation and redirection.

The advantage of the Hub and Spoke configuration is the ability to add another spoke without making any changes to other B2B Gateway configurations. The downside is that by inserting the hub in the middle, an extra hop was created, and thus, increasing the latency. Hub can also become a message bottleneck.


Another model (shown on the following figure) that has emerged recently is an e-marketplace, or e-hub. This pattern represents a natural evolution of the Hub and Spoke pattern. E-marketplaces are virtual marketplaces owned by a company or consortium, which allows other companies or individuals to engage in transactions. In this configuration, the centralized hub supports a many-to-many process. For example, Cisco and Dell run their own private e-marketplaces to sell their products, while other companies such as GM and Ford joined together to form Covisint to link automakers and suppliers.


B2B Gateway

B2B Gateway is an application that enables businesses to provide a secure and reliable real-time data interchange between internal systems, and the systems and applications of their trading partners or customers. While selecting B2B Gateway, many companies focus on the B2B aspect of it, ignoring the fact that B2B Gateway must also support End-to-End (E2E) integration that connects B2B with A2A applications and, subsequently, with Application-to-Execution (A2E) applications. Without the E2E integration, enterprises will be missing key capabilities limiting their ability to be responsive to business needs. The B2B Gateway application serves as a central point for validation and transformation of multiple data sources through interoperability standards, such as XML (Extensible Markup Language) and EDI.

A typical B2B Gateway offers:

  • Ability to convert incoming documents to a format acceptable for internal applications

  • Management of the secure collaboration between trading partners

  • Ability to handle both asynchronous and synchronous communication

  • User notification if there are any failures

  • Support for a variety of connection models

B2B Gateway and Open System Interconnection (OSI) model

B2B Gateway leverages the OSI model of most native protocols including TCP/IP and HTTP. In our example, as shown in the following figure, a trading partner sends an EDI 850 (Purchase Order) transaction using an EDIINT AS2 messaging protocol over HTTP/S. The messaging protocols are generally off-the-shelf implementations that have no knowledge of the specific payload being transported by the B2B exchange. AS2 uses Multipurpose Internet Mail Extensions (MIME) format for message transmission. The sender's B2B Gateway embeds an EDI electronic document into the MIME message payload, encrypts, and signs the message. In this case, S/MIME (S stands for Secure) is used to transmit an encrypted message. AS2 invokes the transport protocol (HTTP/S in our case) that resides at the Application layer.

The Application Layer is also known as a Messaging Layer. Being responsible for most of the B2B message transfers, the Application Layer is considered to be a B2B workhorse. The Application Layer determines the address (the IP address and socket number) of the receiver, and hands the message payload and address information over to the Secure Socket Layer (SSL). SSL leverages the Transport Layer to deliver the message across to the receiver using HTTP protocol. The secure tunnel that SSL creates, is an encrypted connection that ensures that all information sent between trading partners remains private. What it means is that, in our example, both the payload and the communication channel are encrypted, providing end-to-end security. After the data package is received by the remote trading partner, the process is reversed. The communication channel is decrypted, the payload signature is verified, and the message is unencrypted.

The detailed discussions of the message encryption and SSL will be addressed when we visit the topic of B2B Security in Chapter 9, Oracle B2B Security Management.


B2B standards

In general, the standard is a formal document that establishes a technical norm or requirement. The B2B standards define how to format, secure, and exchange information between companies.

There are several standard-writing groups that include:

  • Recognized standard bodies, such as International Standards Organization (ISO) and United Nations Centre for Trade Facilitation and Electronic Business (UN/CEFACT), that can write and approve standards

  • Non-profit standards organizations such as Organization for the Advancement of Structured Information Standards (OASIS), Open Applications Group (OAGi), among others who write their own standards to be approved by their own members

  • Standards such as RosettaNet, that are drawn by a consortium of the companies to create a standard with a focus on their industry

  • Standards such as Microsoft BizTalk, created by a single company

For the standard to get legitimacy, it has to be approved by international and national standards bodies, among those being ISO and UN/CEFACT. These published standards are intended for use by industries with the goal to become common practices. These standards are also called open standards versus proprietary, ones that are based on the specifications created by a single vendor. However, unless the open standard implementation is mandated by the government, or other authorities, there is no force that can make companies comply with them.

Most businesses and organizations have specific needs that lead them to adjust the standards, so that they can be effectively used in the context of their business data relationships. Those businesses needs make B2B system development highly specific to each implementation, and thus, increasing project costs. Unfortunately, it is hard to avoid this continuing customization, given that the companies have to keep up with the frequent marketplace changes while the standard entities are lagging behind. Failing to keep up with their users' demands, some standard bodies have accepted the reality and even started to encourage participating companies to modify the standards to satisfy their immediate needs. Despite all this, there is a concentrated effort in the industry to improve the situation. Recognizing this, and despite living in the world of fierce competition for market share, some major companies have buried the hatchet (who would have thought it is possible), and formed committees with responsibilities to draft B2B standards for their industries. For example, major financial institutions around the world joined together to form the Society for the Worldwide Interbank Financial Telecommunication (SWIFT), with a goal to standardize electronic document exchange between banks.

Each B2B standard reflects the vision of their creators. However, they all aim to create the best possible environment for B2B integration, while at the same time, struggling to balance constraints that standards impose on the implementer to comply with a freedom of choice that the standards offer. The common constraints include the following:

  • Character set: It is a standard that can support EDI, XML, or both.

  • Document format: It identifies the fields, the tags, and so on in the transaction set, for example, for the XML-based document is described by the XML schema.

  • The transport requirements: They identify the transport protocol, the packaging mechanism, and the messaging protocol for sending data from one trading partner to another.

  • Choreography or business process: It defines collaboration between trading partners. It either can be defined by the standard, or agreed upon by the trading partners.

Some standards impose all four of these constraints, while others are less restrictive.


In the early days of B2B, there was only one standard, EDI, which was used by many industries around the world. Today, almost every vertical has its own standard, or complies with some sort of a regulatory specification. For example, almost every financial transaction between major banks is formatted according to the SWIFT. Association for Cooperative Operations Research and Development (ACORD) has created a standard for the insurance vertical's EDI and XML transactions.


B2B standards overview

Knowledge of B2B standards is very helpful for the design and implementation of B2B technology. Without a good understanding of B2B standards, it is very hard to collaborate with trading partners, manage existing B2B deployments, and troubleshoot B2B document validation issues. This topic is devoted to familiarize the user with two major B2B standard types: EDI and XML.

EDI standards

Although EDI is the oldest standard, it is still the most widely used. EDI standards describe the rigorous format of electronic documents with all data field names, types, formats, and lengths that must be followed to make them EDI compliant.


EDI X12 is governed by standards released by the Accredited Standards Committee (ASC X12). Every year the standards committee produces a new release, which attempts to catch up with the demand to fix the issues of the previous release, as well as to absorb the latest industry changes. Each release contains a set of message types (such as invoice, purchase order, and healthcare claim.). Each message type has specific number (ID) assigned to it instead of a name. For example, X12 810 was assigned to an Invoice document, X12 850 was assigned to a Purchase Order document and Eligibility, and X12 270 was assigned to Coverage or Benefit Inquiry document.

The protocol architecture is hierarchical, starting from protocol revisions (4010, 4020, and so on). A document revision consists (6010 in our case) of one or many functional groups (PO = Purchase Order, HS=Eligibility, Coverage or Benefit Inquiry, FA=Functional Acknowledgement, and so on). Each functional group consists of multiple document IDs (850, 270, 997, and so on).

It is worth mentioning that each electronic message represents a real life document. For instance, the X12 810 Invoice represents a real life invoice, or a batch of invoices.

The X12 EDI document consists of the following data structures:

  • Data elements: Defined in the X12 Data Element Dictionary, it is a field in a data dictionary.

  • Segments: Defined in the X12 Segment Directory, it is a collection of data elements separated by an element separator. Each segment starts with a two or three character segment tags, which identifies the segment.

  • Loops: They are a block of data segments with data that are interdependent.

  • Transaction Set: It is a group of one or more data segments. Transaction Sets (Messages) can be organized by grouping them into functional groups. The Control Segments are the header and trailer segments that mark the start and end of their respective controlling structure. For every message in a Transaction Set there are three levels of enveloping:

    • Interchange Control Header (ISA) and Trailer (IEA) Control segment: The outermost level is the interchange envelope that is defined by ISA and IEA segments. The interchange envelope encloses the data from sender to receiver that helps route the interchange between trading partners in B2B exchange. The file may contain multiple ISA and IEA segments. The ISA segment is a fixed width segment that always has 106 bytes. The 4th byte defines the element separator (*), the 105th byte is the sub-element separator (>), and the 106th byte is the segment terminator (~). These separators and terminators can, and will be different, and the ISA segment defines what they are for that interchange. Non-printable characters are sometimes used to avoid conflicts with actual data that may contain the separators.

    • Functional Groups Header (GS) and Trailer (GE) Control Segment: The middle level, defined by GS/GE segments, is the functional group envelope used to group similar types of transaction sets (such as Purchase Orders and Purchase Order Acknowledgements), sharing the same functional group ID within a transmission. The GS is also specific to a department within a company on either end. If someone is ordering laptops, servers, and inkjet cartridges from a single supplier, but each is sold by a different department, the purchaser may need to include three different functional groups, with different GS Sender/Receiver IDs, and subsequently have three different Purchase Order documents.

    • Transaction Set Header (ST) and Trailer (SE) Control Segment: The innermost level is the transaction set. Each transaction set in the functional group is bounded by an ST segment at its beginning and an SE segment at its end.

The EDI X.12 Interchange example shown on the following figure illustrates the EDI X12 850 Purchase Order release 4010 Transaction Set. The key points are as follows:

  • The Document has one Transaction Set, in one functional group, in one Interchange

  • An asterisk * is used for the element separator

  • There are four N1 Name/Address loops

  • Each segment is listed on a separate line for readability, but in reality, the data appears as a single stream with the segments separated only by the tilde (~)

  • Control numbers (only the ISA segment Control number was highlighted) are used to uniquely identify Interchanges, Groups, and Transactions, and are used for tracking and tracing, duplicate detection, and missing document identification

EDI X12 is transport medium free—the standard defines the message format only. Trading partners are free to use any method for the transmission of documents.

XML-based standards

The EDI standard stringency forced many companies to customize the protocol to fit their demands. This has led to the original standard mutation into a large number of sub standards. As a result, the EDI implementation has become very expensive, since, every new business partner requires an extensive customization of the current B2B communication system. Emergence of the XML-based standards provided companies with a hope for a more flexible solution. One direction has been to combine vocabulary and grammar with XML syntax in essence, dropping EDI into an XML wrapper. This combination produced the new standards such as XML/EDIFACT. The second approach has been to create a new brand by learning from EDI shortcomings. Only the latter is presented in the book.

ebXML (electronic business XML)

With all due respect to EDI, it would be unfair not to mention the ebXML standard. By providing companies with a standard method to exchange business messages, it allows to define and register business processes, and communicate data in uniform and consistent matter. ebXML is a framework that accomplishes cross-industry XML-based business process integration. As an alternative to EDI processes that are highly labor intensive to configure and deploy, ebXML seeks to move to a world where trading partners can discover each other, and then begin to do business electronically by linking their systems together using the Internet.

While the EDI standards were created more than 40 years ago and were based on the technical capabilities of mainframe systems, ebXML was hatched in the late nineties in the middle of the technological revolution related to the emergence of the Internet. Concerned about the ambiguity of the EDI and subsequent emergence of a myriad of document formats, the ebXML creators' goal was to merge business requirements of EDI and the technical functionality of XML.

A cornerstone of the ebXML architecture is the creation of interoperable web services and associated components. The key concepts of ebXML architecture include:

  • Communication infrastructure: It should provide a standard message transport mechanism with a defined interface, packaging rules, and a predictable delivery and security model

  • Share metadata vocabulary: A share metadata vocabulary with the information about common business processes and reusable business logic should be used for the ebXML trading partners to interoperate

  • ebXML Registry: It provides a way for trading enterprises to find each other, and agree to become trading partners

ebXML is not a document standard as EDI. It is not forcing to use any document standards. It merely provides a specification to define business collaboration called Business Process Specification Schema (BPSS). As shown in the following figure, after the company determines what to do (what document format to use) and how to do it (transport and packaging), it may create a Collaboration Protocol Profile (CPP) and publish it to the ebXML Registry. If the company finds a registered trading partner, the two partners may agree to collaborate. In this case, they will merge their CPP into a Collaboration Protocol Agreement (CPA). Both CPA and CPP are XML documents that have the same root element CollaborationProtocolProfile with PartyInfo, Packaging, Signature, and Comment elements. The PartyInfo element provides information about the organization, and includes multiple elements with the most important among them being the PartyId element that provides a logical identifier for the organization, such as the DUNS number and one or more DeliveryChannel elements that define the ways in which the party can receive messages.

Agreement acceptance between trading partners resulting in CPA concludes the design time phase of the ebXML project.

The runtime phase covers message choreography and actual business transactions. The ebXML Message Service Handler (MSH) is the heart and soul of ebXML message processing. It provides basic services such as header processing, header parsing, security services, and message packing. MSH implements the concept of operation defined by the ebXML Message Service (ebMS) specification. ebMS is defined as a set of layered extensions to the SOAP and SOAP Messages with Attachments specification (SwA). More details about the SwA can be found at:

An ebXML Message is a MIME/Multipart message envelope, structured in compliance with the SwA, referred to as a Message Package. As shown in the following figure, the Message Package has two parts:

  • The first MIME part, referred as the Header Container

  • Zero or more additional MIME parts, referred as the Payload Container

Communication Protocol Envelope header provides information about what transport protocol was used in the message exchange. This protocol serves as the carrier of ebXML Messages, and provides the underlying services necessary to carry out a complete ebXML message exchange between two parties. Prior to sending, the ebXML message must be formatted according to the ebXML service specification and conform to the HTTP specific MIME canonical form constraints. The rules for forming an HTTP message containing an ebXML service message are as follows:

  • The Content-Type: Multipart/Related MIME must appear in the ebXML message envelope header to identify the message as an ebXML compliant structure

  • SOAPAction: HTTP header field must be included and have a value of ebXML

An ebXML message extends the SOAP message with the following principal extension elements:

  • Message header extends the SOAP header.

  • Manifest element extends the SOAP Body. The contents of each payload container are identified by the ebXML message manifest element within the SOAP body.

The ebXML message is payload neutral, allowing it to include any document formats, for example, EDI files, or XML messages.

The following figure shows the ebXML message structure. It starts with an outer HTTP Transport Envelope with a mandatory SOAPAction field set to ebXML to help determine the ebXML handler. It follows a transport independent Message Envelope that consists of the ebXML Header Container and ebXML Payload Container. The ebXML Message Envelope element Content-Type: specifies multipart/mixed. This tells that this message has parts separated by the string argument defined in the boundary=. In our case, the message includes a single payload document (a small XML document). The ebXML Header Container includes SOAP Envelope. SOAP Envelope's SOAP Header includes an ebXML extension to the SOAP Specification called Message Header that contains routing information for the message (To/From, and so on), as well as other context information about the message.

SOAP Envelope's SOAP Body includes an ebXML extension to the SOAP Specification called Manifest that identifies payload data associated with the message.

For more information please refer to the ebXML Message Service Specification that can be found at

ebXML has been a great success in many ways by letting companies of any size, using any computing platform, conduct business over the Internet. By not enforcing the document format, ebXML allows companies to reuse their existing formats. However, openness comes in the expense of interoperability. By not providing some reasonable guidance on what transport to support, ebXML left to the companies to investigate various options, procure the required software, and configure everything, and thus, increased implementation costs.



B2B has traveled a long way from its roots to become a de facto standard for many industries. In the early B2B days, EDI was the only B2B standard. However, with the advent of the Internet, there has been an explosion of new XML-based standards. Knowledge of these standards plus familiarity with the architectural concepts such as B2B Gateway, message exchange patterns, and document formats will provide a fundament for the following chapters, where the reader will learn how the Oracle e-commerce B2B Gateway supports these standards, and enables the secure exchange of business documents between trading partners.

About the Authors

  • Krishnaprem Bhatia

    Krishnaprem Bhatia has over twelve years of experience in the Software Development, Product Management, and IT industry. He started working with Oracle in 2001 and since then he has been working in various aspects of enterprise software integration including application, business process, and B2B integration. He has extensive software development experience, building world class integration solutions using Oracle technologies. As a Product Manager for Oracle B2B, he has worked extensively with customers and partners worldwide to develop unique B2B solutions, for solving integration challenges in nearly all industry verticals. Through dozens of workshops, he has interacted with and trained hundreds of integration experts on Oracle B2B across North America, Europe, and Asia. He loves to read, workout at the gym, and also has a passion for traveling as he has been to more than 26 countries. He holds a B.S. (with Highest Honors) in Computer Science and Engineering from UC Davis and an MBA from UC Berkeley Haas School of Business.

    Browse publications by this author
  • Alan Perlovsky

    Alan Perlovsky is a Senior Principal Consultant with Oracle's SOA/Fusion Middleware Practice and has been with Oracle for last five years where he is helping the Oracle Clients with the adoption of technologies such as Service-Oriented Architecture (SOA), B2B, and security. After starting his career as an Enterprise Application Development in the early nineties, and until now, he has been lucky to be involved in many exciting projects such as 24x7 EDI and XML transaction Clearinghouse, the world's biggest HIPAA implementation to date, and Global Combat Support Systems that introduces cutting edge enabling technology in support of the US Marines logistics operations, among others.

    Browse publications by this author
  • Scott Haaland

    Scott Haaland has over 20 years experience in the Software Development and IT industry. He started working in 1992 for Hewlett Packard, and then for the spinoff company from HP called Agilent Technologies. After branching out on his own with two different businesses, including a Software Consulting business, he also picked up many business management skills along the way as well. Most recently, Scott has joined Oracle in 2012 as a Principal Product Manager for the SOA Suite team, with a special emphasis on Oracle B2B. While working for Hewlett Packard as a Developer for their EDI Services team, Scott gained expertise in many different B2B standards, such as EDI X.12, TRADACOMMS, EDIFACT, and EIAJ. With the advent of Message Oriented Middleware and then the transition into Service Oriented Architecture, Scott continued to gain important Integration Architecture skills while at Agilent Technologies, where he helped to develop a Canonical model based on the OAGIS 8.0 specification for internal application to application integration using TIBCO technologies. Scott learned SOA Suite while providing consulting services, and helped his clients with a transition to a Service Oriented Architecture approach for integration using Oracle SOA Suite 11g. As a Product Manager for Oracle SOA Suite, his expertise in EDI, A2A, SOA, and B2B have proven invaluable towards the writing of this book. Scott enjoys spending time with his family, working on home improvement projects, working on cars, and volunteering at his church and in his community.

    Browse publications by this author

Latest Reviews

(1 reviews total)
Great summary of what the B2B integration provides. Easy to follow examples, and great screenshots when necessary. Exactly what I needed before starting a new project!
Book Title
Access this book, plus 7,500 other titles for FREE
Access now