Configuring Trading Partners

5 Configuring Trading Partners

This chapter describes how to configure trading partners by 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.

Configuring trading partners is the third step in the Oracle B2B process flow.

This chapter includes the following sections:

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-1 shows the steps to configure a trading partner.

Figure 5-1 Configuring Trading Partners

Description of "Figure 5-1 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:

5.2.1 Update the Default Host Trading Partner Name

Do this the first time you set up Oracle B2B.

Click the Partners link.
Click MyCompany.
Click Edit.
Provide the host trading partner name and optional button file, and click OK.

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

The host trading partner name appears in the Partner list.

5.2.2 Add a Remote Trading Partner

Do this for each remote trading partner.

Click the Partners link.
Click Add.
Provide a partner name and click OK.

The remote trading partner name appears in the Partner list.
(Optional) Click Edit to add a 16 x16-pixel PNG file as an button for the remote trading partner, as shown in Figure 5-2, and click OK.

Figure 5-2 Editing a Remote Trading Partner Profile

Description of "Figure 5-2 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 button, as shown in Figure 5-3, and provide the trading partner information that is not cloned: identifiers, contacts, and users.

Figure 5-3 Cloning a Remote Trading Partner

Description of "Figure 5-3 Cloning a Remote Trading Partner"

Note:

Use the Delete button 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.

5.2.3 Add Identifier Types and Values

Identifier types enable Oracle B2B to identify a trading partner at runtime. 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.

To add identifier types and values for both the host and remote trading partners:

Click the Partners link.
Click the Profile tab.
Select a trading partner.
In the Identifiers area, click Add, as shown in Figure 5-4.

Figure 5-4 Adding Identifier Types

Description of "Figure 5-4 Adding Identifier Types"
From the Type list, select an identifier type. For information about how to create the types shown here, see Creating Types.

See Table 10-1 (Identifier Types Defined in Oracle B2B) for descriptions of the identifier types.
Provide a value.
Repeat Steps 4 through 6 as needed.
Click Save.

5.2.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. For more information, see Creating Custom Contact Information Types.

Click the Partners link.
Click the Profile tab.
In the Contact Information area, click Add.
Select from the list under Type and enter a value, as shown in Figure 5-5.

Figure 5-5 Adding Contact Information

Description of "Figure 5-5 Adding Contact Information"
Click Save.

5.2.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 button does not appear.) For more information, see Creating Types.

Click the Partners link.
Click the Profile tab.
In the Parameters area, click Add.
Select a parameter and click OK.
Click Save.

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

5.2.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 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.

Click the Partners link.
Click the Profile tab.
Select the host trading partner.
In the Key Store section, provide a password and location, as shown in Figure 5-6.

Figure 5-6 Entering Key Store Information

Description of "Figure 5-6 Entering Key Store Information"
Click Save.

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. For more information, see Restricting Access to Document Types.

Note:

A B2B user with the Administrator role must have membership in the WebLogic Administrators group to get the privileges such as seeing all trading partners. In addition, a B2B user with the Monitor role must be a member of the WebLogic Monitors group.

To add users, complete the following tasks:

5.3.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-7.

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

Description of "Figure 5-7 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-8.

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

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

5.3.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.

Click the Partners link.
Click the Users tab.
Select a trading partner.
Click Add.
Provide the user name created in Create a New User in the Identity Store and click Search.

Enter the user name exactly is it was created.
Select the Monitor or Administrator role, shown in Figure 5-9, and click OK.

Figure 5-9 Assigning the Monitor or Administrator Role

Description of "Figure 5-9 Assigning the Monitor or Administrator Role"

5.3.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.

In the Supported Document Types area on the Users tab click Add.
Select a document type and click Add, as shown in Figure 5-10.

Figure 5-10 Selecting a Document Type

Description of "Figure 5-10 Selecting a Document Type"
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 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 Creating Document Definitions.

To add document definitions, do the following:

Add Document Definitions

5.4.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. For more information, see Using Document Protocols.

Click the Partners link.
Click the Documents tab.
Select a trading partner.
Click Add.
Expand the nodes, select a document definition as shown in Figure 5-11, and click Add.

