B2B Trading Partner Management SAP PI

Agenda
TPM templates
Functional profiles
Trading partner profiles
Trading partner agreements
TPM administration settings
TPM runtime access
TPM UDFs
2014 SAP AG or an SAP affiliate company. All rights reserved. 2

How to access TPM ?
You follow the procedure below to access B2B TPM application:

1. You need to assign user roles for managing the TPM tool. Without these roles being added
to your user, you wouldn't have access to Trading Partner Management. For more
information about required TPM roles, refer assigning user roles for managing B2B
application in B2B Security Guide.
2. Enter the URL format as http:<localhost:port>/b2bic in the Web browser and logon to
B2B Integration Cockpit application.
3. To access Trading Partner Management tool, choose Trading Partner Management.
4. Important:
Before referring this guide, make sure you are on the following SP and patch level of B2B components:
B2B Add-On SP2
o B2B ToolKit SP2 Patch 12
o XI CONTENT B2B TOOLKIT 1.0 Patch 3
o XI CONTENT B2B MAPPING KIT 1.0 Patch 2
Note: It is important to install latest patch for PIB2BTOOLKIT on SP02 level to benefit from this TPM feature.

Trading partner
Management
TPM User

TPM templates
You access and create TPM template in TPM system by choosing Trading Partner Management >
Profiles > Templates
TPM template
What is a TPM template?
o TPM template consists of unique set of values that are defined by the user. It is created for specific
business requirements. Each value in the template represents referential information that are defined as
per the business transaction. You can attach a template to multiple functional profile.
TPM Template
Property Key Default Value
What type of parameters are found in a template?
o A template consists of the following parameters:

o Display Name
o Display Type
o Code List
o Property Key
o Default Value

TPM template
What are Key-pair values?

o A set of property keys and associated values that are defined in a template are known as Key-value
Pairs. Important: These keys and values are case sensitive.
What kind of templates can be created?

o Templates are custom build forms that stores generic data which can be reusable. Based of your business
requirement you can create different templates. Few examples are Material Code Mapping, EDI
separators for partners, status Indicator fields etc. and , a template can consists of the following
information:

Functional profiles
You access and create TPM template in TPM system by choosing Trading Partner Management >
Profiles > Functional Profiles
Functional profile
What is a functional profile?

o Functional profile is a collection of TPM templates that uses custom key value for that can be accessed
during message mapping
o The default key-value pairs defined in a template are applied to test and production values. You cannot
add a new key-value pair to an existing profile but you can edit any existing values in a profile. During
message mapping runtime, either the test or production value is returned based on the selected system
environment under Administration.
You can configure the system

environment in Administration
>Configuration

Choose this button
To add a template to apply templates
to a profile, choose to the profile
Define a name Add
for the functional
profile
Parameters from
the applied
templates are
displayed here

Functional profile
What is the purpose of a functional profile?

o You use functional profiles to group different templates. Functional profiles themselves can be reused
across different partners.
o Functional profile can be independent or can be attached to a trading partner agreement. During runtime
based on the conditions in an agreement, the functional profiles values can be used for messages
mapping
o You can access functional profile during runtime either by calling an agreement or by directly calling a
Functional profile Name using predefined UDFs . For more information about UDFs, refer the TPM User
Defined Functions

Functional profile
The figure below describes a runtime message mapping scenario, wherein an Idoc
XML file is mapped to an EDI XML file using a functional profile that is defined as
per an agreement.
Use Case
For example, you can build a functional profile for processing transaction
requirements such as material codes, partner specific delimiters and so on.

Trading partner profiles
You access Partner Profiles in TPM system by choosing Partners tab page.
Trading partner profile
What is purpose of trading partner profile?
o Trading partner profile provides a central access to the following partner related information and
configuration:
Identity and classification parameters such as partner name, partner type, classification details and so
on. This data also get passed to monitoring so that you can created User Defined Search Attributes
and perform a search based on these parameters.
Defining certificate rollover from NWA key store
Custom parameters such as functional profiles
Details on agreements that are defined for specific trading partners
Details of EDI run time parameters such as encoding, intending and so on that are used to configure
generic converter module
Partner Profile
Add/ Edit/ View/ Copy/ Search
Identity and EDI Message Certificates EDI Runtime Exceptional Custom Contacts and
classification Type and Ack Roll Over Parameters conditions via Parameters Documents
requirements agreements reference

General tab
The general tab page consists of information that are partner specific and the classification categories.
These details can be using during local message monitoring for searching EDI messages via UDS.
Below are the important fields and their description that needs to be configured
You should also create a Profile for your own organization. You can select Partner Type as self. This is
needed during runtime, while creating Agreements and also an essential part for monitoring.
Define the partner

