Konsultanci RXP i moc integracji

SAP & Coupa

RXP miało przyjemność być częścią „zespołu marzeń” w rocznym projekcie integracyjnym dla globalnej firmy tytoniowej jako podwykonawca technologiczny. Projekt obejmował uruchomienie opartej na chmurze platformy Coupa do celów obługi procesów zaopatrzenia.

Konsultanci RXP byli odpowiedzialni za integrację procesów procure-to-pay między platformą Coupa a SAP – budowali interfejsy w SAP PI umożliwiając automatyczny przepływ dokumentów, zmodyfikowali adapter HTTP na potrzeby połączenia z REST API, dla specyficznych wymagań klienta programowali rozszerzenia SAP w języku ABAP w obszarach SD, MM i FI. Zadania obejmowały również przygotowanie dokumentacji technicznej i budowę zaawansowanych raportów.

RXP Consultants Make The Magic Happen

SAP & Coupa

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
 .getTransformationParameters()
 .get(StreamTransformationConstants.DYNAMIC_CONFIGURATION);

[/codesyntax]

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(
 “http://sap.com/xi/XI/System/File”,
 “FileName”);

[/codesyntax]

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.

Applications

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

Adapter Specific Message Attributes (ASMA) – dynamiczna konfiguracja parametrów kanałów komunikacji

Podstawową funkcją mapowań w SAP PI jest budowanie zawartości docelowego komunikatu w oparciu o dane zawarte w komunikacie źródłowym. Parametry techniczne, takie jak np. nazwa pliku, ścieżka, adres serwera, konfiguruje się zwykle w kanale komunikacji.

Czasem jednak zachodzi potrzeba dynamicznego ustawienia tych parametrów w mapowaniu – również w zależności od przesyłanych danych. Dla najprostszych przypadków (jak zmiana nazwy docelowego pliku), można skorzystać z mechanizmu Variable Substitution, jednak o wiele większe możliwości daje funkcja ASMA (Adapter-Specific Message Attributes).

Dla większości adapterów istnieje zestaw atrybutów kanału komunikacji, który można zdefiniować w nagłówku komunikatu PI korzystając z obiektów konfiguracji dynamicznej (Dynamic Configuration). Dla poszczególnych atrybutów można włączyć konfigurację dynamiczną z ASMA w zakładce Advanced ustawień kanału komunikacji:

Adapter Specific Message Attributes (ASMA)

Adapter Specific Message Attributes (ASMA)

Konfiguracja dynamiczna ASMA w funkcjach użytkownika Java (UDF)

Atrybuty komunikatu w konfiguracji dynamicznej można ustawić za pomocą własnych funkcji użytkownika – UDF (User-Defined Functions). Każda definiowana przez użytkownika funkcja standardowo otrzymuje obiekt Container. Za pomocą jego metod, można pobrać obiekt konfiguracji dynamicznej:

[codesyntax lang=”java”]

DynamicConfiguration conf = (DynamicConfiguration) container
 .getTransformationParameters()
 .get(StreamTransformationConstants.DYNAMIC_CONFIGURATION);

[/codesyntax]

Kolejnym krokiem jest utworzenie par klucz – wartość dla każdego konfigurowanego atrybutu. Należy przy tym pamiętać o przestrzeni nazw właściwej dla danego typu kanału komunikacji. Przykładowe atrybuty dostępne dla wybranych kanałów komunikacji:


 

File Adapter (pliki) – przestrzeń nazw: http://sap.com/xi/XI/System/File

  • FileName – nazwa pliku
  • Directory – katalog
  • TargetTempFileName – nazwa tymczasowego pliku (jeśli jest używany)

 

Mail Adapter (e-mail) – przestrzeń nazw: http://sap.com/xi/XI/System/Mail

  • THeaderFROM – nadawca
  • THeaderTO – odbiorca
  • THeaderCC – odbiorca kopii (DW)
  • THeaderBCC – odbiorca ukrytej kopii (UDW)
  • THeaderSUBJECT – tytuł e-maila

 

