Anwenderhandbuch (SAP2EVI)

Einleitung

Die Webservice-Online-Integration (WOI) überträgt per Webservice Daten (z.B. Geschäftspartner oder Kontakte) von SAP nach EVI. Die Übertragung erfolgt ereignisgesteuert. Die zu übertragenden Ereignisse werden über die SAP-Ereignistypkopplung konfiguriert. Die Übertragung erfolgt asynchron, um die Performance im SAP nicht zu beeinflussen.

Im EVI werden die Daten mittels BPM-Prozess verarbeitet und in das EVI-Datenmodell übernommen. Die Verarbeitungslogik liegt dabei nahezu komplett im EVI und kann kundenindividuell übersteuert werden, ohne die Updatefähigkeit des Moduls zu verlieren.

Neben dem Abgleich der Stammdaten werden auch Schlüsselwerte inkl. Bezeichnungen (Langtexte) übertragen und aktualisiert.

Produktbeschreibung

Schlüsselabgleich

Über einen zyklischen Job in SAP werden definierte Schlüsseltabellen (Key + Schlüsselbeschreibung) nach EVI übertragen. In EVI kann je Schlüsselbereich definiert werden, ob die Schlüsselbeschreibung aktualisiert werden soll oder nicht. Schlüsselbeschreibungen mit "bitte pflegen" werden immer aktualisiert. Neue Schlüssel werden lediglich über die einzelnen Worker mit der Schlüsselbeschreibung "bitte pflegen" angelegt. In den EVI-Nutzdaten sind somit nur von SAP verwendete Schlüssel vorhanden. In der C12-KEY-Tabelle sind alle in SAP vorhandenen Schlüssel ersichtlich (für die relevanten Schlüsseltabellen).

Geschäftspartner

Der Name für den verwendeten WORKER-Prozess lautet: C12OSST_WORKER_GP.

Die Webservice-Online-Integration überträgt per Webservice Geschäftspartner inkl. Adress- und Telekom-Daten von SAP nach EVI. Die SAP-Daten werden in strukturgleichen C12-SAP-Tabellen im EVI abgelegt. Alle zu einem Geschäftsvorfall (Geschäftspartner) gehörenden Daten werden über die WOI-TRANS Tabelle gebündelt. Über einen Verarbeitungsstatus in dieser Tabelle werden die Daten per BPM-Job (Timer) abgearbeitet. In dem folgenden Abschnitt sind hierbei die relevanten bzw. implementierten Felder / Tabellen aufgeführt.

Kundenindividuelle Erweiterungen (Standard- oder Z-Felder) sind möglich, müssen jedoch im Projekt spezifiziert und bewertet werden.

Kontakte/Aktivitäten

Die Webservice-Online-Integration überträgt per Webservice SAP-Kontakte nach EVI. In EVI werden diese als Aktivität gespeichert. Die SAP-Daten werden in strukturgleichen C12-SAP-Tabellen im EVI abgelegt. Textformatierungen werden dabei nicht mit übernommen. Alle zu einem Kontakt gehörenden Daten werden über die WOI-TRANS Tabelle gebündelt. Über einen Verarbeitungsstatus in dieser Tabelle werden die Daten per BPM-Job (Timer) abgearbeitet. In dem folgenden Abschnitt sind hierbei die relevanten bzw. implementierten Felder / Tabellen aufgeführt.

Anschlussobjekte

Die Webservice-Online-Integration überträgt per Webservice SAP-Anschlussobjekte nach EVI. Die SAP-Daten werden in strukturgleichen C12-SAP-Tabellen im EVI abgelegt. Alle zu einem Anschlussobjekt gehörenden Daten werden über die WOI-TRANS Tabelle gebündelt. Über einen Verarbeitungsstatus in dieser Tabelle werden die Daten per BPM-Job (Timer) abgearbeitet. In dem folgenden Abschnitt sind hierbei die relevanten bzw. implementierten Felder / Tabellen aufgeführt.

Vertragskonto

