Trading Partner Management Part 5 - Trading Partne...

piyush_chougaonkar · ‎09-16-2015

What is an agreement?

Agreement is conditional rule that can be defined in TPM. Based on a condition, the following 3 components can be selected during runtime (as shown in the figure below):

Control Key to be used for this message/partner conversion [by generic Converter Module] (refer EDI Content Manager)
EDI parameters (converter module parameters based on EDI message type) [by GenericConverterModule]
Functional Profile (custom key-value parameters) [through UDFs in Message Mapping].

Agreements can be accessed in TPM via two different options. One via a separate “Agreements” tab and other way is to access from the partner profile screen under “Agreements” tab. There is NO difference in its functioning. Only those agreements appear under partner profile’s “Agreements” tab that are related to that partner. You can also choose “Agreements” tab in case you want to search, maintain agreements in bulk irrespective of partners.

What are the parameters included in condition?

Sender Partner Name (Mandatory) Sender Partner Unique Identifier (Optional)
Receiver Partner Name (Mandatory) Receiver Partner Unique Identifier (Optional)
Direction (Inbound/Outbound)
Message Type related Parameters (examples:. UN EDIFACT ORDERS 96A or .* EDIFACT .* )

Is agreement definition mandatory in a Partner Profile? What are the benefits?
No :smile: , it is optional, refer the Use Case section below.

Use Case

You have a VAN scenario where you are sending/receiving data for multiple partners via single communication channel but you would like to use different EDI runtime parameters for each partner (eg. encoding, indent etc.)
You would like to maintain all EDI related runtime parameters for a partner centrally even if they are common so that you don’t have to change it in converter modules during every time there is a change request. You can access trading partner management and change the parameters directly in TPM configurations without redeploying the scenarios in runtime.
You would like to maintain/access custom parameters (functional profiles) based on certain agreement conditions.

Is it mandatory to define both EDI parameters and Functional Profile both in an agreement?
No :smile: , you can defined either of them or both based on your use case. You can remove the value from EDI parameter fields and leave them blank.

What is the relevance of Control Key in Agreements?

Control Key is a versioning mechanism available in EDI Content Manager through which runtime get to know the rule set version to be used for XML-EDI or EDI-XML version. SAP ships all the rules for different EDI versions in default Control Key known as “SAP” or “SAP-EANCOM”. Users can customize the standard rule set definitions by creating their own Control Key (versions)
Current way of defining relation between runtime and Control Key is through Control Key Association table and you can define the specific Control Key to be used by PI runtime scenarios. EDI converter Module during runtime checks “Control Key association table” to find the right Control key to use for that PI scenario.
New way of defining is via TPM based on the Agreements. If it is set, then converter module (if enabled for TPM) takes the value as per agreement definition and does not access Control Key scenario association table.

What are the special considerations to define EDI parameters in the agreement. How it is accessed during runtime?

You have to add TPMContentAccessModule in your configuration scenarios before the Generic converter module. You need to add it either on the sender or receiver side depending on your Inbound/Outbound EDI processing scenarios
Value for Generic converter module parameter “tpm.enable” should be true
You can define zero or more parameters depending on your usecase
Whenever you create a new agreement, default EDI values are displayed on the agreement screen

What are the options possible while defining an agreement?

While defining, agreement has two parts. One (Marked as A) is mandatory and other (Marked as B ) is optional
Both can be defined together. During PI runtime (for converter module parameters), only A will be used
While accessing functional profile from Message Mapping, you can access parameters based on either A or B

Important ℹ :Separate UDFs are available for accessing both the agreement conditions.

Use Case - Optional Agreement Option B

In case you would like to access agreement (and hence) Functional Profile on basis of standard PI Parameters in the agreement condition.

What are mandatory and optional partner parameters while defining partners in an agreement?

Partner Name is mandatory while identifiers are optional.
During Runtime, PI finds the partner name on the basis of incoming/outgoing EDI message from the "senderid+ qualifier" and receiver "id+qualifier" fields and finds the matching partner names. Then it looks for the matching agreement condition between two partners along with other condition parameters
For example, If you have different sender/receivers id's for Test and Production, there are two options:
- Create two separate agreement rows based on these different sender and/or receiver ids for Test and Production (or define in Test and change in production). OR
- Create a single agreement row and leave the identifier field blank so that same agreement/condition can be used in both Test and Production

What is the best way of defining message type in an agreement condition?

Depending on your usecase, TPM agreement condition is completely flexible. You can define the agreement with exact matching values of an incoming/outgoing EDI payload or you can make it flexibleby defining fields as *.
If you are defining strictly, then make sure the incoming/outgoing EDI document exactly matches with the EDI message definition in agreement otherwise runtime will not be able to access the correct agreement
Important ℹ :If you have a bulk interchange of different message types together, make sure you define “.* “in Message Type and Message Version field. Agreement condition can be defined on an interchange level (and not on individual message level)
If you have a bulk Interchange with same message types in it, you can define the agreement with exact message release version or .* . Both ways are accepted

Tip ➕ ! If you want to use same EDI Parameters and Functional Profile parameters for the same Partner, direction and EDI Format, it is recommended to use “.* “ in Message release and version field.

Use Case

Where you may need to defined more than one agreement for the same partner and direction but for different message types:

Either you are exchanging different EDI formats with the partner (eg. EDIFACT and X12) and for each you have to maintain a different converter module and/or functional profile parameter values.
You are exchanging a bulk interchange with the partner having different messages and for all messages except invoices ,you want to apply encoding A. However for Invoices you would like to use encoding B. You can define two agreements for the same sender partner ,receiver partner and direction combination. One with .* in message type and version and other one with Invoice specifically mentioned in Message Type and/or Release

Important ℹ : If you are defining more than one agreement, make sure your definition is aligned with the runtime behavior.

PI runtime gives priority to exact matching agreement. So, in above case, if you define an agreement with Invoice and the interchange contain only one or more invoices, then the invoice will be used. If you have invoices as part of bulk interchange with different message types, then it is important that you define agreement with .* and in this case specialization to invoice cannot be maintained.
Runtime access the agreement in the following priority (for the same partners and direction) wherever applicable Message Format -> Message Agency -> Message release -> Message Type -> Message Subversion/Association Code -> Message Version