Figure 5-11 Selecting a Document Definition

Description of "Figure 5-11 Selecting a Document Definition"
For each document listed, identify if the selected partner is the sender or receiver or both, as shown in Figure 5-12.

Figure 5-12 Selecting the Sender and Receiver

Description of "Figure 5-12 Selecting the Sender and Receiver"
Click Save.

See 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 is a typical configuration for a VAN connection; the channel for the VAN can be configured once in the Host Trading Partner, but then used by many different remote Trading Partners that all use the same VAN. This avoids having to create a delivery channel multiple times, 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. For more information, see:

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

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

Protocol	Description	Communication Channel
AS4-1.0	AS4-1.0 Applicability Statement 4-specificaiton for using XML over WS-HTTP.	External
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.	External
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. For more information, see About MLLP.	External
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.	External
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.	External
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.	External
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.	External
Generic File-1.0	Transport by which messages are sent to or received from a file in a local file system.	Internal/External
Generic AQ-1.0	Transport by which messages are sent to or received from Oracle AQ single or multbuttonsumer queues.	Internal/External
Generic FTP-1.0	Transport by which messages are sent to or received from a file at a remote FTP server.	Internal/External
Generic SFTP-1.0	Transport by which messages are sent to or received from a file at a remote SFTP server.	External
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`.	Internal/External
Generic HTTP-1.0	Transport by which messages are sent to or received from a Web server.	External
Generic Email-1.0	Transport by which messages are sent to or received from an email server.	External
Generic TCP	Transport that supports customized Exchange Protocol parameters such as Start Block, End Block, Header Length, Message Length Index, and Retain Header.	External
Generic MFT-1.0	Transport by which messages are sent to or received from a file at a remote MFT server.	External

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-13.

Figure 5-13 Channel Details Tabs

Description of "Figure 5-13 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:

Note:

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

5.5.1 Add a Channel

Add a channel for the responder in a B2B transaction.

Click the Partners link.
Select a trading partner.
Click the Channels tab.
Click Add.
Enter a channel name.
Select a protocol, as described in Table 5-1.

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...
AS4-1.0	WS-HTTP
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
Generic MFT-1.0	MFT

5.5.2 Provide Transport Protocol Parameters

Click the Transport Protocol Parameters tab.

Provide transport protocol parameters, as described in Table 5-3, depending on the channel/transport protocols selected in Add a Channel.

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) Generic TCP (required)
Consumer	The client that receives the message.	Generic AQ (optional)
Content type	The content type of the payload being sent over email. 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 email) 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	FTP runs on default port 21, which is not displayed. 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. Per the FTP protocol requirement, ensure that the port is higher than 1023.	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 email 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)
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 format	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. Note: In File/FTP channels, if the `filename format` is set then the `directory name format` is ignored.	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)
FIPS Mode	FIPS mode can be enabled for the channel by selecting this check box. Once selected the SFTP connection to remote server will be established in FIPS mode. When this option is not selected and the user is trying to connect to a remote SFTP server which is running in the FIPS mode, a connection error results. When this option is selected, and the user is trying to connect to a server running in non-FIPS mode, the connection succeeds or fails based on whether the remote server supports the FIPS algorithm.	Generic SFTP
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 email 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) Generic TCP (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) Generic MFT-1.0 (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) Generic TCP (optional)
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) Generic TCP (optional)
Port number (or Port)	AQ runs on default port 1521. SFTP runs on default port 22, which can be changed to another port. 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) Generic TCP (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 email 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 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) Generic TCP (optional)
SID	System ID to identify an Oracle database	Generic AQ (optional)
Source	The Oracle B2B source name that is created in MFT and added to any transfer with any target. A source specifies from where a file is transferred.	Generic MFT-1.0 (required)
Subject	The subject header of the email message	AS1 (optional) Generic Email (optional)
Subscriber ID	The JMS subscriber ID is required if JMS is communicating with a topic.	Generic JMS
Target	A target specifies to where a file is transferred.	Generic MFT-1.0 (optional)
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) Generic TCP (optional)
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	A transfer associates a single source with one or more targets, specifying from where and to where a file is transferred.	Generic MFT-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, for all channels except MFT. For an MFT server, enter a T3 URL with the format `t3://<mft_server_host>:<port>`.	AS2 (required) ebMS-2.0 (required) ebMS-1.0 (required) Generic HTTP (required) RosettaNet-V02.00 (required) RosettaNet-01.10 (required) Generic MFT-1.0 (optional)
Flow Trace EM URL	EM URL of the domain for tracking the instance message flow. The following syntax should be used when providing the Flow Trace EM URL.`:##">http://<host>:<port>#<domain_name>#<domain_type>`	Generic JMS (optional)
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) Generic MFT-1.0 (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)

Click Save.

5.5.3 Provide Channel Attributes

Click the Channel Attributes tab.

Provide channel attributes, as described in Table 5-4, depending on the channel/transport protocols selected in Add a Channel.

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) Generic TCP (optional) Generic MFT-1.0 (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) Generic TCP (required)
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) Generic MFT-1.0 (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 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) Generic TCP (optional) Generic MFT-1.0 (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 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) Generic TCP (optional) Generic MFT-1.0 (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) Generic TCP (optional) Generic MFT-1.0 (optional)

Click Save.

5.5.4 Provide Exchange Protocol Parameters

Click the Exchange Protocol Parameters tab.

Provide exchange protocol parameters, as described in Table 5-5, depending on the channel/transport protocols selected in Add a Channel.

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	The value for this property can be a string. 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.	Generic TCP (optional)
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).	Generic TCP (optional)
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 Order Semantics	A placeholder for CPP/CPA; not involved during runtime.	ebMS-2.0 (optional)
Message Length Index	This property indicates the data size available in the header. Start index to end index defines the message size.	Generic TCP (optional)
Persist Duration	A placeholder for CPP/CPA; not involved during runtime.	ebMS-2.0 (optional)
Persist HL7 ACK	Indicates if the ACK payload is persisted or not. This is applicable only in the case of Immediate acknowledgments or Discard acknowledgment cases.	MLLP 1.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. It is recommended that you set this parameter when using the ASync mode for the AS2 transport protocol.	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 handle the custom header. This is handled using the transport callout.	Generic TCP (optional)
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 value can be a string.	Generic TCP (optional)
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)

Click Save.

5.5.5 Configure Security

Click the Security tab.

Provide security parameters, as described in Table 5-6, depending on the channel/transport protocols selected in Add a Channel.

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 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 SHA256 - RSA If Message Signed is selected, then select one of the following for ebMS-2.0 and ebMS-1.0: SMIME 3.0 with SHA1 - RSA SMIME 3.0 with SHA256 - RSA 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 SMIME with AES-128 SMIME with AES-192 SMIME with AES-256 Note: For AES-192 and AES-256 support, you must download and apply Java Cryptography Extension (JCE) Unlimited Strength from http://www.oracle.com/technetwork/java/javase/downloads/jce8-download-2133166.html. Update the JDK/JRE as indicated in the README file and restart the managed servers. 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)

Click Save.

Note:

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

5.5.6 Binary Transfer

Sometimes, you may want to transfer binary content instead of regular XML/Text files. Based on the business needs, binary files, such as PDF, XLS, ZIP, and GIF can also be transferred by using Oracle B2B.

Transfer of binary content can be inbound or outbound.

5.5.6.1 Outbound Transfer

Outbound binary file transfer in Oracle B2B is used on custom documents over the Generic/AS2 exchange protocols. The File, FTP, SFTP, or JMS internal listening channels can be used for binary file transfer. In case of File, FTP, or SFTP channels, the filename format or the directory name format should contain the document type and document version along with From Party and To Party information.

In case of JMS internal listening channels, the event name should contain the BINARYPAYLOAD property as true:

eventName=BINARYPAYLOAD:true

after you set the preceding property, you need to specify the binary payload (in the form of bytes message) in the JMS Message body:

message.setBody(binarypayload);

Based on the configured From, To, documents type, and revision, Oracle B2B identifies the agreement and sends it to the trading partner.