Die Webservice-Online-Integration überträgt per Webservice SAP-Vertragskonten nach EVI. Die SAP-Daten werden in strukturgleichen C12-SAP-Tabellen im EVI abgelegt. Alle zu einem Vertragskonto gehörenden Daten werden über die WOI-TRANS Tabelle gebündelt. Über einen Verarbeitungsstatus in dieser Tabelle werden die Daten per BPM-Job (Timer) abgearbeitet. In dem folgenden Abschnitt sind hierbei die relevanten bzw. implementierten Felder / Tabellen aufgeführt.

Bankverbindung

Die Webservice-Online-Integration überträgt per Webservice SAP-Bankverbindungen nach EVI. Die SAP-Daten werden in strukturgleichen C12-SAP-Tabellen im EVI abgelegt. Alle zu einer Bankverbindung gehörenden Daten werden über die WOI-TRANS Tabelle gebündelt. Über einen Verarbeitungsstatus in dieser Tabelle werden die Daten per BPM-Job (Timer) abgearbeitet. In dem folgenden Abschnitt sind hierbei die relevanten bzw. implementierten Felder / Tabellen aufgeführt.

PDOC/Wechselinformationen

Die Webservice-Online-Integration überträgt per Webservice SAP-PDOCs nach EVI. Die SAP-Daten werden in strukturgleichen C12-SAP-Tabellen im EVI abgelegt. Alle zu einem PDOC gehörenden Daten werden über die WOI-TRANS Tabelle gebündelt. Über einen Verarbeitungsstatus in dieser Tabelle werden die Daten per BPM-Job (Timer) abgearbeitet. In dem folgenden Abschnitt sind hierbei die relevanten bzw. implementierten Felder / Tabellen aufgeführt.

Benutzerhandbuch

Grundlagen zur Technik

Diese Software bindet eine weitere Datenbankanwendung an das SAP-System in der Form, dass Daten, die im SAP-System neu erfasst oder geändert wurden, kurzfristig in das Zielsystem übertragen werden. Kurzfristig heißt: innerhalb von wenigen Sekunden bis wenigen Minuten, je nach Einstellung.

Die Übertragung läuft asynchron und in der Regel über die Ereignistypkopplung. Das bedeutet:

• Auch bei Massenänderungen wird die Performance des SAP-Systems nicht beeinträchtigt.

• Wenn das Zielsystem oder die Netzwerkverbindung ausfällt, werden keine Prozesse in SAP behindert. Die Übertragung wird nachgeholt, sobald das Zielsystem wieder erreichbar ist. Trotzdem besteht keine Gefahr, dass der zuletzt übertragene Datenstand durch einen älteren überschrieben wird, der zu einer Zeit galt, als die Verbindung ausfiel.

• Datenänderungen, die direkt auf der Datenbank gemacht werden (ohne ein Ereignis auszulösen), werden zunächst nicht übertragen.

• Datenänderungen, die keine Ereignisse auslösen, können übertragen werden, indem entweder das Programm selbst, das die Änderung erzeugt, Ereignisse in die Arbeitstabelle schreibt oder indem regelmäßig ein Job läuft, der bestimmte Änderungen abfragt und Ereignisse in die Arbeitstabelle schreibt.

Die Übertragung erfolgt dadurch, dass das SAP-System Webservice-Anfragen an das Zielsystem schickt. Diese Anfragen enthalten sämtliche zu übertragenen Daten. Die Antwort besteht nur in einer Erfolgs- oder Fehlermeldung.

Diese Übertragung per Webservice kann ohne Programmierung sehr flexibel konfiguriert werden. Alle Tabellen, die irgendwie mit dem jeweiligen Ereignis verknüpft sind, können ausgelesen werden, ebenso können beliebige (auch kundeneigene) Felder ausgelesen werden. Allerdings müssen die Tabellen im Zielsystem wieder miteinander verknüpft werden, d.h. der Export erfolgt auf Tabellenebene.

