SAP PI: IDoc Adapter Packaging

Vor PI 7.1 EHP 1 wurden BPM oder Workarounds verwendet, um IDocs als Paket zu sammeln. Seit PI 7.1 EHP 1 hat SAP ein neues Feature namens IDoc Paketverarbeitung eingeführt: Anstatt jedes IDoc sofort zu versenden, können diese in dem Absender-System gesammelt und dann als Paket an SAP NetWeaver PI gesendet werden. Nur ein RFC Anruf ist erforderlich, um mehrere IDocs zu übertragen, was die Performance wesentlich verbessert.

Durch die Verarbeitung mehrerer Nachrichten in einem Paket, kann der Overhead pro Nachricht reduziert werden. Dadurch werden weniger Hardware-Ressourcen verbraucht und ein erhöhter Nachrichten-Durchsatz wird erreicht.

Allerdings kann man hier die Paketgrösse nicht beliebig erhöhen, da die Grösse der resultierenden Nachrichten einen Einfluß auf die Performance hat (siehe hierzu: Mastering SAP NetWeaver PI Throughput with Message Packaging).

Die IDoc Paketgröße sollte so gewählt werden, dass eine optimale Nachrichtengröße zwischen einem und fünf MB erzielt wird. Dies hängt von der üblichen Anzahl der Segmente pro IDoc ab und kann bei verschiedenen IDoc Typen unterschiedlich sein.

Um eine optimale Nachrichtengröße zu erzielen, kann es sinnvoll sein, mehrere IDoc Sender Kanäle mit unterschiedlichen Paketgrößen anzulegen und diese je nach Szenario in der Sender Vereinbarung zu verwenden.

Im sendenden ABAP System im Partnerprofil (WE20) für den entsprechenden Nachrichtentyp:
Output Mode: Collect IDocs
Pack. Size: z.B. 25

Zum Übertragen der gesammelten IDocs muss der Report RSEOUT00 periodisch eingeplant werden (SM36)!

Üblicherweise, zumindest bis PI 7.11, muss kein Sender-Agreement für den IDoc- und den HTTP-Adapter angelegt werden. Bei Verwendung von Packaging im IDoc-Adapter muss man allerdings im PI ein Sender Agreement mit IDoc Sender Channel einrichten. Zusätzlich muss im korrespondierenden IDoc Channel IDoc Packaging aktivieren sein und unter IDoc Package Size der gleichen Wert wie auf dem ABAP System (z.B. 25) angeben.

Im Message und Operation Mapping muss Occurence nicht auf unbounded gesetzt werden, sondern kann auf 1 bleiben! In der Zielnachricht des Message Mapping muss man aber berücksichtigen, dass mehrere IDocs in einer Nachricht ankommen können.

(siehe auch: Link)

Für jedes IDoc Paket wird im ABAP System für die Übertragung eine eindeutige Transaktionsnummer vergeben. Im PI System wird für jedes Paket eine Message ID vergeben. Ist die Paketgrösse in der Partnervereinbarung des ABAP Systems grösser gewählt als im IDOC Sender Adapter des PI, dann bleibt die Transaktionsnummer für die ABAP Paketgrösse gleich und die Message ID im PI für die IDOC Sender Adapter Paketgrösse. Es gibt dann pro ABAP Paket mehrere PI Pakete, d.h. es findet ein Message-Split im PI statt. Ist die Paketgrösse im ABAP System kleiner als im PI, dann wird die Transaktionsnummer und Message ID von der Paketgrösse im ABAP System bestimmt.

Achtung:
Bei der Verwendung der konditionsabhängigen Empfänger Ermittlung gibt es bei IDoc Paketen folgende Besonderheit. Wenn die eingegebene Bedingung bei einem der IDocs innerhalb eines Paketes erfüllt ist, wird das gesamte IDoc Paket weiter geleitet und nicht nur die Nachrichten, für die die Bedingung erfüllt ist.

Dies bedeutet, wenn die Konditionsabhängige Empfänger / Interface Ermittlung eingesetzt wird, muss das Message Mapping die Konditionsabfrage erneut durchführen und nur die IDocs in die Zielstruktur übernehmen, bei denen die Bedingungen erfüllt sind.

 

 

SAP PI: IDoc Adapter Troubleshooting

Beispielszenario:
Nachrichten, die aus einem ERP System an PI versendet werden, kommen nicht an.

