SAP PI für Anfänger

Ziel

Das Ziel dieses Tutorials ist es, Sie zu verstehen – was ist SAP Process Integration? Wir werden nicht auf das Wesentliche des Themas eingehen, sondern über die Architektur und die verschiedenen Funktionen von SAP PI diskutieren. Wir werden nur die grundlegenden Funktionen behandeln und vermeiden, alle Funktionen in diesem Tutorial zu diskutieren.

Als nächstes gibt es eine Reihe von Fallstudien, die Ihnen eine Vorstellung von der branchenweiten Nutzung von SAP PI geben. Sobald Sie sich mit dem Thema vertraut gemacht haben, sollten Sie versuchen, es zu lösen. Die Testfälle sind so vorbereitet, dass Sie mit jeder Lektion von einfach bis komplex in das Thema eintauchen und Ihnen einen Überblick über das Thema geben.

Was ist SAP ERP?

Für jedes Unternehmen – ob groß oder klein – sind dies die Standardfunktionen, die es ausführen muss, z. B. Materialmanagement, Vertrieb, Finanzen, Personalwesen usw. Es gibt viel Software auf dem Markt, die von der Industrie genutzt wird. Sie werden die einfachste bemerken – die Kassiermaschine, die Verkaufsrechnung erzeugt, wenn Sie ein kleines Geschäft zu einem Netzwerk von Computern in einem großen Einzelhandelsgeschäft, Hotel usw. besuchen, das auf einem ERP arbeitet.

Enterprise Resource Planning, dh ERP, ist ein effektiver Ansatz, den die meisten Unternehmen implementieren, um ihre Produktivität und Leistung zu steigern. SAP ERP ist die Enterprise Resource Planning der SAP AG, eine integrierte Softwarelösung, die die wichtigsten Geschäftsfunktionen der Organisation umfasst. Die grundlegenden Funktionalitäten, dh HR, MM, SD, FICO usw., werden in SAP als Geschäftsmodule bezeichnet. SAP baut sie als Produkte auf und verkauft sie am Markt. Es gibt zwei weitere Module, die Business-Funktionen nicht direkt unterstützen, sondern für die Präsentation und Integration genutzt werden. Ersteres heißt EP (Enterprise Portal) und letzteres PI (Process Integration). Alle Geschäftsmodule werden in ABAP entwickelt, während EP und PI hauptsächlich in Java entwickelt werden. Diese Module sind nicht ausführbar, müssen jedoch auf einem Anwendungsserver bereitgestellt werden, z. B. ABAP Web Application Server für ABAP-Module und Java Web Application Server für Java-Module.

Es gibt einige Punkte, die wir wissen sollten, bevor wir in das Thema springen.

• SAP steht für Systeme, Anwendungen und Produkte in der Datenverarbeitung.

• Die SAP AG ist ein deutscher multinationaler Softwarekonzern, der Unternehmenssoftware zur Verwaltung von Geschäftsprozessen und Kundenbeziehungen herstellt. SAP ERP ist die Enterprise Resource Planning des Unternehmens, eine integrierte Softwarelösung, die die wichtigsten Geschäftsfunktionen der Organisation umfasst.

• SAP NetWeaver Process Integration (SAP PI) ist eine SAP Enterprise Application Integration (EAI) -Software, eine Komponente der NetWeaver-Produktgruppe, die den Informationsaustausch zwischen der internen Software und den Systemen eines Unternehmens und denen externer Parteien erleichtert.

Legacy System

Bei der Implementierung des SAP ERP in einem großen Unternehmen wird festgestellt, dass nicht alle Bereiche unter das SAP ERP gebracht werden können. Viele der Geschäftsbereiche verfügen möglicherweise über eigene proprietäre Tools, die sehr komplex sind und möglicherweise nicht ersetzt werden können. Sie laufen parallel zum SAP-System. Sie werden als Legacy-Systeme bezeichnet. Dann wird es notwendig, zwischen den SAP-Systemen und solchen bereits bestehenden Nicht-SAP-System zu integrieren. Hier kommt der SAP PI ins Spiel.

Warum brauchen wir SAP PI Abgesehen von Altsystemen besteht SAP ERP in einem großen Unternehmen nicht aus einem einzigen System, sondern aus mehreren integrierten Systemen, dh CRM, SRM und FICO usw. Um diese Komplexität zu bewältigen, hat SAP Process Integration eingeführt, eine Plattform, die einen einzigen Integrationspunkt für alle Systeme bietet, ohne das bestehende komplexe Netzwerk von Altsystemen zu berühren. Dies ist eine leistungsstarke Middleware von SAP, die eine nahtlose End-to-End-Integration zwischen SAP- und Nicht-SAP-Anwendungen innerhalb und außerhalb der Unternehmensgrenze ermöglicht. SAP PI unterstützt sowohl den B2B- als auch den A2A-Austausch, unterstützt den synchronen und asynchronen Nachrichtenaustausch und enthält eine integrierte Engine zum Entwerfen und Ausführen von Integrationsprozessen.

Architektur von SAP PI

