Skip Headers
Oracle® Fusion Middleware User's Guide for Oracle B2B
11g Release 1 (

Part Number E10229-10
Go to Documentation Home
Go to Book List
Book List
Go to Table of Contents
Go to Index
Go to Master Index
Master Index
Go to Feedback page
Contact Us

Go to previous page
Go to next page
PDF · Mobi · ePub

1 Introduction to Oracle B2B

This chapter discusses how Oracle B2B, an e-commerce gateway, enables the secure and reliable exchange of business documents between an enterprise and its trading partners. It also covers how Oracle B2B supports business-to-business document standards, security, transports, messaging services, and trading partner management.

With Oracle B2B used as a binding component within an Oracle SOA Suite composite application, end-to-end business processes can be implemented. Oracle B2B also supports Health Level 7, which enables health care systems to communicate with each other.

For more information about Oracle SOA Suite, see Oracle Fusion Middleware Developer's Guide for Oracle SOA Suite.

This chapter contains the following topics:

1.1 Oracle B2B and Business-to-Business E-Commerce

E-commerce is the buying and selling of products or services over the Internet, including business-to-business (B2B). In B2B e-commerce, an enterprise extends its business processes over the Internet to reach trading partners. B2B e-commerce represents classic business processes, mature business documents, and industry-tempered messaging services. It requires a unified business process platform, end-to-end instance tracking, visibility and auditing, integrated process intelligence, process and service governance, and centralized security.

You can think of an e-commerce transaction between businesses as analogous to a mail or express carrier (shipping) transaction. In both kinds of transactions, the sender must consider the details required for packaging and sending an item, and the receiver's requirements. Table 1-1 provides an example that compares the two kinds of transactions.

Table 1-1 Comparing Traditional and E-Commerce Transactions

Traditional Shipping Transaction E-Commerce Transaction

What is the item to be shipped, that is, the transaction item?

Cell phone

Electronic document

Document protocols: Custom, EDI EDIFACT, EDI X12, HL7, OAG, positional flat file, RosettaNet, UCCnet, and more

How is the item packaged?

Box, bubble wrap

Packaging protocols: MIME, SMIME, SOAP, XMLDSig, XMLEncrypt

How is the item sent and received?

Truck, ship, airplane

Transport protocols: HTTP, File, FTP, SFTP (SSH FTP), TCP/IP, SMTP, MLLP, and more

Who is the carrier?


Message exchange protocols: RNIF, AS1, AS2, ebMS, and more

What carrier services are required?


  • Signed receipt

  • Overnight/next day

  • Delivery attempts


  • Nonrepudiation

  • Time to acknowledge/respond

  • Retry counts

This guide describes how to use Oracle B2B to define the document, the packaging, and the delivery, in addition to configuring trading partners, creating and deploying agreements, and monitoring a deployment.

1.2 Protocols Supported in Oracle B2B

Oracle B2B supports numerous industry-standard e-commerce protocols, as defined for a range of industries, including health care, retail, IT, telecom, electronics, manufacturing, the food industry, and more. Table 1-2 lists the protocols supported in Oracle B2B.

Table 1-2 Protocols Supported in Oracle B2B

Protocol Type Protocol

Document protocol

  • Custom (user-defined)

  • EDI EDIFACT, all versions

  • EDI X12, all versions

  • HL7, all versions

  • RosettaNet PIP business documents

  • OAG

  • Positional flat file (includes SAP iDoc)

  • UCCnet

  • Custom (non-XML)

  • NCPDP Telecom


Packaging protocol

  • MIME 1.0

  • S/MIME 2.0, S/MIME 3.0

  • SOAP

  • XML digital signature (XMLDSig)

  • XML encryption (XMLEncrypt)

Transport protocol

  • AQ

  • Email (SMTP 1.0, IMAP 1.0, POP3)

  • File

  • FTP and SFTP (SSH FTP)

  • HTTP (HTTP 1.0, HTTP 1.1) and HTTPS (HTTPS 1.0, HTTPS 1.1)

  • JMS

  • TCP/IP

Message exchange protocol

  • AS1-1.0, AS2-1.1

  • MLLP-1.0

  • ebMS-1.0, ebMS-2.0 (ebXML Messaging Service)

  • RosettaNet-01.10, RosettaNet-V02.00

  • Generic File-1.0

  • Generic AQ-1.0

  • Generic FTP-1.0

  • Generic SFTP-1.0

  • Generic JMS-1.0

  • Generic HTTP-1.0

  • Generic Email-1.0

  • Generic TCP

About Document Types:

Using the Custom and positional flat file document protocols, you can use many other document types, including W3CXML Schema (OAGIS, xCBL, UBL, ebXML, and more). Use Oracle Document Editor to create the guideline documents.

1.3 Oracle B2B Metadata

Oracle B2B instance data is stored and managed within the SOAINFRA schema of your database. Oracle B2B metadata for design-time and configuration is stored and managed through Metadata Services (MDS), available in Oracle Fusion Middleware. See Oracle Fusion Middleware Administrator's Guide for more information about MDS.

Because documents created in Oracle B2B are stored in the metadata repository, it is possible that the transaction log for the database can become full. If this occurs often, increase the database configuration parameter to allow a larger log file. A larger log file requires more space but reduces the need for applications to retry the operation.

To increase this value, issue the following command:

db2 update database config for soainfra using LOGFILESIZ 8192

1.4 Security Features of Oracle B2B

Oracle B2B leverages the security features of Oracle Platform Security Services, a comprehensive security platform framework. Oracle Platform Security Service supports:

The default administrator user created during Oracle SOA Suite installation is assigned the administrator role, which has access to all Oracle B2B functionality. The default administrator user can create additional users and assign the following roles:

See Section 5.3, "Adding Trading Partner Users," for how to assign roles.

The partner data you design, deploy, and manage with the Oracle B2B user interface is secured by its centralized storage in the Metadata Service (MDS) repository.

Other security features include:


Oracle B2B run time does not support the CLIENT-CERT authentication method. Therefore, B2B is not able to post to OAM-SSO protected URLs.

See the following for more information about security:

1.4.1 Payload Obfuscation

Oracle B2B supports payload obfuscation before payloads are stored in the instance repository. The security infrastructure of Oracle Fusion Middleware is used to obfuscate, store, and retrieve the payloads, and ensure that payloads in wire messages, business messages, and application messages are visible to authorized users only. The encryption algorithm is not specifiable. Keys are stored in the Credential Store.

At run time, the payload is obfuscated before it is stored in the instance repository. When this payload is retrieved from the instance store during processing, it is automatically unobfuscated so that B2B engine processes it.

Similarly, in the outbound direction, if payload obfuscation is required, then the payload is obfuscated before it is stored in the instance repository. If exchange-level encryption is specified, then the payload is encrypted using the encryption scheme specified before it is put on the wire.

Payload obfuscation can be configured in Oracle Enterprise Manager Fusion Middleware Control. See Oracle Fusion Middleware Administrator's Guide for Oracle SOA Suite and Oracle Business Process Management Suite and Appendix C, "Setting B2B Configuration Properties in Fusion Middleware Control," for more information.

When you enable payload obfuscation, consider the following:

  • Large payloads, as defined in the Large Payload Size parameter on the Configuration tab, are not obfuscated because they are stored in a directory (file system) rather than the instance repository. Storing a large payload in the file system is a security risk.

  • The obfuscated payload can be accessed in the Oracle B2B interface only by authorized users who have access to the document type. The payload is unobfuscated and displayed in the interface for these authorized users. Other users cannot access the document type at all. The users can be provisioned to access document types. See Section 1.4.2, "Restricting Access to Document Types," for information about document-type provisioning.

Obfuscation is available for payloads that use multibyte characters, and is available for non-Oracle databases.

If you migrate instance stores that contain obfuscated payloads, then you must ensure that you export the Credential Store Framework (CSF) as well, because the CSF has the key to unobfuscate those payloads (the same key is used for obfuscation and unobfuscation). If this is a new store, then no migration is required because the key is created (if not already present) the first time the payload is obfuscated.

A payload that was obfuscated and persisted in Oracle B2B is passed unobfuscated to other SOA components within a composite application, when using the Default or JMS integration types. Users viewing this unobfuscated payload in other SOA components are responsible for ensuring that the payload is obfuscated and persisted securely, and that users are authorized to view the payload.

1.4.2 Restricting Access to Document Types

Oracle B2B supports payload security by restricting access based on document type. The following user permissions for document-type access are available:

  • Admin permission for all document types

    With this permission, the user can add, access, edit, and delete all document types. This user also has access to administrative functions such as import, export, and purge.

  • Admin permission for specified document types

    With this permission, the user can access, edit, and delete the specified document types for which he has permission. The user is not allowed to access, edit, or delete the restricted document types. The user cannot add new document types or have access to any administrative functions such as import, export, and purge.

  • Monitor permission for all document types

    With this permission, the user can access and view (but not edit or delete) all document types.

  • Monitor permission for specified document types

    With this permission, the user can access and view (but not edit or delete) the specified document types. The user cannot access and view the restricted document types.

The default administrator user can restrict document-type access to other roles as follows:

  • The host administrator can be granted access to all document types, in which case this user can restrict document-type access to other host or remote administrators.

  • The host administrator can be granted access only to specified document types, in which case this user cannot restrict document-type access to other host or remote administrators.

  • The remote administrator can be granted access to specified document types only, or all document types pertaining to the remote trading partner. In either case, the remote trading partner administrator cannot create document types in the system, or provision users for that particular remote trading partner. Users can only be provisioned by a host trading partner administrator user.

  • The host monitor can be granted view-only access to all document types or to specified document types, but cannot restrict document-type access to other users.

  • The remote monitor can be granted view-only access to all document types pertaining to the remote trading partner or to specified document types pertaining to the remote trading partner, but cannot restrict document-type access to other users.


Admin users with access to all Administration tab functions lose admin privileges when permission for any or all document types is assigned, and the Administration tab is no longer available.

See Task 3, "Add Document Types That the User Has Permission to Access" in Section 5.3, "Adding Trading Partner Users," for how to specify document-type access in the Oracle B2B interface.

When access to specific document types is restricted, consider the following:

  • New document definitions for a restricted document type cannot be added.

  • No document types can be imported, exported, or purged.

  • No document types can be modified on the Partners > Documents tab, as shown in Figure 1-1.

    Figure 1-1 Accessing a Restricted Document Type from the Documents Tab

    Description of Figure 1-1 follows
    Description of "Figure 1-1 Accessing a Restricted Document Type from the Documents Tab"

  • The restricted document types are listed, but details cannot be viewed or accessed, on the following tabs:

    • Administration > Document tab

    • Reports tabs

    • Metrics tabs

  • Agreements that include document definitions for restricted document types cannot be modified or exported.

  • In a SOA composite with a B2B binding component, restrictions on document types are not in effect. All document types are available to any user in the B2B Configuration Wizard of Oracle JDeveloper.

1.5 How Does Oracle B2B Fit into a SOA Implementation?

As a business-to-business gateway, Oracle B2B is used to extend business processes to trading partners. When Oracle B2B is used in a SOA composite application, you can model an end-to-end business process integration.

Oracle SOA Suite provides a complete set of service infrastructure components for designing, deploying, and managing composite applications. The multiple technology components of a composite application share common capabilities, including a single deployment and management model and tooling, end-to-end security, and unified metadata management. See Oracle Fusion Middleware Developer's Guide for Oracle SOA Suite for more information.

In a SOA implementation, Oracle B2B functions as a binding component, with network protocols and services that enable message sending and receiving:

In addition to messages, Oracle B2B can also send attachments and large payloads in a SOA implementation. See Appendix A, "Handling Large Payloads," for information about handling large payloads.


With the integration of Oracle B2B, Mediator, and BPEL components within Oracle SOA Suite, the XML Gateway Internal Delivery channels are not needed in Oracle B2B 11g to communicate with Oracle E-Business Suite. This can be achieved by using the Oracle Application Adapter available in Oracle SOA Suite.

1.6 Sending a Purchase Order: An Example of a SOA Implementation

The following example describes how the components of a SOA composite application are used to send a purchase order that originates from Oracle E-Business Suite, as shown in Figure 1-2.

Figure 1-2 An Outbound Purchase Order in a SOA Composite Application

Outbound purchase order
Description of "Figure 1-2 An Outbound Purchase Order in a SOA Composite Application"

The outbound purchase order (P. O.) is an XML document that participates in an end-to-end business process as follows:

  1. An application, for example, Oracle E-Business Suite, initiates the P. O. process. The P. O. document uses the application-generated XML.

  2. Oracle Mediator receives the P. O. from Oracle E-Business Suite. The P. O. is translated to canonical XML through XSLT Mapper, and is validated by using the schema obtained when the composite application was validated. Oracle Mediator routes the message to Oracle BPEL Process Manager.

  3. Oracle BPEL Process Manager receives the P. O. from Oracle Mediator. Business processes such as human workflow, business rules, and error handling can apply before Oracle BPEL Process Manager sends the P. O. back to Oracle Mediator.

  4. Oracle Mediator receives the P. O. from Oracle BPEL Process Manager. The P. O. is transformed from canonical XML to the target XML through XSLT Mapper and then routed to Oracle B2B.

  5. Oracle B2B receives the P. O. from Mediator, translates the P. O. to EDI native format, for example, and manages the interaction with the trading partner.

  6. Oracle Business Activity Monitoring (BAM) monitors the end-to-end process.

See the following for more information:

1.7 Oracle B2B Samples and Cookbooks

The Oracle B2B samples guide you through the steps to create guideline files, design Oracle B2B transactions, deploy and monitor trading partner agreements, and create and deploy SOA composite applications. The composite applications include an Oracle B2B binding component and use the document definitions that you create in Oracle B2B.

Samples are available for the following document types:

These end-to-end samples are based on a scenario in which two trading partners, Acme and GlobalChips, participate in a transaction. Acme is the initiator (the buyer, in the case of a purchase order scenario) and GlobalChips is the responder (the seller in a purchase order scenario). In the HL7 sample, Acme (initiator) sends an ADT_A01 admit patient message and receives an ACK_A01 acknowledgment from GlobalChips.

The samples include instructions and sample document definition files for you to create all the documents, agreements, and SOA composites you need to run the samples. The completed SOA composite application is also provided for each sample.

You can download the samples from the Oracle SOA Suite samples.

The Oracle B2B cookbooks provide detailed information on the implementation of ebXML, EDI (EDIFACT and X12), and HL7 in Oracle B2B. The cookbooks include configuration steps, performance best practices, discussions of typical errors, and FAQs. To download the cookbooks, go to

See Section 2.1, "What You Need to Get Started with Oracle B2B," for the components required to use the samples and cookbooks.

1.8 Administering Oracle B2B in the Oracle Fusion Middleware Environment

The following components provide monitoring, configuration, and performance tuning capabilities for Oracle B2B:

Within the Oracle B2B interface, use the following for monitoring and configuration: