Document type

Design documentation

Title
SAP PI / AIF Development Guideline Design

Work package
FC-Application – IT3 – Development & Interfaces

Version
V3.00

Document status
Released

Status
January 19th, 2011

Common Basic
FC-System
 Common Basic FC-System
Integration Architecture Design

481325269.doc 24.06.2020 Page 1 of 50

 Common Basic FC-System
Integration Architecture Design

Integration Architecture Design documentation

Work package Global FC Application
Responsible Jens Richter
Name of document FCA_3_GU_PI_AIF_Development_Guideline_V1.00.doc
Current released version V3.00
Last released version approved by Boris Basica

Document History
Date Version Changed Changed by Comment
chapter
26.03.2008 V0.01 Falk Winthuis Initial Creation
02.09.2008 V0.02 Jens Richter Include open points: Chapter 1
11.09.2008 V0.03 Dr. Robert Sowa Include Chapters about Mapping
and Integration Processes an
other design topics, Enhance
Chapter about Interface
Configuration
16.09.2008 V0.04 Jens Richter Adapt cbFC specific Guidance to
chapter 3
22.09.2008 V0.05 Sebastian Moch AIF Update & Review
23.09.2008 V0.06 Dr. Robert Sowa Include Chapter about Modelling
Capabilities in PI7.1
25.09.2008 V0.07 Dr. Robert Sowa Include Chapter about example
Model for CBFC Controlling
Scenario, Include chapter about
Versioning Capabilities in PI7.1
26.09.2008 V1.00 Jens Richter Released Version
29.09.2008 V1.00 Boris Basica Release
14.10.2008 V1.01 Jens Richter Outbound Concept
18.04.2008 V1.02 3.1, 3.26, 3.3 Jens Richter Update Modeling Guidelines;
Update Outbound Concept;
Add Chapter 3.3:cbFC related
Interface Configuration Guidelines
23.04.2009 V2.00 Jens Richter Released Version
23.04.2009 V2.00 Boris Basica Release
18.01.2011 V2.01 1.2.2.6; Markus Update AIF implementation steps
1.2.2.8; Schmidthuysen
19.01.2011 V3.00 Boris Basica Release

481325269.doc 24.06.2020 Page 2 of 50

 Common Basic FC-System
Integration Architecture Design

Table of contents
1 Application Interface Framework.................................................................................................... 5
1.1 Overview............................................................................................................................... 5
1.2 cbFC AIF Interface Design Guidelines..................................................................................6
1.2.1 General Rules................................................................................................................... 6
1.2.2 AIF implementation steps.................................................................................................. 6
1.2.3 Reusable AIF Objects....................................................................................................... 9
1.2.4 Working in parallel in AIF.................................................................................................. 9
1.2.5 Implementation of local and global parts within AIF..........................................................9
2 General PI Interface Design Guidelines.......................................................................................11
2.1 General PI design rules....................................................................................................... 11
2.2 Process Component Architecture Models in Enterprise Service Repository (ESR).............11
2.2.1 Available Model Types.................................................................................................... 11
2.3 Process Integration Scenarios in Enterprise Service Repository (ESR)..............................14
2.3.1 PI Integration Scenarios including actions......................................................................14
2.4 Typical Pattern to model Services in Enterprise Service Repository...................................14
2.5 PI Interface Objects............................................................................................................. 15
2.5.1 Data Types...................................................................................................................... 15
2.5.2 Data Type enhancements............................................................................................... 15
2.5.3 External Definitions......................................................................................................... 16
2.5.4 Context Objects............................................................................................................... 16
2.5.5 Message Type and Fault Message Type........................................................................16
2.5.6 Service Interface............................................................................................................. 16
2.6 PI Mapping Guidelines........................................................................................................ 17
2.6.1 Graphical mapping / General rules..................................................................................17
2.6.2 Java mapping.................................................................................................................. 18
2.6.3 XSLT mapping................................................................................................................ 18
2.6.4 ABAP mapping / ABAP XSLT mapping...........................................................................18
2.6.5 Mapping Templates......................................................................................................... 19
2.6.6 Mapping at Runtime........................................................................................................ 19
2.6.7 Imported Archive Object.................................................................................................. 19
2.6.8 Comparison of mapping type.......................................................................................... 19
2.6.9 Specific Mapping Scenarios............................................................................................ 21
2.6.10 Interface Mappings..................................................................................................... 23
2.6.11 Imported Archives....................................................................................................... 23
2.7 PI Integration Process Guidelines.......................................................................................23
2.7.1 Process Patterns............................................................................................................. 24
2.7.2 Using Correlation............................................................................................................ 24
2.7.3 Exception handling and Alerting......................................................................................24
2.8 PI Versioning Capabilities.................................................................................................... 24
2.8.1 Example Usage of PI Versioning.....................................................................................25
2.9 PI Interface Configuration Guidelines..................................................................................25
2.9.1 Configuration Scenario.................................................................................................... 27
2.9.2 Receiver Determination................................................................................................... 27
2.9.3 Interface Determination................................................................................................... 28
2.9.4 Routing Conditions.......................................................................................................... 28
2.9.5 Collaboration Agreements............................................................................................... 28
2.10 PI Technical Connection Guidelines....................................................................................28
2.10.1 ERP Connection......................................................................................................... 28
2.10.2 Configuration of Communication Channels.................................................................28
2.11 Code Documentation........................................................................................................... 31
2.11.1 Object Documentation................................................................................................ 31
2.11.2 Program Documentation............................................................................................. 31
2.11.3 Tracking of Changes................................................................................................... 32
3 cbFC related PI Interface Guidelines........................................................................................... 33
3.1 cbFC related Modeling in Enterprise Service Repository (ESR)..........................................33
3.1.1 Process Integration Scenario Example for Controlling....................................................34

481325269.doc 24.06.2020 Page 3 of 50

 Common Basic FC-System
Integration Architecture Design

3.2 cbFC related PI Development Units....................................................................................34

3.2.1 cbFC global Interface Repository....................................................................................36
3.2.2 Local direct Connection................................................................................................... 38
3.2.3 Local connection with structure Mapping........................................................................38
3.2.4 Local cbFC Interfaces..................................................................................................... 40
3.2.5 Global Systems............................................................................................................... 40
3.2.6 Outbound Interface with value Mapping..........................................................................41
3.3 cbFC related Interface Configuration Guidelines.................................................................45
3.3.1 cbFC PI Landscape (SLD).............................................................................................. 45
3.4 cbFC related Technical Connection Guidelines...................................................................47
3.4.1 ERP Connection.............................................................................................................. 47
3.4.2 Local system technical Connection.................................................................................47
4 Miscellaneous.............................................................................................................................. 48
4.1 Glossary.............................................................................................................................. 48

481325269.doc 24.06.2020 Page 4 of 50

 Common Basic FC-System
Integration Architecture Design

1 Application Interface Framework

1.1 Overview
Due to requirements and concepts related to the Integration Architecture of cbFC the Application
Interface Framework (AIF) will be used together with SAP PI. The AIF is based on the proxy interface
technology. It is integrated into the cbFC SAP ERP 6.0 (cbFC) system and provides the following
capabilities:

• Interface process definition is stored in customizing tables and thus transportable

 Mappings
 Value Mappings
 Checks
 Actions
 etc.
• Encapsulated development
 Interface independent development and test of single actions
 Interface specific function modules can be developed independent from the process
context
• Generic error handling transaction
 Customizable for each interface
 Restart capability of messages
 Mass changes / restart

The following figure provides a quick overview on activities which have to be executed during interface
implementation using SAP PI and the AIF. Green balloons indicate actions to be done in SAP PI,
whereas orange balloons indicate actions to be performed in the cbFC SAP ERP 6.0 (cbFC) system
and AIF.

Figure 1: Overview on activities for configuring an interface using SAP PI / AIF (inbound)

The AIF can be used for inbound (from SAP PI to cbFC) or outbound (from cbFC to SAP PI)
interfaces. The process of developing an inbound or outbound interface is very similar and will be
described later on.

481325269.doc 24.06.2020 Page 5 of 50

 Common Basic FC-System
Integration Architecture Design

1.2 cbFC AIF Interface Design Guidelines

This section provides a structured overview on steps and considerations for implementing interfaces
with the AIF within the scope of the cbFC system.

1.2.1 General Rules

• Before implementing any interface consider the naming conventions to be met within the
scope of the AIF as described in the current version of DMS Doc # 1188 (PI Naming
Conventions)
• By dividing the implementation in structured units of functionality a higher level of reusability
can be reached. This reduces implementation effort as existing implementation can be reused
multiple times. Most common reusable objects are value mappings, checks and actions.

1.2.2 AIF implementation steps

Before starting with the interface implementation in the cbFC system using the AIF the following steps
have to be completed in SAP PI:

1. Creation of data types

2. Creation of message type
3. Creation of service interface

After completion of the SAP PI configuration the following main steps can be performed in the AIF.
The steps should be performed in the suggested sequence.

1. Define Package (SE80)

2. Generate ABAP Proxy (SPROXY)
3. Implement ABAP Proxy with AIF call (SPROXY / SE24; inbound only)
4. Find / implement BAPI / function module (SE37; inbound only)
5. Create SAP target structure (SE11)
6. Define interface in AIF (/AIF/CUST_IF)
7. Define error handling for AIF interface (/AIF/CUST_IF) (to be updated later)

1.2.2.1 Define Package

A package is created per interface or interface cluster in transaction SE80. It is very important to set
“Software Component” to HOME.

1.2.2.2 Generate ABAP Proxy

The ABAP proxy is generated via transaction SPROXY. Proxies are generated based on the
corresponding service interface which has been created on SAP PI. In case data types or message
types are in a different namespace than the service interface, they need to be generated first.
The proxy prefix is /DCR/CBFC_ for objects in the global repository and /DCR/<pppp>_ for plant
specific objects. <pppp> has to be replaced with the Daimler plant number (not SAP plant).

1.2.2.3 Implement ABAP Proxy

In order to link the AIF to the proxy the AIF call has to be implemented in the proxy class. This can be
done via transaction SPROXY or SE24. For inbound interfaces the standard code has been created in
an include which should be put into the proxy class. The name of the include is
/DCR/CBFC_IF_AIF_PROXY_INBOUND.