Der SAP PI besteht aus einer Hub- und Spoke-Struktur; die Spokes verbinden sich mit externen Systemen, während der Hub Nachrichten zwischen ihnen austauscht. Das Quellsystem wird als Sendersystem und das Zielsystem als Empfängersystem bezeichnet. Der PI ist keine einzelne Komponente, sondern eine Sammlung von Komponenten, die flexibel zusammenarbeiten, um Integrationsszenarien zu implementieren. Die Architektur umfasst Komponenten, die zur Entwurfszeit, zur Konfigurationszeit und zur Laufzeit verwendet werden.

Wir können den SAP PI in mehrere Bereiche unterteilen

1. Integration Server
2. Integration Builder
3. Systemlandschaft
4. Konfiguration und Monitoring

Integration Server ist die zentrale Verarbeitungsengine des SAP PI. Alle Nachrichten werden hier konsistent verarbeitet. Es besteht aus drei separaten Engines

1. Integration Engine
2. Adapter Engine
3. Business Process Engine

Integration Engine kann als Hub und Adapter Engine als Speiche betrachtet werden. In Bezug auf die Business Process Engine werde ich es später erklären.

Integration Builder ist ein Client-Server-Framework für den Zugriff auf und die Bearbeitung von Integrationsobjekten und besteht aus zwei verwandten Tools:

1. Enterprise Service Repository – zum Entwerfen und Entwickeln von Objekten für Szenarien
2. Integration Directory – zum Konfigurieren der ESR-Objekte für die Entwicklung von Szenarien

Zwei Zusammen haben wir Integrationsprozesse erstellt, die allgemein als Szenarien bezeichnet werden.

Die Systemlandschaft ist ein zentrales Repository für Informationen über Software und Systeme im Rechenzentrum und vereinfacht die Verwaltung Ihrer Systemlandschaft.

In Konfiguration und Überwachung können wir die Nachrichten und Adapter überwachen.

Single Stack und Dual Stack

Als PI zum ersten Mal veröffentlicht wurde, wurden nicht alle Komponenten auf derselben Plattform erstellt. Integration Engine und Business Process Engine wurden in ABAP erstellt, während Adapter Engine, Integration Builder, SL, CM und Mapping Runtime in Java erstellt wurden. PI benötigt also sowohl die Java- als auch die ABAP-Umgebung und wird als Dual-Stack bezeichnet.

ABAP Stack	Java Stack
Integrationsmodul Geschäftsprozessmodul Integration Builder	Enterprise Service Repository Integrationsverzeichnis Runtime Workbench Systemlandschaftsverzeichnis Adapter-Engine Mapping-Laufzeit

Aber in der späteren Version sind alle Komponenten in Java gebaut. Einige der Dual-Stack-Komponenten werden entweder weggelassen oder modifiziert, um auf dem Java-Stack zu arbeiten. PI benötigt also nur die Java-Umgebung zum Ausführen und wird als Single Stack bezeichnet.

Es gibt Vor- und Nachteile zwischen den beiden Stapeln, aber sie werden in diesem Tutorial nicht behandelt.

Integration Motor

Die Integration Engine ist für die zentralen Dienste des Integrationsservers verantwortlich, d. h. für das Pipe-Line Steps – Routing und Mapping. Wenn sich die Quellnachrichtenstruktur von der Zielnachrichtenstruktur unterscheidet, ruft Integration Engine die Mapping-Laufzeit auf, wobei die Quellstruktur in die Zielstruktur konvertiert wird. Die Mapping Runtime basiert auf dem Java Stack. Die Integration Engine kann auch ein ABAP-Programm für die Konvertierung verwenden, das auf dem ABAP-Stack basiert.

Eine Nachricht kann von zwei Typen sein

1. Synchron – hat sowohl den Anforderungs- als auch den Antwortteil
2. Asynchron – hat entweder nur den Anforderungs- oder den Antwortteil

In PI wird die Nachricht durch eine Schnittstelle dargestellt.

Schnittstelle -> Struktur der Nachricht im XML–Format + Richtung

Basierend auf den oben genannten Kriterien gibt es drei Arten von Schnittstellen

1. Ausgehende Schnittstelle – Verbindung zum Absendersystem
2. Eingehende Schnittstelle – Verbindung zum Empfängersystem
3. Abstrakte Schnittstelle – Verbindung zum BPE

Wenn wir die Integrationslogik (Szenario) im SAP PI gemäß unseren Geschäftsanforderungen konfigurieren, führt die Integration Engine diese Konfiguration schrittweise aus. Pipeline bezeichnet alle Schritte, die während der Verarbeitung einer XML-Nachricht ausgeführt werden. Die Rohrleitungsschritte bestehen aus den folgenden:

1. Empfängeridentifikation – bestimmt das System, das am Austausch der Nachricht beteiligt ist.
2. Schnittstellenbestimmung – Bestimmen Sie, welche Schnittstelle die Nachricht empfangen soll.
3. Nachrichtenaufteilung – Wenn mehr als ein Empfänger gefunden wird, instanziiert PI für jeden Empfänger eine neue Nachricht.
4. Message Mapping – Mapping, um die Quellnachricht in das Zielnachrichtenformat umzuwandeln.
5. Technisches Routing – Binden Sie ein bestimmtes Ziel und Protokoll an die Nachricht.
6. Call Adapter – Sendet die transformierte Nachricht an den Adapter oder einen Proxy.

