Zum Inhalt springen

SAP Best Practices für Jitterbit Design Studio

Einführung

Bei SAP -Integrationsprojekten, insbesondere bei bidirektionalen Integrationen, gibt es eine Reihe spezieller Probleme und Überlegungen. Auf dieser Seite finden Sie relevante Informationen zu allen SAP -Integrationen, allgemeine Integrationsmuster für SAP und ihre Designüberlegungen sowie SAP-spezifische Anleitungen.

Grundlegende Informationen

Dieser Abschnitt behandelt die SAP und Jitterbit-Terminologie, die Aktualisierung von SAP Daten, die IDoc-Struktur und Datumsformate.

Terminologie

In diesem Abschnitt wird die SAP-spezifische Terminologie in Bezug auf Jitterbit Design Studio und seinen SAP Connector definiert.

SAP Terminologie

  • SAP: Wenn wir von SAP sprechen, meinen wir eine Version von SAP, die mit dem Jitterbit Design Studio SAP Connector kompatibel ist. Die wesentliche Komponente, die der Design Studio SAP Connector erfordert, ist eine SAP Version, die den SAP Java Connector (SAP JCo) verwendet. Dies umfasst ECC Version 6 oder höher und SAP S/4HANA Single-Tenant.
  • IDoc: Ein Intermediate Document (IDoc) ist eine Textdatei mit einem vordefinierten Format, das einem Electronic Data Interchange (EDI)-Dokument ähnelt. Es gibt IDocs für Stammdatenobjekte wie Kunden und Lieferanten sowie für Transaktionsobjekte wie Verkaufsaufträge. Ursprünglich zum Datenaustausch zwischen SAP -Systemen verwendet, können IDocs auch für die Integration von Drittpartei verwendet werden. Beachten Sie, dass ein IDoc im Dokument deutsche Abkürzungen verwendet.
  • BAPI: Ein Business Application Programming Interface (BAPI) ist eine API - ähnlich einer SOAP oder REST- API - und verwendet eine Anforderungs- und Antwortkonstruktion zur Kommunikation mit SAP. Ein Hauptunterschied zu SOAP oder REST besteht darin, dass ein BAPI eine einzelne Methode hat und objektspezifisch ist. Beispielsweise gibt es 60 BAPIs, die sich ausschließlich auf das Kundenobjekt von SAP beziehen. BAPIs werden von SAP bereitgestellt und verwaltet.
  • RFC: Ein RFC (Remote Function Call) ist dasselbe wie ein BAPI, außer dass ein RFC über SAP Upgrades hinweg beibehalten werden kann oder nicht. Einige RFCs sind Standard und werden von SAP bereitgestellt. Es können auch benutzerdefinierte RFCs erstellt werden, um Integrationen zu unterstützen, und diese müssen vom SAP Kunden verwaltet werden.

Jitterbit-Terminologie

  • SAP Konnektor: Der Jitterbit Design Studio SAP Connector verwendet SAP Java Connector (SAP JCo) für die Arbeit mit SAP Objekten und ist mit ECC Version 6 oder höher sowie SAP S/4HANA vor Ort kompatibel. Der SAP Connector kann sofort für SAP-eingehende Kommunikation von Harmony zu SAP unter Verwendung von RFCs, BAPIs oder IDocs verwendet werden.
  • SAP Ereignislistener: Der Jitterbit SAP Event Listener ist eine Anwendung, die als Dienst auf einem Windows oder Linux-Server installiert und ausgeführt wird. Er erweitert die Funktionalität des SAP Connectors, indem er auf ausgehende SAP-IDocs wartet und diese empfängt. Mithilfe des transaktionalen RFC-Protokolls (tRFC) werden IDocs in einem Charge ohne definierte Reihenfolge gesendet. Mithilfe des Warteschlangen-RFC-Protokolls (qRFC) antwortet der SAP Event Listener SAP nach dem Empfang jedes IDocs und signalisiert SAP, das nächste IDoc in der Transaktion zu senden.

Aktualisierung von SAP Daten

