Host trading partner concepts are provided. See Host Company.

• Define Identifiers in the Host Profile
• Create the Host Profile

Define Identifiers in the Host Profile

You specify the host identifier and value when configuring the host profile. Understand the following details about how the identifier is used.

• Where the identifiers are used:
  The following table lists where each type of identifier is used and its purpose.

  Identifier Type	Where Used	Purpose	Value Restrictions
  Application Partner ID	Not used.	This identifier from the host profile is not used.	Not used.
  AS2 Identifier	Under Trading Partners, then Transports & agreements, then AS2, then AS2 identifiers, and then Host identifier.	Mandatory only when the AS2 transport protocol is used. This identifier type is not used for the FTP transport protocol. For an outbound message, this value is inserted as the AS2-From HTTP header of the AS2 message. For an inbound message, this value is used for validation against the AS2-To header of the incoming message.	Up to 128 printable ASCII characters except double quotes or back slashes. This value can be any value agreed upon with the trading partner as a value with which they can identify your company. The value is case sensitive.
  EDI Interchange ID	Under Trading Partner, then Transports & agreements, then Outbound agreement, and then Select host identifiers.	Mandatory for all EDI data formats. This identifier is used as the Interchange Sender ID field of the interchange envelope (ISA segment for X12 and UNB segment for EDIFACT). For an outbound message, this value is inserted as the Interchange Sender ID. For an inbound message, this identifier (from the host profile) is not used.	Up to 15 characters for X12. Up to 35 characters for EDIFACT. The value is case sensitive and must not contain any delimiter characters.
  EDI Interchange ID Qualifier	Same as above.	Mandatory for X12 and optional for EDIFACT. This identifier is used as the Interchange Sender ID Qualifier field of the interchange envelope of the EDI payload. It's a code to indicate the category of the value specified in the EDI Interchange ID (for example, DUNS number, IATA number, and so on). For an outbound message, this value is inserted as the Interchange Sender ID Qualifier. For an inbound message, the value (from the host profile) is not used.	Must be exactly two characters for X12. The value must be from an X12 code list. See EDI Standards Reference. A generic sample value for X12 is ZZ. Up to four characters for EDIFACT. The value must be from an EDIFACT code list (https://www.gefeg.com/jswg/cl/v3/11b/cl3.htm). A generic sample value for EDIFACT is ZZZ. The value is case sensitive and must not contain any delimiter characters.
  EDI Interchange Internal ID	Same as above.	Only used for EDIFACT. In that, it is also optional. EDIFACT defines this field as an identification (for example, a division, branch, or computer system/process) specified by the sender of the interchange to be included if agreed to by the recipient in response interchanges to facilitate internal routing.	Up to 35 characters for EDIFACT. The value is case sensitive and must not contain any delimiter characters.
  EDI Interchange Internal Sub ID	Same as above.	Only used for EDIFACT syntax version 4. In that, it is also optional. EDIFACT defines this field as the sublevel of sender internal identification when further sublevel identification is required.	Up to 35 characters for EDIFACT. The value is case sensitive and must not contain any of the delimiter characters.
  EDI Group ID	Same as above.	Mandatory for X12 and optional for EDIFACT. EDIFACT defines this field as an identification of the sender's division, department, and so on from which a group of messages is sent. X12 has a similar definition. For an outbound X12 message, this value is inserted in the GS segment as the Application Sender's Code. For an outbound EDIFACT message, this value is inserted in the UNG segment as the sender identification (a UNG is only generated when this identifier is selected in an outbound agreement; otherwise not). For an inbound message, the value from the host profile is not used.	Minimum of two characters and up to 15 characters for X12. Up to 35 characters for EDIFACT. The value is case sensitive and must not contain any delimiter characters.
  EDI Group ID Qualifier	Same as above.	Only used for EDIFACT. In that, it is also optional. It's a code to indicate the category of the value specified in the EDI Group ID (for example, DUNS number, IATA number, and so on).	Up to four characters for EDIFACT. The value must be from an EDIFACT code list (https://www.gefeg.com/jswg/cl/v3/11b/cl3.htm). A generic sample value is ZZZ. The value is case sensitive and must not contain any delimiter characters.
  DUNS	Same as above.	Only used for RosettaNet.	A nine digit, numerical value.
  LocationID	Same as above.	This is a free text field and used to populate the Service Header if it is provided.	Free text field.

• Host identifiers in use are protected:

  You cannot delete host identifiers referenced in transports or agreements. The associations must be removed from the transports or agreements before you can delete the host identifier from the host profile page.

• Multiple identifiers of the same type:

  You may add multiple identifiers of the same identifier type. For example, you may want to add identifiers based on X12, X12 HIPAA, EDIFACT, or RosettaNet usage, based on business units within your company, or based on an environment such as development, test, production, and so on. The combination of identifier type and value must be unique, and this validation is enforced in the user interface.

  Even though you may define multiple identifiers of the same type, in outbound agreements, you must choose specific unique types so that B2B for Oracle Integration knows exactly which identifiers to insert in an outbound message without ambiguity.

  In the following example, two different rows, both with EDI Interchange ID, are defined.

  
  
  
  
  
• Updating values and applying changes to runtime:
  You can update existing identifier values any time. However, they are not used in runtime B2B processing until:

  • Each transport where an identifier value was referenced is redeployed.
  • Each outbound agreement where an identifier value was referenced is redeployed.

  Redeployment is a life cycle action available for transports and agreements. It applies changes to the runtime on-the-fly, without disruption of message processing.

Create the Host Profile

1. In the navigation pane, click B2B, then Host profile.
2. Click Create.
3. In the Host company name field, enter your company name. The name is currently only for reference and not used elsewhere.
4. Select a host identifier or, if none are defined, click Add . You add identifiers to the host profile on behalf of your company. This is typically a one-time activity that you perform before adding your first trading partner.
   Host identifiers define your company when acting as the host interacting with other trading partners. They identify and validate the source of the document when sent by the host. Identifiers defined here are used in two places:

   • Transports
   • Outbound agreements
5. Select a host identifier name and specify a value. You can specify multiple name and value pairs for the host.
6. Click Save.

   If you change the host identifier value used in a deployed agreement, the changes only take effect after you explicitly redeploy the agreement between the host and the trading partner.

7. If you want to delete any unneeded host identifiers, click Delete . You cannot delete host identifiers referenced by active agreements. The associations must be removed from the agreements before you can delete the host identifier from the host profile page.