Adapter Engine

Sie müssen bereits bemerkt haben, dass die Integration Engine Nachrichten nur im XML-SOAP-Protokoll verarbeitet. Aber was ist, wenn wir ein Absender- und ein Empfängergeschäftssystem haben, bei dem die Daten nicht im selben Format vorliegen. Wir verwenden die verschiedenen Adapter in der Adapter Engine, um XML- und HTTP-basierte Nachrichten in das spezifische Protokoll und Format zu konvertieren, das von diesen Systemen benötigt wird, und umgekehrt.

Wie bereits erwähnt, ist SAP PI eine Hub- und Speichenstruktur, bei der die Adaptermaschine als Speiche betrachtet werden kann. Wir verwenden die Adapter Engine, um die Integration Engine (Hub) mit den externen Systemen zu verbinden. Das Adapter Framework ist die Basis der Adapter Engine. Das Adapter Framework basiert auf der SAP J2EE Engine (als Teil des SAP Web Application Servers) und der J2EE Connector Architecture (JCA). Das Adapter Framework stellt Schnittstellen zur Konfiguration, Verwaltung und Überwachung von Adaptern bereit.

In einem Dual-Stack-System basieren die meisten Adapter auf dem Java-Stack, mit Ausnahme von zwei Adaptern, die auf dem ABAP-Stack basieren.

Java Stack	RFC-Adapter, SAP Business Connector-Adapter, Datei- / FTP-Adapter, JDBC-Adapter, JMS-Adapter, SOAP-Adapter, Marktplatz-Adapter, E-Mail-Adapter, RNIF-Adapter, CIDX-Adapter
ABAP stack	IDOC-Adapter und HTTP-Adapter

Als SAP PI von Dual Stack zu Single Stack wechselte, wurden diese beiden Adapter Teil des Java-Stacks. Die modifizierte Adapter-Engine wird als Advance Adapter Engine bezeichnet, und die beiden Adapter werden als IDOC_AAE-Adapter bzw.

Geschäftsprozessmodul

Die Business Process Engine ist für die Ausführung und Persistenz von Integrationsprozessen verantwortlich.

BPM steht für Cross-Component Business Process Management oder ccBPM und wird auch Integrationsprozess genannt. Ein Integrationsprozess ist ein ausführbarer, systemübergreifender Prozess zur Verarbeitung von Nachrichten. In einem Integrationsprozess definieren Sie alle auszuführenden Prozessschritte und die für die Steuerung des Prozesses relevanten Parameter. Business Process Management stellt SAP Exchange Infrastructure folgende Funktionen zur Verfügung:

1. Status-vollständige Nachrichtenverarbeitung: Der Status eines Integrationsprozesses wird auf dem Integrationsserver beibehalten.
2. Sie können auch Korrelationen verwenden, um semantische Beziehungen zwischen Nachrichten herzustellen.
3. Sie implementieren Integrationsprozesse, wenn Sie komplexe Integrationsprozesse definieren, steuern und überwachen möchten, die sich über Unternehmens- und Anwendungsgrenzen erstrecken, z. B. Sammeln /Zusammenführen, Teilen, Multicast

Zur Laufzeit führt die Business Process Engine die Integrationsprozesse aus. Der Integrationsprozess kann Nachrichten nur über abstrakte Schnittstellen senden und empfangen.

Erstellen eines Szenarios in SAP PI

Wir beginnen von der Startseite, wenn wir ein Szenario in PI erstellen müssen.

Die Homepage wird ähnlich aussehen wie unten angegeben:

Abbildung 6 – Startseite für SAP PI Java Stack

Die Startseite enthält Hyperlinks zu den folgenden 4 Arbeitsbereichen

1. Enterprise Services Repository (ESR)
2. Integration Directory (ID)
3. Systemlandschaft (SL)
4. Konfiguration und Überwachung (CM)

Jeder Hyperlink öffnet eine Anwendung. Alle diese vier sind Java-Anwendung. ESR und ID sind Swing-Anwendungen. Sie werden vom Browser basierend auf JNLP gestartet. Zum ersten Mal dauert es also länger, da die gesamte Bibliotheksdatei heruntergeladen wird. Ab dem zweiten Mal dauert der Start jedoch weniger Zeit. SL und CM sind reine Webanwendungen und laufen im Browser.

Enterprise Services Repository

Hier entwerfen und erstellen wir Objekte, die bei der Erstellung eines Integrationsszenarios verwendet werden sollen. Der Datenfluss in PI sieht ähnlich aus wie unten gezeigt:

Wir finden die Option zum Entwerfen der folgenden

1. Schnittstellenobjekte – Serviceschnittstelle, Nachrichtentyp, Datentyp
2. Zuordnungsobjekte – Operationszuordnung und Nachrichtenzuordnung
3. Integrationsprozesse

