1 16_xi_standards v2 0

8/3/2019 1 16_XI_Standards v2 0

1/20

SAP PI DEVELOPMENT STANDARDS

Version 1.0Release

date

Revision history

Version Date Description Contributor/Author

Review history

Version Date Reviewer comments Reviewed by

Approval history

Version Date Approver comments Approved by

Reference: 72868253.doc Page 1 of 20

8/3/2019 1 16_XI_Standards v2 0

2/20

SAP PI STANDARDS

Version 1.0Release

date

Contents

1. Introduction 31.1 Objectives of the PI Developer Standards and Guidelines Document 3

1.2 Document Structure 31.3 Intended Audience 31.4 References 3

2. PI Naming Standards & Guidelines 52.1 Purpose of Naming Standards 52.2 Scope of Standards 52.3 General Rules 52.4 Documentation and Description Standards 6

3. Enterprise Service Repository: 73.1 Namespace 8

3.2 Integration Scenario 83.3 Actions 83.4 Application Components 93.5 Integration Process / BPM 93.6 External Data Definitions (CDF) 93.7 Context objects: 103.8 Folder: 113.9 Data types: 113.10 Data type Enhancement: 113.11 Fault message types: 113.12 Message types: 123.13 Service Interfaces: 12

3.14 Message Mapping: 133.15 Mapping Templates: 133.16 User Defined Functions (Java) 133.17 Function Libraries 143.18 Operation Mapping 143.19 Value Mapping Context 153.20 Group Name 153.21 Imported Archive Development 16

4. Configuration Guidelines & Standards: 174.1 Business Scenarios 174.2 Party 17

4.3 Business System 184.4 Business Component 184.5 Process Component 184.6 Communication Channels 194.7 Value Mapping Group 20


8/3/2019 1 16_XI_Standards v2 0

3/20

SAP PI STANDARDS

Version 1.0Release

date

1. Introduction

This document defines the Integration PI Developer Standards and Guidelines for all PI development projectswithin its scope. The Standards and Guidelines document defines standards for naming and also providesdeveloper guidelines on the application of the standards in the form of a walkthrough of the developmentprocess for a single interface.

1.1 Objectives of the PI Developer Standards and Guidelines Document

The objectives of the Integration Framework Design are as follows:

Define PI naming standards for objects managed within the PI toolset

To provide advice to developers on how to implement PI interfaces

1.2 Document Structure

This document is structured as follows:

1. Introduction. This section describes the document objectives, scope and audience.2. PI Naming Standards. This section provides naming standards for objects within the PI toolset.3. Guidelines for use of Integration Builder: Design. Guidelines are provided for usage of the

Integration Builder: Design tool within the PI toolset.4. Guidelines for use of Integration Builder: Configuration. Guidelines are provided for usage of the

Integration Builder: Configuration tool within the PI toolset.5. Guidelines for Interface Development. Provides a walkthrough of the steps required to complete the

development of an interface, based on an example scenario.

1.3 Intended Audience

This document is intended for PI Configurations and Developers.

1.4 References

This document refers to the following external resources:


8/3/2019 1 16_XI_Standards v2 0

4/20

SAP PI STANDARDS

Version 1.0Release

date

Ref Document Name Location

[1] Sap Help PI.7.1 http://help.sap.com/saphelp_nwpi71/helpdata/en/e1/8e51341a06084de10000009b38f83b/frameset.htm

http://help.sap.com/saphelp_nwpi71/helpdata/en/e1/8e51341a06084de10000009b38f83b/frameset.htmhttp://help.sap.com/saphelp_nwpi71/helpdata/en/e1/8e51341a06084de10000009b38f83b/frameset.htmhttp://help.sap.com/saphelp_nwpi71/helpdata/en/e1/8e51341a06084de10000009b38f83b/frameset.htmhttp://help.sap.com/saphelp_nwpi71/helpdata/en/e1/8e51341a06084de10000009b38f83b/frameset.htm

8/3/2019 1 16_XI_Standards v2 0

5/20

SAP PI STANDARDS

Version 1.0Release

date

2. PI Naming Standards & Guidelines

2.1 Purpose of Naming Standards

The purpose of having a common approach to the creation and maintenance of development objects is to ensurethat a level of standardisation is achieved. This will provide common procedures and development methods thatfacilitate quality assured developments and can easily be transported across environments and systems.