Ein Export von langen Texten, z.B. Texten zu einem Kontakt oder Vertragskontonotizen, können ebenfalls exportiert werden. Dazu wird formal die Tabelle STXH exportiert. Die erzeugte XML-String sieht so aus, als hätte diese Tabelle zusätzlich das Feld TDLINE, in dem der gesamte Text steht. Es gibt hier keine Begrenzung der Länge.

Der erzeugte XML-String muss genau zu der Definition des Webservice-Providers im Zielsystem passen. Die mitgelieferte ABAP=>XML-Transformation /SEB/OSST kann verwendet oder als Beispiel für eine eigene Transformation verwendet werden. Wenn die Ereignisse (testweise) online (und nicht in einem Hintergrundjob) übertragen werden, wird sowohl der XML-String der Webservice-Anfrage als auch die Rückmeldung in einem Struktureditor angezeigt. Das ist bei der Entwicklung der Transformation bzw. des Webservice-Providers sehr hilfreich.

Deshalb hier nur kurz: Mit jedem Aufruf wird ein Eintrag in eine Transaktionstabelle (im Zielsystem) geschrieben. Diese enthält (mindestens) folgende Felder: BOBJ (Business Object, entsprechend dem Objekttyp in der Ereignistypkopplung, z.B. ISUPARNER), PAKET (siehe nächstes Kapitel, max. 10 Zeichen), EVENT (Ereignis aus der Typkopplung, z.B. CHANGED), OBG (Ordnungsbegriff, OBJKEY aus der Typpkopplung) und TRANS_STATUS (immer mit T belegt).

Außerdem hat jede Tabelle im Zielsystem, auch die Transaktionstabelle, ein Feld mit dem Namen TRAID: Transaktions-ID. Über diese können bei asynchroner Verarbeitung im Zielsystem die Daten verknüpft werden, die zu einer Webservice-Anfrage gehören.

Ereignisse, Pakete und Tabellen

Ein Paket ist die Einheit, die bei einem Webservice-Aufruf übertragen wird. Es kann die Daten aus bis zu 10 Tabellen enthalten.

Ein Ereignis ist z.B. das Anlegen oder Ändern eines Geschäftspartners. In der Regel sollen in beiden Fällen (Anlegen oder Ändern) dieselben Daten übertragen werden. So wird einfach dasselbe Paket, z.B. GP, bei beiden Ereignissen verwendet. Andererseits kann die Beschränkung auf 10 Tabellen umgangen werden, indem bei einem Ereignis mehrere Pakete eingetragen werden.
Ein Beispiel: Tabelle /SEB/OSSTEVENTPK

Wenn ein Kontakt geändert oder erstellt wird, wird das Paket KNT übertragen, bei dem Anschlussobjekt OBJ und bei dem Geschäftspartner GP. Die Definition, welche aus Tabellen bei einem Paket selektiert wird und wie diese verknüpft werden, ist leider etwas komplex.

Zur Erklärung ein Beispiel:

TABNAME ist die Tabelle, aus der selektiert wird. VERKN_FELD ist das Feld, über das die Tabelle TABNAME verknüpft ist, also das Selektionskriterium. QUELLETABELLE und QUELLFELD sind der Verweis, womit verknüpft wird.

In der ersten Zeile muss REIHENFOLGE = 0 sein. QUELLTABELLE und QUELLFELD müssen hier leer sein. Die Verknüpfung erfolgt mit dem Schlüssel OBJKEY aus dem Ereignis, also bei einem Geschäftspartner mit der Geschäftspartnernummer. Es wird also der Datensatz aus der Tabelle BUT000 gelesen, bei dem im Feld PARTNER die GP-Nummer steht, die bei der Ereignistypkopplung übergeben wurde.

Dann werden bei REIHENFOLGE = 1 alle Datensätze aus der Tabelle BUT021_FS gelesen, deren PARTNER mit dem PARTNER aus der BUT000 übereinstimmt. (Weitere Selektionskriterien stehen in der Tabelle zur Definition der Felder.)