1.2.2.4 Find / Implement BAPI / function module

AIF development is driven by the BAPI(s) or function module(s) that should be executed for the
specific interface. Therefore the BAPI(s) need(s) to be identified and/or the function module(s) need(s)
to be implemented (transaction SE37). This is necessary in order to create the SAP target structure in
the next step.

481325269.doc 24.06.2020 Page 6 of 50

 Common Basic FC-System
Integration Architecture Design

1.2.2.5 Create SAP target structure

The SAP target structure is created based on the BAPI(s) / function module(s) identified in the
previous step. The SAP target structure has to contain all components from all BAPI(s) and/or function
module(s) required for the specific interface. Furthermore it has to support multiple business
documents (e.g. multiple sales orders). Find an example below.

The table type SALESORDERS satisfies the requirement to support multiple business documents, in
this case multiple sales orders. The other structures and table types are derived from the BAPI that is
used to post the sales orders in the cbFC system (BAPI_SALESORDER_CREATEFROMDAT2).

1.2.2.6 Define interface in AIF

The AIF customizing is started via transaction /AIF/CUST_IF.
The first steps are to define the AIF namespace and AIF interface. An AIF namespace is created per
interface or per interface cluster if applicable. The namespace contains the name of the namespace
and a description. The AIF interface describes one specific interface and is linked to a proxy.
All interfaces of the same cluster are linked to the same proxy. Furthermore it has a SAP target
structure assigned. Later on the mapping between the proxy structure (source) and the SAP target
structure will be defined. Mandatory fields in the AIF interface definition are marked in the example
below.

After the definition of the AIF namespace and AIF interface the required AIF action(s) can be defined.
An action can consist of multiple functions. A function is linked to one BAPI / function module.

481325269.doc 24.06.2020 Page 7 of 50

 Common Basic FC-System
Integration Architecture Design

Functions should be grouped into an action if they belong closely together from a business or technical
perspective. If an interface uses multiple actions they are based on the same SAP target structure,
since only one SAP target structure per interface can be assigned. Depending on the business
requirements the correct commit mode and commit level for each action has to be set.

In order to be able to map the fields from the proxy structure to the SAP target structure, the mapping
of the structures needs to be defined (hierarchical mapping). This is done by selecting a source
structure and assigning it to a destination structure. This step also ensures that the cardinalities on
each hierarchy level are reflected correctly. A structure mapping is required for each table type in the
proxy structure. Table types can only be mapped against table types. See example below:

Source Hierarchy Target Hierarchy

Structure Mapping
Source Target Indirect Mapping
SALES_ORDER  SALESORDERS
ITEMS  ORDER_ITEMS_IN X
ITEMS  ORDER_SCHEDULES_IN X
ITEMS  BAPE_VBAP X
PARTNERS  ORDER_PARTNERS X
CONDITIONS  ORDER_CONDITIONS_IN X
SERIAL_NUMBER  ORDER_TEXT X
TEXTS  ORDER_TEXT X

AIF field mappings define how individual fields are mapped on the different hierarchy levels (e.g.
header or item level). Field mappings can be done by assigning fix values, value mappings or fields
from the proxy structure. Furthermore it is possible to use fields from different hierarchy levels. The
necessary syntax will be added via the F4 Help.

AIF value mappings can be defined in different ways.

 AIF internal value mapping (single or multi value – in customizing or application tables)
 Dynamic select statement
 Value mapping function module (Template: /AIF/FILE_TEMPL_VALMAPPING)
 Default value
The execution order is as listed above.

AIF checks can be defined in different ways.

 Checks on proxy or target structure
 Simple field checks (e.g. empty, numeric, contains pattern, etc.)
 Dynamic select statement (e.g. check for existence or comparison with a constant value)
 Check function module (Template: /AIF/FILE_TEMPL_CHECK)

481325269.doc 24.06.2020 Page 8 of 50

 Common Basic FC-System
Integration Architecture Design

Note: Checks are not performed on field level, but on structure level. For checks on field level
conditional mapping should be used.

AIF fix values have a unique name per namespace, a description and the value itself.

AIF conditional mappings allow configuring an alternative to the standard AIF field mapping.
Therefore a check needs to be defined. The check can be an assigned check (see AIF checks) or a
simple field check (e.g. empty, numeric, etc.). In case the check is successful, the alternative field
mapping will be executed. There are three kind of alternative field mappings
 Empty value (target field will not be mapped)
 Ignore value mapping use alternative field mapping
 Use alternative value mapping and alternative field mapping

!!! In case the AIF mapping will be changed upon the first execution of the interface, the report
/AIF/DELETE_STRUCTURE_CACHE needs to be executed in order to delete the AIF structure cache
which contains all the customized AIF mappings. The cache will be built up again when the interface is
executed the next time. !!!

1.2.2.7 Define Error Handling for AIF Interface

This chapter will be delivered at a later point in time.

1.2.2.8 Implementation of function modules in AIF

When implementing function modules that are customized in AIF the following guidelines apply. These
guidelines also apply to any ABAP code that can be executed from a function module that is
customized in AIF (e.g. external PERFORM, INCLUDES, other function modules or methods).
 Always copy the function module that is customized in AIF from the corresponding template
function module defined in function group /AIF/AIF_TEMPLATES
 Do not use “COMMIT WORK (AND WAIT)” or “ROLLBACK WORK”. This is handled by the
AIF as described in chapter 1.2.2.6.
 Do not issue messages via the statement “MESSAGE”. Instead use function module
/AIF/UTIL_ADD_MSG to add the message to the message table (usually called “return_tab”)
 Use additionally statement MESSAGE … INTO var. (var needs to be a char-type data object)
in order to have the where-used functionality available for all the used messages.
 Choose message type “A” instead of “E” for technical errors that cannot be corrected by the
end user. “A” identifies technical errors, whereas “E” identifies application / process errors

1.2.3 Reusable AIF Objects

Reusable objects in AIF are defined in the namespace “CBFC” (e.g. value mappings or checks).
During implementation objects can be “upgraded” to reusable objects if it turns out that many
interfaces need the same object. Reusable objects are maintained from the central team only.
Nevertheless roll-out projects may request objects to be added to the reusable namespace “CBFC”.

1.2.4 Working in parallel in AIF

The AIF customizing is based on view clusters. Therefore some restrictions regarding the parallel
maintenance apply.
 Structure Mappings can be accessed in change mode by one user per namespace, AIF
Interface and AIF interface version
 Actions, Checks, Fix Values, Value Mappings and AIF Interfaces can be accessed in change
mode by one user per namespace
 The interface determination can be access in change mode by one user only
Generally all view clusters are accessed by default in change mode. Therefore it is advisable to
change to display mode if no changes need to be done.

1.2.5 Implementation of local and global parts within AIF

This section gives an overview on the To-Be functionality which the AIF Tool will be enhanced with
due to cbFC project requirements. Due to the To-Be status this chapter can be revised and
functionality may change.

481325269.doc 24.06.2020 Page 9 of 50

 Common Basic FC-System
Integration Architecture Design

All interfaces specified by the specific application teams have been clustered for reusability and
consolidation. Each interface cluster refers to a message interface and results in an ABAP Proxy. The
interfaces which are part of a cluster are mapped into AIF interfaces (cf. previous section). The
message contains a generic header (MessageProcessingInformation) which contains technical fields
for the AIF Interface Determination.
The details on global and local parts within AIF will be delivered at a later point in time.

481325269.doc 24.06.2020 Page 10 of 50

 Common Basic FC-System
Integration Architecture Design

2 General PI Interface Design Guidelines

2.1 General PI design rules
The development objects are to be created in the correct Software Component Version (SWCV).
PI content of standard SWCVs (from SAP or any partner) is neither to be modified nor to be enhanced
within the standard SWCV. If customer specific modifications need to made to standard developments
a customer specific SWCV is to be created with a usage dependency to the standard one.
All development and configuration objects are to be documented by using the built-in facilities of the
Integration Builder.
Existing development objects should be reused or enhanced if possible.
Also existing interface object definitions (e.g. XSDs, WSDLs, DTDs) should be used if available, which
just need to be imported into the ESR rather than creating them manually.

2.2 Process Component Architecture Models in Enterprise Service

Repository (ESR)
The models in the ES Repository support a model-driven development of an Enterprise Service
Oriented Architecture (Enterprise SOA).

2.2.1 Available Model Types

According to the harmonized Enterprise Service model, there are five model types: process
component model, integration scenario model, process component interaction model, business object
map, and integration scenario catalogue.

2.2.1.1 Process Component Model

The process component model (SAP ProcComp model) is used to describe the inner workings of a
process component. One or multiple BOs are used to model the data. Additionally the operations and
service interfaces are defined that the process component uses to access the data/BOs, and the
operations that are used to access other process components data.

In the process component model, the process component is modeled from the provider view.

481325269.doc 24.06.2020 Page 11 of 50

 Common Basic FC-System
Integration Architecture Design

2.2.1.2 Integration Scenario Model

Integration scenario models describe which process components belong to which deployment units
and how the process components interact with each other in an end-to-end scenario. The integration
scenario models give a better understanding of the whole process.

The following process component types could be used: process component (A2A), process
component at business partner(B2B), third-party process component (A2A). Placeholders should show
interaction with important process components that are essential for the end-to-end scenario and
which have interactions with a lot of Servers in the model.
There are four types of interactions available between the process components that show how two
process components exchange data between each other or the technology on which this data
exchange is based:
 Enterprise Service Interaction (implemented outbound from service interfaces in the ESR)
 Web Service Interaction (represents synchronous point-to-point communication)
 Direct Interaction (this interaction must be implemented in a deployment unit; it can be for
example a local RFC call)
 Other Interaction (other interactions between deployment units, different from Enterprise
Service or Web Service Interactions)

2.2.1.3 Process Component Interaction Model

Process component interaction models (SAP ProcComp interaction model) describe the
communication between two process components in detail. The model shows all involved BOs,
service interfaces, operations, and message types. A process component interaction model can only
be used for an Enterprise Service Interaction and there can be none, one, or multiple process
component interaction models assigned to one Enterprise Service Interaction.
The following message types are used to define communication:

 One message type for an asynchronous operation without mapping.

 Two message types for a synchronous operation without mapping (one for the request and
one for the response).
 Use mapping when the message type structures of the two PCs do not agree – in this case
