5 Configuring Trading Partners

The third step in the Oracle B2B process flow, shown in Figure 5-1, is to configure the trading partners.

Figure 5-1 Oracle B2B Process Flow

Oracle B2B process flow
Description of "Figure 5-1 Oracle B2B Process Flow"

Configuring a trading partner includes creating a trading partner profile (providing values for identifiers, contact information, trading partner parameters, and Key Store information); adding trading partner users; adding document definitions and assigning sender and receiver roles, and configuring channel details, including security.

This chapter contains the following topics:

5.1 Introduction to Trading Partners

In Oracle B2B, a transaction involves two trading partners, the host trading partner and a remote trading partner. The host trading partner is typically the organization where Oracle B2B is installed. The remote trading partner is the organization with whom the host trading partner conducts an e-business transaction. A trading partner can have host (back-end) applications, databases, or customers to involve in the transaction. Either the initiator of a transaction or the responder can be the host or the remote trading partner.

The host trading partner organization configures all the trading partners, host and remote. By using the trading partner users created for each remote trading partner by the host trading partner, remote partners can access their own data in Oracle B2B. Figure 5-2 shows the steps to configure a trading partner.

Figure 5-2 Configuring Trading Partners

Steps to configure trading partners
Description of "Figure 5-2 Configuring Trading Partners"

5.2 Creating Trading Partner Profiles

Oracle B2B supplies a default host trading partner name, MyCompany, which you update to reflect your enterprise. After you create one or more remote trading partners, use the cloning feature to create new trading partners that participate in similar transactions. Cloning copies the source trading partner's document definitions and delivery channels (except MLLP channels), but does not copy identifiers, contacts, and users. Renaming the delivery channel in the newly created trading partner is recommended.

After you create and configure a trading partner, the information is saved as a trading partner profile in Oracle Metadata Repository. Partner data can be exported to a ZIP file by using the Export button on the Profile tab.

To create a trading partner profile, do the following:

Task 1   Update the Default Host Trading Partner Name

Do this the first time you set up Oracle B2B.

  1. Click the Partners link.

  2. Click MyCompany.

  3. Click Edit, as shown in Figure 5-3.

    Figure 5-3 Editing the Host Trading Partner Profile

    Default host trading partner name
    Description of "Figure 5-3 Editing the Host Trading Partner Profile"

  4. Provide the host trading partner name and optional icon file, and click OK.

    The optional icon file must be a 16 x 16-pixel PNG file.

    The host trading partner name appears in the Partner list.

Task 2   Add a Remote Trading Partner

Do this for each remote trading partner.

  1. Click the Partners link.

  2. Click Add, as shown in Figure 5-4.

    Figure 5-4 Adding a Remote Trading Partner

    The Add icon is featured.
    Description of "Figure 5-4 Adding a Remote Trading Partner"

  3. Provide a partner name and click OK.

    The remote trading partner name appears in the Partner list.

  4. (Optional) Click Edit to add a 16 x16-pixel PNG file as an icon for the remote trading partner, as shown in Figure 5-5, and click OK.

    Figure 5-5 Editing a Remote Trading Partner Profile

    Description of Figure 5-5 follows
    Description of "Figure 5-5 Editing a Remote Trading Partner Profile"

A variation on this task is to use the clone feature. If you have already created a trading partner that is similar to a trading partner you want to create, click the Clone icon, as shown in Figure 5-6, and provide the trading partner information that is not cloned: identifiers, contacts, and users.

Figure 5-6 Cloning a Remote Trading Partner

Clone icon
Description of "Figure 5-6 Cloning a Remote Trading Partner"

Note:

Use the Delete icon to delete a remote trading partner. However, you cannot delete a remote trading partner that is part of a deployed trading partner agreement. You must first delete the agreement.
Task 3   Add Identifier Types and Values

Identifier types enable Oracle B2B to identify a trading partner at run time. In general, the identification process is to identify the partner, then the document, and then the partner-document pair identifies the agreement. Oracle B2B provides each trading partner with a default identifier type, Name, whose value is the name of the trading partner.

Add identifier types and values for both the host and remote trading partners. See Chapter 10, "Creating Types," for how to create the types that you add here.

  1. Click the Partners link.

  2. Click the Profile tab.

  3. Select a trading partner.

  4. In the Identifiers area, click Add, as shown in Figure 5-7.

    Figure 5-7 Adding Identifier Types

    Adding an identifier
    Description of "Figure 5-7 Adding Identifier Types"

  5. From the Type list, select an identifier type.

    See Table 10-1, "Identifier Types Defined in Oracle B2B" for descriptions of the identifier types.

  6. Provide a value.

  7. Repeat Steps 4 through 6 as needed.

  8. Click Save.

Task 4   Add Contact Information

To add optional contact information for a trading partner, use the preseeded types—Contact Name, Email, Fax, Phone. Or, you can create a contact type on the Administration > Types page. See Section 10.2, "Creating Custom Contact Information Types," for more information.

  1. Click the Partners link.

  2. Click the Profile tab.

  3. In the Contact Information area, click Add.

  4. Select from the list under Type and enter a value, as shown in Figure 5-8.

    Figure 5-8 Adding Contact Information

    Contact information for a partner
    Description of "Figure 5-8 Adding Contact Information"

  5. Click Save.

Task 5   Add a Trading Partner Parameter and Value

Before adding an optional trading partner parameter and value for a trading partner, you must create the parameter on the Administration > Types page. (If you have not already created a parameter, the Add icon does not appear.) See Chapter 10, "Creating Types," for more information.

  1. Click the Partners link.

  2. Click the Profile tab.

  3. In the Parameters area, click Add, as shown in Figure 5-9.

    Figure 5-9 Adding Trading Partner Parameters and Values

    Add parameters is the green plus sign icon.
    Description of "Figure 5-9 Adding Trading Partner Parameters and Values"

  4. Select a parameter, as shown in Figure 5-10, and click OK.

    Figure 5-10 Selecting Trading Partner Parameters

    Trading partner parameters
    Description of "Figure 5-10 Selecting Trading Partner Parameters"

  5. Click Save.

You can also update values for a specific trading partner on this page.

Task 6   Provide Key Store Information for the Host Trading Partner

Add an optional Key Store password and location for host trading partner security. If a digital signature, encryption, or SSL are enabled, you must specify a Key Store location. See Task 5, "Configure Security" for where you specify digital signatures and encryption, and Table 5-6 for descriptions of security parameters.

You can choose any Key Store for Oracle B2B. If you are using SSL, using the same Key Store for both B2B and Oracle WebLogic Server SSL configuration is recommended to avoid SSL-related problems when exchanging messages with trading partners.

  1. Click the Partners link.

  2. Click the Profile tab.

  3. Select the host trading partner.

  4. In the Key Store section, provide a password and location, as shown in Figure 5-11.

    Figure 5-11 Entering Key Store Information

    Wallet area
    Description of "Figure 5-11 Entering Key Store Information"

  5. Click Save.

Note:

If you re-enter a Key Store password that you previously entered incorrectly (which produces errors trying to connect to the Key Store), then you must restart the server after entering the correct password.

5.3 Adding Trading Partner Users

The host trading partner administrator (the default login username-password combination) can add additional host and remote trading partner users. These users can log in to Oracle B2B and access their own trading partner data only.

The following roles are available:

  • Administrator role—Provides access to all Oracle B2B functionality

  • Monitor role—Provides access to reporting and metrics functionality only (use of the Reports and Metrics links)

Users with the administrator role can access all B2B functions for their trading partner data only. No data for other trading partners is displayed. Users with the monitor role can access report functionality for their trading partner data only. No other links and no data for other trading partners are displayed. Oracle B2B also supports restricting access based on document type. See Section 1.4.2, "Restricting Access to Document Types," for more information.

To add users, do the following:

Task 1   Create a New User in the Identity Store

A user must exist in the Identity Store before you can provision the user in Oracle B2B. Although there are many tools that you can use to create users, one way is to use the Security Realms function in Oracle WebLogic Server Administration Console, as shown in Figure 5-12.

Figure 5-12 Oracle WebLogic Server Administration Console—Security Realms

Description of Figure 5-12 follows
Description of "Figure 5-12 Oracle WebLogic Server Administration Console—Security Realms"

Note:

It is recommended that you use an LDAP-based policy store because the default file-based policy store is not supported if Oracle B2B is running on a managed server.

Then, within the myrealm settings, the Users and Groups tab displays a table of all users in your realm. Click New, and then add a user and user password on the page shown in Figure 5-13.

Figure 5-13 Oracle WebLogic Server Administration Console—Adding a New User

Description of Figure 5-13 follows
Description of "Figure 5-13 Oracle WebLogic Server Administration Console—Adding a New User"