JMS Adapter – przestrzeń nazw: http://sap.com/xi/XI/System/JMS

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

HTTP Adapter – przestrzeń nazw: http://sap.com/xi/XI/System/HTTP

  • URL

Znając nazwę klucza i przestrzeń nazw, klucz tworzymy następującą metodą:

[codesyntax lang=”java”]

DynamicConfigurationKey key = DynamicConfigurationKey.create(
 “http://sap.com/xi/XI/System/File”,
 “FileName”);

[/codesyntax]

Pozostaje przypisanie pary klucz – wartość do konfiguracji dynamicznej. W poniższym przykładzie funkcja UDF ustawia atrybut – nazwę pliku – w oparciu o wejściowy ciąg znaków (parametr filename):

Adapter Specific Message Attributes (ASMA)

Adapter Specific Message Attributes (ASMA)

Listę atrybutów, jakie można ustawić dynamicznie dla danego kanału komunikacji, można znaleźć na stronie Using Adapter-Specific Message Attributes in the Message Header, przechodząc do interesującego nas typu kanału komunikacji, w sekcji Define Adapter-Specific Message Attributes.

Konfiguracja dynamiczna w mapowaniach XSLT

Alternatywą dla funkcji Java (UDF) w celu ustawienia atrubutów kanału komunikacji w konfiguracji dynamicznej, są mapowania XSLT. Mechanizm ten jest opisany w pomocy SAP na stronie XSLT Mapping of Adapter-Specific Message Attributes.

Zastosowanie

Dzięki temu, że konfiguracja dynamiczna jest dostępna z poziomu mapowania, otwierają się szerokie możliwości programowego ustawienia atrybutów kanału komunikacji. Możliwe zastosowania nie ograniczają się do przykładów:

  • ustawienie docelowego katalogu w zależności od numeru zakładu, składu SAP
  • wpisanie numeru zamówienia, faktury lub klienta w nazwie pliku
  • ustawienie odbiorcy e-maila wg adresu w komunikacie źródłowym
  • ustawienie tematu e-maila w zależności od zawartości komunikatu
  • dynamiczna budowa URL docelowej usługi HTTP

User Defined Functions – własne funkcje w mapowaniach SAP PI

User Defined Functions (UDF) to funkcje zdefiniowane przez programistę, które mogą być wykorzystywane w mapowaniach graficznych SAP PI. Funkcje te definiowane są w języku Java i umożliwiają uruchomienie dowolnego kodu na etapie mapowania pól komunikatów XML, znacznie rozszerzając zakres operacji, jakie można wykonać na polach i wartościach komunikatu.

W mapowaniach graficznych UDF reprezentowane są przez jeden blok. Dzięki im wykorzystaniu, można przykładowo uprościć realizację stosunkowo prostej logiki, której implementacja wymagałaby użycia dużej liczby standardowych bloków:

udf-01

UDF tworzy się przez kliknięcie w ikonę czystej kartki w lewym dolnym rogu edytora mapowań graficznych:

udf-02

W najprostszym wariancie wystarczy uzupełnić podstawowe dane – nazwę i etykietę funkcji, oraz nazwę argumentów wejściowych. Wartość argumentów będzie można przypisywać podobnie jak w przypadku standardowych bloków mapowania graficznego – za pomocą strzałek na wejściu i wyjściu funkcji:

udf-02a

Kolejnym krokiem jest implementacja funkcji w języku Java. Wejście i wyjście jest realizowane jak w innych funkcjach / metodach Java – poprzez argumenty i polecenie return. Na poniższej ilustracji znajduje się definicja UDF o takim samym działaniu jak na przykładzie mapowania graficznego powyżej.

udf-03

Parametry UDF

Wartości konfiguracyjne można określić jako parametry UDF. Będą również przekazywane do funkcji jak argumenty, lecz ich wartość przypisuje się na poziomie mapowania graficznego.