you use an outbound and a target message type.

SAP recommends representing the sequence of events from top to bottom.

481325269.doc 24.06.2020 Page 12 of 50

 Common Basic FC-System
Integration Architecture Design

2.2.1.4 Business Object Map

Business object maps (SAP entity map), or business object template maps, aggregate business
objects or business object templates in a model for overview purposes. A business object map is an
entity map, which is a structured directory of all entities of the main entity types. An entity map for a
given application is a structured directory of all deployment units, process components, and business
objects in the application. Business object maps are defined for all major applications and are shipped
as ESR content.

481325269.doc 24.06.2020 Page 13 of 50

 Common Basic FC-System
Integration Architecture Design

2.2.1.5 Integration Scenario Catalogue

Integration scenario catalogs (SAP Scenario Catalog) group and structure all the integration scenarios
of a solution and thereby represent the business starting point for process modeling. The contained
scenarios and their variants are clustered using integration scenario groups.

2.3 Process Integration Scenarios in Enterprise Service Repository

(ESR)
Process Integration scenarios enable to define the message exchange and process flow for
collaborative processes. Normally, these are processes between different business partners that are
generally coupled by the exchange of messages.
The Process Integration scenario provides a central point of access for all objects that are require for
semantic and technical integration, such as interfaces and mappings.
An executable integration process can be integrated into the Process Integration scenario

2.3.1 PI Integration Scenarios including actions

An initial integration scenario is created by the Integration Team in order for visualization purposes. To
be able to do so initial actions need to be created as well. The Integration Team takes care that the
scenario is created complying with the naming conventions.
After the developers have been started with their work they should complete the initiated integration
scenario including actions. For example they should assign the correct interfaces to the actions,
assign mappings to the connections.
Concerning the modeling of integration scenarios including their actions a guideline from SAP is
provided which should be followed.
As the related configuration scenarios are often used as transport units the content of one integration
scenario should be grouped as one logical unit.
The integration scenario is to be created within the leading software component version of the
integration scenario.
As application components product versions from the SLD should be chosen. Templates are used if
no detailed information about the product version is available.
All actions are to be created within the SWCV the integration scenario is belonging to. By doing so the
entire integration scenario (incl. actions) can be transported within one SWCV.
Actions belonging to the main application components are to be defined as internal actions. Actions
belonging to other application components are to be defined as external actions.

2.4 Typical Pattern to model Services in Enterprise Service Repository

To model the overall architecture of a business application, the components it consists of, the services
those components offer, and how those components relate to and interact with each other must be
defined. Modelling focuses on design and ensures reusability, naming conventions, and scalable
interaction and integration scenarios.
The ES Builder in the Enterprise Services Repository should be the tool to define and manage all
necessary objects.
First the models should be created in order to determine which design objects are required for the
application and then the design objects should be defined in the ES Repository.
There are three essential objects for creating a service: data types (these define the structures and
substructures to be used in the messages exchanged at runtime), message types (these define the
types of data that can be exchanged in messages between a service provider and a consumer;
message types are based on data types), and service interfaces (these are programming-language-
independent representations of the service objects used at runtime). These objects are then used to
generate and implement the services.

Example step by step solution:

Step 1: A Software Component Version (SCV) should be created in the SLD. This SCV should be
imported in the ESR. A adequate namespace should be created for that SCV.
All objects required will be created under this namespace. Additionally, folders and subfolders could
be used to manage your content. The folders are used to group the objects in one place and to
manage the authorizations for these objects.
Step 2: To model which data the process component works with and which service interfaces are to
be offered, a new process component model (SAP ProComp model) should be created.

481325269.doc 24.06.2020 Page 14 of 50

 Common Basic FC-System
Integration Architecture Design

Step 3: The required business objects should be added to the model. The BO data structure is defined
using data types.
Step 4: All the operations and service interfaces should be identified and modelled that will provide the
process components with access to the data.

1. Definition of the service interfaces (inbound and outbound). A service interface can consist
of one or more operations and one or more message types. Interfaces must also be able to
declare policy definitions in machine readable format for granting access to service contents,
or for requiring protection guarantees to service elements, such as encryption or signatures.

2. Definition of the service operations. The operation pattern and the operation mode
(synchronous or asynchronous) should be defined.

3. The message types required by each operation should be created and assigned to that
service operation.

4. The data type should be assigned to each message type.

Step 5: The operations and service interfaces should be identified and modelled that will provide the
access to the data of other application. A process component interaction model should be used. The
same steps as described in Step 4 should be performed.
Step 6: The integration scenario model should be used to show interactions with other applications.
Step 7: The process component interaction model (SAP ProComp interaction model) should be used
specifically to model the messages exchanged between two process components.
Step 8: All the changes should be activated and the service interfaces should be released.

Once these steps have been completed, the service interface definitions that are needed to build and
implement the services should be already created. The next step is to generate development objects
for the definitions using proxy generation.

2.5 PI Interface Objects

2.5.1 Data Types
Whenever possible, already existing data types should be reused.
Before creating a data type from scratch it should be checked out whether a XSD definition for the
data type, the related message type or WSDL of the related message interfaces is available. These
can be imported into the Integration Repository rather than re-entering it manually using the data type
editor.
If available, a global or standardized business object should be used as the data type.
Simple data types: It is not recommended to create a simple data type for each single element unless
this data type has specific constraints, or it is planned to reference this data type in other objects as
well.
Complex data types: These are to be created in terms of logical units (e.g. address data, purchase
order item). Elements and attributes can, in turn, reference built-in, simple, complex, or global data
types. This enables large complex data types to be structured using smaller complex data types.
Default or automatically proposed names for data types should be changed to specific names. For
example, the data types for the JDBC receiver adapter should reflect the content of the JDBC call:
The tags <root>, <Statementx> should be replaced with specific names,
Instead of <keyx> the key’s name should be used,
Instead of <col1> the real database column names should be used.

2.5.2 Data Type enhancements

Data type enhancements are always to be used if the related standard objects of SAP have been
extended (e.g. by using Business Add-Ins). In this case the data type enhancement is to be done in a
customer specific SWCV and a separate namespace. This software component version must be
based on the SAP software component version in which the data type to be enhanced is defined.
It is not necessary to use enhanced data types if standard IDocs have been extended and/or modified.
Those definitions can be imported directly into the Integration Repository.

481325269.doc 24.06.2020 Page 15 of 50

 Common Basic FC-System
Integration Architecture Design

Furthermore, if an application is used that exchange messages by using XI, data type enhancements
should be used for the related Integration Repository data types. These enhancements are used for
sending additional data with a message and can be accessed by using BAdIs, for example.

2.5.3 External Definitions

External definitions of standard or global objects are to be imported in the corresponding software
component version of the external organization (e.g. OASIS.org).
In case of IDocs and RFCs, their definitions should be imported directly out of the corresponding
system into the integration repository and not be maintained as an external definition.

2.5.4 Context Objects

If routing conditions should be required within a receiver and/or interface determination context objects
should always be defined and used instead of XPath-expressions if technically possible.
For using XI specific objects for routing purposes technical context objects are predefined. These often
cannot be replaced by XPath expressions.
The reference between a specific node in a message and a context object will be retained after re-
import if the node itself has not changed.

2.5.5 Message Type and Fault Message Type

Check whether an XSD schema is available for a message type which can be imported into the
Integration Repository.
Fault message types are designed for application-specific errors that occur on the inbound side and
that are reported back to the sender or persisted in monitoring. As these are just supported by proxies
these just need to be created if this technology is used and the related application is making use of
application specific errors.

2.5.6 Service Interface

In case of RFCs and IDocs no message interface is to be created as the IDoc and RFC schemata can
be imported directly into the Integration Repository.

Please note that with SAP PI 7.1 and proxy technology only one operation per service interface is
allowed. Furthermore the operation has to have the same name as the service interface. For an
example see the screenshot below.

481325269.doc 24.06.2020 Page 16 of 50

 Common Basic FC-System
Integration Architecture Design

2.6 PI Mapping Guidelines

SAP XI supports four different types of mapping technologies:
 Message mappings: Message mappings are created using a graphical editor integrated in the
Integration Builder. Java classes are generated for use at runtime from a graphical description.
Standard functions for typical transformation tasks are provided which can be enhanced with user-
defined functions developed in Java.
 XSLT mappings: XSLT (eXtensible Stylesheet Language Transformations) is a template language
for transforming one XML document into another one. This is achieved by using XSLT commands
to search for tags in the source document and replacing them with other tags or values in the
target document. It is also possible to call Java programs from XSLT.
 Java mappings: The message is transferred to a Java program as an inbound stream and can be
imported using any parser (for example, SAX or DOM). The modified message is then transferred
to an outbound stream.
 ABAP mappings: Customers can develop ABAP mappings within the ABAP workbench based on
ABAP objects or XSLT mappings by using the Transformation Editor. These mappings are not
imported into the Integration Repository just the corresponding ABAP class is referenced. In
contrast to the other mapping technologies these mappings are executed by the ABAP engine of
XI at runtime.

2.6.1 Graphical mapping / General rules

When using Graphical tool the use of context mapping can improve performance.
Working with Context and Queues: Contexts do not have identifiable context changes whereas
Queues contain context change indicators which is much more memory intensive.
The use of Mapping template (when using graphical tool) is recommended this could enables a
maximum reuse. Mapping programs can be executed in a sequence by means of an interface
mapping.
The MappingTrace object should be used. This object gives the possibility to transfer messages to the
mapping trace. If the trace level is set correspondingly then the trace is visible in message monitoring

481325269.doc 24.06.2020 Page 17 of 50

 Common Basic FC-System
Integration Architecture Design

(transaction SXMB_MONI). The execution of the mapping is not interrupted when the entries are written
to the trace.
Concerning user-defined functions:
 User defined functions are intended for transformation purposes only. Transactional processes
(e.g. create, delete, updates …) should not be realized through mappings.
 Their naming and development should follow the general recommendations concerning Java
developments, which are defined at Daimler.
 For large messages, during message mapping, user-functions using "context"s or "queue"s as this