Task 2   Add a User in the Oracle B2B Interface

The default administrator can add users. Host administrators and remote administrators can add users (remote administrators for their own data only) if they have been granted that permission by the default administrator.

  1. Click the Partners link.

  2. Click the Users tab.

  3. Select a trading partner.

  4. Click Add.

  5. Provide the user name created in Task 1 and click Search.

    Enter the user name exactly is it was created.

  6. Select the Monitor or Administrator role, shown in Figure 5-14, and click OK.

    Figure 5-14 Assigning the Monitor or Administrator Role

    Register user dialog
    Description of "Figure 5-14 Assigning the Monitor or Administrator Role"

Task 3   Add Document Types That the User Has Permission to Access

The default administrator can add document types for a user. Host administrators and remote administrators can add document types for a user (remote administrators for their own data only) if they have been granted that permission by the default administrator. If no document types are added here, then the user has access to all document types.

  1. In the Supported Document Types area, shown near the bottom of Figure 5-15, click Add.

    Figure 5-15 Adding Document Types

    Description of Figure 5-15 follows
    Description of "Figure 5-15 Adding Document Types"

  2. Select a document type and click Add, as shown in Figure 5-16.

    Figure 5-16 Selecting a Document Type

    Description of Figure 5-16 follows
    Description of "Figure 5-16 Selecting a Document Type"

  3. Repeat Steps 1 and 2 as needed.

    The document types that the user has permission to access are displayed in the Document Type Names column.

    The document types in the Document Type Names column can also be deleted. If all types in the list are deleted, then the user has access to all document types.

5.4 Adding Document Definitions

The Oracle B2B host administrator creates all document definitions, which are automatically assigned to the host trading partner. The host administrator can assign any document definition to a remote trading partner. For both the host and remote trading partners, the sender and receiver for each document must be identified.

For information on updating a document definition after it has been added, see Section 8.9, "Changing Document Details."

Note:

Document definitions that are automatically associated with the host trading partner must be deleted from the host trading partner profile (and also from the remote trading partner profile) before you can delete a document definition (from Administration > Document).

Consider the scenario in which Acme (buyer) sends a purchase order to GlobalChips. As part of this transaction, Acme also receives an acknowledgment that GlobalChips (seller) received the purchase order. Therefore, this EDIFACT transaction uses two document definitions, one for the purchase order and one for the functional acknowledgment. GlobalChips receives the purchase order and also sends the acknowledgment.

For information on creating a document definition—required before you can add it to the trading partner profile—see Chapter 4, "Creating Document Definitions."

To add document definitions, do the following:

Task 1   Add Document Definitions

Add document definitions to both host and remote trading partner profiles. You can also change document type parameters and document version parameters for the remote trading partner on this page. See Chapter 8, "Using Document Protocols," for more information.

  1. Click the Partners link.

  2. Click the Documents tab.

  3. Select a trading partner.

  4. Click Add.

  5. Expand the nodes, select a document definition as shown in Figure 5-17, and click Add.

    Figure 5-17 Selecting a Document Definition

    Document definitions in a tree structure
    Description of "Figure 5-17 Selecting a Document Definition"

  6. For each document listed, identify if the selected partner is the sender or receiver or both, as shown in Figure 5-18.

    Figure 5-18 Selecting the Sender and Receiver

    Document definitions: ID sender and receiver
    Description of "Figure 5-18 Selecting the Sender and Receiver"

  7. Click Save.

See Section 8.9, "Changing Document Details," for how to change document protocol versions and document type parameters for a remote trading partner, including using the Override Version Param and Override DocType Param parameters.

5.5 Configuring Channels

A channel defines how a message is delivered. It specifies trading partner security characteristics, the transport protocol, the exchange protocol, any exchange protocol override elements, and, if defined, support for digital envelopes, encryption credentials, digital signatures, signing credentials, and validation.

When you configure an external delivery channel for the host trading partner, it is available for all remote trading partners when you create agreements. This avoids having to create a delivery channel multiple times, once for each remote trading partner. When you configure an external delivery channel for a remote trading partner, it is available for only that remote trading partner when you create agreements. When you configure an internal delivery channel for the host trading partner—for inbound messages to Oracle B2B using the AQ, File, or JMS transports— the channel is available for only the host trading partner when you create inbound agreements.

You can also create custom JMS exception queues by configuring JMS internal delivery channels for the host trading partner. See the following for more information:

Table 5-1 lists the channels/exchange protocols available in Oracle B2B.

Table 5-1 Channels/Exchange Protocols Available in Oracle B2B

Protocol Description

AS2-1.1

Applicability Statement 2, version 1.1—specification for using EDI over the Internet. AS2 provides S/MIME support over HTTP or HTTPS. AS2 also works with non-EDI document types such as .xml, .txt, .doc, and .xls. AS2 is also called EDI over the Internet, or EDIINT AS2.

MLLP-1.0

(Remote trading partner only)

Minimum Lower Layer Protocol (MLLP) is a minimalistic OSI-session layer framing protocol.

MLLP (and the TCP transport protocol) are available for remote trading partners only. It is used with HL7 or Custom documents. With MLLP, the same channel can be used for sending or receiving messages, and can be configured as either the server or the client.

MLLP connections can be permanent or transient:

Features of a permanent connection:

  • Caches the socket based on the endpoint.

  • Only one socket per endpoint is created.

  • The socket is reused for future messages.

Features of a transient connection:

  • A new socket is created for each message.

  • A message is sent and the listener waits for the acknowledgment.

  • When the acknowledgment is received, the socket is closed.

See Section 5.5.1, "About MLLP" for more information.

ebMS-2.0

ebMS-1.0

Electronic business Extensible Markup Language (ebXML) Messaging Service (ebMS)—specification used to exchange XML documents. ebMS is built on a SOAP Web services message format. Oracle B2B supports ebMS 1.0 and 2.0 and uses the HTTP, HTTPS, and Email transport protocols and the SOAP packaging protocol. The ebMS protocol supports correlation between documents. Oracle B2B also supports XMLDSig, XML Encrypt, and gZip-based compression for large documents.

RosettaNet-V02.00

RosettaNet 2.0 does not include the proprietary aspects of RosettaNet 1.1, and adds support for multiple transfer protocols, hub-based routing, attachments, payload encryption, and more.

RosettaNet-01.10

Implementation guidelines for creating software applications that provide for the reliable transport of PIPs in XML-format business documents between trading partners. Guidelines are provided for transport, routing, packaging, security, signals, and trading partner agreements.

RosettaNet specifies the envelope or container format that remains constant when exchanging business documents (the payloads), whereas the document exchange choreography and the XML schemas vary based on which PIP and document type are used. The RosettaNet envelope format is also independent of the specific transfer protocol you use.

AS1-1.0

Applicability Statement 1—specification for using EDI over SMTP. AS1 also works with non-EDI document types such as XML and TXT files.

Generic File-1.0

Transport by which messages are sent to or received from a file in a local file system.

Generic AQ-1.0

Transport by which messages are sent to or received from Oracle AQ single or multiconsumer queues. To specify and use an AQ queue as single consumer, set the Consumer parameter of the Generic AQ protocol to none.

Generic FTP-1.0

Transport by which messages are sent to or received from a file at a remote FTP server.

Generic SFTP-1.0

Transport by which messages are sent to or received from a file at a remote SFTP server.

Generic JMS-1.0

Transport by which messages are sent to or received from a JMS queue or topic. If a user name and password are not provided, the local JNDI is used, including in a clustered environment, provided that the destinations are distributed.

Oracle B2B does not support javax.jms.ObjectMessage.

Generic HTTP-1.0

Transport by which messages are sent to or received from a Web server.

Generic Email-1.0

Transport by which messages are sent to or received from an e-mail server.


Depending on the channel/transport protocol selected, you provide channel details such as transport protocol parameters, channel attributes, exchange protocol parameters, and security parameters, as shown in Figure 5-19.

Figure 5-19 Channel Details Tabs

Description of Figure 5-19 follows
Description of "Figure 5-19 Channel Details Tabs"

The transport protocol parameters define the properties specific to a given use of a protocol endpoint. The transport is responsible for message delivery using the selected transport protocol, mode (synchronous or asynchronous), server, and protocol endpoint address (trading partner address, such as a URI). Table 5-3 describes the transport protocol parameters.

The channel attributes define the communication interface between the host trading partner's host application and its installation. Table 5-4 describes the channel attributes.

The exchange protocol parameters define the headers, acknowledgments, and packaging that puts the headers and payload together (the message exchange mechanism). Table 5-5 describes the exchange protocol parameters.

Security parameters define features such as signing, encryption, and digital signatures. Message encryption using an AES setting is preferable, where available. Table 5-6 describes the security parameters.