PI verwendet Integration Repository, um Nachrichtenstrukturen für Sender- und Empfängersysteme zu entwerfen und eine Schnittstellennachricht unter Verwendung entsprechender Nachrichtenstrukturen zu entwickeln, die als Interaktionspunkt zur Außenwelt dienen. Datentyp und Nachrichtentyp werden verwendet, um das Design einer komplexen Schnittstelle zu vereinfachen und zu modularisieren.

Operation Mapping ermöglicht die Transformation der Quellstruktur in die Zielstruktur, wenn die beiden Strukturen unterschiedlich sind. Wenn jedoch die Quell- und die Zielstruktur identisch sind, kann auf die Operationszuordnung verzichtet werden. Ähnlich wie bei der Serviceschnittstelle wird die Nachrichtenzuordnung verwendet, um das Design einer komplexen Operationszuordnung zu vereinfachen und zu modularisieren. Message Mapping kann auf 4 Arten implementiert werden

1. Graphisches Mapping
2. Java Mapping
3. XSLT Mapping
4. ABAP Mapping

Graphisches Mapping wird am häufigsten verwendet, da Entwickler Attribute beider Strukturen grafisch abbilden können, um Daten über Serviceschnittstellen zu übergeben. Für die anderen drei müssen wir das Mapping durch Schreiben von Code entwickeln. Wenn es sich um einen einzelnen Stack-Server handelt, ist das ABAP-Mapping nicht verfügbar.

Es gibt auch andere Bereiche, die in diesem Tutorial jedoch nicht behandelt werden.

Integration Directory

Hier führen wir die Pipe-Line-Schritte durch, indem wir die zuvor erstellten ESR-Objekte konfigurieren. Diese Schritte werden von der Integration Engine während der Laufzeit ausgeführt.

Bevor wir mit der Konfiguration beginnen, müssen wir die folgenden Objekte im Verzeichnis erstellen / importieren.

1. Service – Business System/ Business Service/ Integrationsprozess
2. Kommunikationskanal

Mit einem Service können Sie einen Absender oder Empfänger von Nachrichten ansprechen. Je nachdem, wie Sie den Dienst verwenden möchten, können Sie aus den folgenden Diensttypen auswählen.

1. Geschäftssystem – Wenn Sie ein bestimmtes Geschäftssystem als Absender oder Empfänger von Nachrichten ansprechen möchten, wählen Sie diesen Diensttyp. Ein Business-System ist ein tatsächliches Anwendungssystem in einer Systemlandschaft.
2. Business Service – Wenn Sie eine abstrakte Geschäftseinheit als Absender oder Empfänger von Nachrichten ansprechen möchten, wählen Sie diesen Servicetyp. Ein Business Service ist in der Systemlandschaft nicht definiert.
3. Integrationsprozessdienst – Wenn Sie einen Integrationsprozess als Absender oder Empfänger von Nachrichten adressieren möchten, wählen Sie diesen Diensttyp. Zur Laufzeit werden diese Integrationsprozesse durch Nachrichten gesteuert und können selbst Nachrichten senden.

Kommunikationskanal bestimmt die eingehende und ausgehende Verarbeitung von Nachrichten. Die Nachrichten werden vom nativen Format in das soap-XML-spezifische Nachrichtenformat und umgekehrt über den Adapter konvertiert. Im Allgemeinen gibt es in einem Szenario zwei Arten von Kommunikationskanälen

1. Sender-Kommunikationskanal
2. Empfänger-Kommunikationskanal

Sie müssen einem Dienst einen Kommunikationskanal zuweisen. Je nachdem, ob der Dienst als Sender oder Empfänger von Nachrichten angesprochen wird, hat der zugeordnete Kommunikationskanal die Rolle eines Sender- oder eines Empfängerkanals und muss entsprechend konfiguriert werden. Sie können einem Integrationsprozess-Service keinen Kommunikationskanal zuweisen.

Die Pipe-Line-Schritte werden erstellt, indem die folgende 4-Konfiguration im DIR

Wir finden die folgenden Optionen:

1. Absendervereinbarung
2. Empfängerbestimmung
3. Schnittstellenbestimmung
4. Empfängervereinbarung

Absendervereinbarung definiert, wie die Nachricht eines Absenders transformiert werden soll, damit sie vom Integrationsserver verarbeitet werden kann. Es besteht aus den folgenden

1. Absenderkomponente
2. Absenderschnittstelle
3. Absenderkommunikationskanal

Die Absendervereinbarung ähnelt dem Primärschlüssel in der Tabelle. Es kann nicht zwei ähnliche Absendervereinbarungen in einer Landschaft geben.

Empfängervereinbarung definiert, wie die Nachricht transformiert werden soll, damit sie von einem Empfänger verarbeitet werden kann. Es besteht aus

1. Senderkomponente
2. Empfängerkomponente
3. Empfängerschnittstelle
4. Empfängerkommunikationskanal

Mit einer Empfängerbestimmung legen Sie fest, an welche Empfänger eine Nachricht gesendet werden soll. Sie haben die Möglichkeit, Bedingungen für die Weiterleitung der Nachricht an die Empfänger zu definieren. Es besteht aus

1. Senderkomponente
2. Senderschnittstelle
3. Empfängerkomponente