The key objectives for these standards are to:

establish common standards for developments

provide standards and recommendations based on best practice

minimise costs in the development process

avoid duplication of development effort

create easily readable and maintainable developments

2.2 Scope of Standards

These standards shall be applied to all objects and developments within SAP PI system. The aspects of objectsand the development and maintenance of objects that this document considers are:

Documentation and Description Standards

System Landscape Directory Standard

Integration Repository Standards

Integration Directory Standards

2.3 General Rules

The name of the component must explicit and meaningful.

The name must start with a capital letter, (it should not start with a figure).

The name should be written in English so that it is globally understood.

The name should not comprise any space.

Special characters are prohibited: ? ' - # = ) ( . / \ ;

& @ ^ ! | } { ` > < % *: $ ] [ " + , ~

Separate individual words by switching between uppercase and lowercase characters

An "underscore" can be used to separate the various key words.


8/3/2019 1 16_XI_Standards v2 0

6/20

SAP PI STANDARDS

Version 1.0Release

date

If one or more words of the name of the component are acronyms, it is generally advised to putonly the first letter in capital letter.

The name of the component must reflect its role. It is necessary to avoid the generic names (Development for example).

Optional : It is advised to begin or end the name with the acronym of the component (ex:Software Component : SC_ , Message Interface: _MI)

2.4 Documentation and Description Standards

Standard:

For all components that are used within a scenario there is an input line Description. This line should containone sentence that describes the component.

For Business Scenario, Interface Mappings and Interface Archives there is an additional screenDocumentation for a more precisely description. For all component documentation there must be a uniqueheader, including the following information:


8/3/2019 1 16_XI_Standards v2 0

7/20

SAP PI STANDARDS

Version 1.0Release

date

3. Enterprise Service Repository:

Guidelines:

From SAP, the development of an interface (i.e. Scenario in PI terms) begins with its design. The IntegrationBuilder provides you with an environment with which you can describe Business Scenarios, interfaces andmappings independently of a system landscape.

To define the contents of a message and the communication type, create new message interfaces in theIntegration Repository or import existing interfaces from another system. If interfaces do already exist, you cansimultaneously design mappings and develop in the business systems.


Introduction

Short Text

Use

Notes

Structure

8/3/2019 1 16_XI_Standards v2 0

8/20

SAP PI STANDARDS

Version 1.0Release

date

To map the structure of a message to another message, use a message mapping. It is then possible to specify forwhich messages a mapping is required in two interfaces, by using an interface mapping

3.1 Namespace

Namespaces are used to identify objects within a software component version. Namespace is required for PIDesign / Development. All objects are developed within a namespace, and this namespace is no more than aunique identifier that ensures that name clashes do not occur between interfaces. Each interface is identified bya unique interface ID ex: SDO001 where SD is the functional area O signifies that the interface is outboundto SAP and 001 signifies the interface number. In order to have fine control over each interface duringtransports and maintenance a new namespace will be created for each interface under the software componentversion.

Standard:

Namespace: http://www..com/

Example:

Namespaces: http://www.XXX/SDO001 http://www.XXX/SDI001

As a general rule: Software component : Namespace = 1 : n A namespace is transferred to a new version of a software component after development isfinished (Release-Transfer)

3.2 Integration Scenario

The purpose of Integration Scenarios is to document the business process on a more abstract level. Theparticipants of an Integration Scenario are visualized by application components having a specific role withinthe process (e.g. Buyer, Seller). The interactions between these application components are defined within PI as"Actions.

Standard:

__

Example:

CTC_SD/Vendor_Maintenance

3.3 Actions

http://www.xxx/SDO001http://www.xxx/SDO001

8/3/2019 1 16_XI_Standards v2 0

9/20

SAP PI STANDARDS

Version 1.0Release

date

Standard:

_

Example:

Vendor_SendOrVendor_ReceiveOrVendor_Delete

3.4 Application Components

Name after the system that you are functionally developing.

3.5 Integration Process / BPM

Integration Process is an executable, cross-component process which is implemented by cross-componentBusiness Process Management (ccBPM). An Integration Process defines which messages are to be processedand how. How the messages are processed is determined by the choreography of different step types, containerelements and correlations:

Steps Types are: Receive, Receiver Determination, Send, Transform, Control, Fork, Wait, Loop,

Switch, Container Operation, Block, Undefined Container Elements: Each individual step of an integration process can either supply or demand data.

This data is managed in containers consisting of container elements (variables).

Correlations: Messages that belong together at runtime need to be correlated using correlations.

Integration process is integral part of PI running on business process engine. It designs execute and monitorsautomated process across applications.Standards: IP__

Each step can be given a meaningful name.

Container elements start with CO_

3.6 External Data Definitions (CDF)

Data structure definitions in form of WSDL, XSD or DTD can be imported into the Integration Repository andused like Message Types and Data Types.


8/3/2019 1 16_XI_Standards v2 0

10/20

SAP PI STANDARDS

Version 1.0Release

date

Standard:

The External Definition name will be: _XSD/DTD/WSDL

3.7 Context objects:

Context objects are used to represent a point a particular element in a structure or a name to XPATH expression.

Pointer to a specific element (field) within the message, for future reference .Encapsulate access to data that iscontained in the payload or in the header (technical context objects) of a message

Standards:CO_


8/3/2019 1 16_XI_Standards v2 0

11/20

SAP PI STANDARDS

Version 1.0Release

date

3.8 Folder:

Folders concept is similar to windows folders to group development objects into one location. This could be ascenario name or an Interface name.

Standards:F_

3.9 Data types:

Data types are the most basic entity to define the structure of XML elements. It is a basic unit for defining thestructure of the data for a message type. A data type can be created in a nested way by referencing data typesfrom a complex data type.

Standards:DT_

3.10 Data type Enhancement:

Data type enhancements are used to extent the most basic entity (Data Types) to define the structure of XMLelements. It is an extension to basic unit for defining the structure of the data for a message type. A data typecan be created in a nested way by referencing data types from a complex data type.

Standards:DTE_

3.11 Fault message types:

Used for error handling/ Synchronous processing of messages.

Standards:

FMT_


8/3/2019 1 16_XI_Standards v2 0

12/20

SAP PI STANDARDS

Version 1.0Release

date

3.12 Message types:

Guidelines:

The Message type corresponds to the root of the XML message. Name and namespace must match exactly theroot of XML Business documents. The Message type references one single data type XSD representationavailable for export that describes the structure of a message. It is assigned to one message interface and definedas the root element of the message. More than one message interface can use the same message type (e.g. if theinterfaces have a different mode or category).

Standards:

MT_

3.13 Service Interfaces:

A service interface is used to describe a platform-independent or programming-language-independent interface,which you want to use to exchange messages between application components within PI. If imported objects(RFC, IDocs) are used, no service interface needs to be created.

Guidelines:

The Service Interface is the highest-level representation of XML metadata.

Inbound or outbound (respective to the application), or abstract (for BPM only)

Synchronous or asynchronous

Asynchronous refers to one message type

Synchronous refers to two message types (request and response)

References fault message types for exception handling

WSDL representation available for export

Starting point for proxy generation (ABAP and Java)

Context objects can be assigned

Restrict the length for the name of Data Types, Message Types and Message Interfaces (especially forinterfaces where we are using proxy).

Standards:

SIIA_ : where SI-Service interface, I Inbound, A-Asynchronous.


8/3/2019 1 16_XI_Standards v2 0

13/20

SAP PI STANDARDS

Version 1.0Release

date

SIOS_ : where SI-Service interface, O Outbound, S-Synchronous.

SIAS_ : where SI-Service interface, A Abstract, A-Asynchronous.

Operation:

OP_ : where OP-Operation

3.14 Message Mapping:

Messages mapping are program that defines the mapping between two interfaces and messages. This programcan be implemented using graphical tool or by importing an archive (Java/XSLT).

Standard:

Sending External Definition /Message Type + _2_ + Receiving Message type/ External Definition

Example:

1. MT_VENDORORDERS_2_MT_PURORDERS

3.15 Mapping Templates:

Messages templates are program that defines the mapping between two data types. This program can beimplemented using graphical tool or by importing an archive (Java/XSLT).

Standard:

Sending Data Type + _2_ + Receiving Data type

Example:

1. DT_VENDORORDERS_2_DT_PURORDERS

3.16 User Defined Functions (Java)


8/3/2019 1 16_XI_Standards v2 0

14/20

SAP PI STANDARDS

Version 1.0Release

date

User defined functions are the java source code in graphical mapping to manipulate the source data. When thestandard functions in graphical mapping are not sufficient to convert the input data to the required target data,we have to use Java user defined functions.

Standard:

Give self explanatory name to the java function with proper description, and source code must be wellcommented.

Example:

AddLeadingZero This function adds leading zeros to the input data.

3.17 Function Libraries

Function libraries store user defined functions independent of specific message mappings, and one can use thefunctions in multiple message mappings. User functions are the java source code in graphical mapping tomanipulate the source data. When the standard functions in graphical mapping are not sufficient to convert theinput data to the required target data, we have to use Java user defined functions

FL_

Eg:

FL_Addressfunctions : This function library has a few user defined java functions that are useful formanipulating address fields.

3.18 Operation Mapping

Operation mapping are program that defines the mapping between two interfaces and messages. This programcan be implemented using graphical tool or by importing an archive (Java/XSLT). When defining mappingprograms for request, response, or fault messages, the definition is first separated (or abstracted) from theinterfaces that reference the corresponding message types. This enables you to reuse a message type formultiple interfaces.

This role is undertaken by the operation mapping:

An operation mapping specifies the corresponding mapping programs for request, response, or faultmessages for a selected interface pair. You use an interface mapping to register mappings for aninterface pair.

You can also specify multiple mapping programs to be executed one after the other in the case ofrequests and responses for an interface mapping.


8/3/2019 1 16_XI_Standards v2 0

15/20

SAP PI STANDARDS

Version 1.0Release

date

You can also define multiple operation mappings for the same interface pair, to provide multiple variants in therepository.

Standard:

Naming standard for Interface Mappings: OM_< InterfceID>

Example:

OM_MATMASOM_DEBMAS

***************************Comments***************************

The suggestion is to keep the naming convention of message mapping and

Operation mapping same because it will be more representative.

***************************Comments***************************

3.19 Value Mapping Context

3.19.1.1AgencyA functional Name representing the system

Standard:

_

Example:LEG_mainframeLEG_oracle

3.19.1.2Schema

A functional Name representing the source set of data

Standard:

Example:ACLPAY.ACLPAY01MIOut_Vendor

3.20 Group Name

The Field Name that the data is being mapped TO.


8/3/2019 1 16_XI_Standards v2 0

16/20

SAP PI STANDARDS

Version 1.0Release

date

Standard:

-

Example:ZPLBAL1-ZCSIMIOut_Vendor-CSINumber

3.21 Imported Archive Development

There are a number of types of mapping programs available, including Graphical Mapping, XSLT, Java andABAP. XSLT, Java and ABAP mapping programs should be developed outside the PI environment andimported as archives. The standard mapping approach is to use Graphical Mapping, but in exceptionalcircumstances, the following standards for imported archives should be observed.

Standard:

XSLT and Java mappings are to be held separately in archives (since this improves systemperformance when searching for programs).

Archive Name: ZIP (XSL) and JAR (Java) File name should same name as theBusiness Scenario.

File Name: Archives contain files XSL or Java.__.xsl

__.cls

Action can be :

Filter reduce the segments that are to be sent to the receiver. Sender andreceiver have the same structure.

Map map different structures.

Example: Filter_E1MAKTM_excludePLandEN.xsl

NameSpace: See the section earlier on Namespace Definitions.


8/3/2019 1 16_XI_Standards v2 0

17/20

SAP PI STANDARDS

Version 1.0Release

date

4. Configuration Guidelines & Standards:

You use the Integration Builder to configure business processes that are based on the cross-componentexchange of messages. You can reproduce the choreography of the messagesthat you have defined in aBusiness Scenario in a system landscape and define the message flow between the participating businesssystems.

This enables you to gather together all the information in the Integration Directory that is required to process

messages a runtime.

4.1 Business Scenarios

Configuration is grouped by Business Scenario. This Business Scenario describes all facets of the integrationpoint Send, receiver, End Point, Mapping, routing, Logon Data. In the case of the IDOC Adapter, only onething is able to be defined manually the Business Scenario Name.

Standard:

The following standard applies to Business Scenario Names

Business Scenario : _

Example:

RECEIVE_ORDER_IDES_ECC1_001

For each scenario, multiple interfaces or messages - will exist.

4.2 Party

Parties represent business partner connections, and are normally created for scenarios where a service bindingto a particular business partner is required.

Party names come in two formats 1 party for the entire company, or separate parties for separate businessunits. The use of registered Internet domain names is mandated for defining Party names whenever possible.The domain and optional business unit should be in upper camel case; the domain suffix in lower case.

All business parties, partners for B2B or EDI communication will use the domain name approach:

_-or-__


8/3/2019 1 16_XI_Standards v2 0

18/20

SAP PI STANDARDS

Version 1.0Release

date

Examples:

Walmart_com_EastBUSherwin-Williams_com

4.3 Business System

Business systems are always imported from the SLD. Only those systems that are needed for an integrationscenario should be imported; the entire list of available business systems should not be imported in order tokeep navigation in the Directory reasonable.

Business systems in QA, Production, and other environments on the transport path will automatically beimported in the Directory when the corresponding Business System objects from the lesser environment aretransported to that system. If a Development business system shows up in the QA PI system, please fix thetransport path for that business system in the SLD.

Business systems for external business partners will not be maintained in the SLD; these should be defined asBusiness Services under the respective Party.

If internal SAP system

Sys__< ColloquialName >_

Eg:

Sys_D_SR5 _100, Sys_X_SI5_100

4.4 Business Component

Business component are defined to expose interfaces without binding them tightly to a particular sender.Business component should be named according to SAPs standard, in upper camel case.

BusComp_

Examples:

BusComp _OrderCreate Service to create an order (Commit to process a Purchase Order)

4.5 Process Component

Integration process services represent a runtime container for a ccBPM process to allow reuse of the sameccBPM process map in multiple scenarios. They should be named according to SAPs naming convention, withthe addition of a grouping by functional area. Normally, the process name will be the same as the ccBPMdevelopment in the Integration Repository.

Prc__


8/3/2019 1 16_XI_Standards v2 0

19/20

SAP PI STANDARDS

Version 1.0Release

date

Examples:

Prc_OrderCreateServicePrc_B2BGateway_OrderCreate

4.6 Communication Channels

Communication channels represent a technical point of access to a system. They are defined at configurationtime to specify the technical call information for the business systems implemented in the system landscape.This information is located in the Integration Directory and is used at runtime to map logical receivers (businesssystems) to physical addresses during technical routing.

Standard:

Business System: CC___

Example: CC_SEND_IDES_IDOC

************************Comment **************************

The naming convention can be:

Standard:__

Example:BusComp_FileServcie_HRPayroll_JDBCSender

The advantage with this naming convention is that it clearly depict to which service & message type thischannel belongs to.

In case of IDoc and RFC adapter, communication channel naming convention can be

Standard:

_< Sender | Receiver >

Example:

Sys_D_SR5_100_IDocReceiver

The advantage with this naming convention is that we can have a single IDoc/RFC Communication channelpointing to ECC system for all IDoc types.

************************Comment ***************************


8/3/2019 1 16_XI_Standards v2 0

20/20

SAP PI STANDARDS

Version 1.0Release

date

4.7 Value Mapping Group

Value mapping entries allow configuration for 1:1 and N:1 mappings. N:1 mappings are managed by assigningmultiple source records and a single target record to a single Value Mapping Group in the Integration

Directory.

Groups should be named according to the - format specified in SAPs conventions,where EDM stands for Enterprise Data Model and is a logical data model maintained by an informationarchitecture group (often tied to Master Data Management or Data Warehousing efforts). Valid EDM entitiesshould be defined by the EDM modeling group. A value mapping group should be defined for all value mappingrecords.

Examples:

Company _COMCountryCode USCountryCode CA

Value Mapping Records

If the records are owned by The System members:

The Agency will be the name of the business system as configured in the SLD, or of theorganizational unit that owns responsibility for that entity. In the case of cross-reference tables,the use of the business system name is strongly preferred. This allows the sender system tobe used to dynamically determine the appropriate lookup from the mapping APIs.

If the records are owned by a third party:

The Agency will be the name of the Party as configured (or as it would be configured) in theIntegration Directory.

1 16_xi_standards v2 0

Documents