Note the following:

  • No security parameters are specified for the Generic protocols—Generic File-1.0, Generic AQ-1.0, Generic FTP-1.0, Generic SFTP-1.0, Generic JMS-1.0, Generic HTTP-1.0, and Generic Email-1.0.

  • Security parameters do not apply to the MLLP channel.

To configure a channel for a trading partner, do the following:

Task 1   Add a Channel

Add a channel for the responder in a B2B transaction.

  1. Click the Partners link.

  2. Select a trading partner.

  3. Click the Channels tab.

  4. Click Add.

  5. Enter a channel name.

  6. Select a protocol, as described in Table 5-1.

    Figure 5-20 shows the list of protocols.

    Figure 5-20 Selecting a Protocol

    Available channels
    Description of "Figure 5-20 Selecting a Protocol"

  7. Click Save.

    Based on the delivery channel protocol you selected in Step 6, the applicable protocol is displayed in the Transport Protocol field, as shown in Table 5-2.

    Table 5-2 Delivery Channels and Transport Protocols

    Channel Protocol Selected... Transport Protocol Displayed...

    AS2-1.1

    ebMS-2.0, ebMS-1.0

    RosettaNet-V02.00, RosettaNet-01.00

    Generic HTTP-1.0

    HTTP

    AS1-1.0

    Generic Email-1.0

    Email

    MLLP-1.0

    TCP

    Generic File-1.0

    File

    Generic AQ-1.0

    AQ

    Generic FTP-1.0

    FTP

    Generic SFTP-1.0

    SFTP

    Generic JMS-1.0

    JMS


