RXP Consultants Make The Magic Happen


RXP had a pleasure to be a part of ‘Dream Team’ in 1-year integration project
at a global tobacco company as technology subcontractor. The project involved deployment of a cloud-based Coupa platform for the purposes of procurement processing.

RXP consultants were responsible for procure-to-pay process integration between Coupa and SAP – developing interfaces on SAP PI platform to enable automated document flow, adapting HTTP adapter to handle REST API connectivity, or ABAP programming SAP enhancements for specific customer needs in areas of SD, MM and FI. The tasks included technical documentation and advanced reporting.

Adapter Specific Message Attributes (ASMA) – dynamic configuration of communication channels

Basic function of SAP PI mappings is tu build target message content.Technical parameters, such as file name, path, target host address, are usually configured in Communication Channels.

Sometimes it is necessary to set these parameters dynamically – depending on the source data. For the most simple cases (such as changing target file name) one can use Variable Substitution method, but much more possibilities can be offered by ASMA (Adapter-Specific Message Attributes).

For the majority of PI adapters there is a set of Communication Channel attributes, that can be defined in PI message header using Dynamic Configuration objects. For particular attributes dynamic configuration with ASMA can be enabled in Advanced tab of Communication Channel details:

Adapter Specific Message Attributes (ASMA)

Adapter Specific Message Attributes (ASMA)

ASMA dynamic configuration in User Defined Functions (UDF) in Java

Message attributes in dynamic configuration can be set using UDF (User-Defined Functions). Every user-defined function includes Container-class object as a parameter. With its methods, one can get Dynamic Configuration object:

[codesyntax lang=”java”]

DynamicConfiguration conf = (DynamicConfiguration) container


The next step is to create key & value pairs for each object to be configured, keeping in mind a relevant namespace for the given Communication Channel type. Here are some sample attributes for selected Communication Channels:

File Adapter – namespace: http://sap.com/xi/XI/System/File

  • FileName
  • Directory
  • TargetTempFileName (if used)

Mail Adapter – namespace: http://sap.com/xi/XI/System/Mail

  • THeaderFROM – sender
  • THeaderTO – receiver
  • THeaderCC – carbon copy receiver (Cc)
  • THeaderBCC – blind carbon copy (Bcc) receiver
  • THeaderSUBJECT – e-mail subject

JMS Adapter – namespace: http://sap.com/xi/XI/System/JMS

  • DCJMSCorrelationID – Correlation ID
  • DCJMSMessageID – Message ID
  • DCJMSMessageQueue – Message Queue

HTTP Adapter – namespace: http://sap.com/xi/XI/System/HTTP

  • URL

Knowing key name and namespace, value is assigned to attribute key:

[codesyntax lang=”java”]