Ebenso wird die Adresse aus der Tabelle ADRC anhand der ADDRNUMBER, die in der BUT021_FS gefunden wird, gelesen.

Bei der ADR2 (Telefonnummern) wird die ADDRNUMBER ebenfalls mit der aus der BUT021_FS verknüpft aber zusätzlich noch angegeben, dass das Feld PERSNUMBER leer sein muss. Dazu wird statt der Quelltabelle ein Vergleichsoperator angegeben, der aus zwei Buchstaben besteht. Im Feld QUELLFELD steht dann der Vergleichswert. Wenn der Vergleichswert fehlt, wird der typgerechte Initialwert angenommen, also bei einem Zeichenfolgefeld ein Leerzeichen.

Details zur dem Vergleichsoperatoren stehen im Benutzerhandbuch zum universellen Datenexport.

Wenn in der Verknüpfungsspezifikation ein Vergleichsoperator angegeben ist, wird ein eventuelles Selektionskriterium, das bei diesem Feld in der Exportspezifikation angegeben ist, wirkungslos. Die Kriterien aus der Exportspezifikation, die bei Feldern stehen, die in der Verknüpfungsspezifikation nicht angegeben sind, werden weiterhin angewendet.

Ebenso werden aus den Tabellen ADR3 und ADR6 die Faxnummern und Email-Adressen gelesen. Diese Verknüpfung liefert adressunabhängigen Kommunikationsdaten.

Dieses Beispiel zeigt auch, dass aus derselben Tabelle mehrmals gelesen werden kann. Bei Reihenfolge 6 bis 8 steht die Selektion der adressabhängigen Kommunikationsdaten.

Export der Schlüsseltabellen

Um die Belastung des SAP-Systems, das übertragene Datenvolumen und die Beanspruchung des Zielsystems möglichst gering zu halten, auch wenn z.B. sehr viele Kontakte in kurzer Zeit übertragen werden, sollten z.B. bei jedem Kontakt nur die Kürzel für den Kontaktanlass und das Kontaktergebnis übertragen werden. Die Umcodierung in die Bezeichnungen, die auf der Benutzeroberfläche zu sehen sind, sollte ausschließlich im Zielsystem erfolgen.

Dazu müssen die entsprechenden Schlüsseltabellen im Zielsystem aktuell gehalten werden. Diese werden z.B. jede Nacht oder sogar stündlich komplett übertragen. Dazu wird derselbe Mechanismus verwendet. Es gibt jedoch ein paar Sonderregelungen.

• Das Pseudo-Ereignis KEY ist für den Export der Schlüsseltabellen fest im Programm vorgegeben.

• Das Feld für das Ereignis ist leer.

• Die Felder VERKN_FELD, QUELLTABELLE und QUELLFELD sind in der Regel leer. Es ist jedoch auch hier möglich, Selektionsbedingungen anzugeben, z.B. um nur einen Teil der Schlüsseltabelle zu exportieren oder um eine sehr große Tabelle auf mehrere Webservice-Aufrufe aufzuteilen.

• Eine Verknüpfung mit der Systemsprache sy-langu ist möglich, indem das Verknüpfungsfeld (z.B. SPRAS oder LANGU) in VERKN_FELD eingetragen wird, aber QUELLTABELLE (und QUELLFELD) leer bleiben. Auch an dieser Stelle überschreibt die Selektionsbedingung aus der Verknüpfungsspezifikation die aus der Exportspezifikation.

• Der Export erfolgt mit dem Report /SEB/OSST_KEYTRANSFER statt mit dem /SEB/OSST_EVENTTRANSFER.

• Der Job wird manuell eingeplant (mit dem fest vorgegebenen Namen OSST_TRANSFER).

Hier als Beispiel die weiteren Einträge:

Tabelle /SEB/OSSTEVENTPK

Tabelle /SEB/OSSTVERKNPF