Note:

Document validation needs to be turned off at the agreement level for outbound binary transfer.

5.5.6.2 Inbound Transfer

Inbound binary file transfer in Oracle B2B is used on custom documents over the Generic/AS2 exchange protocols. Incase of File, FTP, or SFTP trading partner listening channels, you need to configure the filename format with From, To, document type and document revision information. Based on the filename format, Oracle B2B identifies the agreement and sends it to the back-end application.

In case of Generic HTTP/AS2, based on the additional HTTP headers, such as DOCTYPE_NAME and DOCTYPE_REVISION, Oracle B2B identifies the agreement and sends it to the back-end application.

The following is a sample of inbound listening channel filename format:

%FROM_PARTY%_%DOCTYPE_NAME%_%DOCTYPE_REVISION%_%TIMESTAMP%.dat

The following is a sample filename based on the preceding format:

GlobalChips_ORDERS_1.0.123333333.dat

Note:

Oracle B2B supports filenames with any naming formats, such as 123.dat for Generic Exchange when using File, FTP, or SFTP transport.Oracle B2B processes such files (which do not have their file names based on formats such as %FROM_PARTY%_%TO_PARTY%_%DOCTYPE%_%DOC_REVISION%) successfully for outbound and inbound direction by implementing callouts.

5.5.7 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, after 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 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.7.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.7.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-14): Start Block, End Block, Header Length, Message Length Index, and Retain Header.

Figure 5-14 Parameters for Generic TCP

Description of "Figure 5-14 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-14. After creating the channel, two subtabs appear, with MLLP-specific and generic TCP-specific parameters grouped under them.

See Table 5-5 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.7.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

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.7.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 for details.

5.5.8 Multiple Channel Support for ebMS

For ebMS, Oracle B2B provides multiple channels for Actions, Services, and Service Types. From the multiple channels, Oracle B2B identifies the relevant outbound channel that is associated with a specific Action, Service, and Service Type and uses the channel to communicate with a trading partner.

This feature allows you to override the following parameters of an ebMS channel:

URL
Retry Count
Retry Interval
Duplicate Elimination
Ack Signed
Ack Required

Depending on the Action, Service, and Service Type along with the optional From Role and To Role parameters, the corresponding delivery channel is used for trading partner communication and its associated acknowledgment.

5.5.9 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).

Note:

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 acknowledgment (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.9.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.

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-15.

Figure 5-15 Dispatcher Configuration: Administration > Configuration Tab

Description of "Figure 5-15 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.

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

ACTION_NAME = TARGET:sequence_target_name

5.5.9.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-16.

Figure 5-16 Sequencer Configuration

Description of "Figure 5-16 Sequencer Configuration"

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

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.9.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. after 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-15. 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.9.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:

Inbound case: resubmit the wire message.
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.10 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.

[need sample location in install footprint]

To configure sync response:

Set up the inbound and outbound agreement.
Create callout with the capability to send inbound requests and receive its business response from back end applications.

See Example 13-3 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.
Attach the callout to the Inbound Agreement.
All the sync requests should be send to the following URL
```
http://host:port_number/b2b/syncreceiver
```
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.11 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.12 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 acknowledgment or functional acknowledgment on time.

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

5.5.12.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 acknowledgment case (for example MDN in AS2 and acknowledgment 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.12.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 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

This feature creates one agreement for each document definition associated with the selected remote trading partner.

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

Figure 5-17 The Auto Create Agreement Feature

Description of "Figure 5-17 The Auto Create Agreement Feature"

You can further customize the agreement on the Agreement tab. See 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 the chapter 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 Creating Custom Trading Partner Parameter Types for more information.

5.10 Validating Certificate in Inbound Message Processing

This feature performs Certificate validation for the inbound signed message processing.

The following configuration is required to validate the certificates in inbound message processing.

Add a new identifier with the name CertificateAlias.
Set the required alias in the trading partner profile with the name as CertificateAlias.
Enable this feature by setting the b2b.validateMessageCertificate property in Enterprise Manager console to true. By enabling this property, all the messages will be validated against the certificate.