details Provide
classification of the
trade
Determine the Party

Name (or attach existing
Party) from Integration
Directory

Contacts tab
This tab page you provide the details of the trading partners such as e-mail, phone, mobile and so on.
You can provide multiple contacts and provide a short description about the contact along with the
address in two separate fields.
Note: This information is NOT used during runtime

Documents tab
In this tab page you provide the references to existing documents
You can provide short description on each saved documents and edit them as per your requirement.
Though TPM does not provides you a Document Management system, the reference to documents
provides you a central screen for accessing all partner related data.

Identities tab
You provide the details such as identifier, agency code, and agency scheme for identifying business
partners.
There is a F4 help from which you can choose the standard agencies.
You can also define your own custom identifiers (for example, SupplierNo, CustomerNo and so on. )
Predefined UDFs in message mapping provides you the access to these identities (ie. you can provide
one identifier code, agency qualifier code and target qualifier code to get the right unique identifier value
for the partner.
Very Important: This is the core of TPM during runtime and monitoring . Please make sure you define
the correct values in identities. You cannot define same values for a given combination of Agency Code
and identifier for multiple partners.
Determine unique ID Define the
that has been agency Define the agency
assigned to the qualifier scheme that is
partner code implemented

Messages tab
This provides a consolidated view on messages that are getting exchanged between the trading partners
In the message format column press F4 and select the required EDI message format and select relevant
message type.
You can add the following EDI formats currently (EDIFACT, EANCOM, X12, TRADACOMS, Odette). The
values in the drop down will appear only if you imported the correct required content via EDI Content
Manager.
You can also select XML messages and manually type the Message Type and Version value. You can
use this feature to defined agreements based on XML and use the functional profile for different
conditions for XML related scenarios.
This information is not used during runtime however it is a mandatory step before defining an
agreement.

EDI acknowledgement tab
This functionality enables the processing of EDI acknowledgements, such as EDIFACT, EANCOM and
ANSI X12, for inbound and outbound EDI communications. Select and save the settings as per the
requirement that can be used during runtime.
For Inbound, settings are same as provided by EDI Separator receiver channel. You can configure it now
based on individual partners. For Outbound, values will be used by Generic Converter module during
time to set the corresponding fields in a EDI message.
How to access information during runtime?

You have to use TPMContentAccessModule as first module on the sender channel during runtime in
your Integrated Configuration scenario. This module automatically read the EDI message information for
sender and receiver identifiers, find the corresponding TPM Partners and fill the correct dynamic
headers for acknowledgment processing as defined in TPM
Enable the check box Read from dynamic headers in EDI Seperator receiver channel. If no values are
there in dynamic headers, EDI Seperator receiver channel will use the current default configuration from
the channel.

Functional profile tab
In this tab page you can add functional profiles that are specific to a trading partner.
In the functional profile column press F4 and select the relevant functional profile and save the changes.
For more information about functional profiles, refer to the Functional profile slide.
By clicking the link you can only view the functional profile. As functional profiles are reusable and can
be used across multiple partners, you cannot change it from the partner screen.
This information is not used during run time but is an essential step if you want to define agreements.

Agreements tab
You use this functionality to store partner agreements. You choose Create to create agreement and then
save the changes.
For more information about agreements, refer the Trading partner agreement slide.

Certificates tab
You can define the automatic certificate Rollovers for NWA certificates in Profiles > Certificate section.
Currently, you can only view the certificate profiles related to a specific trading partner in the Certificate
Tab of Partner Profile. You can also add, edit and store certificates in Profiles > Certificate section.
By default, the expiry time of certificate is selected as Rollover time. You can customize this time
according to your need.
You cannot add/store a new certificate form this screen. You can only access the certificate that have
already been uploaded in NWA.
After RollOver, new certificate replace the old active certificate. You can also define the backup view to
archive the replaced certificate.
Time when
Time when
Certificate the validity
the
Name of the
certificate is
certificate
extended
expires

You access partner agreements in TPM system by choosing Agreements tab page.
What is an agreement?
Agreement is conditional rule that can be defined in TPM. Based on the condition, 3 components can be
selected during runtime
1) Control Key to be used for this message/partner conversion [by generic Converter Module] (refer EDI
Content Manager documentation)
2) EDI parameters (converter module parameters based on EDI message type) [by
GenericConverterModule].
3) 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 Agreement tab. There is NO functional
difference. Only those agreements will appear under partner profiles Agreement tab that are related to
that partner. You can go to separate Agreement tab in case you want to search, maintain agreements in
bulk irrespective of partners.