can result in large memory utilization
 If more complex Java programmes should be required for realizing a user defined function it is
advisable to develop it using the SAP NetWeaver Developer Studio and import them as archives
into the Integration Repository of the same or underlying SWCV. After the Java packages has
been added to the import statement of the user defined function the Java programme and
methods can be called out of the message mapping rather than implementing everything into the
user defined function.

2.6.2 Java mapping

In order to develop a Java mapping, the interface StreamTransformation must be implemented. This
interface gives access to the message as a stream that is received at runtime on the integration
server. Within the mapping program there is also access to runtime constants like senderName or
receiverName to implement a mapping that depends on message header content.
Java mappings are to be developed in accordance with the general rules for Java developments of
Daimler. The Java code has to be documented. In addition information should be written to the trace of
SAP XI.All kinds of possible exceptions have to be handled properly.
In case of complex transformations it might be quite difficult to get these realized by using message
mappings. However, before deciding to develop a pure Java mapping, it should be analyzed if the
same cannot be realized by a message mapping with user defined functions. Within user defined
functions java programs can be called for handling specific transformations. By doing so the
complexity of a message mapping can be reduced and additionally the advantages of Java can be
facilitated.
When developing Java mappings for SAP XI it is beneficial to use the SAP NetWeaver Developer
Studio for this purpose.
In case of XML messages the Java API for XML Processing (JAXP) should be used. For the parsing of
XML messages the DOM or the SAX parser can be used. The DOM parser should be used in case of
small messages as the entire message is loaded into memory. In contrast to this the SAX parser
should be used in case of large messages as single elements can be accessed with no need to load
the entire message into memory. As a rule of thumb Java mappings using the DOM parser are easier
to develop as the ones using a SAX parser.

2.6.3 XSLT mapping

Messages are in the form of XML documents. XSL Transformation (XSLT) is a member of the XML
family of languages. It describes how an XML structure is transformed into another XML structure.
Mappings can be defined using XSLT together with XPath. XPath is also a specification of the XML
family. Using XPath gives the ability to address any node in a XML document. XSLT implements
XPath expressions to select substructures of an XML document. Using templates in XSLT gives the
possibility to define the mapping rules for the selected substructures. Further supported features are:
To use the XSLT tags <xsl:include> and <xls:import> to include predefined templates for substructures
in a complete mapping definition. In this way, mappings or parts of mappings can be reused.
Moreover, using an XSLT definition enables to call external Java methods to convert XML structures.
This procedure gives more flexibility when defining mappings. However, not all XSLT processors
support external Java calls.
The XSLT code has to be documented. In addition information should be written to the trace of SAP
XI. All kinds of possible exceptions have to be handled properly.

2.6.4 ABAP mapping / ABAP XSLT mapping

ABAP mappings and XSLT mappings (ABAP Engine) are development objects of the ABAP
Workbench on the SAP Web Application Server. This has the following consequences:

481325269.doc 24.06.2020 Page 18 of 50

 Common Basic FC-System
Integration Architecture Design

●     These development objects are created in the Object Navigator (transaction SE80) and
transported using ABAP transports. They must be available on the Integration Server at
runtime. XI ES Repository does not support these transports.
●      ABAP mappings and XSLT mappings (ABAP Engine) can only exist in one active version on the
Integration Server. In contrast, the Java, XSLT, and message mappings that are executed on
the J2EE Engine can be used in multiple versions in parallel.

At present there is no mechanism for shipping mapping programs of the ABAP Engine with SAP
applications and importing them on the Integration Server. Therefore, only customers that can create
such mapping programs directly on the SAP Web AS of the Integration Server or can transport them
there can use ABAP Engine mappings. Unlike XSLT and Java mappings, which run on the J2EE
Engine, mapping programs of the ABAP Engine cannot be imported to the ES Repository. Therefore,
there are no mappings shipped by SAP that run on the ABAP Engine.

2.6.5 Mapping Templates

If it can be foreseen that parts of a mapping can be reused within another context a mapping template
is to be created.
Mapping templates can be re-used within message mappings or even other mapping templates.
These can be defined for data types, complex types in IDocs and RFCs or external definitions. The
types that are referenced from mapping templates can be located in any software component version.
The mapping templates can be used within message mappings from any software component version.

2.6.6 Mapping at Runtime

In conjunction with Integration Process, the mapping can be done at three different stages:
- before entering the Integration Process, defined at Interface Determination
- during the Integration Process (Transformation Step)
- after the Integration Process, defined at Interface Determination

Due to performance reasons, mappings should be done always before entering the Integration
Process or after the integration Process. This rule helps to take away complex transformations in
Integration Processes and to shrink down the number of context switches.

2.6.7 Imported Archive Object

XSLT and Java mappings are imported as archive files into the Integration Repository

Archives should be created on an interface mapping basis (at least one archive per interface mapping)
in order to ease the transport between different environments (e.g. from development to QA
landscape).
For performance reasons, XSLT and Java files should be stored in separate archives.
If Java is used, the .class and .java files should be uploaded into the Integration Repository even
though files of type .java will be ignored at runtime. But in the event of an exception, java files are quite
useful for analyzing and fixing errors. Keep in mind that java files cannot be recompiled within the
Integration Repository (corresponding .class files will not be updated). There is need to modify and
compile the Java source code in a Java development environment and then upload the updated
archive again into the Integration Repository.

2.6.8 Comparison of mapping type

The following table gives an overview of the possible mapping types and considerations regarding
their handling and their performance.
There are no published metrics or benchmarks from SAP on the mapping performance of the XI
Mapping Runtime versus other implementations; few benchmarks have been done. Hence,
performance tests in the project’s environment are necessary in order to provide throughput numbers.
In general, it can be said that performance depends on the complexity of the mapping scenario.

481325269.doc 24.06.2020 Page 19 of 50

 Common Basic FC-System
Integration Architecture Design

Mapping Handling considerations Performance considerations

type
XI  The Mapping Editor with a graphical  The Mapping Runtime is optimized
Message user interface (GUI) is integrated in (threading, smart input caching mechanism)
Mapping XI’s Integration Builder. It includes a
mapping test tool  The generated Java code parses the XML
document based on SAX (see comparison
 Java code is generated automatically below)
by the Integration Builder
 The XI message mapping only loads the
 Java functions can be developed as node that it is working on and maps
user defined functions and used in the according to the instructions. This means it
message mapping. This enhances uses less memory in regard to XSLT
vastly the flexibility of message mapping.
mapping
 Generally, it is equivalent to XSLT mapping
 Java function libraries can be imported
to the user defined functions
 Versioning of the mapping objects is
managed automatically by the
Integration Builder
 Mapping patterns are provided
Java  The mapping is programmed in native  Performance could be enhanced by
Java and has to implement at least the efficient Java programming
function execute that is called by XI’s
Mapping Runtime
 Great flexibility for mapping definitions
because you can program anything
you want
 XML parsing has to be implemented by
the Java program. You have the
choice between DOM and SAX parser
(see comparison below)
 Non-XML messages can be handled
easily
 An external Java development tool is
recommended, mainly for source code
rendering and debugging, i.e. SAP
NetWeaver Developer Studio or
Eclipse
 Versioning of the maps has to be
handled by an external tool

481325269.doc 24.06.2020 Page 20 of 50

 Common Basic FC-System
Integration Architecture Design

Mapping Handling considerations Performance considerations

type
XSLT  Big mapping programs can become  Performance given by XLST processor
complex. Hence, higher maintenance
effort  XSLT loads the entire XML message into
memory and then maps the data according
 Java functions can be called from out to the instructions. This means that the
XSLT process will use more memory.
 An external XSLT development tool is  XSLT mapping with calculations is slower
recommended, mainly for source code than in Java. XSLT parsing is using
rendering and debugging, i.e. character based processing so to do
XMLSPY from Altova calculation with XSLT , the parser has to
first convert all data into numeric which is
 There is the possibility to plug-in XI’s not the case in Java using numeric as well
XSLT processor into the development as character data.
tool (1). However, debugging functions
are only supported in other XSLT
processors (i.e. like the one from
XMLSPY from Altova)
 The imported XSLT programs can be
modified within the XI Repository by
means of a simple editor.
 Versioning of the maps has to be
handled by external tool
ABAP  Objects are outside of Integration  No switching required between ABAP stack
Repository, therefore versioning and (Integration Engine) and Java stack
transportation has to be handled (runtime mapping). This can enhance
differently than the other objects performance

ABAP  Objects are outside of Integration  No switching required between ABAP stack
XSLT Repository, therefore versioning and (Integration Engine) and Java stack
transportation has to be handled (Mapping Runtime). This can enhance
differently than the other objects performance
 Quick XSLT Transformer because it is
implemented in a system programming
language.

Notes:
(1) In Altova’s XMLSPY, the following command should be entered under Options -> XSL ->
External XSL transformation program to use XI’s XSLT processor which is part of SAP XML
Toolkit for Java:
java -cp <path>\sapxmltoolkit.jar com.inqmy.lib.xsl.Process -xsl=%3 -xml=%1 -out=%2

2.6.9 Specific Mapping Scenarios

Data Lookups
Within some integration scenarios data from other applications might need to be looked up for
enhancing the message before it is send to the final receiver. These kind of data lookups can be
realized by the following options:
o Mapping Lookups:
Within mapping programs (message, Java, and XSLT mappings) so called mapping lookups into
other applications can be implemented. For this purpose a specific Java API is provided by SAP
which allows to carry out look ups via communication channels of type JDBC, RFC or SOAP.
o Lookups by using integration processes:
A cross component integration process could be used for reading the data out of an application
before it is send to the final receiver. For this purpose an async./synch. Bridge could be used, no

481325269.doc 24.06.2020 Page 21 of 50

 Common Basic FC-System
Integration Architecture Design

correlation is required (stateless processing). The response message is merged by using a multi-
mapping. The Access to back-end system via an communication channel.
o Value mappings:
If an object has got different representations, depending on the context in which it is used, a value
mapping as a special kind of data look up needs to be carried out. Value mappings can be realized
as follows:
 Manual maintenance of value mappings within SAP XI:
For converting only few values value mapping groups can be maintained directly within
the integration directory. By doing so the cross-reference information is held within XI and
will be evaluated at runtime.
 Value mapping replication for mass data:
If the value mappings are stored in external tables, these can be replicated in the runtime
cache (on the Integration Server). This is done through special message interfaces (value-
mapping replication interfaces) that allows to implement both synchronous and
asynchronous replication scenarios.
Other variants like using SAP MDM, harmonizing master data etc. are not discussed any further within
this context.
Depending on the requirements of the integration scenario the suitable variant for carrying out data
look ups needs to be selected:
 Mapping Lookups:
o If real-time lookups are required and the corresponding application can be accessed
via RFC, SOAP or JDBC the mapping look ups using the lookup API should be used.

 Lookups by using integration processes:

o If real-time lookups requiring other adapter types are required it should be analyzed
whether an integration process could be used alternatively. Before developing an
integration process the Integration Team should be consulted in this regard.
 Value mappings:
o These should be used if the value mapping data is more or less static meaning that no
regular updates or real-time lookups are required.
o In case of few data sets these should be maintained manually within XI.
o In case of mass data these should be replicated to XI by using the mass replication
interface.
Multi Mappings
A mapping is a multi mapping if its transformation is not restricted to one source and one target
message type. The multi mapping is realized by an interface mapping consisting of a message, Java
or XSLT mapping. The mapping programs for multi mappings can be implemented in two different
ways:
 Into an integration process: Within a transformation step a 1:n-, n:1, and n:m transformations can
be implemented.

481325269.doc 24.06.2020 Page 22 of 50

 Common Basic FC-System
Integration Architecture Design

 Into a logical routing (receiver or interface determination): For this purpose an enhanced
receiver/interface determination has to be selected within the Integration Directory which allows to
assign an interface mapping. This option just supports 1:n transformations in terms of a message
split.
Multi mappings within logical routings should be chosen for the following use cases:
 If a 1:n multi mapping should be realized.
 The related message interfaces are asynchronous.
 As receiver communication channel an adapter of the J2EE adapter engine or the Java proxy
runtime are used (e.g. no HTTP, IDoc, no integration process as receiver of messages).
 Attachments of the original message are not required as these are lost when splitting a message.
 The outbound messages are processed through one J2EE adapter engine.
Multi mappings within an integration process should be chosen for the following use cases:
 If a multi mapping within a logical routing cannot be used due to its limitations as listed above and
the integration scenario is suitable for using an integration process.
 If an integration process is used anyway.
If both multi mappings cannot be used it should be sorted out if the sending application would be
capable of providing the messages in the correct format as required by the receiving application.
Another work around could be to use a file adapter in-between (merging inbound messages per
append mode, splitting one inbound messages by using the configuration parameter “record sets per
message” of the file content conversion).
References between Mapping Programmes
They are needed to reuse existing developments made for a specific mapping programme within other
ones. To be able to do so the mapping programs need to be located in the same, or an underlying
software component version:
 The Java classes in an archive can be used in the user-defined functions of a message mapping.
 Java classes can use each other.
 XSLT programs in different archives can include or import each other. It is also possible to call
Java methods from an XSLT mapping (see: XSLT Mapping with Java Enhancement).

2.6.10 Interface Mappings

Within interface mappings a sequence of mapping programmes (e.g. message mappings, XSLT, Java,
ABAP) can be referenced for execution. For performance reason the number of mappings to be
executed in a sequence should be kept to a minimum.
If a mapping sequence is used within an interface mapping different types of mapping programmes
can be combined. Therefore the best mapping technology should be chosen for the required
transformation.

2.6.11 Imported Archives

If XSLT or Java mappings are used the related files have to be imported into the “Imported Archives”
section of the Integration Repository. They should be separated in different archives to enhance
performance and enable easy transportation.
If more complex user defined functions for message mappings need to be developed these should be
imported as archives and referenced within the message mapping rather than typing the Java coding
into the message mapping editor.
In case of Java code the class file and the source file should be imported in order to have both file
types centrally stored within XI.

2.7 PI Integration Process Guidelines

An integration process is an executable cross-system process for processing messages. In an
integration process all the process steps to be executed and the parameters relevant for controlling
the process are defined.
Integration processes are needed to define, control, and monitor complex business processes that
extend across enterprise and application boundaries. The design and processing of integration
processes is also known as cross-component Business Process Management (cross-component
BPM, ccBPM), or service orchestration.

481325269.doc 24.06.2020 Page 23 of 50

 Common Basic FC-System
Integration Architecture Design

SAP offers a checklist: Making Correct Use of Integration Processes.

An integration process should be developed if this has been proposed within the High Level
Integration Solution Design document of the corresponding integration scenario. If this shouldn’t be the
case but it should turn out that the use of an integration process could be beneficial the integration
team is to be contacted in order to agree on how to proceed.

2.7.1 Process Patterns

The standard Integration Process patterns should be used for reference. They are mostly installed with
the Integration Repository and show how common process cases can be implemented.
 See XI 7.1 Online Documentation SAP Exchange Infrastructure -> Integration Processes
(ccBPM) -> Examples and Usage Cases.
 See Integration Repository -> Software Component Version SAP BASIS -> SAP BASIS 7.10
-> http://sap.com/xi/XI/System/Patterns -> Integration Scenarios & Integration Processes ->
Integration Processes

Currently, following patterns exist:

 Multiple start process receive steps
 Collect: Collecting several messages and merge them into one message
o There are different ways to stop collecting:
 Payload-dependent
 Time-dependent
 Receiving a certain message (stop message)
o Collecting messages from different interfaces:
 Collecting all messages
 Collecting based on a condition
 Multicast: sending a message to multiple receivers and waiting for a response message from
each of the receivers
o Sending simultaneously (ParForEach)
o Sending to one after the other (ForEach)
 Serialization: defining the sequence in which a process sends received messages. You can
specify that the process must wait for an acknowledgement from the receiver each time that it
sends a message
o One start message
o Multiple start message
 Sync/Async Bridge: communication between a synchronous and an asynchronous business
system
 Integration process for booking connecting flights (IDES example)
 Deadline Monitoring for Receipt of a Response Message
 Sending Synchronously to Multiple Receivers

Process pattern could be reused own processes. To perform this task the following step must be done,
choose Insert -> Integration Process After form the context menu for a step or from the menu bar of
the Process Editor.

2.7.2 Using Correlation

The correlation is the concept provided by XI to handle the call between Integration Process instances.
This correlation is based on the definition of an ID. So it is very important to carefully define a unique
ID to avoid duplicate messages or incoherent treatment. This ID could be a combination of functional
attribute or a sequential ID provided by an “ID referential “using Oracle Database for example.

2.7.3 Exception handling and Alerting

Exception handling and alerting features must be used in the Integration Process definition. This will
allow a better monitoring and support of the processes during operations. There should be no
unhandled exceptions left in the Integration Process.

481325269.doc 24.06.2020 Page 24 of 50

 Common Basic FC-System
Integration Architecture Design

2.8 PI Versioning Capabilities

The versioning of XI development objects is handled automatically by the PI Integration Builder.

Each time an object is created or modified its version number is increased as soon as the object is
activated. The history of versions is stored and kept by the Integration Builder and can be accessed at
any time. If an old object version is edited, this version becomes the current object version (all
changes to previous versions of that Software Component Version (SWCV) are then lost).
Once a version of an PI object is released, i.e. for production, this object can be transferred to the next
Software Component Version (Release Transfer). This new version of the Software Component would
reflect a new phase of development.
If a bug occurs, the bug fixing needs to be done in the corresponding Software Component Version
and will imply a new version of the object. Once deployed this new version then needs to be
transferred to the next releases if a new Software Component Version has already been created. It
can happen that there is a conflict when merging two different objects (i.e. merging 1.3 and 2.1 in the
following figure). In this case the target object needs to be updated manually.

XI development object versioning

Release Bugfixing

1.0 1.1 1.2 1.3

Release transfer

Release Bugfixing

2.0 2.1 2.2 2.3

Release transfer

Release Bugfixing

3.0 3.1 3.2 3.3

Releases
(SWCV)

2.8.1 Example Usage of PI Versioning

For an integration project the version number of the Product and the Software Components shall be
aligned.

For the first version:

Version 1 for Product XYZ_Complete

Version 1 for all used SWCV

For the next version after release transfer:

Version 2 for Product XYZ_Complete

Version 2 for all used SWCV

A release transfer will take place from Version 1 to Version 2 once developments for XYZ Version 2
will start.

2.9 PI Interface Configuration Guidelines

481325269.doc 24.06.2020 Page 25 of 50

 Common Basic FC-System
Integration Architecture Design

The message path through PI should be configured within the “Integration Directory” of the PI Server.
Each message has to pass from the source system to the target system a queue with different stages.
And each step has to be configured, and will be used during runtime.

The elements for the Integration Directory will be shown within the following picture:

The following table defines the required configuration objects. The current PI naming conventions should
be used to create any object!

481325269.doc 24.06.2020 Page 26 of 50

 Common Basic FC-System
Integration Architecture Design

Object Type(Name) Description

Configuration Scenario The configuration Scenario should be generated with the wizard.
The input will be the integration scenario from the design.

Groups all configuration objects that are relevant for the

execution of the integration scenario.

This documentation recommends that you group the

configuration objects for all variants of the integration scenario in
the same configuration scenario.
Business System or Business Identifies a business system in the Integration Directory that is to
Service be addressed as the sender or receiver of messages
Sender Communication Channel Contains the details for configuring a sender adapter that is used
to process the message on the inbound side. The sender
file/FTP adapter is used to write a file from a source directory to
the pipeline
Receiver Communication Channel Contains the details for configuring a receiver adapter that is
used to process the message on the outbound side. The receiver
file/FTP adapter writes the file to one or more target directories
Receiver Determination Specifies the receiver of the message for the sender and the
outbound interface. The receiver must be entered in the receiver
determination as a configured receiver.
Interface Determination Specifies the inbound interface for the sender, outbound
interface, and the receiver. The inbound interface must be
entered in the interface determination as a configured inbound
interface
Sender Agreement Specifies the sender communication channel to be used for the
sender and the outbound interface
Receiver Agreement Specifies the receiver communication channel to be used for the
sender, the receiver, and the inbound interface