DynamicConfigurationKey key = DynamicConfigurationKey.create(


Finally, attribute key and value is to be assigned to dynamic configuration. In the below example, user-defined function sets target file name attribute based on an input parameter (filename) value:

Adapter Specific Message Attributes (ASMA)

Adapter Specific Message Attributes (ASMA)

Complete list of attributes, which can be configured dynamically for each Communication Channel, can be found on SAP Help portal: Using Adapter-Specific Message Attributes in the Message Header, selecting a specific Communication Channel type and proceeding to Define Adapter-Specific Message Attributes section.

Dynamic Configuration in XSLT mappings

An alternative to UDFs in Java to set Communication Channel attributes in Dynamic Configuration is to use XSLT mappings. The method is described in SAP Help: XSLT Mapping of Adapter-Specific Message Attributes.


Thanks to dynamic configuration access from message mapping level, wide range of programmable Communication Channel attributes is available. Potential applications are not limited to the following sample usages:

  • choosing target directory depending on plant, storage location number in SAP
  • placing order, invoice number or partner name in file name
  • setting e-mail recipient based on an address included in source message
  • setting e-mail subject depending on message content
  • dynamic URL creation for target HTTP service

User Defined Functions in SAP PI mappings

User Defined Functions (UDF) are functions defined by a programmer, which can be used in SAP PI graphical mappings. UDFs are defined in Java programming language and allow running any custom code on XML field mapping stage, significantly extending possibilities of message field and value mapping.

UDFs are represented by one block in graphical mappings. They can be utulised to simplify implementation of logic, that requires using multiple standard mapping blocks:


UDF can be created by clicking the icon in lower-left corner of graphical mapping editor window:


In the simplest caase it is enough to provide some basic data – function’s name and title, and its input arguments. Arguments’ value can be assigned in the same way as for standard mapping blocks – using arrows on function’s input and output:


The next step is implementation of function in Java programming language. Input and output are handled in the same fashion as other Java functions or methods – through arguments and return statement. The below screen shows a UDF function, that works in the same way that the graphical mapping above.


UDF Parameters

Configuration values can be assigned as UDF parameters. They will be passed to the function as arguments, too, but their values are defined in graphical mapping editor.



UDF Testing

After saving the function, it can be used in graphical mapping, connecting inputs and output. Similarly to standard mapping blocks, after running a test case, a queue of arguments and returned values can be viewed under Display Queue:


In the above example, UDF has been utilised to simplify value mapping implementation. Depending on needs, a programmer can use a variety of Java language features to implement more complex mappings, than standard mapping blocks allow.

Overview of new features in SAP Process Integration 7.31

Limitations of earlier version: SAP PI 7.11

  • Idoc and HTTP adapters are not available for Integrated Configuration
  • Multimapping (1:n) is not possible in ICO
  • Content based interface routing in ICO is not possible

New Advanced Adapter Engine connectivity options


  • Idoc packaging is possible (not for outbound)
  • Adapter modules can be added to Idoc configuration
  • ALEAUDIT is supported


  • New features: POST and Multipart document

SFTP adapter

  • add-on available from PI 7.11 SP08

Integrated configuration improvements

Multimapping possible in ICO

  • 1:n mappings
  • Content based selection of inbound interface

PI 7.31 ICO Multimapping

Monitoring tools

  • Idoc Message Monitor (it replaces IDX5)

PI 7.31 Idoc Monitor

  • Metadata Monitor

PI 7.31 Metadata Monitor

  • New message monitor

PI 7.31 Message Monitor


  • Ping option
    • Check connectivity
    • User/password
    • Authorizations (e.g. ftp access)
    • Connectivity (e.g. firewall settings)

PI 7.31 Ping 1


PI 7.31 Ping 2

User Defined Message Search

  • No need to use TREX
  • Usually used to search by key fields (Order Number, Partner ID)
  • A filter is defined per interface
  • Allows search by defined key that can be configured as:
    • Dynamic Header

      Dynamic Header
  • Indexing possible for messages processed prior to defining filter
  • Index is deleted when the message is archived



Inbound IDOC_AAE configuration in PI 7.31 single stack

1. Determining values for GatewayHost and GatewayService 

  • Log in to the SLD and choose Administration -> Settings tab Parameters and All from the drop-down menu:

SLD Gateway PI/PO 7.31 single stack

2. Creation of RFC connection to a SAP system, from which Idocs will be sent:

  • After logging in to SAP NetWeaver Administrator (NWA) go to Configuration -> Infrastructure -> Destinations

SAP NWA Destinations


  • Connection parameters:

Hosting System: Local Java System PID
Destination Type: RFC

SAP NWA Destinations step 1


In next steps please provide connection parameters to the SAP system and logon data:

SAP NWA Destinations step 2


To make sure that the connection works properly you may use an option Ping Destination. An expected test result is Successfully connected to system <PID> as user <user>

Ping destination

3. Creating a JCo connection (Java Connector)

  • In SAP NetWeaver Administrator (NWA) go to Configuration -> Infrastructure -> Jco RFC Provider

JCo RFC Provider


  • Use an option Create, parameters to be provided:

Gateway Host: as in step 1
Gateway Service: as in step 1

JCo step 1


  • In the next step enter the connection name from step 2, in our case XI_IDOC_DEFAULT_DESTINATION

JCo step 2


After saving, the newly created connection needs to be started (option Start), expected message is JCo servers started

4. Adding parameters for Resource Adapter inboundRA

  • In SAP NetWeaver Administrator (NWA) go to Configuration -> Infrastructure -> Application Resources and filter Resource List using *inboundRA*

Resource Adapter step 1

  • In Properties tab please fill parameters (or make sure that they are already entered):

GatewayServer – as in step 1.
ProgramID – as in step 3. – XI_IDOC_DEFAULT_PID
MaxReaderThreadCount – value between 5 and 10
DestinationName – as in step 2. – XI_IDOC_DEFAULT_DESTINATION
GatewayService – as in step 1. – sapgw01
Local – true
BindingKey – PI_AAE_IDOC

Resource Adapter step 2

  • After saving the application needs to be started: More Actions -> Start Applications and choose com.sap.aii.adapter.idoc.sapjra.inboundRA from the list:

Resource Adapter step 3

5. Creating a RFC destination in SAP system that will send Idocs to PI

  • In transaction SM59 create a new connection of type (T) TCP/IP Connection using parameters:

Activation Type: Registered Server Program
Program ID: as in step 3. – XI_IDOC_DEFAULT_PID
Gateway Host: as in step 1.
Gateway Service: as in step 1. – sapgw01

SM59 TCP/IP Connection


SM59 TCP/IP Connection


  • After connection test an expected message is:

SM59 RFC connection test


6. Creating sender communication channel in PI

  • In contrast with Idoc configuration for Integration Engine (ABAP) a communication channel of type Sender is required, it will be used in Integrated Configuration. 
  • Parameter RFC Server Parameters should be set to Default, in Ack Destination please enter a connection from step 2. – XI_IDOC_DEFAULT_DESTINATION

Idoc_AAE sender channel


After completing all steps above PI system is ready for configuration of inbound Idoc scenarios.

Materials available on help.sap.com and scn.sap.com have been used when creating this guide.

XSLT mapping to a flat file

In certain cases it is required to send an output mapping file as a flat file with specified field lengths. When the file adapter is used it is recommended to use standard File Content Conversion. However, in case of i.e. calling web service using SOAP adapter the best option is XSLT transformation. For the sample input file:

[codesyntax lang=”xml” lines=”normal”]



After using XSLT transformation that creates a new line for each occurrence of a <Line> element and sets field lengths to: 20, 20, 3, 20, 5, 5:

[codesyntax lang=”xml” lines=”normal”]

<?xml version="1.0" encoding="UTF-8"?>
<xsl:stylesheet xmlns:xsl="http://www.w3.org/1999/XSL/Transform" version="1.0">
   <xsl:output method="text" indent="yes" encoding="UTF-8" />
   <xsl:variable name="DocumentNumber">
      <xsl:call-template name="padRightSide">
         <xsl:with-param name="stringToPad" select="Order/Header/DocumentNumber" />
         <xsl:with-param name="totalLength" select="20" />
   <xsl:variable name="Date">
      <xsl:call-template name="padRightSide">
         <xsl:with-param name="stringToPad" select="Order/Header/Date" />
         <xsl:with-param name="totalLength" select="20" />
   <xsl:template match="/Order">
      <xsl:for-each select="Line">
         <!-- Repeat header data -->
         <xsl:copy-of select="$DocumentNumber" />
         <xsl:copy-of select="$Date" />
         <!-- Item data -->
         <xsl:call-template name="padRightSide">
            <xsl:with-param name="stringToPad" select="ItemNumber" />
            <xsl:with-param name="totalLength" select="3" />
         <xsl:call-template name="padRightSide">
            <xsl:with-param name="stringToPad" select="Material" />
            <xsl:with-param name="totalLength" select="20" />
         <xsl:call-template name="padRightSide">
            <xsl:with-param name="stringToPad" select="Quantity" />
            <xsl:with-param name="totalLength" select="5" />
         <xsl:call-template name="padRightSide">
            <xsl:with-param name="stringToPad" select="UOM" />
            <xsl:with-param name="totalLength" select="5" />
         <!-- End Line -->
         <xsl:text />
   <xsl:template name="padRightSide">
      <xsl:param name="totalLength" />
      <xsl:param name="padChar" select="' '" />
      <xsl:param name="stringToPad" />
      <xsl:param name="padBuffer" select="concat($padChar,$padChar,$padChar,$padChar,$padChar, $padChar,$padChar,$padChar,$padChar,$padChar )" />
      <xsl:variable name="vNewString" select="concat($stringToPad, $padBuffer)" />
         <xsl:when test="not(string-length($vNewString) &gt;= $totalLength)">
            <xsl:call-template name="padRightSide">
               <xsl:with-param name="stringToPad" select="$vNewString" />
               <xsl:with-param name="totalLength" select="$totalLength" />
               <xsl:with-param name="padChar" select="$padChar" />
               <xsl:with-param name="padBuffer" select="$padBuffer" />
            <xsl:variable name="output">
               <xsl:value-of disable-output-escaping="no" select="substring($vNewString,1,$totalLength)" />
            <xsl:value-of select="$output" />


we get:
001 20140401 1 1203040 10 PCE
001 20140401 2 2349040 20 PCE