What all parameters are included in condition?

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

Condition/Rules Response Returned if a
Parameter condition Matches
Used by Generic
converter Module
Used during
Message
Mapping
2 3
Note: Functional Profiles can be selected only if you have already attached to the
partner profile. If agreement is Inbound, it displays the values from Sender
Partner. If it is outbound, it displays the values from Receiver Partner

Is agreement definition mandatory in a Partner Profile? What are the benefits?

o No, it is optional. See use cases below
What are typical use cases when I would like to use this agreement?
o 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.)
o You would like to maintain all EDI related runtime parameters for a partner centrally even if they are
common so that you dont have to change it in converter modules during everytime 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.
o 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?
o No, you can defined either of them or both based on your usecase. 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 ruleset 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 ruleset 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?
o 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
o Value for Generic converter module parameter tpm.enable should be true
o You can define zero or more parameters depending on your usecase.
o Whenever you create a new agreement, default EDI values are displayed on the agreement
If the valuesscreen.
are blank,,
converter module will
replace it will the value
defined in module
context in integration
directory or will use the
default values during
runtime

What are the options possible while defining an agreement?
o While defining, agreement has two parts. One (Marked as A) is mandatory and other (Marked as B on
next slide) is optional
o Both can be defined together. During PI runtime (for converter module parameters), only A will be used
o During Functional profile Access from Message Mapping, you can access parameters based on either A
or B

Separate UDFs are available for accessing both the agreement conditions.
What is the usecase of 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?
o Partner Name is mandatory while identifiers are optional.
o 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?

o 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 flexible by defining
fields as *.
o 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.
o 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)
o 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.
o 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.

Example usecases where you may need to defined more than one agreement for the
same partner and direction but for different message types:
1) 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.
2) 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.
o 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.
o 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

TPM runtime access
TPM runtime access
During runtime, information defined in the TPM can be accessed in the following
manner:
o You need to add TPMContentAccessModule in your Integration scenarios wherever you have EDI
document processing.
Important: You must use enable.edisepUsage parameter as a precautionary step, before using TPM content access
module parameter.
o Set enable.ediAckProfile to true. This parameter when it is set to true is required for applying the TPM
settings to EDI Separator Receiver channel. The module reads parameters from TPM related to EDI
acknowledgment settings and publishes them to PI processing pipe-line. This parameter needs to be set
for the TPMContentAccessModule only in the ICO(s) where EDI Separator receiver channel is used.
o Depending on the Inbound/Outbound EDI processing, you need to add this module either on sender or
receiver side respectively
o This module should be added before generic converter module. Set the value of module parameter
tpm.enable of genericConverterModule to true. It will then fetch the a) Control Key info and b) module
parameters info as per TPM agreement.
o Enable the checkbox Read From Dynamic header in EDI Seperator receiver channel to apply the TPM
settings.
Important: In case if you are using EDISearchParametersModule, then it should be used in order such that it is before
genericConverterModule and used after TPMContentAccessModule. It is recommended to use EDISearchParametersModule
as it enables monitoring based on sender ID, receiver ID, interchange number, and correlation number.

TPM runtime access - monitoring
TPMContentAccessModule when added does the following:

1) Enable monitoring related parameters in XI message headers so that you can
create UDS in local message monitoring and enable search. (See Next Slide)
2) Enable acknowledgement related settings from TPM so that EDI Separator can
apply the settings.
3) Enable module related EDI parameters as defined in TPM agreement

TPM runtime access - monitoring
You can create the UDS and enable search on the following parameters from TPM.
Sender Partner and Receiver Partner Information is set based on the sender and receiver ids from the
Inbound/Outbound EDI message
Partner Name information is set based on the following:
1) For Inbound EDI messages, sender id is considered
2) For Outbound messages, receiver id is considered.

o PartnerName o SenderPartnerName o ReceiverPartnerName
o PartnerType o SenderPartnerType o ReceiverPartnerType
o PartnerIndustry o SenderPartnerIndustry o ReceiverPartnerIndustry
o PartnerRegion o SenderPartnerRegion o ReceiverPartnerRegion
o PartnerParentGroup o SenderPartnerParentGroup o ReceiverPartnerParentGroup
o PartnerPIParty o SenderPartnerPIParty o ReceiverPartnerPIParty
NOTE: While creating an UDS, you have to use the following Dynamic header namespace
http://sap.com/xi/XI/EDISeparator/EDISeparator
TPM administration settings
You access administration settings in TPM system by choosing Administration tab