Es gibt zwei Arten der Empfängerbestimmung – Standard oder Erweitert, je nachdem, ob Sie den Empfänger zur Laufzeit manuell oder dynamisch durch ein Mapping angeben möchten.

Mit einer Schnittstellenbestimmung legen Sie fest, an welche eingehende Schnittstelle eines Empfängers die Nachricht weitergeleitet werden soll. Sie können auch angeben, welche Schnittstellenzuordnung aus dem Integrations-Repository für die Verarbeitung der Nachricht verwendet werden soll, z. wenn die Sender- und die Empfängerschnittstelle nicht dasselbe Format haben, besteht eine operationelle Zuordnung zum Ändern des Formats. Sie definieren eine Schnittstellenbestimmung für einen Sender, eine ausgehende Schnittstelle und einen Empfänger. Es besteht aus

1. Absenderkomponente
2. Absenderschnittstelle
3. Empfängerkomponente
4. Empfängerschnittstelle

Die Schnittstellenbestimmung besteht aus zwei Typen – Standard oder Erweitert, je nachdem, ob Sie die Empfängerschnittstelle manuell oder durch zuordnungsbasierte Nachrichtenaufteilung angeben möchten.

Empfängerbestimmung und Schnittstellenbestimmung – die beiden zusammen werden allgemein als logisches Routing bezeichnet. Absendervereinbarung und Empfängervereinbarung – die beiden zusammen werden allgemein als Kooperationsvereinbarung bezeichnet.

Systemlandschaft

Das SAP System Landscape Directory (SLD) ist der zentrale Informationsanbieter in einer Systemlandschaft. Auf der Webseite finden Sie die folgenden Links:

1. Technisches System – Technische Systeme sind Anwendungssysteme, die in Ihrer Systemlandschaft installiert sind.
2. Geschäftssystem – Geschäftssysteme sind logische Systeme, die innerhalb von PI als Absender oder Empfänger fungieren. Business Systems hat eine Eins-zu-Eins-Abhängigkeit mit dem zugehörigen technischen System.
3. Produkte und Komponenten – Dies sind Informationen zu allen verfügbaren SAP-Produkten und -Komponenten, einschließlich ihrer Versionen. Wenn sich in der Systemlandschaft Produkte von Drittanbietern befinden, werden diese ebenfalls hier registriert.

Die SLD wird ähnlich wie unten angegeben aussehen:

Abbildung 11 – Systemlandschaft

Produkte und Komponenten werden allgemein als Komponenteninformationen bezeichnet

Technisches System und Geschäftssystem werden allgemein als Landschaftsbeschreibung bezeichnet.

Ein Geschäftssystem kann als Integrationsserver oder Anwendungssystem konfiguriert werden.

1. Integration Server – Der Integration Server führt nur die im Integration Builder konfigurierte Integrationslogik aus. Sie können auch als Rohrleitungsschritte identifiziert werden. Es empfängt XML-Nachrichten, bestimmt den Empfänger, führt die Zuordnungen aus und leitet die XML-Nachricht an die entsprechenden Empfängersysteme weiter. Somit wird die konfigurierte Integrations-Engine als zentral konfigurierte Integrations-Engine identifiziert.
2. Anwendungssystem – Das Anwendungssystem führt die Integrationslogik nicht aus. Dieser wiederum ruft den Integrationsserver auf, um bei Bedarf die Integrationslogik auszuführen. Es fungiert als Absender oder Empfänger von XML-Nachrichten. Das Anwendungssystem mit einer lokalen Integrations-Engine benötigt also den Integrationsserver, um die Integrationslogik auszuführen.

Es kann nur ein Client des SAP-Systems als Integrationsserver konfiguriert werden.

Die folgenden Informationen werden aus dem SLD in den ESR extrahiert und DIR

1. Komponenteninformationen werden im ESR zur Definition des Produkts verwendet und das SWCV
2. Geschäftssystem wird im Verzeichnis zur Definition des Absenders und Empfängers von Nachrichten verwendet

Konfiguration und Überwachung

Es ist der zentrale Einstiegspunkt für Überwachungszwecke. Damit haben Sie die Möglichkeit, zu den Monitoring-Funktionen der Integration Engine sowie zur Integration mit dem Rechenzentrumsmanagementsystem (CCMS) und der Prozessüberwachungsinfrastruktur (PMI) von SAP zu navigieren.

Die Konfiguration und Überwachung sieht ähnlich wie unten angegeben aus:

Abbildung 13 – Konfiguration und Überwachung

Mit der Konfiguration und Überwachung werden folgende Überwachungsfunktionen unterstützt:

1. Komponentenüberwachung – Überwachung der verschiedenen SAP PI-Komponenten (Java- und ABAP-Teile).
2. Message Monitoring – Verfolgung des Nachrichtenverarbeitungsstatus innerhalb einer SAP PI-Komponente und zur Fehlererkennung und -analyse.
3. End-to–End Monitoring – Überwachung eines Nachrichtenlebenszyklus aus Sicht des SAP PI.
4. Performance Monitoring – Statistiken über verschiedene Performance-Aspekte von SAP PI können über die RWB abgerufen werden. Hier können Sie Leistungsdaten auswählen und aggregieren, z. B. nach Komponente, Zeitbereich oder Nachrichtenattributen.
5. Indexverwaltung – Durch die Verwaltung und Überwachung der Indizierung von Nachrichten pro SAP PI-Komponente aktivieren Sie eine indexbasierte Nachrichtensuche, die Sie in der Nachrichtenüberwachung verwenden können. Diese Art der Nachrichtensuche bietet Ihnen erweiterte Auswahlkriterien, einschließlich adapterspezifischer Nachrichtenattribute und Begriffe oder Phrasen aus der Nachrichtennutzlast.
6. Alert-Konfiguration – Mit dem Alert Framework kann eine zentrale Überwachung in PI mit allen gemeldeten Fehlern während der Nachrichtenverarbeitung in ABAP und Java bereitgestellt werden. Dies ermöglicht eine verbesserte Reaktion auf solche Fehler sowohl in der ABAP Runtime als auch in der Java-basierten Adapter Engine. Zu diesem Zweck wird das Alert-Framework mit Regeln versehen, die auf bestimmten Ereignissen und auf Informationen aus dem Header des PI-Nachrichtenprotokolls basieren. Diese Regeln bestimmen, ob Warnungen gesendet werden oder nicht. Wenn eine Warnung gesendet wird, kann sie zur Fehleranalyse verwendet werden.
7. Warnungseingang – Der Warnungseingang ist benutzerspezifisch und zeigt alle Warnungen für jeden Warn-Server an, die basierend auf der Warnungskonfiguration generiert wurden.
8. Cache-Überwachung – Die Cache-Überwachung zeigt Objekte an, die sich derzeit im Laufzeitcache befinden. Je nach Cache-Instanz werden unterschiedliche Cache-Objekte überwacht.

Synchrone vs. asynchrone Kommunikation

Ein Prozess kann als synchron oder asynchron definiert werden.

• Ein synchroner Prozess wird durch eine Request/Response-Operation aufgerufen, und das Ergebnis des Prozesses wird über diese Operation sofort an den Aufrufer zurückgegeben.
• Ein asynchroner Prozess wird durch eine Einwegoperation aufgerufen, und das Ergebnis und etwaige Fehler werden durch Aufrufen anderer Einwegoperationen zurückgegeben. Das Ergebnis wird über eine Callback-Operation an den Aufrufer zurückgegeben.

In der Computerwelt gibt es keine asynchrone Kommunikation. Die gesamte Kommunikation zwischen zwei Systemen erfolgt immer über einen Methodenaufruf (Request / Response-Operation). Wie machen wir es asynchron? Die Antwort liegt in der Einführung eines dritten Systems zwischen der Called- und der Caller-Funktion.

Angenommen, es gibt zwei Systeme – A und B. Die gesamte Kommunikation zwischen A und B erfolgt über einen Methodenaufruf und ist somit synchron. Wir führen ein drittes System zwischen A und B ein und nennen es das Zwischensystem – I. Die Kommunikation zwischen A und I erfolgt über Methodenaufruf und in ähnlicher Weise auch zwischen I und B über Methodenaufruf. Die Kommunikation zwischen A und B kann jedoch als asynchron bezeichnet werden, da A nicht auf die Antwort von B warten muss.

Dies ist die Grundlage der asynchronen Kommunikation und was ist dieses Zwischensystem? Das ist die Warteschlange. A wird als Sender und B als Empfänger bezeichnet. Die Nachricht von A wird zuerst zur Warteschlange hinzugefügt und dann erneut aus der Warteschlange gezogen und an B gesendet. In bestimmten Situationen müssen die Nachrichten gemäß den Geschäftsanforderungen in derselben Reihenfolge an B gesendet werden, in der sie von A ausgelöst werden. Wenn keine solchen Anforderungen vorliegen, werden Nachrichten in beliebiger Reihenfolge von der Warteschlange an B gesendet.

Bei asynchroner Kommunikation erreichen wir eine garantierte Zustellung, d. H. System B ist nicht verfügbar, wenn System A die Nachricht sendet. Die Nachricht wird der Warteschlange hinzugefügt und verbleibt dort, solange B nicht verfügbar ist. Sobald B verfügbar ist, wird die Nachricht aus der Warteschlange gezogen und an B gesendet.

So können wir unsere Nachrichtenkommunikation auf drei Arten klassifizieren:

1. Synchron
2. Asynchron mit nicht gepflegter Bestellung
3. Asynchron mit gepflegter Bestellung

In PI identifizieren wir sie als: Synchron – BE (Best Effort), Asynchron mit nicht gepflegter Bestellung – EO (Genau einmal), Asynchron mit gepflegter Bestellung – EOIO (Genau einmal in der Reihenfolge).

Bestätigung

Bestätigung ist die Wurzel der asynchronen Kommunikation. Warum?