Als bewährte Methode empfiehlt sich beim Aktualisieren von Daten in SAP in der Regel die Verwendung eines BAPI oder RFC gegenüber einem IDoc. Der Hauptgrund hierfür ist, dass BAPIs und RFCs eine Antwort zurückgeben, die im Integrationsprojekt verwendet werden kann:

  • Bei einer erfolgreichen Aktualisierung sind in der Antwort häufig Datensatz-IDs enthalten, die zum Aktualisieren der Quellanwendung verwendet werden können.
  • Wenn ein Fehler zurückgegeben wird, kann er in Fehlerbehandlungsprozesse integriert werden.

Im Vergleich dazu wird beim Senden eines IDocs nur ein Empfangscode zurückgesendet; es gibt keinen Hinweis auf Erfolg oder Misserfolg. IDocs werden in SAP asynchron verarbeitet. Wenn ein IDoc fehlschlägt, ist eine Benutzeraktion erforderlich, um das IDoc erneut zu verarbeiten.

Es gibt bestimmte Szenarios, in denen ein IDoc vorzuziehen ist:

  • Ein IDoc kann mehrere Datensätze enthalten, während BAPIs und RFCs normalerweise nur eine einzige Datensatzaktualisierung verarbeiten können. Bei einem Massenaktualisierungsszenario kann die Verwendung eines IDocs erforderlich sein.
  • Ein IDoc kann zum Erfassen geänderter Daten verwendet werden, während BAPIs und RFCs keine zeitstempelbasierten Abfragen verarbeiten können.
  • Möglicherweise gibt es Funktionen, die ein IDoc aufrufen kann, die bei Verwendung eines BAPI oder RFC nicht verfügbar sind.

IDoc-Struktur

Die Struktur eines IDoc ist flach. Obwohl das XML hierarchisch aussieht, sind sich wiederholende Knoten nicht wirklich in übergeordneten Knoten verschachtelt.

In der Beispielstruktur unten sind alle Segmente des übergeordneten Knotens IDOC befinden sich auf derselben Unterebene. Kopfinformationen befinden sich auf derselben Ebene wie Artikelinformationen:

Anhang

Datumsformate

Obwohl SAP Daten in seiner GUI in verschiedenen Formaten anzeigen kann (entsprechend den Länderkonventionen), ist das Datenformat für die SAP APIs yyyy-mm-dd.

Integrationsmuster

In diesem Abschnitt werden gängige Integrationsmuster vorgestellt, die für die Interaktion mit SAP Daten verwendet werden können.

Stammdatenintegration von Kunden

In SAP kann ein Kunde eine der Partnerfunktionen (oder eine Kombination davon) sein, wie z. B. Verkauft an, Lieferung an und Rechnung an. Beispiel:

  • Ein Kunde kann sein eigener VerkauftAn, Lieferan und Rechnungsan sein.
  • Ein Kunde kann sowohl ein Verkauft an als auch ein Rechnungsempfänger sein, wobei der Lieferempfänger ein anderer Kunde ist.
  • Ein Kunde könnte ein VerkauftAn sein, während viele andere Kunden die Lieferans sind (ein häufiger Fall, wenn ein Franchise-Kunde viele Standorte hat)

Bei der Verwendung des SAP Kundenobjekts in Integrationsprojekten ist ein umfassendes Verständnis der Integrationsanforderungen sowohl für Kunden als auch für Partnerfunktionen von entscheidender Bedeutung.

Beim ersten Laden von Daten müssen im Allgemeinen zuerst die VerkauftAn-Kunden geladen werden, da die anderen Kunden davon abhängig sind, dass VerkauftAn im Endpoint vorhanden ist, um die Beziehung aufzubauen. Da Rechnungsan die Rechnungsadresse enthält, benötigt die Endpoint Kundendefinition häufig Haupt- und Lieferadressen, und die Integration muss den VerkauftAn-Kunden mit der Rechnungsan-Adresse im Endpoint aktualisieren.

Im folgenden Beispiel führt ein einzelnes IDoc von SAP zu einem Upsert sowohl für ein Konto als auch für ein untergeordnetes benutzerdefiniertes Objektkonto in Salesforce:

Anhang

Bidirektionale Integrationen

Bei bidirektionalen Integrationsprojekten fließen Daten sowohl zu als auch von jedem Endpoint. Beispielsweise müssen möglicherweise SAP Kundendaten in einem Endpoint erstellt werden und alle Änderungen an Kundendaten in diesem Endpoint müssen in den Kunden- und Partnerfunktionen in SAP widergespiegelt werden.

Da die Validierungsregeln für die Objekterstellungsdaten von SAP strenger sind als bei anderen Endpoints, sind für die Handhabung der Partnerfunktionen sowohl am Endpoint als auch an SAP selbst individuelle Anpassungen erforderlich. Dieses Beispiel zeigt die Verschiebung von Salesforce-Konten nach SAP und behandelt die Verwaltung der Partnerfunktionen:

Anhang

Erfassen geänderter Daten für Stammdatenobjekte

Im Allgemeinen werden IDocs zum Erfassen geänderter Daten in SAP verwendet, da BAPIs und RFCs keine zeitstempelbasierten Abfragen verarbeiten können.

IDocs können so konfiguriert werden, dass sie mithilfe von Änderungszeigern generiert werden, die einem Objekt zugeordnet sind. Sie können so generiert werden, dass sie entweder alle Daten oder nur Änderungen enthalten. Es ist im Allgemeinen die bessere Wahl, alle Daten abzurufen, da die Daten möglicherweise Beziehungen enthalten, die für ein Upsert erforderlich sind. Massenaktualisierungen von Daten können jedoch Tausende von IDocs gleichzeitig auslösen, deren Verarbeitung dann Anmelde- oder andere Grenzwerte im Endpoint überschreiten kann.

Durchgängige Verarbeitung

Die Straight-Through-Processing-Verarbeitung folgt diesem Datenfluss:

  1. Der SAP Event Listener empfängt ein IDoc.
  2. Der SAP Ereignislistener verschiebt die Payload in die Jitterbit-Operation.
  3. Der Operation empfängt das IDoc.
  4. Die IDoc-Daten werden in den Endpoint geladen.

Obwohl die Verarbeitung durchgehend erfolgt, sollten Sie die folgenden Auswirkungen der durchgehenden Verarbeitung berücksichtigen:

  • Wenn Tausende von IDocs auf einmal gesendet werden, instanziiert der SAP Event Listener mehrere Threads und erstellt mehrere gleichzeitige Aufrufe. Wenn der Aufruf dazu dient, einen Endpoint mit Anmeldebeschränkungen wie Salesforce zu aktualisieren, kann das Volumen der Aufrufe die Anmeldebeschränkungen überschreiten.
  • Wenn der Endpoint nicht erreichbar ist, wird die IDoc-Payload nicht an das Endziel übermittelt und geht verloren.

Store-and-Forward-Verarbeitung

Die Alternative zur Straight-Through-Processing ist die Store-and-Forward-Verarbeitung, bei der die IDoc-Payload in eine temporäre Datei geschrieben werden.

In der folgenden Beispiel Operation:

  1. Die erste Operation empfängt ein IDoc vom SAP Event Listener und speichert es lokal.

  2. Der zweite Operation erfolgt nach einem schnellen Zeitplan (z. B. jede Minute) und durchsucht das Dateiverzeichnis nach zu verarbeitenden Dateien. Wenn Dateien gefunden werden, werden sie durchlaufen und jede Datei wird an den nächsten Operation übergeben.

  3. Wenn der letzte Operation in der Kette ausgeführt wird, wird die Datei gelöscht und die Schleife wird wiederholt, bis sie erschöpft ist. Tritt während des Vorgangs ein technischer Fehler auf, wird die Datei nicht gelöscht und ein zweites Mal erneut verarbeitet.

    Hinweis

    Standardmäßig werden temporäre Dateien 24 Stunden lang gespeichert, bevor sie gelöscht werden. Dies kann bei Bedarf für einen längeren Zeitraum konfiguriert werden.

Anhang

Anhang

Beim Ausführen von Vorgängen in einer Umfeld mit mehreren Agenten kann ein IDoc von Agent 1 empfangen und lokal gespeichert werden, der Zeitplan kann jedoch Agent 2 auswählen, der keine zu verarbeitenden Dateien findet. Erst wenn Agent 1 vom Zeitplaner aufgerufen wird, werden seine Dateien verarbeitet.

Bedenken Sie, dass alle Dateien in den temporären Verzeichnissen verarbeitet werden, bis sie erschöpft sind. Wenn die Anforderung besteht, dass IDocs garantiert in der richtigen Reihenfolge verarbeitet werden müssen, verwenden Sie eine gemeinsam genutzte Ressource wie eine FTP Site, ein lokales Dateisystem oder eine Datenbank. Das Hinzufügen externer Datenspeicher kann jedoch eine zusätzliche Fehlerquelle darstellen. Agent werden für Failover und Lastausgleich verwendet. Die Verwendung externer Datenspeicher, die nicht ähnlich konfiguriert sind, kann daher die Gesamtstabilität des Systems beeinträchtigen.