Ein IDoc durchläuft mehrere Stati, bis es an den Port (WE21), welcher individuell für jedes eingehende oder ausgehende IDoc im Partner-Profil (WE20) festgelegt wird, weitergeleitet wird. IDocs, die den Status „An Port gesendet“ besitzen, befinden sich auf dem Weg zum Zielsystem.

(siehe auch: SAP Help)

Auf dem ERP System kann man sich mit den Transaktionen WE02/WE05 zunächst anschauen, ob die IDocs an das Port weitergeleitet wurden. Wenn keine direkte Verbuchung der IDocs stattfindet, befinden sie sich nicht im Status 03. Mit der Transaktion BD87 kann man das überprüfen.

Nachdem die IDocs direkt oder indirekt (BD87) verbucht sind, werden sie an den im Partner-Profil bestimmten Port weitergeleitet. Die erzeugten IDocs werden abhängig vom Ausgabemodus entweder gesammelt oder sofort zum Versand weitergeleitet. Das geschieht im Partner Profile. Wenn die IDocs gesammelt werden, muß der Report RSEOUT00 eingeplant werden, der dann die Weiterleitung zum Versand übernimmt. Der Report kann mit SE38 direkt oder mit SM36 als Hintergrundjob definiert werden (Monitoring mit SM37).

Sind die IDocs schliesslich im Status 03 und treten hier Probleme auf, kann man das mit der SM58 oder SE16 (Tabelle ARFCSSTATE) feststellen.

Auf dem PI System wird mit der Transaktion SM21 das Systemlog angezeigt. Probleme mit dem IDoc Adapter werden auch hier angezeigt:

Mit der Transaktion IDX5 kann man ein bestimmtes IDoc finden. Wenn man auf dem ERP System die Transaktion WE02/WE05 aufruft, ein bestimmtes IDoc auswählt, das Status-Rekord 03 wählt und im Reiter „Statusdetail“ die Transaktionsnummer kopiert, kann man auf dem PI System mit IDX diese Transaktionsnummer eingeben und erhält das entsprechende IDoc im PI System.