Mit dem Paket KEY_ADR1 wird erst die gesamte Tabelle T005T exportiert und anschließend die T005U: erst die Länder, deren Kürzel mir einem Buchstaben vor J (also A bis I) anfängt, dann der Teil ab J.

Exportspezifikation

Bei der Entwicklung der Webservice-Integration (WSI) wurde davon ausgegangen, dass der universelle Datenexport (UDE) im System vorhanden ist und zumindest für den initialen Aufbau des Zielsystems verwendet wurde. Somit ist in der Tabelle /SEB/EXPORTSPEZ bereits eingetragen, welche Felder bei den einzelnen Tabellen exportiert werden sollen, ebenso eventuelle Selektionsbedingungen für die einzelnen Tabellen. In der Regel möchte man bei der WSI dieselben Felder exportieren. Deshalb wird diese UDE-Tabelle auf für die WSI verwendet, allerdings um zwei Felder erweitert: CRMTAB und CRMFIELD: Tabellenname und Feldname im Zielsystem. (Dabei wurde vorrangig an ein CRM-System gedacht.)

Bei dem UDE können mehrere Export-Projekte definiert werden, z.B. Stamm- und Abrechnungsdaten oder Daten für ein EDM-System und für das Portfoliomanagement. Die Tabellen, die über die WSI aktuell gehalten werden, können zu verschiedenen UDE-Projekten gehören. Allerdings müssen alle Felder einer Tabelle, bei der CRMTAB / CRMFIELD für die WSI eingetragen ist, zu demselben Projekt gehören.

Aus Sicht der WSI steht die Exportspezifikation in /SEB/OSSTEXPSPEZ . Das ist eine View, die die Tabellen /SEB/EXPORTSPEZ und /SEB/OSST_FELDER verknüpft. Sie enthält nur die Datensätze, bei denen CRMTAB / CRMFIELD gefüllt sind.

Als Beispiel einige Datensätze aus der /SEB/OSSTEXPSPEZ.

Ein X im Feld NSEL (nicht selektieren) bedeutet, dass dieses Feld nicht exportiert werden soll, sondern nur der Selektion dient.

Im Feld VERGLEICHSTYP steht der Vergleichsoperator:

VERGLEICHSWERT: Wert mit dem verglichen wird. Strings sind – außer bei den freien Selektionen IN, EX und FS – ohne Texttrennzeichen anzugeben. Alle Buchstaben werden als Großbuchstaben interpretiert. Leerzeichen am Ende werden ignoriert. Bei Vergleichen mit einem Bereich wird die Zeichenfolge „ AND “ verwendet. Die Leerzeichen vor und nach dem Wort „AND“ sind wichtig.

Datumsangeben werden in der Form JJJJMMTT angegeben. Der 25. März 2003 ist zu schreiben als 20030325 . Das Wort SYSDATE steht für das aktuelle Datum. Hier kann man außerdem eine feste Anzahl von Tagen addieren oder subtrahieren, z.B. ein Intervall SYSDATE-100 AND SYSDATE+20 . SYSDATE kann auch bei Feldern vom Typ Zeit verwendet werden und stellt die Uhrzeit dar, zu der der Export gestartet wurde. Ein Offset wird in Sekunden interpretiert.

In dem Feld Vergleichswert kann auch eine Auflistung von Werten stehen. Diese sind durch ein Komma zu trennen. Eine Aufzählung von Mustern ist möglich. Achtung: nach dem Komma darf kein Leerzeichen stehen, weil dieses als Teil des Strings betrachtet wird, mit dem verglichen wird.

Fehlt der Vergleichswert, so wird der typgerechte Initialwert eingesetzt. Insbesondere wird bei einem Datumsfeld '00000000' eingesetzt.

Upload und Download des Customizings

Die Konfiguration der WSI wird direkt im Produktivsystem vorgenommen – auch wenn es theoretisch möglich ist, die Inhalte der betroffenen Tabellen explizit in einen Transportauftrag aufzunehmen und durchzutransportieren.