Task 2   Provide Transport Protocol Parameters
  1. Click the Transport Protocol Parameters tab.

  2. Provide transport protocol parameters, as described in Table 5-3, depending on the channel/transport protocols selected in Task 1.

    Table 5-3 describes the transport protocol parameters (listed in alphabetical order) and the protocols to which the parameters apply.

    Table 5-3 Transport Protocol Parameters

    Parameter Description Protocol Used With

    Additional transport headers

    The custom HTTP headers used to send messages to a trading partner

    For the sync response process, additional transport headers must be set. For sender to treat the response as an inbound message, add syncresponse=true as part of Additional Transport Header.

    AS2 (optional)

    ebMS-2.0 (optional)

    ebMS-1.0 (optional)

    Generic HTTP (optional)

    RosettaNet-V02.00 (optional)

    RosettaNet-01.10 (optional)

    Archival Directory

    B2B channels move the processed files to this directory. By default, it is a destructive read—processed files are deleted from the endpoint. In this case, files are moved to the path provided.

    Generic File-1.0 (optional)

    Generic FTP-1.0 (optional)

    Generic SFTP-1.0 (optional)

    Cache Connections

    If enabled, file listing and processing of the file occur in the same session (contrary to the default, in which listing and processing occur in different sessions).

    Generic FTP-1.0 (optional)

    Channel mask

    To enable SSL for FTP, enter one of the following:

    • Control—Encrypts the control channel

    • Data—Encrypts the data channel

    • Both—Encrypts both the data and control channels

    The default is None (no SSL).

    Generic FTP (optional)

    Cipher suites

    Provide the preferred cipher for encryption.

    Generic FTP (optional)

    Connection factory

    The JNDI location or Java class name for the connection factory, as in jms/b2b/B2BQueueConnectionFactory.

    Generic JMS (optional)

    Connection Mode

    Select from Client or Server.

    MLLP-1.0 (required; for remote trading partners only)

    Consumer

    The client that receives the message. Set this parameter to none to use a single consumer AQ queue.

    Generic AQ (optional)

    Content type

    The content type of the payload being sent over e-mail. The default content type is text/plain; other examples include application/xml and application/edi. This value is used only for the delivery channel (to send e-mail) and not for the listening channel. On the listening channel side, intelligence is built into the transport adapter to deal with different content types, so no configuration is required.

    AS1 (optional)

    Generic Email (optional)

    Control port

    Provide a value to change the default FTP port value (21)

    Generic FTP (optional)

    Data port

    For active FTP connections, use this option to configure the static/fixed data port of the FTP server.

    Generic FTP (optional)

    Datasource

    The JNDI name of the JDBC data source to access AQ queues.

    Generic AQ (optional)

    Destination name

    The JMS destination name

    Generic JMS (optional)

    Destination Provider

    Enables B2B to connect to JMS queues or topics available on remote servers. JNDI properties required to connected to the target server are expected as the value. Use ; (semicolon) as the separator for each key/value pair.

    Generic JMS-1.0 (optional)

    Directory name format

    Directory name format to receive

    Generic FTP (optional)

    Email ID

    The e-mail address to which messages are delivered (similar to specifying the path for a file channel or queues in AQ or JMS).

    AS1 (required)

    Generic Email (required)

    Email Server

    Select IMAP or POP3.

    AS1 (required)

    Generic Email (required)

    dateFormat

    The date format specified in the e-mail delivery channel.

    Sample formats are as follows:

    • dd/mm/yyyy

    • yyyy.MM.dd G 'at' HH:mm:ss z

    • yyMMddHHmmssZ

    Generic Email (optional)

    Enable CCC

    Enables B2B to authenticate in an SSL session and do the rest of the file transfer commands on a plain socket.

    Generic FTP-1.0 (optional)

    Enable Marker

    If enabled, creates a zero-byte file with the same name as the source, indicating completion of reading or writing. The file carries the same name as the source, but with the extension marker.

    Generic File-1.0 (optional)

    Generic FTP-1.0 (optional)-1.0

    Generic SFTP-1.0 (optional)

    Encoding

    The encoding used in B2B to convert the contents of the inbound files.

    Generic FTP (optional)

    Filename formatFoot 1 

    The following file name formats can be used:

    %FROM_PARTY%
    %TO_PARTY%
    %DOCTYPE_NAME%
    %DOCTYPE_REVISION%
    %MSG_ID%
    %TIMESTAMP%
    

    The following file name format can be used for ebMS documents only:

    %ACTIONNAME%
    

    These file name formats can be used in any combination; for example,

    %TO_PARTY%_%DOCTYPE_NAME%_%DOCTYPE_REVISION%.dat
    

    produces something like Acme_4010_850.dat. Any file extension is allowed.

    See footnote below.

    Generic File (optional)

    Generic FTP (optional)

    Generic SFTP (optional)

    Filename Separator

    File name format separator to separate the keys. If a character other than _ (underscore) is used as the filename separator, then specify the value in the Filename Separator field.

    The Filename Separator parameter works with the Filename format parameter, and you should use the same separator value in the Filename format and Filename Separator parameters.

    For example if using Filename format %TO_PARTY%_%DOCTYPE_NAME%_%DOCTYPE_REVISION%.dat, then the Filename Separator should be _ (underscore).

    The $ and ^ characters cannot be used as filename separators

    Default value is _ (underscore)

    Generic File (optional)

    Generic FTP (optional)

    Generic SFTP (optional)

    Folder

    An absolute directory path is recommended.

    AS1 (optional)

    Generic Email (optional)

    Folder name

    An absolute directory path is recommended.

    Generic File (required)

    Generic FTP (required)

    Host name

    The trading partner's transport or e-mail server exchanging messages.

    For the MLLP 1.0 protocol, if the connection mode is set to Server, then the host name must be the B2B server. If the connection mode is set to Client, then the host name must be the remote B2B server (MLLP server).

    AS1 (required)

    Generic AQ (optional)

    Generic FTP (required)

    MLLP-1.0 (required; for remote trading partners only)

    Generic SFTP (required)

    Generic Email (required)

    Is Map Payload Alone

    Indicates that the JMS map message contains only the payload

    Generic JMS (optional)

    Is topic

    Select to indicate that JMS is communicating with a topic (not a queue).

    Generic JMS (optional)

    Is Van Mailbox

    If enabled, B2B treats the endpoint as a VAN Mailbox and operates accordingly.

    Generic FTP-1.0 (optional)

    Message type

    Select a JMS message type: BYTES, TEXT, or MAP.

    Generic JMS (optional)

    Minimum Age

    Files arriving at the endpoint are processed after the time interval entered, in milliseconds.

    Generic File-1.0 (optional)

    Generic FTP-1.0 (optional)

    Generic SFTP-1.0 (optional)

    Pass phrase and Confirm pass phrase

    If you enter a private key file location, and if the private key file is pass-phrase protected, then enter the pass phrase.

    Generic SFTP (optional)

    Password and Confirm Password

    To use password authentication, provide a Key Store password, which is used for HTTP basic authentication.

    AS1 (optional)

    AS2 (optional)

    Generic AQ (optional)

    ebMS-2.0 (optional)

    ebMS-1.0 (optional)

    Generic FTP (optional)

    Generic HTTP (optional)

    Generic SFTP (optional)

    Generic JMS (optional)

    Generic Email (optional)

    RosettaNet-V02.00 (optional)

    RosettaNet-01.10 (optional)

    Path

    The absolute directory path where messages are sent from or received.

    Generic SFTP (required)

    Permanent Connection

    When set to false (the default value), a message is sent on a new connection and the connection is closed after the ACK is received. As a receiver of the message, the connection is closed after the ACK is sent back to the trading partner. When set to true, a cached connection is used to exchange all the messages.

    MLLP-1.0 (optional; for remote trading partners only)

    Polling interval

    The time interval in seconds during which Oracle B2B polls the server for inbound messages.

    AS1 (optional)

    Generic File (not available)

    Generic AQ (optional)

    Generic FTP (not available)

    MLLP-1.0 (optional; for remote trading partners only)

    Generic SFTP (not available)

    Generic JMS (optional)

    Generic Email (not available)

    Port number (or Port)

    AQ runs on default port 1521.

    SFTP runs on default port 22, which can be changed to another port.

    FTP runs on default port 21, which is not displayed. See the description of Control Port for how to change this port number.

    For the MLLP 1.0 protocol, if the connection mode is set to Server, then the port must be a valid TCP port number. If the connection mode is set to Client, then the port must be the same as the port used on the MLLP server.

    Generic AQ (optional)

    MLLP-1.0 (required; for remote trading partners only)

    Generic SFTP (required)

    Preserve Filename

    Retains the file name.

    Generic File-1.0 (optional)

    Generic FTP-1.0 (optional)

    Generic SFTP-1.0 (optional)

    Private key

    To use public key authentication, provide the private key file location. You may also need to provide a pass phrase if the private key file is pass-phrase protected.

    Generic SFTP (optional)

    Queue name

    The AQ queue name

    Generic AQ (optional)

    Recipient

    The value used when delivering a message to the AQ queue. For example, if you set the recipient to testuser, then the message can be consumed only by the consumer with the name testuser (in other words, the recipient is on the sending side and the consumer is on the listening side).

    Generic AQ (optional)

    Send as attachment

    If enabled, the message (payload) is sent as an e-mail attachment instead of the typical delivery in which the payload is the message body.

    AS1 (optional)

    Generic Email (optional)

    Sequence (Sequencing)

    Enable this property when delivering the incoming EDI, HL7, or Custom message in sequence to the back-end application is required.

    See Section 5.5.2, "Message Sequencing" for more information.

    MLLP-1.0 (optional; for remote trading partners only)

    Generic File-1.0 (optional)

    Generic FTP-1.0 (optional)

    Generic SFTP (optional)

    SID

    System ID to identify an Oracle database

    Generic AQ (optional)

    Subject

    The subject header of the e-mail message

    AS1 (optional)

    Generic Email (optional)

    Subscriber ID

    The JMS subscriber ID is required if JMS is communicating with a topic.

    Generic JMS

    Timeout

    Defines how long a transient MLLP connection keeps the socket open for the acknowledgment message. The default timeout value is 300 seconds. This parameter applies only to a transient MLLP connection (not to a permanent connection).

    Timeout can be configured as additional transport header at HTTP delivery channel.

    Example value: timeout=30 (timeout value is in seconds)

    MLLP-1.0 (optional; for remote trading partners only)

    Timestamp Format

    About the timestamp format, timestamp offset, and timestamp source parameters:

    When the minimum age of the parameter receiver file has a value greater than zero, B2B ensures that the file has not been modified before picking up the file for processing. In other words, the system timestamp of the FTP server may differ from the system timestamp of the B2B server. The timestamp format, timestamp offset, and timestamp source parameters are used to get the last modified time for the receiver file. (See also the Minimum Age parameter in this table.)

    The receiver read-ordered timestamp format specifies how to parse the timestamp from the response string that is obtained using the FTP command. Index information is also included. For example,

    [43,55,'MMM dd HH:mm',ucy] - In the response string from the FTP command, the timestamp is present between index 43 and 55.

    [4,+14,'yyyyMMddHHmmss'] - In the response string from the FTP command, the timestamp is present between index 4 and index (4+4=18).

    You can specify multiple format masks, each enclosed by square brackets, as follows:

    format-mask = start "," end "," "'" time-pattern "'" ["," current-year]
    

    where

    start = integer
    end   = integer
    time-pattern = java.text.SimpleDateFormat | "N"
    current-year   = "CY"
    TimestampFormats = {"[" format-mask "]" }+
    

    For example, [41,53,'MMM dd HH:mm',CY][41,53,'MMM dd yyyy']

    CY must be added for time patterns in which a year is not present. The adapter then internally appends the format yyyy to the format mask you provide and appends the current year to the actual timestamp string before parsing it.

    The start and end indexes demarcate the timestamp substring of the string, originating either from the FTP LIST command or the actual file name. For a given FTP server, you may need to manually experiment with the server to determine which format masks to use.

    If time-pattern is specified as N, the substring is treated as a regular integral number. In terms of time (t), the number (N) is interpreted as follows:

    t = "12:00 am, January 1, 1970 UTC" + N milliseconds
    

    Generic FTP-1.0 (optional)

    Timestamp Offset

    The receiver read-ordered timestamp offset is used to convert the timestamp of the file with respect to the system time where the B2B Server is running.

    For example, -25200000, subtracts 2520 milliseconds from the timestamp obtained from the FTP command to make it compatible with the B2B system time.

    Note:

    • Even if B2B and FTP are on the same machine, you may need an offset if the timestamp from the FTP command is in a different time zone.

    • Turn on the transport log to see how what timestamp the FTP command returns and then set values appropriately.

    Generic FTP-1.0 (optional)

    Timestamp Source

    The receiver read-ordered timestamp source specifies the format used to get the timestamp, as follows:

    LISTTIME - The last modified time in the format 'MMM dd HH:mm', ucy

    TIMESTAMP - The last modified time in the format 'yyyyMMddHHmmss'

    Generic FTP-1.0 (optional)

    Transfer Type

    Select binary or ascii for the file transfer mode.

    Generic FTP-1.0 (optional)

    URL

    The HTTP or HTTPS endpoint URL of the trading partner.

    AS2 (required)

    ebMS-2.0 (required)

    ebMS-1.0 (required)

    Generic HTTP (required)

    RosettaNet-V02.00 (required)

    RosettaNet-01.10 (required)

    Use JMS ID

    Uses the JMS message ID as the B2B message ID. This facilitates correlation at the JMS level.

    Generic JMS-1.0 (optional)

    User name

    The user name (login name) to connect to the target server, used for HTTP basic authentication. This value is optional for AQ and JMS because B2B can use the configured JNDI data sources to connect to queues.

    AS1 (optional

    AS2 (optional)

    Generic AQ (optional)

    ebMS-2.0 (optional)

    ebMS-1.0 (optional)

    Generic FTP (required)

    Generic HTTP (optional)

    Generic SFTP (required)

    Generic JMS (optional)

    Generic Email (optional)

    RosettaNet-V02.00 (optional)

    RosettaNet-01.10 (optional)

    Use proxy

    Select a proxy server if used.

    AS2 (optional)

    ebMS-2.0 (optional)

    ebMS-1.0 (optional)

    Generic FTP (optional)

    Generic HTTP (optional)

    Generic SFTP (optional)

    RosettaNet-V02.00 (optional)

    RosettaNet-01.10 (optional)


    Footnote 1 In File/FTP channels, if the filename format is set then the directory name format is ignored.

  3. Click Save.

Task 3   Provide Channel Attributes
  1. Click the Channel Attributes tab.

  2. Provide channel attributes, as described in Table 5-4, depending on the channel/transport protocols selected in Task 1.

    Table 5-4 Channel Attributes

    Parameter Description Protocol Used With

    Ack Mode

    Select Sync, Async, or None, for the mode in which the trading partner receives messages. Select None for all generic exchanges.

    For MLLP exchanges, select Sync or Async for a transient connection. Select None for a permanent connection.

    AS1 (optional)

    AS2 (optional)

    ebMS-2.0 (optional)

    ebMS-1.0 (optional)

    MLLP-1.0 (required; for remote trading partners only)

    RosettaNet-V02.00 (optional)

    RosettaNet-01.10 (optional)

    Compressed

    Select for message compression.

    AS1 (optional)

    AS2 (optional)

    This parameter is available only with AS1 and AS2, although it may appear in the B2B interface for other protocols.

    Description

    Provide an optional description.

    AS1 (optional)

    AS2 (optional)

    ebMS-2.0 (optional)

    ebMS-1.0 (optional)

    MLLP-1.0 (optional; for remote trading partners only)

    Generic File (optional)

    Generic AQ (optional)

    Generic FTP (optional)

    Generic HTTP (optional)

    RosettaNet-V02.00 (optional)

    RosettaNet-01.10 (optional)

    Generic SFTP (optional)

    Generic JMS (optional)

    Generic Email (optional)

    Enable/Disable Channel

    The channel is the communication interface between the host trading partner's host application and its installation.

    MLLP-1.0 (required; for remote trading partners only)

    Internal

    Caution: While the B2B interface permits you to select invalid protocols when Internal is selected, do not select any protocols other than the generic protocols.

    Select this option if the channel is internal to the host trading partner's enterprise.

    If this option is checked, then only the generic protocols are valid:

    Generic File (optional)

    Generic AQ (optional)

    Generic FTP (optional)

    Generic HTTP (optional)

    Generic SFTP (optional)

    Generic JMS (optional)

    Generic Email (optional)

    If this option is not checked, all protocols are valid:

    AS1 (optional)

    AS2 (optional)

    ebMS-2.0 (optional)

    ebMS-1.0 (optional)

    Generic File (optional)

    Generic AQ (optional)

    Generic FTP (optional)

    Generic HTTP (optional)

    RosettaNet-V02.00 (optional)

    RosettaNet-01.10 (optional)

    Generic SFTP (optional)

    Generic JMS (optional)

    Generic Email (optional)

    Retry Count

    The number of times that Oracle B2B retries to send the message.

    See Section 5.5.5, "Configuring Delivery Retry Options" for more information.

    AS1 (optional)

    AS2 (optional)

    ebMS-2.0 (optional)

    ebMS-1.0 (optional)

    Generic File (optional)

    Generic AQ (optional)

    Generic FTP (optional)

    Generic HTTP (optional)

    MLLP-1.0 (optional; for remote trading partners only)

    RosettaNet-V02.00 (optional)

    RosettaNet-01.10 (optional)

    Generic SFTP (optional)

    Generic JMS (optional)

    Generic Email (optional)

    Retry Interval

    The interval, specified in minutes, after which B2B attempts to resend a message. B2B tries to resend the message if the status of the message is not Complete.

    For protocols with acknowledgments, B2B waits for the acknowledgment (formerly called the Time to Acknowledge parameter). If it is not received, the retry interval setting causes B2B to retry.

    See Section 5.5.5, "Configuring Delivery Retry Options" for more information.

    AS1 (optional)

    AS2 (optional)

    ebMS-2.0 (optional)

    ebMS-1.0 (optional)

    Generic File (optional)

    Generic AQ (optional)

    Generic FTP (optional)

    Generic HTTP (optional)

    MLLP-1.0 (optional; for remote trading partners only)

    RosettaNet-V02.00 (optional)

    RosettaNet-01.10 (optional)

    Generic SFTP (optional)

    Generic JMS (optional)

    Generic Email (optional)

    Transport Callout

    For the inbound message, B2B invokes the transport callout immediately after it receives a message from the transport. For the outbound message, B2B invokes the transport callout immediately before it sends a message to the transport.

    AS1 (optional)

    AS2 (optional)

    ebMS-2.0 (optional)

    ebMS-1.0 (optional)

    Generic File (optional)

    Generic AQ (optional)

    Generic FTP (optional)

    Generic HTTP (optional)

    MLLP-1.0 (optional; for remote trading partners only)

    RosettaNet-V02.00 (optional)

    RosettaNet-01.10 (optional)

    Generic SFTP (optional)

    Generic JMS (optional)

    Generic Email (optional)


  3. Click Save.

Task 4   Provide Exchange Protocol Parameters
  1. Click the Exchange Protocol Parameters tab.

  2. Provide exchange protocol parameters, as described in Table 5-5, depending on the channel/transport protocols selected in Task 1.

    Table 5-5 Exchange Protocol Parameters

    Parameter Description Protocol Used With

    Carriage Return Character

    This value can be only one character. The carriage return character does not appear in the wire message payload. The default value is 0x0D (hexadecimal).

    MLLP-1.0 (optional; for remote trading partners only)

    Custom Immediate ACK File

    Browse for a file with a customized acknowledgment.

    MLLP-1.0 (optional; for remote trading partners only)

    Discard HL7 ACK

    Enable this property for the FA to be correlated at the transport level. This avoids the traditional message correlation that includes trading partner agreement identification, translation, and so on, thus improving performance. Because the ACK is stopped at the transport layer after correlation, it appears in the wire message report, but does not appear in the business message report.

    To enable the property, select one of the following codes. If the selected code is in the MSA.2 segment, then the ACK is stopped at the transport layer:


    AA—Application acknowledgment: Accept
    AE—Application acknowledgment: Error
    AR—Application acknowledgment: Reject
    CA—Application acknowledgment: Commit Accept
    CE—Application acknowledgment: Commit Error
    CR—Application acknowledgment: Commit Reject

    Selecting None does not enable this property.

    MSA.2 is the second element of MSA segment.

    MLLP-1.0 (optional; for remote trading partners only)

    Duplicate Elimination

    If enabled, a duplicate elimination header is added for an outbound message. This flag does not apply to the inbound message flow.

    ebMS-2.0 (optional)

    ebMS-1.0 (optional)

    End Block

    This property is used to indicate the end of the message. Generally, End Block is sent after the message is sent to the trading partner.

    MLLP-1.0 (optional; for remote trading partners only)

    For generic support for TCP only.

    End Block Character

    This value can be only one character. The end block character does not appear in the wire message payload. The default value is 0x1C (hexadecimal).

    MLLP-1.0 (optional; for remote trading partners only)

    Header Length

    This property defines the header size, which is prefixed to the actual data. (This includes the start block, message length, and padded header).

    MLLP-1.0 (optional; for remote trading partners only)

    For generic support for TCP only.

    Identify TP by Delivery Channel

    The trading partner is identified using the delivery channel.

    Enable this parameter to identify an incoming message by the delivery channel configured for the remote trading partner (rather than by using the MLLP ID). This feature serves as an anonymous trading partner, for situations when identifying the sender is not important. If this parameter is not checked, then the MLLP ID (or some document-level identifier such as HL7 Message Application ID or HL7 Message Facility ID to identify the agreement) is required for MLLP exchanges.

    MLLP-1.0 (optional; for remote trading partners only)

    Immediate ACK

    Note: The MLLP immediate ACK of an incoming business message (with control number 1017, for example), prefixes the control number with A, as in A1017. This indicates to the trading partner that it is an ACK control number. If the prefixed string exceeds the permissible length (for example, if any validation rules are violated at the receiving end), use the Map ACK Control ID parameter.

    An immediate acknowledgment is generated and transmitted in the TCP transport layer instead of the document layer. It is an alternative to the functional acknowledgment. It is available when the turnaround time of a functional acknowledgment is undesirable (for example, for some business-critical health care applications), because the functional acknowledgment captures translation and validation errors.

    Oracle B2B can send an immediate acknowledgment in the following modes:

    • Default: B2B parses the incoming HL7 message and generates an acknowledgment from it. In this mode, B2B can send the acknowledgment to the sending application with correlation details (for example, the control number from the incoming message, the sending application, and so on.) Hence, the trading partner application can correlate the incoming acknowledgment message. If mapping the MSH.10 of the ACK with the MSH.10 of the incoming business message is required, then enable the Map ACK Control ID property. By default, an Immediate ACK is a generic ACK. If generating an ACK with a trigger event is required, then enable the Map Trigger Event property.

    • Simple: B2B sends the predefined acknowledgment message to the sender and does not parse the message.

    • Custom: B2B sends the custom HL7 acknowledgment message based on a configurable file content. If this mode is selected, then specifying the file in the Custom Immediate ACK File property is required.

    • Negative: Select this option to send an immediate ACK only in the case of exceptions.

    MLLP-1.0 (optional; for remote trading partners only)

    Map ACK Control ID

    Select to enable the mapping of the MSH.10 message header of the business message to the MSH.10 message header of the immediate acknowledgment.

    MLLP-1.0 (optional; for remote trading partners only)

    Map Trigger Event

    Sends an immediate acknowledgment with a trigger event.

    MLLP-1.0 (optional; for remote trading partners only)

    Message Length Index

    This property indicates the data size available in the header. Start index to end index defines the message size. For example, if the data length is the first four bytes, then the header size is 4 and Message Length Index is 1-4.

    MLLP-1.0 (optional; for remote trading partners only)

    For generic support for TCP only.

    Message Order Semantics

    A placeholder for CPP/CPA; not involved during run time.

    ebMS-2.0 (optional)

    Persist Duration

    A placeholder for CPP/CPA; not involved during run time.

    ebMS-2.0 (optional)

    Receipt Delivery Option

    This parameter is used to configure a URL to which MDN has to be sent back in the case of an asynchronous mode.

    AS2 (optional)

    Retain Header

    Select this property to retain the header while sending the message to the trading partner (for outbound messages) or to Oracle B2B (for inbound messages).

    When you retain the header, B2B does not not handle the custom header. This is handled using the transport callout.

    MLLP-1.0 (optional; for remote trading partners only)

    For generic support for TCP only.

    Send Party Type and Value

    If enabled, the send party type and value from the message header are sent to the back-end application.

    ebMS-2.0 (optional)

    ebMS-1.0 (optional)

    Signed and Compressed

    If selected, the message is first signed, and then compressed. If not selected, the message is first compressed, and then signed.

    AS1 (optional)

    AS2 (optional)

    Start Block

    This property is used to indicate the beginning of the message. Generally, Start Block is sent before the message is sent to the trading partner.

    MLLP-1.0 (optional; for remote trading partners only)

    For generic support for TCP only.

    Start Block Character

    This value can be only one character. The start block character does not appear in the wire message payload. The default value is 0X08 (hexadecimal).

    MLLP-1.0 (optional; for remote trading partners only)


  3. Click Save.

Task 5   Configure Security
  1. Click the Security tab.

  2. Provide security parameters, as described in Table 5-6, depending on the channel/transport protocols selected in Task 1.

    Note:

    The Digital Signature and Encryption lists are populated with the available certificates when the Key Store location is provided for the host trading partner. See Task 6, "Provide Key Store Information for the Host Trading Partner" for more information.

    Table 5-6 Security Parameters

    Parameter Description Protocol Used With

    Ack Signed

    Select this option to ensure that the responder acknowledges receipt of the messages; nothing needs to be provided.

    AS1 (optional)

    AS2 (optional)

    ebMS-2.0 (optional)

    ebMS-1.0 (optional)

    RosettaNet-V02.00 (optional)

    RosettaNet-01.10 (optional)

    Digital Signature

    To use a digital signature certificate, the Key Store must have the corresponding private key.

    If Message Signed is selected, then select the following for AS1:

    SMIME 3.0 with SHA1 - RSA

    If Message Signed is selected, then select one of the following for AS2:

    SMIME 3.0 with MD5 - RSA

    SMIME 3.0 with SHA1 - RSA

    If Message Signed is selected, then select one of the following for ebMS-2.0 and ebMS-1.0:

    XMLDSIG with SHA1 - RSA

    XMLDSIG with SHA1 - DSA

    If Message Signed is selected, then select one of the following for RosettaNet-V02.00:

    SMIME 3.0 with MD5 - RSA

    SMIME 3.0 with SHA1 - RSA

    SMIME 2.0 with MD5 - RSA

    SMIME 2.0 with SHA1 - RSA

    XMLDSIG with SHA1 - RSA

    XMLDSIG with SHA1 - DSA

    If Message Signed is selected, then select one of the following for RosettaNet-01.10:

    SMIME 3.0 with MD5 - RSA

    SMIME 3.0 with SHA1 - RSA

    SMIME 2.0 with MD5 - RSA

    SMIME 2.0 with SHA1 - RSA

    AS1

    AS2

    ebMS-2.0

    ebMS-1.0

    RosettaNet-V02.00

    RosettaNet-01.10

    Encryption

    To use an encryption certificate, no private key entry is needed.

    If Message Encrypted is selected, then select one of the following for AS1 and AS2:

    SMIME 3.0 with DES

    SMIME 3.0 with 3DES

    SMIME 3.0 with RC2 - 40

    SMIME 3.0 with RC2 - 64

    SMIME 3.0 with RC2 - 128

    If Message Encrypted is selected, then select one of the following for ebMS-2.0 and ebMS-1.0:

    XMLENC with 3DES - RSA-v1.5

    XMLENC with AES-128 RSA-OAEP

    XMLENC with AES-192 RSA-OAEP

    XMLENC with AES-256 RSA-OAEP

    AS1

    AS2

    ebMS-2.0

    ebMS-1.0

    RosettaNet-V02.00 (optional)

    Message Encrypted

    Select this option to enable message encryption. This option requires you to select an encryption schema in the Encryption field.

    AS1 (optional)

    AS2 (optional)

    ebMS-2.0 (optional)

    ebMS-1.0 (optional)

    RosettaNet-V02.00 (optional)

    Message Signed

    Select this option to provide a digital signature in the Digital Signature field.

    AS1 (optional)

    AS2 (optional)

    ebMS-2.0 (optional)

    ebMS-1.0 (optional)

    RosettaNet-V02.00 (optional)

    RosettaNet-01.10 (optional)


  3. Click Save.

Note:

For AS1, B2B supports only SHA1 for signing. MD5 is not supported for AS1 signing.

5.5.1 About MLLP

An MLLP delivery channel is established by a two-way handshake between the server and client. It is always bidirectional, unlike other transports, and is used for both sending and receiving messages. An MLLP delivery channel is configured for the remote trading partner only, and is configured as a server socket or a client socket. As a server socket, the channel accepts connections on the specified port. As a client socket, the channel establishes a connection on the specified IP address and port. For either socket type, you specify a permanent or transient connection type. A permanent connection, once established, is cached and serves as a channel for the message exchange throughout the life cycle of the endpoint. A transient connection serves as a channel only for exchanging one set of messages comprised of the business message and its acknowledgment. See Section 5.5.1.1, "Overriding the Connection Mode."

A recommended configuration is for the sender to configure the MLLP client delivery channel and for the receiver to configure the MLLP server channel. For example, if Acme wants to send an HL7, Custom, or positional flat file message to GlobalChips, Acme can have the client MLLP permanent channel and GlobalChips can have the server MLLP permanent channel. MLLP connection types (permanent and transient) for the server and client must match (both permanent or both transient). However, in some cases the sender can have the server channel and receiver can have the client channel provided the connection is pre-established.

Because MLLP is a bidirectional channel, it is not considered to be a listening channel and the same MLLP delivery channel can be used for both sending and receiving messages.

Because MLLP operates in single delivery channel mode by default, simply select a delivery channel under the remote trading partner when creating an agreement. If operating in a non-single MLLP delivery channel mode is required, select a different MLLP delivery channel in the other agreements.

5.5.1.1 Overriding the Connection Mode

To override the connection mode for a message without changing the configuration manually, set the following properties:For changing from a transient to a permanent connection:

CONNMODE:Permanent

For default integration:

b2b.connMode:Permanent

You can also change from a permanent connection to a transient connection.

5.5.1.2 Generic Support for TCP

MLLP uses SB (start byte), EB (end byte) and CR to interpret a message. To interpret a message using the length of the data or the start string and end string instead of SB and EB, Oracle B2B provides a generic solution for TCP.

For generic support for TCP, use with the following parameters on the Exchange Protocol Parameters tab (shown in Figure 5-21): Start Block, End Block, Header Length, Message Length Index, and Retain Header.

Figure 5-21 Parameters for Generic TCP

Description of Figure 5-21 follows
Description of "Figure 5-21 Parameters for Generic TCP"

Note:

When you create a generic TCP channel using the MLLP protocol, the parameters on the Exchange Protocol Parameters tab appear as shown in Figure 5-21. After creating the channel, two subtabs appear, with MLLP-specific and generic TCP-specific parameters grouped under them.

See Table 5-5, "Exchange Protocol Parameters" for descriptions of these parameters.

Table 5-7 describes how Oracle B2B processes messages using MLLP when data is sent or received using the parameters that support generic TCP.

Table 5-7 Generic TCP Solutions

Generic TCP Solution Description

Send or receive data by specifying a start block and end block

Use the Start Block and End Block parameters available on the Exchange Protocol Parameters tab when you select MLLP-1.0 for a remote trading partner. See Table 5-5 for descriptions of the Start Block and End Block parameters.

Example: <start block>Data<end block>

Send or receive data by specifying a start block, end block, and data length

Use the Start Block, End Block, Message Length Index, and Header Length parameters available on the Exchange Protocol Parameters tab when you select MLLP-1.0 for a remote trading partner. See Table 5-5 for descriptions of the parameters.

Example: <start block><length>Data<end block>

Send or receive data by specifying the data length

Use the Message Length Index and Header Length parameters available on the Exchange Protocol Parameters tab when you select MLLP-1.0 for a remote trading partner. See Table 5-5 for descriptions of the Message Length Index and Header Length parameters.

Example: <length>Data

Example: <length+header>Data

That is, 15HDRDATADATADATA, where you configure:


Message Length Index=1-2
Header length=5

15 is the length start after end index of Message Length Index. HDR is the header.

Send or receive data by specifying the start block and data size

Use the Start Block, Message Length Index, and Header Length parameters available on the Exchange Protocol Parameters tab when you select MLLP-1.0 for a remote trading partner. See Table 5-5 for descriptions of the Start Block, Message Length Index, and Header Length parameters.Note: In this case, the start block is part of the header and the minimum message length index must be more than the start block size.

Example: <start block><length>Data

Retain the back-end application header and B2B will not add the start block, data size, and end block.

To send data to the trading partner without adding a header and retain the back-end application header, select the Retain Header property. See Table 5-5 for a description of Retain Header parameter.


5.5.1.3 Dynamic Endpoints

The dynamic IP feature of MLLP provides flexibility to dynamically change the endpoints associated with a delivery channel. This is done by overriding the IP address of the delivery channel through the actionName/eventName attribute in the message enqueue header.

For example:

eventName=DynamicIP:GlobalChips:IP_address:port_number

or

actionName=DynamicIP:GlobalChips:IP_address:port_number

This feature is also available in B2B composites (as part of the SOA Service Component Architecture (SCA) assembly model) using the following syntax:

b2b.toDynamicIP=GlobalChips:IP_address:port_number

The b2b.toDynamicIP property is set in a normalized message property that is sent to B2B.

Oracle B2B generates a unique control number for each message. For a broadcasting case involving multiple dynamic endpoints corresponding to the same trading partner, the back-end application must provide the control number. Oracle B2B stores and uses the dynamic endpoint details for correlation of the acknowledgment. No additional configuration is required.

5.5.1.4 Using a Transport Callout to Extract Custom Headers

To extract a custom header for outbound messages, add the CUSTOM_HEADER property in the actionName property from the back-end application. This property will be available in the callout as a CUSTOM_HEADER parameter of CalloutMessage. You can retrieve the property in the callout for your usage.

For example:

eventName= CUSTOM_HEADER:your_value

For default integration:

b2b.customHeader= your_value

To extract a custom header for inbound messages, set the CUSTOM_HEADER property as the CalloutMessage parameter in the callout. The property will be available as part of the actionName properties in the back-end application. See Example 13-1, "Setting and Getting the CUSTOM_HEADER Property" for details.

5.5.2 Message Sequencing

Exchanging messages in sequence can be challenging in a multi-threaded system, because the first message produced may not necessarily arrive at the destination first. For enterprises with this business requirement, Oracle B2B provides a sequencer and a dispatcher. The sequencer sequences a message based on arrival time. The dispatcher dispatches the sequenced message. Message sequencing is available for outbound and inbound directions.

Protocols supported for message sequencing include MLLP Exchange (TCP transport) and Generic Exchange (FILE, FTP, SFTP, JMS, AQ, and HTTP transports).

Notes:

Even though it works for all documents, message sequencing is certified only for EDI, HL7, and Custom document protocols.

Sequencing is not supported for transient mode MLLP connections.

EDI batching is not supported for message sequencing. If sequencing is enabled on messages as part of BATCH, it can lead to errors and not all messages are processed. Do not use EDI batching on the messages that are sequenced.

FunctionalAck(FA) and Acknowledgement(ACK/MDN) are not sequenced.

Sequencing does not support the Delivery Channel retry feature. Use the Auto Stack Handler in the Sequencing feature to retry delivery of failed document delivery attempts rather than the retry setting in delivery channel. When documents are sequenced, the delivery channel used for the documents should avoid the use of retry settings.

5.5.2.1 Outbound Message Sequencing

Outbound Message Sequencing for AQ and JMS Delivery Channels

To enable sequencing for an outbound message, for AQ and JMS delivery channels, enqueue the message by setting the ACTION_NAME property to TARGET:sequence_target_name as shown in Example 5-1.

However, when using the ENQUEUE utility that is provided with the b2b.jar, set eventName (not ACTION_NAME) to TARGET:sequence_target_name; for example, eventName=TARGET:sequence1.

To enable sequencing when using the default channel, use b2b.sequencingTarget = sequence_target_name.

When using a self written AQ Enqueue utility, the AQ Header to be used is ACTION_NAME. eventName is to be used when using the B2B provided Enqueue utility in b2b.jar.

Example 5-1 Outbound Message Sequencing for AQ and JMS Delivery Channels

ACTION_NAME = TARGET:sequence_target_name

Outbound Message Sequencing for FTP and SFTP Delivery Channels

To enable FTP/SFTP sequencing selecting only the sequencing flag in the delivery channel configuration does not work. You must also configure an FTP listening channel with following parameters:

Sequencing

TimeStamp Format

TimeStamp Offset

TimeStamp Source

For example the following are sample values for the parameters:Sequencing: trueTimeStamp Format: 43,55,'MMM d yyyy'TimeStamp Offset: +0000TimeStamp Source: MMM dd yyyy

Note that, if sequencing is enabled, the order in which files are copied to the folder is the order in which they are processed. If a large payload is copied, the partner must wait until the large payload copy is complete. Then the sender may send the next file, as sequencing is based on the last-modified-timestamp on the file.

Outbound Message Sequencing for HTTP Delivery Channels

Post the message in b2b/sequenceReceiver, and add an additional HTTP header TARGET:sequence_target_name, otherwise the IP address is used as the sequence target.

The messages enqueued with the above header will be sequenced based on the specified sequence target for the transport protocols such as FTP, SFTP, JMS, AQ and HTTP/HTTPS. The enqueued messages with this header would be processed by Oracle B2B, and based on the enqueue time, the messages are sequentially delivered to the trading partner.

To dispatch the sequenced message, configure the Outbound Dispatcher Count parameter, shown in Figure 5-22.

Figure 5-22 Dispatcher Configuration: Administration > Configuration Tab

Description of Figure 5-22 follows
Description of "Figure 5-22 Dispatcher Configuration: Administration > Configuration Tab"

By default, the value is 0, which is the setting for sequencing without dispatching (stacking). Depending on the message load, set Outbound Dispatcher Count to the appropriate value.

Sequencing in Burst Mode

For sequencing with AQ and JMS, the Oracle B2B server might not be polling while messages get added into the queue. When Oracle B2B begins polling, several messages are available in a burst mode and Oracle B2B cannot maintain the sequence under normal conditions. To ensure sequence in burst mode, the following is recommended:

For AQ, along with the TARGET:target_name property, add the flag for B2B_SEQUENCE_TIMESTAMP with timestamp as the value.

For example:

TARGET:targetname;B2B_SEQUENCE_TIMESTAMP:1284371552121

In this example, 1284371552121 is the time in milliseconds (in Java).

For JMS, a new header can be added as B2B_SEQUENCE_TIMESTAMP with value as the time in milliseconds.

5.5.2.2 Inbound Message Sequencing

Inbound message sequencing is enabled as part of the delivery channel configuration. The incoming messages received by these delivery channels are processed by Oracle B2B and delivered in a sequenced manner based on the inbound time.

To enable sequencing for an inbound message, enable the Sequence property for the delivery channel, as shown in Figure 5-23.

Figure 5-23 Sequencer Configuration

Description of Figure 5-23 follows
Description of "Figure 5-23 Sequencer Configuration"

To dispatch the sequenced message, configure the Inbound Dispatcher Count parameter, as shown in Figure 5-22.

For AQ and JMS, in the case of inbound messages received from a partner, if there is a header TARGET (similar to how outbound message sequencing is enabled), then the same value is used and inbound messages are sequenced on the given target.

For HTTP inbound message sequencing, Oracle B2B exposes a URI, /b2b/sequenceReceiver, and requests arriving at this endpoint are processed sequentially. If you want to use multiple sequence targets, you can provide them by adding an HTTP header SEQUENCE_TARGET to the request.

To add SEQUENCE_TARGET as a header to an outbound HTTP message, use the Additional transport headers parameter in the delivery channel. See Table 5-3 for more information.

If the incoming message's HTTP headers contains SEQUENCE_TARGET as a header, then the value of this is used as the sequence target. If SEQUENCE_TARGET is not available and there is a FROM HTTP header, then that is used as the sequence target. If FROM HTTP header does not exist, then B2B will use the IP address from which the message originated as the Sequence Target. The originating IP address of the HTTP request is treated as the Sequence Target by default.

5.5.2.3 Sequencing Without Dispatching

Trading partner downtime is typically handled by stacking messages in the back-end application, which requires the entire message processing in B2B after the downtime. This leads to under-utilizing the B2B application during downtime and overloading when the trading partner comes up. This affects the regular message flow, because there is a surge in message processing.

When the auto stack handler is used, then Oracle B2B retries the outbound failed message in sequence. Once the endpoint is up for delivery, all messages in the sequence will be eligible for delivery, and this may cause an overload of message delivery at the endpoint. To reduce the outflow, set the b2b.OutboundDispatchInterval property, which sets the interval between dispatch of messages in milliseconds.

Upon trading partner delivery failure, the corresponding messages are marked not to be picked up by the dispatcher, resulting in stacking the messages in B2B instead of the back-end application. To process the messages, set the following properties:

Auto Stack Handler = true
Auto Stack Handler Interval = interval (in seconds)

The Auto Stack Handler and Auto Stack Handler Interval parameters are shown in Figure 5-22. When set to true, the stacked message are eligible for delivery by the dispatcher during an appropriate interval. It is also possible to specify the variable interval with a comma-separated value to Auto Stack Handler Interval.

5.5.2.4 Troubleshooting Message Sequencing

B2B Becomes Non-Responsive

If B2B becomes non-responsive after running thousands of messages as part of outbound sequenced messages, check the number of dispatchers. The recommended maximum number of dispatchers is 5.

Sequenced Message Failure

If the failure of a sequenced message is due to

  • Agreement not found

  • Validation errors which can be fixed by updating the ECS file.

You can recover the failed message by the following options:

  1. Inbound case: resubmit the wire message.

  2. Outbound case: resubmit the app message.

Otherwise, you can manually delete the row in the sequence manager table, if you do not want to process the failed message, but want to allow the blocked messages (following the failed message in sequence) to be allowed for delivery.

5.5.3 Using Transport Sync Callback

Sync support is provided using callout. This provides a platform to respond to the incoming requests in a synchronous way.

There may be several requirements for an Enterprise to send business responses synchronously. For example, an inbound 270 document may expect a 271 document response synchronously. Enterprises may want to set up sync support for simple custom documents of their choice over HTTP protocol.

Callout is the key component to enable synchronous response. In this model, callout holds the responsibility of delivering the incoming request message to the back end application, and get the corresponding business response from the back end application. Capabilities of back end applications in Enterprises may vary, so the callout implementers can choose their own approaches for sending and receiving messages to and from back end applications.

B2B Engine provides inbound message as an input to configured callout, and expects callout to give the response received from the back end application as its output. The output of callout will be processed as an outbound message in B2B, and the same is streamed back as a response for the inbound message on the same HTTP connection.

To configure sync response:

  1. Set up the inbound and outbound agreement.

  2. Create callout with the capability to send inbound requests and receive its business response from back end applications.

    See Example 13-3, "Code Example of a Sync Callback Callout" for a code sample.

    Callout output should have all the required values for Oracle B2B to process it as an outbound message. This may include TO_PARTY, DOCTYPE_NAME, DOCTYPE_REVISION and payload, among others.

    Callout output parameters such as TO_PARTY, DOCTYPE_NAME, and DOCTYPE_REVISION are case-sensitive. Parameters supported by Oracle B2B JMS adapters can be output valid output parameters.

  3. Attach the callout to the Inbound Agreement.

    All the sync requests should be send to the following URL

    http://host:port_number/b2b/syncreceiver
    
  4. Test the flow.

Note:

One dummy outbound channel is required to deploy the outbound agreement on the responder side, however Oracle B2B will not use the dummy channel, and the sync response is sent back on the same connection on which it received the inbound request.

Note:

Timeout can be configured as an additional transport header at HTTP delivery channel. For example: timeout=123

Note that the initiator of the sync flow must pay attention to the following issues:

The initiator of the sync flow must add syncresponse=true as part of the Addition Transport Header in a Generic HTTP, AS2, or ebms channel.

The initiator of the sync flow must set ack mode none/Async in AS2 or ebms channel.

5.5.4 Correlating Messages Using JMS Queues

You can correlate inbound and outbound messages using JMS queues, by setting A2A=true in the JMS header.

If the message ID (MSG_ID) is provided from a back end application, then MSG_ID is set to JMS Correlation ID in the B2B output, otherwise the JMS Message ID is set to JMS Correlation ID in the B2B output.

5.5.5 Configuring Delivery Retry Options

In the critical situations of B2B world, it is important to have the message delivered to the destination without fail and receive the exchange level acknowledgement or functional acknowledgement on time.

Oracle B2B provides the ability to retry message delivery at the Channel and Document levels.

5.5.5.1 Delivery Retry at the Channel Level

Channel retry is associated with the delivery channel, and is used to ensure successful delivery. You can configure the Retry Count and Retry Interval parameters for the number of times to retry and the interval between each retry. Oracle B2B retries the message for a successful delivery until all available retries are exhausted before errors are written. See Table 5-4 for information about the channel retry parameters.

Description of b2b_channelretry.gif follows
Description of the illustration b2b_channelretry.gif

For any exchange protocol with Acknowledgement case (for example MDN in AS2 and Acknowledgement in ebMS), the channel retry is used to retry the business message until the message gets to either the COMPLETE or ERROR state after completing the configured retry count. For generic exchange, channel level retry plays a role only in case of transport error.

The number of remaining retries in the retry count and retry interval for a specific message can be seen as part of the business message report.

5.5.5.2 Delivery Retry at the Document Level

Document retry is associated with an Agreement, and is used to ensure the successful integration of the message with the recipient trading partner. This feature consists of configuring a timeout value within which the Functional Acknowledgment has to be received for outbound business messages.

To enable this feature, set the Document Retry Count and Document Retry Interval parameters as shown in the following graphic.

Description of b2b_docretry.gif follows
Description of the illustration b2b_docretry.gif

After successful transmission of a business message, B2B must wait for Functional Acknowledgment for specified time. If FA is not received after retries are exhausted, B2B will raise an exception message to B2B Inbound Queue.

The number of remaining retry and interval for a specific message can be seen as part of the business message report.

Generic Exchange Scenario

For generic exchange, document retry attempts are triggered only upon successful transport Acknowledgment, and in the case of standard based exchange (such as AS1/AS2), only upon receipt of Positive Acknowledgment. That is, for a generic exchange, document retry attempts are triggered only post-transmit, whereas for a standard Acknowledgment case, attempts are triggered only upon receipt of positive Acknowledgment. For a negative Acknowledgment, document retry attempts are not triggered.

Channel-level Retry Interoperability

Channel-level retry attempts are not triggered by document level retries attempts.

In cases where no channel retry parameters are configured, document-level retry attempts are triggered after Document Retry Interval expires.

5.6 Using the Auto Create Agreement Feature

In the Partner area, shown in Figure 5-24, you can use the Auto Create Agreement icon to create an agreement for a remote trading partner.

Figure 5-24 The Auto Create Agreement Feature

Description of Figure 5-24 follows
Description of "Figure 5-24 The Auto Create Agreement Feature"

This feature creates one agreement for each document definition associated with the selected remote trading partner. You can further customize the agreement on the Agreement tab. See Chapter 6, "Creating and Deploying Trading Partner Agreements," for more information about the Agreement tab.

5.7 Using Identifiers for Trading Partner Lookup

Identifiers available in design-time data are used to look up trading partners. Identifiers do not need to be part of a deployed, active agreement. The appropriate document and exchange identifiers are used for lookup; for example:

  • For the AS2-1.1 exchange protocol, the AS2 identifier is used.

  • For the EDI X12 document protocol, the Sender Group ID and Sender Interchange ID are used.

5.8 Scheduling Trading Partner Downtime

On occasion a trading partner will need to go offline for planned maintenance. You can configure downtime so that partners are adequately notified and messages are queued for delivery when downtime ends.

See Chapter 12, "Scheduling Trading Partner Downtime" for information about scheduling and managing trading partner downtime.

5.9 Broadcasting Messages to Multiple Trading Partners

Oracle B2B provides the capability to send the same message to multiple trading partners. This gives you the flexibility to create your own groups of trading partners specific to certain business needs. The back-end application interface can then send a message to the group and Oracle B2B sends the message to all the members of the group.

The salient points of the feature are:

1. Prevents BPEL from sending multiple files, reducing the traffic on BPEL-B2B and also in B2B.

2. Introduces the concept of trading partner groups in B2B and uses it for broadcasting. This will prevent BPEL users from knowing about trading partner details as well as the group because it is B2B-specific metadata.

3. Provides an event driven approach to handle the multiple messages to various trading partners.

To use broadcasting, specify the group name as part of the actionName attribute. The actionName attribute would look like this:

actionName = Grouping:name_of_the_group

Broadcasting requires an additional identifier to be added to the Trading Partner configuration indicating the group to which the partner is assigned. This is achieved by creating a new custom Identifier and associating the same for the required trading partners. See Section 10.3, "Creating Custom Trading Partner Parameter Types" for more information.