Administration
You can enable the change log
You can export/import the TPM configuration

settings in the form of a file.
Important: Before Importing the TPM content

on a different system landscape, make sure
corresponding directory content is already
transported.
Important: According to current behavior,

when you import a TPM configuration file into
other system (eg. trasferring from Dev to QA or
QA to Production) in the landscape, all existing
data/information is replaced by the content
included in the current import file i.e. it
completely overwrites the existing data.

Appendix
Assigning user roles for managing the TPM tool
For more information about TPM roles, refer assigning user roles for managing B2B
application in B2B Security Guide.

TPM User Defined Functions (UDF)
TPM UDFs Description Arguments
Returns the Integration agency - Agency Qualifier Code
getParty directory Party name for scheme - Agency Scheme
given values partyIdentifier - Identifier Name
getPartyID Returns the Identifier value partyName- Party Name
for a given Party , agency agency Agency Name
qualifier code and agency scheme Agency Scheme
scheme
getAgreementID senderParty Sender Partner Identifier
Returns the TPM agreement senderQual Sender Partner Agency qualifier code
ID for given PI parameters. receiverParty Receiver Partner Identifier
The values should match receiverQual Receiver Partner Agency qualifier code
exactly as defined in senderService Sender Business Component
agreement receiverService Receiver Business Component
interf Interface
namespace Interface Namespace
getAgreementID Choose this UDF if you need senderID Sender Partner Identifier
to retrieve parameters such senderIDQual Sender Partner Agency Qualifier Code
as senderID, receiverID, and receiverID Receiver Partner Identifier
so on. receiverIDQual Receiver Partner Agency Qualifier Code
msg_protc Message Format
msg_type Message type
msg_ver Message version
msg_rel Message release
msg_agency Message agency
msg_subver Message subversion
direction- Message direction

TPM User Defined Functions (UDF)
TPM UDFs Description Arguments
getAgreementID Returns the TPM agreement senderProfileID Sender Partner name
ID for given Partner receiverProfileID Receiver Partner Name
Parameters. The values msg_protc Message format
should match exactly as msg_type Message type
defined in agreement msg_ver Message version
msg_subver Message subversion
msg_rel message release
msg_agency Message Agency
direction Message direction
getFunctionalProfileName Returns Functional Profile agreementID Agreement ID

name for the given agreement
ID as defined in TPM. To be
used with getAgreementID
function
getFunctionalProfileProperty Returns value of a given profileName Functional Profile name
functional Profiles key keyName key name as defined in functional profile
getSystemEnvironment Returns the current activated
system environment test or
production from TPM.
getIdentity Returns the required identity sourceID Partner Identifier
for the given partner ID and sourceQual Source partner qualifier agency code
Qualifier code targetQual Target partner qualifier agency code

Example- Accessing TPM information using UDF
1. senderID Sender Partner Identifier

2. senderIDQual Sender Partner Agency Qualifier Code
3. receiverID Receiver Partner Identifier
4. receiverIDQual Receiver Partner Agency Qualifier Code
5. msg_protc Message Format
6. msg_type Message type getAgreementID
7. msg_ver Message version
8. msg_rel Message release
9. msg_agency Message agency
10. msg_subver Message subversion
11. direction- Message direction

Thank you
2014 SAP AG or an SAP affiliate company. All rights reserved.

2014 SAP AG or an SAP affiliate company.
All rights reserved.
No part of this publication may be reproduced or transmitted in any form or for any purpose without the express permission of SAP AG or an
SAP affiliate company.
SAP and other SAP products and services mentioned herein as well as their respective logos are trademarks or registered trademarks of SAP AG
(or an SAP affiliate company) in Germany and other countries. Please see http://global12.sap.com/corporate-en/legal/copyright/index.epx for additional
trademark information and notices.
Some software products marketed by SAP AG and its distributors contain proprietary software components of other software vendors.
National product specifications may vary.
These materials are provided by SAP AG or an SAP affiliate company for informational purposes only, without representation or warranty of any kind,
and SAP AG or its affiliated companies shall not be liable for errors or omissions with respect to the materials. The only warranties for SAP AG or
SAP affiliate company products and services are those that are set forth in the express warranty statements accompanying such products and
services, if any. Nothing herein should be construed as constituting an additional warranty.
In particular, SAP AG or its affiliated companies have no obligation to pursue any course of business outlined in this document or any related
presentation, or to develop or release any functionality mentioned therein. This document, or any related presentation, and SAP AGs or its affiliated
companies strategy and possible future developments, products, and/or platform directions and functionality are all subject to change and may be
changed by SAP AG or its affiliated companies at any time for any reason without notice. The information in this document is not a commitment,
promise, or legal obligation to deliver any material, code, or functionality. All forward-looking statements are subject to various risks and uncertainties
that could cause actual results to differ materially from expectations. Readers are cautioned not to place undue reliance on these forward-looking
statements, which speak only as of their dates, and they should not be relied upon in making purchasing decisions.