Bei synchroner Kommunikation ruft System A System B auf, und wenn B die Antwort nicht sendet, ist der Prozess fehlgeschlagen. Aber in einer asynchronen Kommunikation ruft System A System I auf und System I ruft System B. Angenommen, die Kommunikation zwischen A und I ist erfolgreich, aber zwischen I und B schlägt sie fehl. Wie soll A erkennen, dass die Lieferung an B fehlgeschlagen ist? Dies wird durch eine Quittung realisiert, die von B auf dem gleichen Weg wie die Nachricht von A nach B an A zurückgesendet wird. Wenn die Bestätigung von B nicht bei A ankommt, berücksichtigt A, dass der Prozess fehlgeschlagen ist, und sendet die Nachricht erneut.

Während wir über asynchrone Kommunikation in PI diskutierten, haben wir den Begriff ‚Genau einmal‘ sowohl für EO als auch für EOIO verwendet. Genau einmal bedeutet, dass eine einmal übermittelte Nachricht nicht erneut zugestellt werden kann. Um dies zu erreichen, gibt es für jede von A nach B gesendete Nachricht eine Bestätigung. Die Adapter müssen also die Bestätigung unterstützen.

Alle Adapter bieten System-Bestätigung i.e. Lieferbestätigung. Diejenigen Adapter, die eine synchrone Kommunikation unterstützen, unterstützen zusätzlich zur Systembestätigung die Anwendungsbestätigung.

Also in PI, im Folgenden sind die Art der Bestätigung

1. Systembestätigung – Systembestätigungen, die von der Laufzeitumgebung verwendet werden, um zu bestätigen, dass eine asynchrone Nachricht den Empfänger erreicht hat.
2. Anwendungsbestätigung – Anwendungsbestätigungen, die verwendet werden, um zu bestätigen, dass die asynchrone Nachricht am Empfänger erfolgreich verarbeitet wurde.

Remote-Funktionsaufruf

Während Sie in PI arbeiten, werden Sie auf den Begriff – RFC stoßen. Was sind sie? Um die Kommunikation zwischen zwei SAP-Systemen, d. H. einem R / 3 und einem PI, herzustellen, erstellen wir das RFC-Ziel. Es wird durch folgende konfiguriert

1. Verbindungstyp
2. IP-Adresse und Port des Empfängers

Verbindungstyp gibt den Typ der Systemverbindung an, d. H. R / 3, TCP / IP, Intern usw.

Das von uns erstellte RFC-Ziel wird nach dem erforderlichen Kommunikationsmodus klassifiziert, d. h. ob synchrone oder asynchrone Kommunikation unterstützt werden soll.

1. für synchrone Kommunikation – Synchroner RFC
2. für asynchrone Kommunikation mit nicht gewartetem Auftrag – Transaktions–RFC
3. für asynchrone Kommunikation mit gewartetem Auftrag – RFC in der Warteschlange

Sie werden durch sRFC, tRFC und qRFC identifiziert.

Fallstudien – 1

Angenommen, Sie befinden sich in einem Klassenzimmer und es befinden sich 10 Schüler darin. Der Lehrer bittet dann jeden Schüler, die folgenden persönlichen Daten vorzubereiten und in einer XML-Datei zu speichern. Die Details sind wie folgt:

1. Studentenausweis
2. Name
3. Mobil
4. E-Mail
5. Geschlecht

Es werden 10 Dateien vorhanden sein und die Dateien werden als cv_1, 2, 3 bezeichnet ….10. Die Dateien werden im Quellverzeichnis gespeichert. Zu Testzwecken werden folgende Verzeichnisse angelegt:

Quellverzeichnis: c:\ibm\sap\training\input

Archiv-Verzeichnis: c:\ibm\sap\training\archive

Fehlerverzeichnis: c:\ibm\sap\training\error

Zielverzeichnis: c:\ibm\sap\training\target

Sie werden aufgefordert, in SAP PI Szenarien zu entwickeln, die die Quelldateien aus dem Quellverzeichnis lesen und in das Zielverzeichnis schreiben. Sobald eine Datei erfolgreich aus dem Quellverzeichnis gelesen wurde, sollte sie in das Archivverzeichnis verschoben werden. Die Dateien, die in das Archiv-, Fehler- oder Zielverzeichnis verschoben wurden, sollten einen Zeitstempel an den Dateinamen anhängen.

1. d.h. dateiname+<Zeitstempel>.

Lektion-1

Bereiten Sie ein Szenario vor, um eine einzelne Datei zu lesen, d. h. die Datei cv_1.xml aus dem Quellverzeichnis und schreiben Sie es in das Zielverzeichnis. Der Zieldateiname sollte ebenfalls cv_1 sein.xml mit dem Zeitstempel an den Namen anhängen.

Lektion-2

Bereiten Sie ein Szenario vor, um alle Dateien aus dem Quellverzeichnis zu lesen und in das Zielverzeichnis zu schreiben. In ähnlicher Weise sollten die Zieldateien auch als cv_1, 2 bezeichnet werden..xml mit dem Zeitstempel an jeden von ihnen anhängen.

Lektion-3

Der Kursleiter fordert Sie dann alle auf, den Daten die folgende Validierung hinzuzufügen.