Die Zuordnung zwischen Ereignissen und Paketen (Tabelle /SEB/OSSTEVENTPK) sowie die Auswahl und Verknüpfung der Tabellen in den einzelnen Paketren (Tabelle /SEB/OSSTVERKNPF) müssen als tabulatorgetrennte Textdatei (z.B. mit Excel erstellt) vorliegen und werden mit dem Report /SEB/OSST_CUSTOMIZING_UPLOAD (Transaktion /SEB/OSST_CUSTOM_IMP) hochgeladen. Dieser macht zahlreiche Prüfungen, kann jedoch nicht garantieren, dass die WSI auch fehlerfrei funktioniert. Außerdem dient dieser Report auch dazu, die Parametertabelle /SEB/OSSTP hochzuladen, siehe Installationsanleitung.

Dateien, die nicht hochgeladen werden sollen, brauchen einfach nicht angegeben zu werden.

Die Exportspezifikation des UDE wird mit dem Report /SEB/EXPORTSPEZ_UPLOADU (Transaktion /SEB/SPEZ_UPLOAD) bzw. /SEB/EXPORTSPEZ_UPLOADB (Transaktion /SEB/SPEZ_UPLOADB) hochgeladen (ohne bzw. mit Berechtigungsprüfung). Die Exportspezifikation, die für die WSI auch die Felder CRMTAB und CRMFIELD füllt, wird mit /SEB/EXPORTSPEZ_UPLOAD_OSST (Transaktion /SEB/SPEZ_UPL_OSST) bzw. /SEB/EXPORTSPEZ_UPLOAD_OSSTB (Transaktion /SEB/SPEZ_UPL_OSSTB) (mit Berechtigungsprüfung) hochgeladen. Diese vier Varianten können auch echte Excel-Dateien (als *.xls) verarbeiten, sofern auf dem Frontend Excel installiert ist.

Das gesamte WSI-relevante Customizing kann mit dem Report /SEB/OSST_CUSTOMIZING_DOWNLOAD (Transaktion /SEB/OSST_CUSTOM_EXP) exportiert werden. Als Parameter wird nur der Dateipfad angegeben. In diesem Verzeichnis werden die Dateien OSSTEVENTPK_JJJJMMTT_HHMISS.txt, OSSTVERKNPF_JJJJMMTT_HHMISS.txt, OSSTEXPSPEZ_JJJJMMTT_HHMISS.txt und OSSTP_JJJJMMTT_HHMISS.txt erzeugt. Mit JJJJMMTT_HHMISS ist das Datum und die Uhrzeit des Exports gemeint.

Ereignistypkopplung

In der Ereignistypkopplung, Transaktion SWETYPV, muss bei den Ereignissen, die über die WSI übertragen werden sollen, der Funktionsbaustein /SEB/OSST_EVENT_LOG als Verbraucher-Funktionsbaustein eingetragen werden.

Der Objekttyp kann über ein Ereignis-Trace ermittelt werden: ein- bzw. ausschalten mit Transaktion SWELS, Trace anzeiegn mit SWEL, Trace löschen mit RSWELOGD.

Nachdem der Objekttyp eingetragen wurde, kann das Ereignis über die Werthilfe gefunden werden.

Der Verbrauchertyp ist völlig beliebig. Er wird an an Funktionsbaustein übergeben, jedoch nicht ausgewertet.

Der Funktionsbaustein /SEB/OSST_EVENT_LOG schreibt für jedes Paket, das dem Ereignis zugeordnet ist, einen Datensatz in die Tabelle /SEB/OSST_EVENT. Anschließend wird der Job OSST_EVENTTRANSFER mit dem Report /SEB/OSST_EVENTTRANSFER eingeplant – sofern einerseits der Job OSST_TRANSFER (für die Übertragung der Schlüsseltabellen) eingeplant ist und andererseits nicht schon ein OSST_EVENTTRANSFER-Job eingeplant ist oder läuft.

Anhang

Die Tabelle /SEB/OSST_EVENT und die Transkations-ID