(siehe auch: http://www.youtube.com/user/MasteringPI#p/a/f/0/GFOcSlcDmJQ)

Für den umgekehrten Weg (PI > ERP) gibt es auch eine Möglichkeit das IDoc zu finden. Selektieren Sie im ERP das IDoc, wählen Sie das Control Record, selektieren Sie den Reiter „Details“ und unter

Identifizierung kopieren Sie den Hex-String (ohne die ersten beiden Stellen).Wechseln Sie im PI auf SXI_MONITOR und geben Sie als Message ID den kopierten Wert ein.

Beim Senden von Massen-IDocs kann der Fehler auftreten: „Überlauf der Sperrtabelle“. Mit der Transaktion SM12 ruft man die Sperrverwaltung auf. Zur Lösung des Problems kann man eigentlich nur den entsprechenden Profil-Parameter ändern und das System neu starten.

(siehe auch: SAP Help)

 

SAP PI: Transport von XI-Objekten mit CTS+

Ab SAP NetWeaver 7.0 SPS12 können Sie XI-Objekte über CTS+ transportieren. CTS+ ist eine erweiterte Version des Change and Transport System des SAP NetWeaver Application Server – ABAP. Weitere Informationen finden Sie im SAP Developer Network im HowTo-Guide How to transport repository content and directory content using CTS+ unter der Adresse http://www.sdn.sap.com/irj/sdn/howtoguides  ® SAP NetWeaver 7.0  ® End-to-End Process Integration (SDN-User erforderlich).

CTS+ (Enhanced Change and Transport System) ermöglicht kombinierte Transportaufträge von ABAP- und Java-Objekten und die zentrale Verwaltung aller Transporte in einer GUI. Es ist die Erweiterung des ABAP CTS (Change and Transport System) um Non-ABAP-Objekte.

Da SAP PI bis zur Version 7.11 (7.1 EHP1) zwingend einen ABAP- und einen Java-Stack voraussetzt, spielt CTS+ für kombinierte Transporte von ABAP- und Java-Objekten eine besondere Rolle.

Vor CTS+ konnte man als Transportsystem für die Java Objekte das sog. CMS (Change Management Service) einsetzen, mit dem Nachteil, dass es ausschließlich auf Java-Objekte beschränkt war.

Im Zusammenhang mit SAP PI/XI lassen sich drei Arten von Transporten identifizieren:

• ABAP Transporte
• ESB (Enterprise Service Builder) Transporte
• ID (Integration Directory) Transporte

Im Dokument „Transporte“ habe ich alles was ich zu diesem Thema gefunden habe, zusammengefasst.

 

SAP PI AAE: ABAP (Provider) Proxy auf SOAP umstellen

Motivation

Ein Provider Proxy stellt einen Service zur Verfügung (SAP PI > SAP ABAP Proxy). Alle Inbound Service Interfaces, die in PI erstellt werden, können über die Transaktion sproxy auf einem ABAP System, als Service Provider generiert werden.

Proxies kommunizieren über das XI-Protokoll, ein an SAP PI Bedürfnisse adaptiertes SOAP Protokoll. Ohne zusätzliche Vorkehrungen, kommunizieren ABAP Proxies direkt über die Integration Engine, also den ABAP-Stack und nicht über die Adapter-Engine, die auf dem Java-Stack läuft. Seit PI 7.1 kann die Performance gesteigert werden, wenn man die AAE (Adavanced Adapter Engine) verwendet. Mit PI 7.1 ist der SOAP Adapter in der Lage das XI-Protokoll zu verwenden und kann damit mit Proxies kommunizieren. Da der SOAP Adapter im Java-Stack, auf der Adapter Engine läuft, kann man die performantere AAE verwenden.

Hier sind, im Gegensatz zum ABAP Consumer Proxy (siehe „SAP PI AAE: ABAP (Consumer) Proxy auf SOAP umstellen„) keine besonderen Vorkehrungen auf dem ABAP System zu treffen. Es muss lediglich sichergestellt werden, dass der Service /default_host/sap/xi/engine über die Transaktion sicf aktiviert ist.

Proxy generieren

Die Generierung des Grundgerüstes ist denkbar einfach:

1. Loggen Sie sich auf dem ABAP System ein, auf dem Sie den Proxy generieren wollen.
2. Rufen Sie die Transaktion sproxy auf.
3. Selektieren Sie das Inbound-Interface, für das Sie den Proxy generieren wollen.
4. Rechtsklick und „Proxy anlegen“ aufrufen. Wenn der Proxy fertig generiert ist, wird er durch einen grünen Punkt markiert:
   
   Alternativ kann man sich die Proxy-Klasse auch über die Transaktion SE80 anschauen:
   

Integration Directory konfigurieren

Im Integration Directory müssen folgende Objekte angelegt werden:

1. Im Integration Directory können Sie eine „Integrated Configuration“ (ICO) anlegen, um über die AAE zu kommunizieren:
   
2. Der Kommunikationskanal für den Proxy verwendet den SOAP Receiver Adapter mit XI-Protokoll:
   
   Hinweis: Um die Target URL zu ermitteln, loggen Sie sich auf dem Zielsystem ein und rufen die Transaktion smicm auf.Die Target URL setzt sich aus http://<host>:<port>/sap/xi/engine?type=entry zusammen. Der Host und das Port kann man über smicm > Services (Shift+F1) ermitteln. Es ist normalerweise 80<SAP-Instanz>.

Monitoring

Eine Integrierte Configuration (ICO) läuft komplett in der AAE ab und kann nicht über die Transaktion sxmb_moni gemonitored werden! Sie müssen hierzu in der Runtime Workbench (RWB) das „Message Monitoring“ benutzen.

 

SAP PI: SOAP Adapter durch HTTP Adapter ersetzen

Einige SOAP Clients, insbesondere ältere, haben teilweise Probleme mit dem SOAP Sender Channel von PI zu kommunizieren. Das fängt schon mal damit an, dass (ohne zusätzlichen Aufwand), die WSDL nicht direkt über eine URL angesprochen werden kann. In einem Projekt hatten wir das Problem, dass das MS SOAP Toolkit nicht mit dem SOAP Sender Channel arbeiten wollte. Nachdem wir eine Vielzahl von Alternativen gesucht hatten, wurde der SOAP Sender Channel durch einen HTTP Channel ersetzt. Da das MS SOAP Toolkit die WSDL über eine URL laden muss, kann man diese als Datei auf einem FTP Server, oder auf einem http Server (z.B. XAMPP Installation) bereitstellen.
SOAP-Endpoint:
http://<PI-Server>:<Port>/XISOAPAdapter/MessageServlet?channel=[<Party>]:<Sender-Service>:<Sende-Channel>&amp;version=3.0&amp;Sender.Service=<Sender-Service>&amp;Interface=<Namensraum Interface Outbound>^<Interface Outbound>

http-Endpoint:
http://<PI-Server>:<Port>/sap/xi/adapter_plain?namespace=<Namensraum Interface Outbound>&interface=<Interface Outbound>&service=<Sender-Service>&party=&agency=&scheme=&QOS=EO&sap-client=<Client SAP>&sap-user=<User SAP>&sap-password=<Passwort SAP>

In der WSDL steht dann als Endpoint die URL des PI http Adapters:

<wsdl:service name="dispatch_OService">
   <wsdl:port name="dispatch_OPort" binding="p1:dispatch_OBinding">
      <soap:address location="http://<PI-Server>:<Port>/sap/xi/adapter_plain?namespace=http%3A//<Namensraum Interface Outbound>&interface=<Interface Outbound>&service=<Sender-Service>&party=&agency=&scheme=&QOS=EO&sap-client=<Client SAP>&sap-user=<User SAP>&sap-password=<Passwort SAP>"/>
   </wsdl:port>
</wsdl:service>

Die Konfiguration des http (Sender) Adapters im PI ist standardmäßig und hat keine besonderen Einstellungen:

Die Nachricht sieht in SXI_MONITOR beispielsweise so aus:

Würde man den SOAP Adapter anstelle des HTTP Adapters verwenden, würde die Nachricht etwa so aussehen:

Das entspricht prinzipiell dem Aufbau der vorangegangenen Nachricht, nur ohne SOAP Envelope. Mit einem Java Mapping kann man die SOAP Envelope einfach entfernen und notwendige Attribute für das nachfolgende Mapping hinzufügen:

package jkh.mapping;

import java.io.*;
import com.sap.aii.mapping.api.*;

public class StripSoapEnvelopeMapping extends AbstractTransformation {
   public void transform(TransformationInput in, TransformationOutput out)
         throws StreamTransformationException {
      getTrace().addInfo("Java Mapping StripSoapEnvelopeMapping started...");
      this.execute(in.getInputPayload().getInputStream(), out
            .getOutputPayload().getOutputStream());
      // String receiverName = (String)
      // in.getInputHeader().getReceiverInterface();
      getTrace().addInfo(
            "...Java Mapping StripSoapEnvelopeMapping successfully ended");

   }

   public void execute(InputStream in, OutputStream out)
         throws StreamTransformationException {
      // Add your code here
      try {
         String inputPayload = convertStreamToString(in);
         String outputPayload = "";
         String dummyPayload = "";
         int nStartMsg = inputPayload.indexOf("<transaction-stack");
         int nEndMsg = inputPayload.lastIndexOf("</transaction-stack");
         outputPayload =
		    "<?xml version="1.0" encoding="UTF-8" standalone="no"?> " +
            "<ns0:Messages xmlns:ns0="http://sap.com/xi/XI/SplitAndMerge"> " +
            "<ns0:Message1> " +
            inputPayload.substring(nStartMsg, nEndMsg) +
            " </transaction-stack> " +
            "</ns0:Message1> " +
            "</ns0:Messages>";

         out.write(outputPayload.getBytes("UTF-8"));
      } catch (Exception e) {
         getTrace().addWarning("Exception in StripSoapEnvelopeMapping::execute()");
         throw new StreamTransformationException(e.getMessage());
      }
   }

   public String convertStreamToString(InputStream is) throws IOException {
      if (is != null) {
         Writer writer = new StringWriter();
         char[] buffer = new char[1024];
         try {
            Reader reader = new BufferedReader(new InputStreamReader(is,"UTF-8"));
            int n;
            while ((n = reader.read(buffer)) != -1) {
               writer.write(buffer, 0, n);
            }
         } finally {
            is.close();
         }
         return writer.toString();
      } else {
         return "";
      }
   }

   // Zum Testen:
   public static void main(String[] args) {
      try {
         // Format: "<directory path>\output.xml"
         InputStream in = new FileInputStream(new File("testnachricht.xml"));
         OutputStream out = new FileOutputStream(new File("out.xml"));
         StripSoapEnvelopeMapping mapping = new StripSoapEnvelopeMapping();
         mapping.execute(in, out);
      } catch (Exception e) {
         e.printStackTrace();
      }
   }
}

Folgende Libraries werden für das Kompilieren des Source-Codes mit NWDS 7.11 benötigt:

Verzeichnis: „C:/Programme/NWDS_platform/eclipse/plugins/com.sap.tc.ap_2.0.1.110608092517/comp/
SAP_XIAF/DCs/sap.com/com.sap.aii.mapping.lib.facade/_comp/gen/default/public/api/lib/java/“

• com.sap.xi.mapping.tool.lib.filter.jar
• com.sap.aii.mapping.api.filter.jar
• com.sap.aii.mapping.lib.facade.jar

 

SAP PI AAE: ABAP (Consumer) Proxy auf SOAP umstellen

Motivation

Seit SAP PI 7.1 gibt es die AAE (Advanced Adapter Engine), die eine lokale Prozessierung auf dem J2EE Stack von SAP PI ermöglicht, ohne den ABAP Stack zu verwenden. Das verspricht vor allem mehr Performanz.

Üblicherweise verwendet ein ABAP Proxy das XI-Protokoll, um direkt, ohne die Adapter Engine, mit dem Integrationserver von PI zu kommunizieren (Proxy Laufzeit). Seit SA PI 7.1 EHP1 (auch als SAP PI 7.11 bezeichnet) kann der SOAP Adapter auch mit dem XI Protokoll umgehen. Da der SOAP Adapter im J2EE Stack läuft, kann man über ein sog. Integriertes Szenario die AAE nutzen und da der SOAP Adapter das XI Protokoll kennt, können ABAP Proxies mit dem SOAP Adapter und damit direkt mit der AAE, ohne die Integration Engine, kommunizieren:

ABAP Proxy <— SOAP (XI Protokoll) —> AAE (J2EE Stack) <—> Empfänger/Sender

Ein integriertes Szenario läuft ausschließlich auf der AAE bzw. dem J2EE Stack und ist wesentlich performanter als ein klassiches Szenario über die Integration Engine, weil hier kein Wechsel zwischen ABAP- und J2EE Stack erfolgen muss. Die AAE übernimmt u.a. das Mapping und Routing.

Um dieses Szenario zu realisieren sind einige Einstellungen im Sender/Empfänger-ABAP-System notwendig, welches die Proxies nutzt und im Integration Directory von SAP PI.

Einstellungen im ABAP System

In klassischen Szenarien setzt man über die SXMB_MONI Transaktion die Integration Server URL (IS_URL) auf die zentrale Integration Engine. Durch Anwendung der SAP Note 1334174, kann man die IS_URL auch auf die AAE zeigen lassen. Damit kann jedes Interface bzw. Proxy entweder über die Integration Engine oder die AAE laufen.

1. Über die Transaktion SM59 (RFC Destination) eine Destination für die AAE einrichten:
   Connection Type: G
   Target Host: Hostname der AAE
   Service Number: Port der AAE
   Path: /XISOAPAdapter/MessageServlet?ximessage=true
2. Über die Transaktion SXMSIF die Sender ID für jedes Interface definieren:
   
3. Transaktion SXMB_ADM aufrufen > Configuration > Integration Engine Configuration
   
   In „Specific Configuration Data“ folgende Werte eingeben:
   Category: RUNTIME
   Parameter: IS_URL
   Subparameter: Eintrag aus SXMSIF
   Current Value: dest://HTTP destination for Advanced Adapter Engine
   
   
   

Einstellungen im Integration Directory

Vorgehensweise:

1. Configuration Scenario anlegen
2. Kommunikationskanal SOAP Sender für ABAP Proxy (Sender) anlegen:
   Moduleinstellungen anpassen:
   
3. Kommunikationskanal für Empfänger anlegen
4. Integrated Configuration anlegen 
   

Monitoring

Da die AAE nur auf dem Java-Stack läuft, sind die Nachrichten nicht SXI_MONITOR sichtbar. Das Monitoring erfolgt in der Runtime Workbench unter Message-Monitoring:

 

 

Links:

SAP NetWeaver How-To Guide: How To Set Up the Communication between ABAP Backend and SOAP Adapter using XI Protocol

 

SAP PI Troubleshooting: Messages die in der Adapter Engine "hängen" erneut senden

Nachrichten, die durch SXI_MONITOR bzw. SXMB_MONI ohne Fehler laufen, können immer noch in der Adapter Engine „hängen“ bleiben. Das wird dann nicht in SXI_MONITOR angezeigt, aber in der Runtime-Workbench unter Message Monitoring/Adapter-Engine:

 

 

 

 

Wenn man auf die eingeplanten oder fehlerhaften Nachrichten (Spalte „Fehler“ und „Eingeplant“ klickt, erscheint am unteren Bildschirmrand ein „Wiederholen“ Knopf:

 

 

Wenn man diesen anklickt, wird die Nachricht erneut versucht zuzustellen.