Extrahieren einer ID zum Abrufen zusätzlicher Daten

Wenn das IDoc eine ID hat, kann ein BAPI aufgerufen werden, um zusätzliche Daten abzurufen:

Anhang

Anhang

Im obigen Beispiel wird bei der dritten Operation (3. Mat-Get Details) das IDoc gelesen, um die Material-ID abzurufen, die dann zum Aufrufen eines benutzerdefinierten RFC verwendet wird. Dieser Screenshot zeigt die Transformation, die die Material-ID extrahiert:

Anhang

SAP-spezifische How-Anleitungen

Dieser Abschnitt enthält SAP-spezifische Anleitungen zu den folgenden Themen:

Umgang mit leeren Enddaten

Wenn in SAP kein Enddatum eingetragen ist (wie es bei einem „Evergreen“-Vertrag der Fall sein kann), sendet SAP 00000000 in einem IDoc, das abgefangen und verarbeitet werden kann:

result = FindValue("108", OUTPUT$ORDERS05.IDOC$E1EDP01.E1EDP03#.IDDAT$, OUTPUT$ORDERS05.IDOC$E1EDP01.E1EDP03#.DATUM$);
If(result == "00000000",
  RunScript("<TAG>Scripts/WTOL</TAG>", "No End Date, using 12/31/4000");
  result="40001231"
);
GetUTCFormattedDateTime(result, "UTC", false);
// The year 4000 is the maximum date used by Salesforce

Weitere Einzelheiten finden Sie in den Jitterbit-Funktionen FindValue(), RunScript(), Und GetUTCFormattedDateTime().

Kunden- und Partnerfunktionen finden

Achten Sie bei der Suche nach der passenden Kunden- oder Partnerfunktion in SAP besonders auf die deutschen Abkürzungen.

Wenn Sie beispielsweise einen Verkaufsauftrag anlegen, wird in der SAP -Benutzeroberfläche möglicherweise ein Name wie „Auftraggeber“ oder die sprachspezifische Partnerfunktion „SP“ angezeigt. Die SAP API verwendet jedoch stattdessen die deutsche Abkürzung „AG“, wie in der ersten Spalte gezeigt:

Partnerfunktion Sprache Name Sprachspezifische Partnerfunktion
AG EN Auftraggeber SP
RE EN Rechnungsempfänger BP
RG DE Zahler PY
WE EN Warenempfänger SH

Verwenden des SAP Function Builders zum Modellieren eines API Aufrufs

Beim Zuordnen von Daten in einer Transformation mithilfe eines BAPI- oder RFC-Ziels ist es hilfreich, die genauen Werte zu testen, nach denen SAP sucht, da das, was in der SAP -GUI angezeigt wird, oft nicht das ist, was in der SAP API verwendet wird.

Mit dem SAP Transaktionscode SE37 können Sie auf den Function Builder von SAP zugreifen, um einen BAPI- oder RFC-Aufruf zu modellieren. Ein vollständiges Beispiel finden Sie unter Teil 2: Modellieren der Abfrage in der SAP Instanz in Leitfaden zur Verwendung von RFC_READ_TABLE zum Abfrage von SAP -Tabellen.

Umgang mit BAPI-Konventionen

Bestimmte BAPIs - wie BAPI_SALESORDER_CREATEFROMDAT2 - verfügen über Feldsätze, die eine besondere Behandlung erfordern.

Wie unten gezeigt, sind die in der Header zugeordneten Felder (ORDER_HEADER_IN) wiederholen sich in der *_INX Um SAP mitzuteilen, dass Sie die Header Felder ausfüllen möchten, fügen Sie ein "X" als Feldwert in jedem der Felder, die eine Wiederholung eines Header-Felds sind:

Anhang

Im ORDER_ITEMS_INX Abschnitt, der ITM_NUMBER Feld unter ORDER_ITEMS_INX hat kein "X" eingefügt, sondern erhält die gleiche Artikelnummer wie im Feld ORDER_ITEMS_IN:

Anhang

Partnerfunktionen mit zusätzlichen Ordnern verwalten

In diesem Abschnitt müssen wir Verkauft an, Lieferan und Rechnungsan übergeben. Wir haben zusätzliche Ordner für die Zuordnung hinzugefügt und die Partnerrollen (AG, WE, RE) standardmäßig festgelegt:

Anhang

Abwicklung von Partnerfunktionen mit demSetInstances Funktion

Alternative zum Hinzufügen neuer Ordner ist die Verwendung von SetInstances() Funktion ohne zusätzliche Ordner:

Anhang

Im Grundzustand würden wir eine Reihe von Arrays innerhalb eines PartnersArray und stellen Sie es auf ORDER_PARTNERS Verwendung:

SoldToParentArray = Array();
Set(SoldToParentArray, "AG", -1);
Set(SoldToParentArray, Order$Header$Sold_To_Customer_Number$, -1);

ShipToParentArray = Array();
Set(ShipToParentArray, "WE", -1);
Set(ShipToParentArray, Order$Lines$Line#1.Customer_Number$, -1); // new change

BillToParentArray = Array();
Set(BillToParentArray, "RE", -1);
Set(BillToParentArray, Order$Header$Bill_To_Customer_Number$, -1);

PartnersArray = Array();
Set(PartnersArray, SoldToParentArray, -1);
Set(PartnersArray, ShipToParentArray, -1);
Set(PartnersArray, BillToParentArray, -1);

SetInstances("ORDER_PARTNERS", PartnersArray);
True

Im Ordner Bedingung unter ORDER_PARTNERS, um die Instanzen festzulegen, die wir verwenden würden:

$instanceReference = GetInstance();
True

Weitere Einzelheiten finden Sie in den Jitterbit-Funktionen Set(), GetInstance(), Und SetInstances().

Umgang mit inkrementellen Zeilennummern

Im Abschnitt ORDER_SCHEDULES_IN, würden wir noch einmal eine "X" in den Datenfeldern.

Anhang

Für das Feld SCHED_LINE, erhöht SAP sie um 10 (Zeile 10, Zeile 20, Zeile 30 usw.). Wir können eine globale Variable counter in der Bedingung unter ORDER_SCHEDULES_IN So berechnen Sie den Wert:

If(Length($ItemLineCounterS) == 0, $ItemLineCounterS = 0);
$ItemLineCounterS = $ItemLineCounterS + 10;
True

Weitere Einzelheiten finden Sie in der Jitterbit-Funktion Length().

Abrufen von Werten aus einem IDoc

Hier möchten wir Start- und Enddatum aus einem IDoc abrufen, um einen Vertrag zu erstellen. Die Daten befinden sich hier:

Anhang

In E1EDP03, wir wollen die DATUM Wert, wobei IDDAT == 107 (oder 108) für das Start- bzw. Enddatum. Eine praktische Funktion hierfür ist der Jitterbit FindValue() Funktion. Diese Funktion durchläuft die IDDAT Werte, finden Sie die mit "107" und rufen Sie die DATUM Feld:

result=FindValue("107", OUTPUT$ORDERS05.IDOC$E1EDP01.E1EDP03#.IDDAT$, OUTPUT$ORDERS05.IDOC$E1EDP01.E1EDP03#.DATUM$);

Fehlerbehebung bei BAPI-Commits

In einigen Szenarien kann es vorkommen, dass die Ausführung eines BAPI zwar scheinbar erfolgreich ist, die erwartete Transaktion jedoch nicht an SAP übermittelt wird.

Dies kann passieren, wenn ein BAPI einen anderen Antworttyp zurückgibt als S (Erfolgreich). Der SAP Connector von Jitterbit gibt standardmäßig nur dann ein BAPI-Transaktions-Commit (im selben Thread) aus, wenn eine BAPI-Antwort Erfolgreich lautet. Es wird jedoch kein Transaktions-Commit ausgegeben, wenn die BAPI-Antwort etwas anderes als Erfolgreich lautet.

Der Antworttyp kann beispielsweise sein I (Information), E (Fehler) oder W (Warnung). Der Antworttyp wird zurückgegeben in RETURN TYPE-Feld des Knotens:

Anhang

Wenn Sie ein angepasstes BAPI verwenden, empfehlen wir, das BAPI so zu ändern, dass es ein Erfolg zurückgibt.