udf-04

udf-05

Testowanie UDF

Po zapisaniu funkcji, można jej użyć w mapowaniu graficznym, podłączając wejścia i wyjście. Podobnie jak w przypadku standardowych bloków, po uruchomieniu testu można prześledzić listę podawanych i zwracanych przez UDF wartości za pomocą funkcji Display Queue:

udf-06

W powyższym przykładzie UDF została wykorzystana do uproszczenia implementacji mapowania. W zależności od potrzeb, programista może wykorzystać szereg możliwości języka Java, które pozwolą na implementację bardziej złożonych mapowań, niż pozwalają na to standardowe bloki mapowania graficznego.

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-01

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

udf-02

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:

udf-02a

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-03

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-04

udf-05

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:

udf-06

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.

Przegląd nowych funkcji w SAP Process Integration 7.31

Ograniczenia wcześniejszych wersji: SAP PI 7.11

  • Adaptery Idoc oraz HTTP nie są dostępne dla Integrated Configuration
  • Mapowanie jednego komunikatu do wielu (1:n) nie jest możliwe w ICO
  • Reguły routingu na podstawie zawartości komunikatu nie mogą być użyte w ICO

Nowe mozliwości połączeń dla Advanced Adapter Engine

IDOC_AAE

  • Przesyłanie wielu Idoców jednocześnie (Idoc packaging), ale nie dla interfejsów wychodzących
  • Moduły adaptera mogą być dodane dla konfiguracji dla Idoców
  • Wsparcie dla ALEAUDIT

HTTP_AAE

  • Nowe funkcje: POST and Multipart document

SFTP adapter

  • dodatek dostępny od wersji PI 7.11 SP08

Ulepszenia dla Integrated Configuration

Mapowanie jeden do wielu możliwe w ICO

  • mapowanie 1:n
  • Reguły routingu na podstawie zawartości komunikatu przychodzącego

PI 7.31 ICO Multimapping

Narzędzia do monitorowania 

  • Monitoring komunikatów Idoc (zastępuje transakcję IDX5)

PI 7.31 Idoc Monitor

  • Monitoring metadanych

PI 7.31 Metadata Monitor

  • Nowy monitoring komunikatów

PI 7.31 Message Monitor

 

  • Opcja ‚Ping’ dla kanału komunikacyjnego
    • Sprawdzenie połączenia
    • Użytkownik/hasło
    • Uprawnienia (np. dostęp do FTP)
    • Ustawienia zapory sieciowej

PI 7.31 Ping 1

 

PI 7.31 Ping 2

Wyszukiwanie komunikatów po zawartości

  • Nie ma potrzeby użycia TREX
  • Zazwyczaj używane do przeszukiwania po polach kluczowych (Numer zamówienia, Numer partnera)
  • Osobne filtry definiowane dla poszczególnych interfejsów
  • Pozwala na przeszukiwanie dla klucza zdefiniowanego jako:
    • XPATH

      XPATH

    • Dynamic Header

      Dynamic Header

  • Indeksowanie jest możliwe dla komunikatów przetworzonych przed zdefiniowaniem filtra
  • Indeks jest usuwany kiedy komunikat jest zarchiwizowany

 

 

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_AAE

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

HTTP_AAE

  • 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:
    • XPATHXPATH 
    • 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 Name: XI_IDOC_DEFAULT_DESTINATION
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:

Program ID: XI_IDOC_DEFAULT_PID
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.

Konfiguracja połączenia IDOC_AAE dla PI 7.31 single stack

1. Ustalenie danych dla GatewayHostGatewayService 

  • Nalezy zalogować się do SLD i wybrać Administration -> Settings zakładka Parameters i tam z rozwijanej listy All:

SLD Gateway PI/PO 7.31 single stack