All development and configuration objects are to be documented by using the built-in facilities of the
Integration Builder.

2.9.1 Configuration Scenario

Configuration scenarios should be created by transferring the integration scenario from the Integration
Repository using the wizard functionality.
Before generating the required configuration objects a simulation run should be carried out in order to
verify that no errors are in place. While running the simulation it should be verified that all required
services and communication channels have already been created (these should be listed within the
“Objects” tab of the Integration Directory). If this should not be the case the Integration Team should
be contacted.
The option “Generate communication channels automatically” is to be deactivated.

2.9.2 Receiver Determination

Whenever possible a receiver determination of type standard should be used. An extended receiver
determination is to be used if the receiver needs to be dynamically determined (e.g. through a
mapping lookup).
The runtime behaviour if no receiver can be found for a specific message should be configured
according to the business requirements.
o Terminate Message Processing with Error (Restart Possible):
This option has to be chosen if the inbound message actually has to have a receiver. It would
indicate an error if no receiver could be found. For this reason these messages should cause an
error in order to inform support staff. After the cause of error would have been fixed the message
processing could be restarted.
o End Message Processing Without Error (Restart not Possible):

481325269.doc 24.06.2020 Page 27 of 50

 Common Basic FC-System
Integration Architecture Design

This option should be selected if an inbound message is broadcasted to many receivers and it
could happen that no receiver can be found. There is no business impact expected if no receiver
would have been found. In this use case this option should be selected which forces the messages
just to terminate without causing any errors.
o Continue Message Processing with the a specific Receiver:
This option is to be used if a default processing can be defined if no receiver can be found for a
message. For example the messages could be sent to a support team by using the mail adapter.

2.9.3 Interface Determination

The interface determinations should be created as generic (using wildcards) as possible. By doing so
these objects can be reused within other scenarios. If a more specific configuration should be required
just a specific configuration object can be added. At runtime the specific configuration will overrule the
generic configuration.
Whenever possible a receiver determination of type standard should be used. An extended receiver
determination is to be used if the receiver needs to be dynamically determined (e.g. through a
mapping lookup).
The option “Maintain Order at Runtime” is selected per default. Check whether the scenarios really
require a processing in EOIO mode (Exactly-Once-In-Order). Whenever possible deselect this option.
By doing so the messages are processed in EO mode (Exactly-Once) allowing parallel processing
which is faster.

2.9.4 Routing Conditions

Routing conditions can be added within receiver and interface determination if more than one
receiver / receiving interface are assigned. Routing conditions are created by using the built-in
condition and expression editor:
 If possible context objects should be used as routing conditions. Besides the technical ones, which
just have to be selected within the expression editor, message related ones are to be defined in
advance within the Integration Repository.
 If possible technical context objects or constants should be used as for these not the message
payload need to be scanned as these are stored within XI’s message header.
 The number of XPath expressions with payload access should be kept to a minimum as these
cost performance.
 If more complex XPath expressions need to be applied (no selection based on the source
message possible) the condition can be entered manually.

2.9.5 Collaboration Agreements

Collaboration agreements (sender and receiver agreements) should be created as generic (using
wildcards) as possible. By doing so these objects can be reused within other scenarios. If a more
specific configuration should be required just a specific configuration object can be added. At runtime
the specific configuration will overrule the generic configuration.

2.10 PI Technical Connection Guidelines

2.10.1 ERP Connection
The proxy connection should be divided into separate authorization groups. Each Software Namespace
of the Software Component CBFC_GLOBUS_SAP_APPL should use a separate http connection with a
different connection user.

2.10.2 Configuration of Communication Channels

The configuration of a communication channel (CC) of a specific adapter type strongly depends on the
requirements of the integration scenario. For this reason no specific recommendations can be
provided within this guide. As a starting point hints and tips for configuring adapters which are mainly
used for integrating SAP applications with SAP XI are given (IDoc, RFC, XI adapter).

Before drilling down into configuration settings per adapter type some general recommendations for
preparing and configuring adapters / CCs are given:

481325269.doc 24.06.2020 Page 28 of 50

 Common Basic FC-System
Integration Architecture Design

 Before creating a new communication channel it should be checked whether an existing one
could be reused. For example in most cases one receiver CC of type IDoc should be sufficient
for one receiving business system.
 For using specific adapter types it is not sufficient just to configure the communication
channels as some prerequisites need to be in place (e.g. RFC destinations, deployment of
libraries). For this reason it should be checked which kind of preparations need to be
performed within the Technology Consultant’s Guide for XI and request their implementation
at the team responsible (e.g. SAP Basis Team, owner of the system to be connected with SAP
XI).
 It should be checked which security measurements have been requested for the integration
scenario for which the CCs are needed. Additionally it should be sorted out which security
configuration within SAP XI would fulfill these requirements and request their preparation as
soon as possible (e.g. at SAP Basis Team).
 It should be checked if the system to be connected to SAP XI is reachable through the
network. It should be kept in mind that ping tests from a local PC cannot be considered as the
network connectivity between SAP XI and the respective system in both directions would need
to be checked. For this purpose RFC destinations could be used within SAP XI (transaction
SM59): If a system is to be connected with an adapter using http as transport protocol a RFC
destination of type “HTTP Connection to Ext. Server” could be used for testing purposes.
 The status of the adapter type and the configured CC should be checked within the Runtime
Workbench of SAP XI. The component monitoring provides some functions for carrying out
ping and self tests. Within the communication channel monitoring the proper functioning or
errors for specific CCs is displayed.
 CCs should be configured “active” only when needed (e.g. for developments, tests) otherwise
the XI system might be flooded by lots of unwanted messages. This applies especially for
sending File and JDBC adapters as these are using poll mechanisms for generating
messages.
 Adapters which are running within the adapter framework of the J2EE Engine (e.g. File, JMS,
JDBC, RFC, Mail, RFC, SOAP) support the use of adapter modules. Adapter modules can be
considered as kinds of user exits for calling J2EE programs. By doing so the behavior of the
adapters can be enhanced as needed: One or a sequence of adapter modules can be called
when processing a message. There are some adapter modules provided by SAP. Additionally
partners and customers can develop their own adapter modules or even their own adapters
with the adapter development framework.
 If desired the trace of single adapters can be increased for analyzing purposes within the
development and testing phase.
 Sender adapters often support adapter specific message attributes. Their use is to be
activated and configured within the communication channel configuration. These values can
for example be read/set within mapping programs or used for message routing purposes
(check the context objects listed within expression editor). If content based routing should be
needed within a particular integration scenario check whether an adapter specific attribute
could be used for this purpose. As these are stored in the XI message header these can be
accessed faster than elements within the message body.

2.10.2.1 RFC Adapter

With the RFC adapter functions within SAP systems can be called or messages resulting out of RFC
calls can be received within SAP PI. SAP systems as of version 3.1x are supported. The native RFC
format is converted into RFC-XML and vice versa.
 For general information concerning the RFC adapter SAP note 30870: “FAQ XI 3.0 RFC Adapter”
should be checked on the SAP Service Marketplace.
 For secure RFC connections SNC (Secure Network Connections) need to be configured within
SAP XI. SNC is a SAP specific security mechanism for the RFC protocol like SSL (Secure Socket
Layer) for HTTP connections.

Sender and receiver RFC CC:

 For loading the RFC metadata from a repository the business system to be connected and no
other one should be used if possible. Another system (a SAP system) has to be used if the
business system shouldn’t be a SAP system.

481325269.doc 24.06.2020 Page 29 of 50

 Common Basic FC-System
Integration Architecture Design

 If the business system is supporting load balancing some settings would need to be applied in a
different way.
 The system owner should be consulted in order to determine the appropriate initial and maximum
number of connections. These should be configured properly for productive environments as
multiple connections allow multiple processing threads at a client system’s gateway. As a result
the performance should increase.
 RFC adapter specific attributes of the sender CC: RFC destination.
 Some specific configuration can be applied by using the advanced mode on the configuration tab.
The supported parameters and settings are published in the SAP Online Help.

2.10.2.2 IDOC-Adapter
The IDoc adapter enables to process IDocs with SAP XI. IDocs from SAP systems Release 3.1x or
higher are supported. The native IDoc format is converted into IDoc-XML and vice versa. In contrast to
most of the other adapters the IDoc adapter is not running on the J2EE adapter engine but within the
ABAP stack of SAP XI. For this reason this adapter doesn’t support adapter modules. Non SAP
systems can also use the IDoc adapter to connect to an Integration Server. In contrast to other
adapters a communication channels just for sending IDocs from XI to a business system (receiver
IDoc CC) needs to be configured. For receiving IDocs from business systems just some RFC
connections between both systems need to be created.

 The preparations should be checked and applied for connecting a business system using the IDoc
adapter. For example RFC destination (TA SM59), partner profiles (TA WE20) and ports (TA
WE21) need to be configured within the business system. After an RFC destination has been
created its functioning should be verified by using the test functionalities provided.
 Within SAP PI some RFC destinations (TA SM59) and a port (IDX1) needs to be created. IDoc
adapter specific attributes the most fields of the IDoc’s control record could be used (e.g. sender /
receiver partner, message type and version, sender / receiver port). If a content-based routing
should be required these attributes should be favored over fields of the message body if possible.
 IDocs which should not be converted into IDoc-XML and processed within the Integration Server
(IDoc tunneling) are to be listed within the exception table IDXIDOCINB through the report
IDX_SELECT_IDOCTYP_WITHOUT_IS.
 The IDocs related to an XI message within the sender or receiver system can be sorted out
through the IDoc tracking functionalities within the IDoc monitoring.

Receiver IDoc CC:

 For the parameter “Segment Version” no value should be applied, because then the newest
version is always used.
 For the parameter “Port” the one created in transaction IDX2 is to be chosen. The IDoc adapter
uses this port to retrieve the IDoc metadata. The port definition again uses an RFC destination to
obtain the IDoc structure by using RFC. For non-SAP systems receiving IDocs a SAP system
needs to be used for retrieving the required IDoc metadata.
 For the parameter “SAP Release” the correct value is to be selected as follows:
o INBOUND_IDOC_PROCESS (for 8 character IDoc types, that is SAP Releases 3.0 and
3.1)
o IDOC_INBOUND_ASYNCHRONOUS (for 30-character IDoc types, that is SAP Releases
4.0 and higher)
 The check box “Queue-Processing” is to be checked if the IDocs are to be processed within the
receiving system in EOIO mode. This feature is supported by SAP systems which are based on
SAP Web AS 6.40 or higher. Otherwise the IDocs are just processed in EO mode.
 If the checkbox “Apply Control Record Values from the Payload” the values are taken out of the
IDoc-XML message and not determined automatically through the configuration settings. The
values of the IDoc-XML message can be modified as desired through a mapping program.

481325269.doc 24.06.2020 Page 30 of 50

 Common Basic FC-System
Integration Architecture Design

 The metadata of every IDoc message type to be processed must be loaded(TA IDX2). If the IDoc
structure should have been changed within the business system the IDoc structure would need to
be reloaded again. If it should not be clear if the IDoc metadata are still up to date this can be
tested by running a check in order to identify any inconsistencies.
 IDocs are using specific acknowledgements (ALE audit IDocs) which have to be requested from
the sender. Some additional configurations (e.g. scheduling of reports within the receiver system)
need to be applied. This specific acknowledgement can be converted into an XI acknowledgement
if required.

2.10.2.3 XI Adapter
The XI adapter is used to exchange messages with an Integration Engine: SAP business systems as
of Web AS 6.20 are able to use proxies (ABAP or Java proxies) for exchanging XI messages with an
XI system. Additionally messages of – of course – other SAP XI systems and the Partner Connectivity
Kit (PCK) are able to communicate with an XI system through this adapter.

 Even though the configuration of an XI CC is quite simple the preparation within the business
system can be considered as difficult for people who are not familiar with SAP XI. As the
configuration of an Integration Engine for a business system doesn’t differ that much from the
configuration of the Integration Server the Integration Team should support the system owner of
the business system in this regard.
 If security settings are going to be used (message signing, message encryption, HTTPs) the
related preparations should be requested in advance at the SAP Basis Team.

Receiver XI CC:
 For the parameter “Addressing Type” the option “HTTP Destination” should be chosen. When
selecting this type the connectivity details (e.g. user and password) are not maintained within the
CC configuration but within a RFC destination (TA SM59). Please note that different kinds of RFC
destinations having different values need to be created for non-ABAP and ABAP based receiving
systems.
 Anonymous logon is not to be used.
 The option “Transfer Hop List” should be activated for A2A communications. By doing so
acknowledgements can be passed backwards as the related XI message was sent through.

2.11 Code Documentation

2.11.1 Object Documentation
The development objects of the Integration Repository have to be documented as follows: For all
objects the description fields is to be filled properly. In case of data types the single elements have to
be described if their meaning cannot be derived from its name. Optionally a documentation can be
applied using the built-in documentation editor for long texts.
Long text documentation is required for the following:
 Integration scenarios
 Integration processes
 Advanced mappings (e.g. with mapping lookups, multi mappings, user defined functions).
For the configuration objects of the Integration Directory the configuration scenario is to be
documented in a detailed manner (e.g. with optional references to other documents like
specifications). If routing conditions are used this logic is to be described briefly (e.g. business
context). In case of special configurations (e.g. extended receiver-/interface determination, security
settings) the reasons for doing so should be documented.

2.11.2 Program Documentation

The most of the development and configuration activities are done by using graphical tools. Programs
only need to be developed in the following cases:
 XSLT mappings
 Java mappings

481325269.doc 24.06.2020 Page 31 of 50

 Common Basic FC-System
Integration Architecture Design

 ABAP mappings
 User defined functions for message mappings
 Development of adapter modules in Java
If Java or ABAP proxies are used the related developments are not done within SAP XI but within the
corresponding application systems.
The code of the above listed developments is always to be documented. In case of XSLT and Java
mappings comments are used for documenting the source code. This should be done in a very
detailed manner. For ABAP developments the documentation rules for ABAP programs are to be
followed.

2.11.3 Tracking of Changes

Within the Integration Repository and Directory old versions of objects are kept and can be reverted if
necessary. However, the changes themselves are neither tracked nor documented automatically. If
major changes are applied these would need to be documented as described within this chapter.
If it should be intended to develop a newer version of an entire integration solution a release transfer
of the related SWCVs should be carried out: For this purpose a new SWCV (e.g. version 2.0) is to be
created within the SLD and imported into the Integration Repository. Afterwards the content of the
corresponding old SWCV (e.g. version 1.0) can be transferred to the new one. By doing so the status
of the old development can be frozen.

481325269.doc 24.06.2020 Page 32 of 50

 Common Basic FC-System
Integration Architecture Design

3 cbFC related PI Interface Guidelines

Following rules are specific and mandatory for the cbFC project.

3.1 cbFC related Modeling in Enterprise Service Repository (ESR)

The following example uses available objects from Software Component Version
CBFC_GLOBAL_SAP_APPL , 1.0 of daimler.com in the Namespace
http://corpintra.net/pi/CBFC_GLOBAL_SAP_APPL/Controlling.

This example shows the modeling capabilities in ESR. This capabilities lead to models, which could be
used as blueprint for the scenario configuration wizard in the Integration Directory. This enables a
consistent and guided creation and change of directory objects.
The respective design objects are assigned wherever possible to the respective model objects to
enable a smooth top down navigation.

481325269.doc 24.06.2020 Page 33 of 50

 Common Basic FC-System
Integration Architecture Design

3.1.1 Process Integration Scenario Example for Controlling

Integration Scenarios are available since SAP Exchange Infrastructure Version 3.0. They could be
used as Blueprints for the configuration in the Integration Directory.

3.1.1.1 PI Integration Scenarios CBFC_Controlling

The Integration Scenario CBFC_Controlling shows both swim lanes with the needed actions
SendControllingObject and ReceiveControllingObject to describe the needed message flow between
the used products.
The actions are linked with an arrow, the relation between both underlying Service
Interfaces/Operations. Due to the fact that both Operations are build of the same Message Type, no
Operational Mapping/Message Mapping is needed, so no Operational Mapping is hooked in there.

3.2 cbFC related PI Development Units

PI development objects will be created with the SAP PI Integration Builder Repository. Interfaces and
Mappings are typical developments objects. Those objects could be clustered to 6 different
development units (see picture below):

1. cbFC global Interface Repository

The target of the Interface development is to provide a central repository of all required cbFC
Interfaces within the repository of the SAP PI. This repository should be used by the roll-out
team, to connect the “local” systems with the cbFC SAP ERP system. This layer represents the
Template Interfaces.

2. Local direct Connection

Local systems should be connected directly to the global cbFC Interfaces, if the global template
structure could be provided. No further interfaces and mappings are required.

481325269.doc 24.06.2020 Page 34 of 50

 Common Basic FC-System
Integration Architecture Design

3. Local connection with structure Mapping

If the local system could not support the global interface structure, then a separate local
interface structure of the local system should be created. And a structure mapping to convert the
message between the local and global structure.

4. Local cbFC Interfaces

Additional local interfaces to the cbFC system are separated into own development units. They
are parallel to the global Interface Repository, to enhance the interface with additional local
requirements.

5. Global Systems
Global Systems like GLOBUS are independent from the roll-out location. They are part of the
global development, and require a separate development unit for interfaces and mappings.

6. Outbound Interface with value Mapping

The outbound interface scenario includes the value mapping for “static” values like shipping
conditions or currencies. ID mappings are out of scope.

The 6 different development units have to follow different guidelines, which are described in the following
chapters.

The ccBPM should be avoided. A justification with an approval should be provided to use the ccBPM in
minor exceptional cases.

481325269.doc 24.06.2020 Page 35 of 50

 Common Basic FC-System
Integration Architecture Design

3.2.1 cbFC global Interface Repository

The global Interface Repository is a pool of Template Interfaces, which defines and provides the
structure to exchange messages with the cbFC SAP ERP system. Specific Interfaces and Mappings to
and from specific Interfaces are not part of this pool. Service Interfaces for the cbFC system and local
direct connection are provided (Inbound and Outbound couple).

The following table defines the required design objects for this development unit. The current PI naming
conventions should be used to create any object!

Object Type(Name) Description

Software Component Software Components are maintained within the SLD (System
Landscape Directory). There is one Software Component for all
global interfaces “CBFC_GLOBAL_SAP_APPL”. This Software
Component is assigned to the cbFC SAP ERP System.
Software Component Version No Software Component versioning is used for the project cbFC.

[The Software Component Version is imported from the SLD to the repository, to
provide a structure for the development (interfaces, datatypes, …).]
Namespace Namespaces are created in the Integration Repository and shall
have a 1:n relationship to the Software Component Version. In
other words, a Namespace can always be attached to only 1
Software Component Version. Therefore the Namespace
should be unique. This behaviour is guaranteed by using the
Software Component Name as part of the Namespace.
E.g.: http://corpintra.net/pi/CBFC_GLOBUS_IBM/ Procurement or
http://corpintra.net/pi/ XYZ/OrderManagement

Actions Actions are containers used in the configuration scenario which

hold the inbound or outbound message interfaces. Each
Interface should be represented by one action. Configuration
Scenarios are created at later stages, which will then use the

481325269.doc 24.06.2020 Page 36 of 50

 Common Basic FC-System
Integration Architecture Design

Interfaces/actions of this Software Component.

Service Interface Specifies the communication mode (asynchronous/synchronous)
and references the used message type. Both direction
categories shall be available. E.g. an inbound interface on the
cbFC will be an outbound interface for the satellite system.
Message Type Describes the message sent at runtime and references the data
type used
Data Type Describes the data structure of the message with following rule:

- Message Data Type. E.g. PurchaseOrderMessage

- Structure Data Elements (optional)
- Global Data Types (GDTs). E.g. DeliveryTerms
- Core Data Types. E.g. string

Global Data Types should be used from the SAP delivered

Software Component “SAPGLOBAL 2.0”.
Interface Mapping Describes the mapping between a standard global IDoc interface
to a cbFC global interface build on GMTs.
Message Mapping Describes the IDoc to global cbFC Interface mapping in detail.
Imported Objects - IDocs Provides IDoc interfaces to local backend Systems as global
Interfaces. The IDoc structures are imported from the cbFC
system. Only global requested IDocs are supported.

