Oracle® Fusion Middleware User's Guide for Oracle B2B 11g Release 1 (11.1.1.7) Part Number E10229-12 |
|
|
PDF · Mobi · ePub |
This chapter describes how to create identifier types, contact information types, and trading partner parameter types. It also discusses how Oracle B2B can meet individual specifications for document exchange, contact information, and trading partner parameters by using custom types.
This chapter contains the following topics:
See Section 5.2, "Creating Trading Partner Profiles," for information on adding custom types and values to a trading partner profile.
Identifier types, or identifiers, help in identifying a trading partner (as exchange identifiers) or can be used to define additional inputs for various document protocols.
Oracle B2B has preseeded many of the commonly required identifiers. A new custom identifier can be created as required.
To create an identifier type:
Click the Administration link.
Click the Types tab.
In the Identifiers area, click Add.
Provide a name and optional description, as shown in Figure 10-1.
Click Save.
See Task 3, "Add Identifier Types and Values" for how to add the new type and a value to a trading partner's profile.
Oracle B2B provides predefined identifiers for the supported document protocols, as listed in Table 10-1. You can deleted unused types to further customize your B2B environment. A type that is used by a trading partner cannot be deleted.
Table 10-1 Identifier Types Defined in Oracle B2B
Name | Description |
---|---|
The specification for using EDI over SMTP to transmit data using email. AS1 also works with non-EDI document types such as XML and TXT files. The AS1 Identifier and the Name identifier are required for AS1 exchanges. |
|
An alias for the service address (specified by the AS2-From/AS2-To fields) inside an AS2 transaction. The value can be any unique name that a trading partner recognizes. The AS2 Identifier and the Name identifier are required for AS2 exchanges. |
|
A unique, sequentially-generated, nine-digit number that is obtained from Dun and Bradstreet, formally as a D-U-N-S number. The DUNS Identifier and the Name identifier are required for RNIF exchanges. |
|
Used to identify multiple branches within a trading partner's company. The group ID can be the same as the interchange ID. |
|
Similar to EDI Interchange ID Qualifier, this qualifier applies to EDIFACT only (not X12). |
|
A unique identifier for a trading partner that can come from different sources. For example, if the trading partner has a Dun & Bradstreet number, that number can be used for the interchange ID. In most cases, the selected VAN assigns the interchange ID. |
|
Informs the network of the type of interchange ID that follows. Typical qualifiers include ZZ, indicating that the interchange ID that follows is mutually defined; 01, indicating that the interchange ID is the trading partner's Dun and Bradstreet number; 12, indicating that the interchange ID is a telephone number. |
|
Identifies the trading partner based on the EDI interchange internal ID. |
|
Identifies the trading partner based on the EDI interchange internal sub-ID. |
|
The IP address to use for identifying trading partners if you are using the generic exchange protocol (EDI X12 over Generic Exchange, EDI EDIFACT over Generic Exchange, or Custom Document over Generic Exchange) with the HTTP or HTTPS transport protocol. Do not enter the host name. The Generic Identifier and the Name identifier are required for Generic HTTP and Generic Email exchanges. Wildcard characters are not permitted in the IP address. |
|
Identifies the trading partner based on the HL7 batch application ID. BHS.3 and BHS.5 have the same definition as the corresponding field in the MSH segment. |
|
Identifies the trading partner based on the HL7 batch application universal ID. |
|
Identifies the trading partner based on the HL7 batch application universal ID type. |
|
Identifies the trading partner based on the HL7 batch facility ID. |
|
Identifies the trading partner based on the HL7 batch facility universal ID. |
|
Identifies the trading partner based on the HL7 batch facility universal ID type. |
|
Identifies the trading partner based on the HL7 file application ID. FSH.3 and FSH.5 have the same definition as the corresponding field in the MSH segment. |
|
Identifies the trading partner based on the HL7 file application universal ID. |
|
Identifies the trading partner based on the HL7 file application universal ID type. |
|
Identifies the trading partner based on the HL7 file facility ID. This field further describes the sending/receiving application. The facility ID can have an organizational entity, unit, product or vendor's identifier. |
|
Identifies the trading partner based on the HL7 file facility universal ID. |
|
Identifies the trading partner based on the HL7 file facility universal ID type. |
|
Identifies the sending/receiving application. |
|
For outbound messages, this field is used to override the Message Application Universal ID, which is MSH.3 for the sender and MSH.5 for the receiver. For inbound messages, this field is used for lookup. |
|
For outbound messages, this field is used to override the Message Application Universal ID Type, which is MSH.3 for the sender and MSH.5 for the receiver. For inbound messages, this field is used for lookup. |
|
Identifies the trading partner based on the HL7 message facility ID. |
|
For outbound messages, this field is used to override the Message Facility Universal ID, which is MSH.4 for the sender and MSH.6 for the receiver. For inbound messages, this field is used for lookup. |
|
For outbound messages, this field is used to override Message Facility Universal ID, which is MSH.4 for the sender and MSH.6 for the receiver. For inbound messages, this field is used for lookup. |
|
The TCP/IP Minimum Lower Layer Protocol (MLLP) is the standard for HL7. The MLLP ID and the Name identifier are required for MLLP exchanges. |
|
Name |
Identifies the trading partner by its name. The value for this type is automatically supplied when you create or edit the trading partner name, for example, Acme or GlobalChips. The Name identifier is required for Generic File, Generic FTP, Generic SFTP, Generic AQ, and Generic JMS exchanges. |
This type, OASIS ebXML Messaging Services (ebXML), specifies a secure and reliable way to exchange messages using HTTP, HTTPS, SOAP, XMLDsig, and XMLEncrypt. The ebMS Identifier and the Name identifier are required for ebMS exchanges. |
Oracle B2B provides a centralized location for trading partner contact information. After you create a type, you can add it to a trading partner's profile and change its value.
You can create any type of contact information. You may want to create types for contact names, email addresses, telephone and fax numbers, and so on. You can deleted unused types to further customize your B2B environment. A type that is used by a trading partner cannot be deleted.
To create a contact information type:
Click the Administration link.
Click the Types tab.
In the Contact Information area, click Add.
Provide a name for the contact information type, an optional description, and click Save.
The string that you provide in the Name field is displayed in a list under the Type field on the Partners > Profile page.
See Task 4, "Add Contact Information" for how to add the new type and a value to a trading partner's profile.
Trading partner parameter types are string types. After you create a type, you can add it to a trading partner's profile and change its value.
To create a trading partner parameter type and default value:
Click the Administration link.
Click the Types tab.
In the Trading Partner Parameters area, click Add.
Provide the following information and click Save.
Name (required)
Default Value (optional)
Group Name (optional)
Display Name (optional; however, the value of Display Name, not Name, appears when you add this type to a trading partner profile)
Description (optional)
See Task 5, "Add a Trading Partner Parameter and Value" for how to add the new type and a value to a trading partner's profile.
There are no predefined trading partner parameter types. You may want to create a type named Country
, for example. Then the value—a specific country code—can be configured for each trading partner. You can deleted unused types to further customize your B2B environment. A type that is used by a trading partner cannot be deleted.