In TIMESTAMP steht der Zeitpunkt des Ereignisses, so dass leicht die Ereignisse eines Zeitraumes selektiert werden können.

Die Transaktions-ID TRAID ist zusammengesetzt aus TIMESTAMP, PAKET, OBJKEY und einer laufenden Nummer, jeweils durch Unterstriche getrennt. Die laufende Nummer zählt die Versuche, dieses Ereignis zu übertragen. Vor der Übertragung ist sie 0, nach der Übertragung in der Regel 1.

Fehlercodes und gespeicherte Fehlermeldungen

Wenn bei der Verarbeitung eines Ereignisses ein Fehler auftritt, wird ein zweistelliges Kürzel in das Feld ERRORCODE in der Tabelle /SEB/OSST_EVENT geschrieben. Die Tabelle /SEB/OSSTE ist einerseits Werthilfe für dieses Feld, andererseits ist dort auch hinterlegt, ob eine individuelle Beschreibung des Fehlers in die Tabelle /SEB/OSST_ERROR geschrieben wird. Die /SEB/OSSTE hat keine steuernde Wirkung, sondern dient rein der Dokumentation.

In der Tabelle /SEB/OSST_ERROR wird z.B. die Fehlermeldung des Zielsystems abgelegt oder ein ungültiges SQL-statement infolge eines Fehlers in der Verknüpfungsspezifikation /SEB/OSST_VERKNPF. Der Primärschlüssel der /SEB/OSST_ERROR ist (der Mandant und) die TRAID, so dass für jeden Versuch, ein Ereignis zu übertragen, eine Fehlermeldung gespeichsert werden kann. Außerdem kann wegen des Zeitstempels am Anfang der TRAID auch hier ein Zeitraum selektiert werden.

Bei dieser Vorgabe werden die Fehlermeldungen ausgegeben, die von Anfang Februar 2016 bis zum 8. April 2016 um 15:19 (ausschließlich) aufgetreten sind.

Worker

In diesem Abschnitt werden alle implementierten Worker beschrieben. Ein Worker ist ein BPM-Prozess, der für die Verarbeitung eines bestimmten EVI-Datensatzes oder EVI-Datenkonstrukt zuständig ist.

Bei jeder Ausführung eines Workers, wird geprüft ob eine vorherige Übertragung von EVI => SAP fehlgeschlagen ist. Ist dies der Fall, wird die Aktualisierung von SAP nach EVI unterbunden. Dies gilt sowohl für die Nacht (Batch) als auch die Online Variante WOI. Bei einem Geschäftspartner würde die Prüfung beispielsweise folgendermaßen ablaufen:

• Gibt es zu der Geschäftspartner Nummer (OBG.C12TRANS = CustomerNo2.Customer) einen Datensatz? Unabhängig von dem Event CHANGE oder CREATE.

• Wenn Ja, Prüfen ob es zu dem Primärschlüssel (Pk.Customer) einen Datensatz in der C12TRANS Tabelle gibt mit folgenden Bedingungen:

  1. C12TRANS = EVI2SAP

  2. C12TRANS = FALSE

  3. C12TRANS != F (Finished)

In diesem Fall wird die Verarbeitung abgebrochen. Im Transaktionsdatensatz wird folgendes protokolliert:

"Übertragung abgebrochen. Es gibt eine offene Transaktion zu dem gleichen Datensatz siehe EVI-Transaktions-ID: <TRAID_EVI.C12TRANS>.
Dies bitte zunächst auflösen und dann den Status auf Restart setzen zum erneuten übertragen."

Die Prüfung erfolgt in folgender Methode "SC12OSSTUtils.isAnyErrorOccuredForOBG(String transPk)".

Weitere Prüfbedingungen:

 → Wenn Nein, normale Verarbeitung.

Funktionsbeschreibung

Über den Button "EVI Datensatz öffnen" in der Aktionsbox der Entität "TRANS (SAP)" ist es möglich, die verarbeiteten Datensätze im EVI zu öffnen.