Global Data Types (GDTs)

The SAP provided repository object SAPGLOBAL version 2.0 will be used as GDT pool. This Software
Component has to be imported into the PI repository, and is the source for any copy.

The cbFC global software component should include the structure and definition of all required global
template interfaces, as well as a copy of the GDTs.

481325269.doc 24.06.2020 Page 37 of 50

 Common Basic FC-System
Integration Architecture Design

3.2.2 Local direct Connection

The connected local system will use exactly the same interface as it is defined within the global cbFC
interface repository template. No further development of interfaces or mappings is required. The
configuration of this interface scenario will be described in the chapter “PI Interface configuration
Guidelines”. The software component CBFC_GLOABL_SAP_APPL is used to describe and implement
the Service Interface for the cbFC and the local system. The software component
CBFC_GLOABL_SAP_APPL provides always both direction categories. One for the cbFC interface, and
the opposite one for the direct connection of local systems.

3.2.3 Local connection with structure Mapping

If the local System could not support the global cbFC template interface structure, then this individual
interface should be created/designed within a separate Software Component. This individual Software
Component should have a dependency to the global cbFC software component (configuration within the
SLD).

481325269.doc 24.06.2020 Page 38 of 50

 Common Basic FC-System
Integration Architecture Design

Due to the different structure between the local interface and the global template interface, a structure
mapping is required to map the message form one format to the other. The following table defines the
required design objects for this development unit. The current PI naming conventions should be used to
create any object!

Object Type(Name) Description

Software Component Software Components are maintained within the SLD (System
Landscape Directory). There is one Software Component for
each connected local system e.g. CBFC_MIF_TSYSTEMS”. This
Software Component is assigned to the local non SAP system
“MIF”.
Software Component Version Versions are used to freeze different releases. E.g. A new
version could be developed, while previous (productive) versions
are still available and unchanged. Previous versions could be
used for bug fixing.

The Software Component Version is imported from the SDL to

the repository, to provide a structure for the development
(interfaces, mappings, …).
Namespace Namespaces are created in the Integration Repository and shall
have a 1:n relationship to the Software Component Version. In
other words, a Namespace can always be attached to only 1
Software Component Version. Therefore the Namespace
should be unique. This behaviour is guaranteed by using the
Software Component Name as part of the Namespace.
E.g.: http://corpintra.net/pi/CBFC_MIF_TSYSTEMS/ Procurement or
http://corpintra.net/pi/ XYZ/OrderManagement

Actions Actions are containers used in the configuration scenario which

hold the inbound or outbound message interfaces. Each

481325269.doc 24.06.2020 Page 39 of 50

 Common Basic FC-System
Integration Architecture Design

Interface should be represented by one action.

Process-Integration-Scenario Create an Integration Scenario to describe the Scenario.
Integration Scenarios are used to:

• Document the message flow

• As input for the Configuration Scenario

“Actions” from the global cbFC template repository are used, as

well as “Actions” from this Software Component.
Process Integration Scenarios are mandatory.
Service Interface Specifies the communication mode (asynchronous) and
references the message type used
Message Type Describes the message sent at runtime and references the data
type used
Data Type Describes the data structure of the individual local message.
External Definitions (optional) Describes the external message types which are held in a XSD
Communication Channel Templates Specifies the sender (and receiver) adapter configuration details which
(optional) are defined at design time. Communication channel templates enable a
communication channel to be preconfigured at design time
Interface Mapping Describes the mapping between the source and target interface
Message Mapping Describes the mapping between the source and target structure in detail
Imported Archives (optional) Describes the imported archives which are needed to use XSLTs or
Java Mappings

Example of an integration scenario:

3.2.4 Local cbFC Interfaces

Separate software components are used for each roll out location.

3.2.5 Global Systems

Global systems should be connected like local systems: Direct to the global template structure, or
indirect with an individual interface and structure mapping to/from the global template interface. So the
same guidelines should be used.

481325269.doc 24.06.2020 Page 40 of 50

 Common Basic FC-System
Integration Architecture Design

3.2.6 Outbound Interface with value Mapping

Outbound Interfaces are messages from the cbFC Server (Sender) to any satellite Server (Receiver).
The receiver systems will be connected with PI, and all outbound messages should pass the PI Server.

3.2.6.1 Outbound – Message Split

The technical implementation for value mappings should be different for outbound interfaces as for
inbound interfaces. While inbound interfaces have always ONE sender, the outbound interfaces could
have multiple receivers. E.g. the master data interface for customer is an outbound interface from cbFC,
and the receivers will be defined within the PI system. There are several systems receiving the
distributed “CREMAS” message. This scenario requires a different technical solution for the value
mapping, because the cbCF does not have the routing/splitting information. The are two reasons for
implementing the value mapping in PI: a) The receiver of the message is only known by the PI system,
and the values are dependent on the receiver. b) The outbound message from the cbCF system could
not include different values for several receivers. This technique will be used for master data, but
transactional data interfaces have mostly just one receiver. And for this 1 to 1 connection the value
mapping could be done in cbFC (AIF).

481325269.doc 24.06.2020 Page 41 of 50

 Common Basic FC-System
Integration Architecture Design

3.2.6.2 Outbound – Message Trigger

The source/trigger of the message within the cbFC influences the used cbFC interface technique. E.g. if
a SAP standard IDOC mechanism is available to send a message, then this ALE feature should be used
instead the AIF tool. And for all none SAP Standard IDOc message, the AIF and PI Proxy interface
should be used.

481325269.doc 24.06.2020 Page 42 of 50

 Common Basic FC-System
Integration Architecture Design

3.2.6.3 Outbound – Master Data distribution

If master data messages have several receivers, then the message split will be done within PI. The
individual value mappings are done after the message split, individual for each receiver system.

3.2.6.4 Outbound – Value Mapping AIF

In the opposite of Master data, the transactional data has often one specific receiver. E.g Purchase
Requisition from cbFC to GLOBUS. For this case the receiver is fixed and already known in the cbFC.
Therefore the value mapping should be used within the AIF outbound process, to reduce the
complexity of monitoring and value mapping replication.

3.2.6.5 Outbound – Value Mapping PI

If there are multiple receiver for one message (as usually used for master data), or the receiver
determination is not part of the cbFC template, or an SAP standard IDoc is used for the outbound
message, then the value mapping should be performed within the PI.

Multiple Receiver for one Message:

- The GMT (cbFC template message type) for the outbound message has just one field to pass
the cbFC value. But multiple receivers require multiple values (a table instead of a single
value). This behavior could be avoided to map the fields within the PI instead of the cbFC AIF.

Receiver Determination is not Part of the cbFC:

- Typically Master Data is just provided by the cbFC, and the PI and/or the Hub defines the
rules and mappings for the receiver.

SAP standard IDocs are used:

- Standard IDocs will not pass the AIF. So the value mapping should be done within the PI
- The field lengths are fixed for standard IDocs. Legacy values often do not fit into the given
SAP length.

481325269.doc 24.06.2020 Page 43 of 50

 Common Basic FC-System
Integration Architecture Design

There is a separate document, which describes the usage and development of the Value Mapping
replication into the SAP PI server (DMS xxxx).

3.2.6.6 Outbound – ID Mapping

ID Mapping is the mapping between cbFC and the connected systems for the IDs of Master Data. E.g.
the IDs for Supplier, Customer or Material. There is an optional inbound interface available to import
those ID values from an external system (e.g. from an MDM system). ID Mapping are replicated to the
PI server, and could be used there for the outbound process. The usage has the same rules as for the
“Value Mapping PI”.

There is a separate document, which describes the usage and development of the ID Mapping
replication into the SAP PI server (DMS xxxx).

3.2.6.7 Outbound – Decision Matrix

Value Mapping location PI AIF

Standard SAP IDoc x
Multiple receiver x
Receiver determination not part of cbFC x
Single receiver known in cbFC and message passes AIF x

481325269.doc 24.06.2020 Page 44 of 50

 Common Basic FC-System
Integration Architecture Design

3.3 cbFC related Interface Configuration Guidelines

3.3.1 cbFC PI Landscape (SLD)
The cbFC landscape, including DTNA, will be build as 3-Tier landscape. The development landscape
is with the standard configuration not connected to any legacy system.

Default Inbound Interfaces

Optional Inbound Interfaces

481325269.doc 24.06.2020 Page 45 of 50

 Common Basic FC-System
Integration Architecture Design

For test purposes messages from the test legacy could be used. For some exceptional cases
production data should be used:

Default Outbound Interfaces

Optional Outbound Interfaces

481325269.doc 24.06.2020 Page 46 of 50

 Common Basic FC-System
Integration Architecture Design

3.4 cbFC related Technical Connection Guidelines

3.4.1 ERP Connection
The proxy connection should be divided into separate authorization groups. Each Software Namespace
of the Software Component CBFC_GLOBUS_SAP_APPL should use a separate http connection with a
different connection user.

3.4.2 Local system technical Connection

Local systems could be connected with the PI Server via the PI standard adapter engine. All available
connection types could be used. The choice depends on the feature of the local system. Additionally
following connection types are available:

MQS: There will be a separate MQS available to communicate with PI. PI should not communicate
directly with the MQS of the local system, only via this additional MQS.

Local System  local MQS ---(Server2Server) PI MQS ---(ClientConnection) PI

RFTS(x): RFTSx functionalities are available on the PI server to exchange files via RFTS.

481325269.doc 24.06.2020 Page 47 of 50

 Common Basic FC-System
Integration Architecture Design

4 Miscellaneous

4.1 Glossary
Term Description
ABAP SAPs Programming Language
ABAP Proxy A generate ABAP Object Class based on a
message interface which is defined in the
integration repository of SAP PI
AIF (Tool) Application Interface Framework (by SAP CD)
cbFC Common basic Finance Transformation
BO Short term for Business Objects
GDTs Global Data Types
SAP CD SAP Custom Development
SAP ERP SAP Enterprise Resource Planning
SAP PI SAP Process Integration
SLD System Landscape Directory

481325269.doc 24.06.2020 Page 48 of 50