2. Utworzenie połączeń RFC do systemu SAP, z którego będą wysyłane Idoci

  • Po zalogowaniu się do SAP NetWeaver Administrator (NWA) należy przejść do Configuration -> Infrastructure -> Destinations

SAP NWA Destinations

 

  • Parametry połączenia:

Hosting System: Local Java System PID
Destination Name: XI_IDOC_DEFAULT_DESTINATION
Destination Type: RFC

SAP NWA Destinations step 1

 

W kolejnych krokach należy podać parametry połączenia do systemu SAP oraz dane logowania:

SAP NWA Destinations step 2

 

Aby upewnić się, że połączenie działa prawidłowo można skorzystać z opcji Ping Destination. Test powinien zakończyć się komunikatem Successfully connected to system <PID> as user <user>

Ping destination

3. Utworzenie połączenia JCo (Java Connector)

  • Po zalogowaniu się do SAP NetWeaver Administrator (NWA) należy przejść do Configuration -> Infrastructure -> Jco RFC Provider

JCo RFC Provider

 

  • Należy utworzyć nowe połączenie korzystając z opcji Create, parametry w pierwszym kroku:

Program ID: XI_IDOC_DEFAULT_PID
Gateway Host: z punktu 1
Gateway Service: z punktu 1

JCo step 1

 

  • W kolejnym kroku należy podać nazwę połączenia z punktu 2., w tym przypadku XI_IDOC_DEFAULT_DESTINATION

JCo step 2

 

Po zapisaniu należy uruchomić połączenie korzystając z opcji Start, prawidłowy komunikat to JCo servers started

4. Wprowadzenie parametrów dla Resource Adapter inboundRA

  • Po zalogowaniu się do SAP NetWeaver Administrator (NWA) należy przejść do Configuration -> Infrastructure -> Application Resources i przefiltrować listę zasobów po *inboundRA*

Resource Adapter step 1

  • W zakładce Properties należy wprowadzić następujące wartości lub upewnić się, że takie są tam już obecne:

GatewayServer – tak jak w punkcie 1.
ProgramID – tak jak w punkcie 3. – XI_IDOC_DEFAULT_PID
MaxReaderThreadCount – wartość pomiędzy 5 a 10
DestinationName – tak jak w punkcie 2. – XI_IDOC_DEFAULT_DESTINATION
GatewayService – tak jak w punkcie 1. – sapgw01
Local – true
BindingKey – PI_AAE_IDOC

Resource Adapter step 2

  • Po zapisaniu parametrów należy uruchomić aplikację: More Actions -> Start Applications i wybrać z listy com.sap.aii.adapter.idoc.sapjra.inboundRA

Resource Adapter step 3

5. Utworzenie połączenia RFC w systemie SAP wysyłającym Idoci do PI

  • W transakcji SM59 należy utworzyć nowe połączenie typu (T) TCP/IP Connection używając parametrów:

Activation Type: Registered Server Program
Program ID: tak jak w punkcie 3. – XI_IDOC_DEFAULT_PID
Gateway Host: tak jak w punkcie 1.
Gateway Service: tak jak w punkcie 1. – sapgw01

SM59 TCP/IP Connection

 

SM59 TCP/IP Connection

 

  • Po przetestowaniu połączenia powinien się pojawić komunikat:

SM59 RFC connection test

 

6. Utworzenie kanału komunikacyjnego na PI

  • W odróżnieniu do konfiguracji Idoc dla Integration Engine (ABAP) wymagany jest kanał komunikacyjny typu Sender, który będzie użyty w Integrated Configuration. 
  •  Parametr RFC Server Parameters należy ustawić na Default, a w Ack Destination podać połączenie z punktu 2. – XI_IDOC_DEFAULT_DESTINATION

Idoc_AAE sender channel

 

Po wykonaniu powyższych kroków system PI jest przygotowany na konfigurację scenariuszy dla Idoców przychodzących.

W trakcie tworzenia poradnika wykorzystane zostały informacje dostępne na stronach help.sap.com oraz scn.sap.com