B2B Trading Partner Management SAP PI

Загружено:

Сведения о документе

Авторское право

Доступные форматы

Поделиться этим документом

Поделиться или встроить документ

Параметры публикации

Этот документ был вам полезен?

Это неприемлемый материал?

Авторское право:

Доступные форматы

B2B Trading Partner Management SAP PI

Загружено:

Авторское право:

Доступные форматы

Agenda

2014 SAP AG or an SAP affiliate company. All rights reserved. 2

You follow the procedure below to access B2B TPM application:

2014 SAP AG or an SAP affiliate company. All rights reserved. 3

2014 SAP AG or an SAP affiliate company. All rights reserved. 4

What is a TPM template?

Property Key Default Value

What type of parameters are found in a template?

o A template consists of the following parameters:

2014 SAP AG or an SAP affiliate company. All rights reserved. 6

What are Key-pair values?

What kind of templates can be created?

2014 SAP AG or an SAP affiliate company. All rights reserved. 7

What is a functional profile?

You can configure the system

2014 SAP AG or an SAP affiliate company. All rights reserved. 9

2014 SAP AG or an SAP affiliate company. All rights reserved. 10

What is the purpose of a functional profile?

2014 SAP AG or an SAP affiliate company. All rights reserved. 11

2014 SAP AG or an SAP affiliate company. All rights reserved. 12

What is purpose of trading partner profile?

Add/ Edit/ View/ Copy/ Search

2014 SAP AG or an SAP affiliate company. All rights reserved. 14

Define the partner

Determine the Party

2014 SAP AG or an SAP affiliate company. All rights reserved. 15

Note: This information is NOT used during runtime

2014 SAP AG or an SAP affiliate company. All rights reserved. 16

In this tab page you provide the references to existing documents

2014 SAP AG or an SAP affiliate company. All rights reserved. 17

2014 SAP AG or an SAP affiliate company. All rights reserved. 18

2014 SAP AG or an SAP affiliate company. All rights reserved. 19

How to access information during runtime?

2014 SAP AG or an SAP affiliate company. All rights reserved. 20

2014 SAP AG or an SAP affiliate company. All rights reserved. 21

2014 SAP AG or an SAP affiliate company. All rights reserved. 22

2014 SAP AG or an SAP affiliate company. All rights reserved. 23

3) Functional Profile (custom key-value parameters) [through UDFs in Message Mapping] .

2014 SAP AG or an SAP affiliate company. All rights reserved. 25

What all parameters are included in condition?

o Receiver Partner Name (Mandatory) Receiver Partner Unique Identifier (Optional)

o Message Type related Parameters (examples:. UN EDIFACT ORDERS 96A or .* EDIFACT .* )

2014 SAP AG or an SAP affiliate company. All rights reserved. 26

2014 SAP AG or an SAP affiliate company. All rights reserved. 27

Is agreement definition mandatory in a Partner Profile? What are the benefits?

Is it mandatory to define both EDI parameters and Functional Profile both in an

2014 SAP AG or an SAP affiliate company. All rights reserved. 28

What is the relevance of Control Key in agreements?

2014 SAP AG or an SAP affiliate company. All rights reserved. 29

2014 SAP AG or an SAP affiliate company. All rights reserved. 30

2014 SAP AG or an SAP affiliate company. All rights reserved. 31

What is the usecase of Optional Agreement Option B?

2014 SAP AG or an SAP affiliate company. All rights reserved. 32

o Partner Name is mandatory while identifiers are optional.

2014 SAP AG or an SAP affiliate company. All rights reserved. 33

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

2014 SAP AG or an SAP affiliate company. All rights reserved. 34

2014 SAP AG or an SAP affiliate company. All rights reserved. 35

2014 SAP AG or an SAP affiliate company. All rights reserved. 37

TPMContentAccessModule when added does the following:

3) Enable module related EDI parameters as defined in TPM agreement

2014 SAP AG or an SAP affiliate company. All rights reserved. 38

Partner Name information is set based on the following:

1) For Inbound EDI messages, sender id is considered