1. Die Handynummer sollte 10 Ziffern haben – wenn die Handynummer nicht aus 10 Ziffern besteht, ersetzen Sie sie durch ‚error‘
2. Die E-Mail sollte ein ‚@‘ Zeichen und ein ‚ haben.‘ Zeichen – wenn die E-Mail nicht das ‚@‘ oder ‚ hat.‘ Zeichen, dann ersetzen Sie es durch ‚Fehler‘

Bevor Sie das Szenario ausführen, ändern Sie in einigen Quelldateien das Mobiltelefon und die E-Mail so, dass sie gemäß der oben angegebenen Logik fehlerhaft sind.

Lektion-4

Bereiten Sie ein Szenario vor, um alle Quelldateien zu lesen und sie nach ihrem Geschlecht zu klassifizieren. Die Dateien für die Männer werden in ein Verzeichnis und für die Damen in ein anderes Verzeichnis geschrieben. Für den obigen Zweck werden zwei Verzeichnisse erstellt:

Zielverzeichnis für Männer: c:\ibm\sap\training\target\men

Zielverzeichnis für Frauen: c:\ibm \sap \training\target\women

Angenommen, es gibt 6 Männer und 4 Frauen in der Klasse, dann, wenn alle Quelldateien erfolgreich gelesen werden, dann sollte das Zielverzeichnis für Männer 6 Dateien haben und das Zielverzeichnis für Frauen sollte 4 Dateien haben.

Fallstudien – 2

Der Kursleiter fordert Sie alle auf, eine einzige Datei mit den persönlichen Daten jedes Schülers in separaten Segmenten zu erstellen.

Lektion-5

Schreiben Sie ein Szenario, das diese Datei liest und 10 Zieldateien erzeugt, wobei jede Datei den persönlichen Daten jedes Mitarbeiters entsprechen sollte. Die Zieldateien sollten als cv_< emp_ID> _< timestamp>

Lesson-6

Ändern Sie das obige Szenario so, dass es 2 Zieldateien anstelle von 10 erzeugt, wobei eine Zieldatei für Männer und eine andere Zieldatei für die Damen. Die Zieldatei für Männer sollte 6 Segmente für 6 Männer und die Zieldatei für Damen 4 Segmente für 4 Frauen haben.

Die Zieldateien sollten wie folgt benannt werden

Für Männer – Männer_<Zeitstempel>

Für Damen – Frauen_<Zeitstempel>

Fallstudie -3

Wie bei Fallstudie – 1 bittet der Ausbilder jeden Schüler, seine / ihre die persönlichen Daten und speichern Sie sie in einer XML–Datei. Es wird 10 Dateien geben. Die Dateien werden im Quellverzeichnis gespeichert.

Lektion-7

Bereiten Sie ein Szenario vor, um alle Quelldateien aus dem Quellverzeichnis zu lesen und eine einzelne Datei im Zielverzeichnis zu erstellen. Der Name der Zieldatei wird ausgegeben.xml mit dem Zeitstempel an den Dateinamen anhängen. Die Zieldatei enthält alle Details jeder Quelldatei als Untersegment.

Lektion-8

Bereiten Sie ein Szenario vor, um die gesamten Quelldateien aus dem Quellverzeichnis zu lesen und zwei Dateien im Zielverzeichnis zu erstellen – eine für die Männer und die andere für die Damen. Für 6 Männer sollte die Männerdatei sechs Segmente mit den Details jedes Mannes und für 4 Frauen haben, ähnlich sollte es 4 Segmente mit den Details jeder Dame geben.

Fallstudie – 4

Der Dozent bittet nun jeden Schüler, einen weiteren Satz von Details vorzubereiten, der aus seinen / ihren folgenden akademischen Details besteht:

1. Studentenausweis
2. Schulname
3. College-Name
4. Abteilungsname
5. Zulassungsjahr

Es werden 10 Dateien angezeigt und die Dateien werden als ad_1, 2, 3 bezeichnet ….10. Die Dateien werden im Quellverzeichnis gespeichert. So hat jeder Student jetzt ein Paar Dateien – eine für die persönlichen Daten und die andere für die akademischen Details. Zwei Dateien sind mit dem Studentenausweis verbunden. Das Eingabeverzeichnis besteht nun aus 10 persönlichen Dateien und 10 akademischen Dateien.

Lektion – 9

Sie werden gebeten, ein Szenario zu entwickeln, das die Quelldateien auswählt und paarweise verarbeitet. Das Szenario generiert 10 Zieldateien. Jede Zieldatei besteht aus den persönlichen und akademischen Details eines Studenten in separaten Segmenten. Die Zieldateien werden als res_1, 2, 10 bezeichnet.

Die Zieldateien werden wie folgt aussehen:

Lektion – 10

Sie werden dann aufgefordert, den Studentenausweis in einigen Dateien so zu ändern, dass sie keine passenden akademischen oder persönlichen Dateien haben und umgekehrt. Das Szenario sollte ausgeführt werden und wenn Dateien gefunden werden, die keine passende entsprechende Datei haben, sollte der Prozess nach einiger Zeit enden, dh 2 Minuten, und diese Dateien werden in das Fehlerverzeichnis verschoben, und es gibt keine entsprechenden Zieldateien für sie.