Smart-Synchronization-Mechanismus 

Verwendung

Der Synchronisationsprozess für alle Anwendungen, die auf Smart-Synchronization basieren, hat folgende Merkmale:

●      Viele Elemente in den Synchronisationskomponenten von Smart-Synchronization sind so ausgelegt, dass jederzeit die sequenzielle Nachrichtenverarbeitung und die einmalige Übertragung sichergestellt sind. Für die garantierte Übertragung der Nachricht ist die Synchronisationsschicht zuständig.

●      Jede Nachricht von einem Gerät wird in Smart-Synchronization über einen Status gesteuert. Der Administrator kann jede Nachricht in unterschiedlichen Status anzeigen.

●      Smart-Synchronization ist ein Framework, das besonders für die Bereitstellung der Entwicklungstools und Synchronisationsfunktionen für Offline-Anwendungen entwickelt wurde. Smart-Synchronization-Prozesse werden daher normalerweise im asynchronen Modus in der SAP MI Server Component ausgeführt.

Für die Synchronisation steht auch der synchrone Modus zur Verfügung. Der grundlegende Synchronisationsmechanismus ist identisch beim synchronen und asynchronen Modus.

Technisch gesehen wird für beide Modi dasselbe Nachrichtenprotokoll verwendet. Der Unterschied liegt in der Zeit, die vergeht, bis eine Antwort vom Server kommt.

●      In der SAP MI Client Component gibt es kein anwendungsspezifisches Coding, das direkt mit den Synchronisationsprozessen interagiert. Anwendungsspezifisches Coding ist nur dann erforderlich, wenn es um lokale Daten im Rahmen der MI-Client-APIs geht. Bei Anwendungsdaten, die lokal in der Persistenzschicht abgelegt werden, halten die zugrunde liegenden Komponenten der MI-Client-APIs die Gerätedaten synchron mit dem Backend.

Fehler- und Konfliktbehandlung sind Ausnahmen. Zur Behandlung von Synchronisationsfehlern mithilfe anwendungsspezifischer Logiken, bietet Smart-Synchronization Funktionen für den Zugriff auf detaillierte Fehler- und Konfliktinformationen.

Funktionsumfang

Schritte bei Smart-Synchronization

Smart-Synchronization ist so ausgelegt, dass die Programmierung für Offline-Anwendungen ermöglicht wird und eine generische Synchronisationsinfrastruktur für eine solche Anwendung bereitgestellt wird. Dieses Framework ist unter der Annahme aufgebaut, dass eine stabile und nicht aufwendige Verbindung zwischen Client und Server in einer produktiven Umgebung unter Umständen nicht verfügbar ist. Die Anwendungen können daher die Daten zwischen dem Backend-System und den mobilen Endgeräten entweder im synchronen Modus oder asynchronen Modus synchronisieren.

Zur Aktivierung beider Synchronisationsmodi ist der Synchronisationsmechanismus technisch in zwei getrennte Bereiche aufgeteilt. Im synchronen Modus werden beide Verarbeitungsbereiche vom mobilen Endgerät aus innerhalb einer Verbindung ausgeführt. Im asynchronen Modus wird nur der erste Verarbeitungsblock ausgeführt, während die Verbindung vom Gerät gehalten wird.

Im asynchronen Modus werden Antwortnachrichten für Synchronisations-Requests vom mobilen Endgerät nur dann zum Gerät zurückgegeben, wenn das Gerät nach dem Abschluss einer asynchronen Ausführung auf der SAP MI Server Component erneut eine Verbindung herstellt.

Im synchronen Modus werden jedoch Synchronisations-Requests ausgeführt, während das Gerät online wartet, und die Antwort wird sofort an das Client-Gerät zurückgegeben.

Das Systemverhalten im synchronen Modus ist für den Benutzer generell leichter zu verstehen. Jedoch kann die Verbindungszeit hinsichtlich Kosten und Stabilität der Systemverbindung kritisch werden, wenn die Ausführung der Nachrichten zu lange dauert.

...

●      Übermittlung von Datenpaketen zwischen dem mobilen Endgerät und der SAP MI Server Component (Gerätesynchronisation)

In diesem Verarbeitungsblock werden die Request-Nachrichten zunächst vom mobilen Endgerät an die SAP MI Server Component übertragen, bevor sie im Smart-Synchronization-Eingang abgelegt werden. Im selben Schritt werden Datenpakete, die Requests aus demselben mobilen Endgerät gesammelt haben, aus dem MI-Ausgang abgerufen und zum Endgerät gesendet.

Die Request-Nachrichten von einem mobilen Endgerät in einem Synchronisationszyklus umfassen:

●        Upload-Nachrichten für alle seit der letzten Synchronisation auf dem Gerät angelegten, geänderten oder gelöschten Objekte.

●        Download-Request-Nachrichten für alle SyncBOs, die in der mobilen Anwendung auf dem Gerät enthalten sind.

Der Client verfügt über eine Option zur Deaktivierung des Sendens von Download-Requests, wenn es unangebracht wäre, sie in jedem Synchronisationszyklus zu senden. Bei Anwendungen steht diese Option durch das API zur Verfügung. Alternativ kann der Benutzer den Download unterdrücken, indem er dies auf der Benutzungsoberfläche der SAP MI Client Component einstellt.

Die Download-Request-Nachrichten von einem mobilen Endgerät in einer Synchronisation umfassen:

●        Antwortnachrichten für Upload-Nachrichten von demselben Client (Verarbeitungsergebnisse und -daten).

●        Antwortnachrichten für Download-Anfragenachrichten von demselben Client (Verarbeitungsergebnisse und -daten).

Alternativ können vom Client-Daten-Distributor Requests ausgelöst werden (Bericht MEREP_DISTRIBUTOR). Der Report legt Requests  für definierte Endgeräte, Gruppen oder Benutzer an, ohne dass dies der Client auslösen muss. Die Algorithmen zur Deltadatenermittlung sind dieselben wie für die vom Client ausgelöste Synchronisation.

●      Ausführung von Geräte-Request-Nachrichten im Smart-Sync-Eingang (Server-seitige Synchronisation)

In diesem Verarbeitungsblock werden für jede Gerätenachricht die folgenden Schritte ausgeführt:

○       Suchen von Deltadaten und Ablegen für den Download auf das Gerät (Downloader)

○       Datenverbuchung im Backend-System. Daten werden vom Gerät hochgeladen (Uploader)

Der Synchronisationstyp und die Nachrichteninhalte legen fest, welcher der beiden Schritte ausgeführt und wie er ausgeführt wird.

Der Deltadaten-Suchprozess sucht nach den Abweichungen zwischen den Daten der lokalen Datenbank auf dem Endgerät und den entsprechenden Daten im Backend-System.

Die folgenden Sätze werden Server-seitig als Deltadaten betrachtet und als Zielsätze ermittelt, die auf ein mobiles Gerät geschickt werden sollen:

○       Ein Datensatz, der bereits auf einem Gerät vorhanden ist und im Backend-System geändert/gelöscht wurde.

○       Ein Datensatz, der noch nicht auf einem Gerät vorhanden ist und im Backend-System angelegt wurde.

In beiden Fällen werden nur die Daten, die für das anfordernde mobile Endgerät berücksichtigt. Dies bedeutet, dass selbst bei Änderung der Datensätze im Backend-System die Änderungen nicht als Deltadaten ermittelt werden, wenn die Filtereinstellungen festlegen, dass die Daten für das spezifische Gerät nicht relevant sind.

Die Änderungen im Backend-System umfassen jene Änderungen, die durch die anderen mobilen Endgeräte vorgenommen wurden.

Ein SyncBO-Datenmodell ist in der Regel eine Untermenge von betriebswirtschaftlichen Daten im Backend-System. Bei der Deltadatensuche werden nur Datenfelder berücksichtigt, die im SyncBO zugeordnet wurden.

Ausgeführte Prozesse nach Synchronisationstyp

Synchronisationstyp	Downloader	Uploader	Replikation aus dem Backend
Upload (U01)	Wird nicht ausgeführt	Wird ausgeführt.	Wird nicht ausgeführt
2-Wege gepuffert (T01)	Wird ausgeführt. Die Daten in der Replikationsdatenbank stellen die Basisdaten für die Ermittlung von Deltadaten dar.	Wird ausgeführt, wenn die Nachricht Upload-Daten enthält	Wird durch eingeplanten Job angestoßen
Backend-gesteuert (T51)	Wird ausgeführt. Die Daten in der Replikationsdatenbank stellen die Basisdaten für die Ermittlung von Deltadaten dar.	Wird ausgeführt, wenn die Nachricht Upload-Daten enthält	Wird durch das Backend-System angestoßen
2-Wege (S01)	Wird ausgeführt. Die Daten im Backend-System stellen die Basisdaten für die Ermittlung von Deltadaten dar.	Wird ausgeführt, wenn die Nachricht Upload-Daten enthält	Wird durch das Gerät angestoßen

Um ein SyncBO anzulegen, das nur zum Herunterladen von Daten dient, verwenden Sie einen der Typen 2-Wege gepuffert (T01), Backend-gesteuert (T51) oder 2-Wege (S01) und geben Sie nur die BAPI-Verschalung GetList BAPI und optional die BAPI-Verschalung GetDetail an.

Datenreplik. aus d. Backend in die SAP MI Server Component (Replik.-Datenbank)

Je nach SyncBO-Typ werden die Daten unterschiedlich ermittelt.

Für SyncBOs des Typs 2-Wege gepuffert und Backend-gesteuert gleicht das System die Replikationsdatenbank mit den lokalen Daten auf einem mobilen Endgerät ab. Dies impliziert, dass die Replikationsdatenbank in einem separaten Prozess in regelmäßigen Abständen aktualisiert werden muss, um die Geräte sehr präzise zu synchronisieren.

●      Für SyncBOs des Typs 2-Wege-gepuffert (T01) wird der Replicator ausgeführt, um die Synchronisation zwischen dem Backend-System und der Replikationsdatenbank durchzuführen, normalerweise mit einem eingeplanten Hintergrundjob.

●      Für SyncBOs des Typs Backend-gesteuert (T51), sendet das Backend-System jeden Deltadatensatz direkt zur Replikationsdatenbank, wenn sich die Anwendungsdaten im Backend-System ändern. Dadurch reduziert sich der Datenverkehr zwischen Backend-System und SAP MI Server Component sowie der gesamte Replikationsprozess.

...

Für SyncBOs des Typs 2-Wege (S01) wird das Backend-System referenziert.

Die Synchronisationsmodi sind unabhängig vom Synchronisationstyp. Darüber hinaus können 2-Wege-SyncBOs  im synchronen Modus verarbeitet werden. Der Synchronisationsmodus wird in der Regel von der Client-Anwendung ermittelt.

Unterstützung mehrerer Sprachen

Daten können in mehreren Sprachen zur Verfügung gestellt werden, so dass Benutzer mit Daten in ihrer Sprache arbeiten können.

●      Für SyncBOs vom 2-Wege können Daten in mehreren Sprachen ohne weitere Einstellungen bearbeitet werden, da die Daten direkt aus dem Backend kommen. Die Replikationsdatenbank enthält nur die Daten, die für Geräte und Benutzer in der gewählten Sprache relevant sind.

●      Für SyncBOs vom Typ 2-Wege gepuffert and Backend-gesteuert, die entsprechend konfiguriert sind, enthält die Replicationsdatenbank Daten in mehreren Sprachen.  Bevor die Daten an das Gerät übertragen werden, werden sie konvertiert. Nur Daten in der Sprache des mobilen Gerätes werden an das Gerät übertragen. Wenn keine Sprache definiert ist, wird die Standardsprache ohne eine Konvertierung der Daten verwendet. 

 

Grundregeln Nachr.-Übertragung u. Synchronisation

●      Übertragungsgarantie

Es ist gewährleistet, dass Nachrichten, die zwischen der SAP MI Server Component und der SAP MI Client Component übertragen werden, dann an das Ziel übertragen werden. Das Protokoll zwischen der SAP MI Client Component und der SAP MI Server Component stellt sicher, dass alle Nachrichten ohne Ausnahme erneut gesendet werden, bis die Bestätigung für die vollständige Ankunft auf der anderen Seite vorliegt.

●      Sequenzielle Verarbeitung

Der Handler stellt sicher, dass alle Nachrichten, die von der SAP MI Client Component an die SAP ME Server Component gesendet werden, in der richtigen Reihenfolge verarbeitet werden. Die richtige Reihenfolge ist die Folge, in der die Nachrichten vom mobilen Endgerät aus gesendet wurden. Die SAP MI Client Component legt die Reihenfolge der Nachrichten fest, wobei die Reihenfolge der Benutzeraktionen bei den lokalen Daten strikt eingehalten wird.

●      Einmalige Ausführung

In einer Offline-Nachrichten-Umgebung, insbesondere für Geschäftsvorgänge, ist es wichtig, dass eine übertragene Nachricht am anderen Ende nur einmal verarbeitet wird. Ein Gerät überträgt z.B. eine Nachricht an die SAP MI Server Component, um einen Kundenauftrag anzulegen. Wenn die SAP MI Server Component diese Nachricht mehr als einmal ausführt, werden im Backend-System mehrere Einträge angelegt.

Wenn die Verarbeitung einer Nachricht z.B. zu einem Anwendungsfehler führt, lässt sich die Nachricht erneut verarbeiten, aber diese zweite Ausführung sollte durch einen Verantwortlichen – in der Regel den Administrator –  mit dem Monitoringtool angestoßen werden.

●      Alles-oder-nichts-Prinzip bei Objektverbuchungen (BAPI / BAPI-Verschalung)

Alle BAPIs folgen einer Grundregel, die als ‚Alles-oder-nichts-Prinzip’ bezeichnet wird. Hier führen die Methoden für die Verbuchung eines Business-Objekts die Verbuchung entweder vollständig oder überhaupt nicht aus. Es wird z.B. eine Methode aufgerufen, um einen Kundenauftrag mit zwei Auftragspositionen zu verbuchen. Wenn der Kopf und die beiden Positionen nicht fehlerfrei verbucht werden können, findet keine Verbuchung statt. Wenn ein Fehler auftritt, wird eine Nachricht mit einem Fehlertyp an das aufrufende Programm zurückgegeben, das bei Smart-Synchronization der Synchronizer ist.

SAP-Standard-BAPIs umfassen nie die Anweisungen COMMIT WORK oder ROLLBACK WORK. Dies ermöglicht es externen aufrufenden Programmen – je nach den Ergebnissen der Aufrufe der BAPI-Methoden – explizit Anweisungen wie COMMIT WORK oder ROLLBACK WORK auszugeben, je nach den Ergebnissen der Aufrufe der BAPI-Methoden. Dennoch erwartet Smart-Synchronization, dass die BAPI-Verschalungen die Anweisungen COMMIT WORK oder ROLLBACK WORK umfassen.

Fluss von Nachrichtenstatus

In Smart-Synchronization-Prozessen haben Nachrichten von und zu einem mobilen Endgerät verschiedene Status. Eine Nachricht, die vom Server empfangen wurde, hat zunächst den Status Wartet und nach der Verarbeitung schließlich den Status Fertig. Die folgende Tabelle zeigt die unterschiedlichen Status, sowie Beschreibungen und Kommentare dazu.

Technisch gesehen werden dieses Status in den Smart-Synchronization-Worklist-Items abgelegt, die einem Nachrichtenkopf für jede Nachricht von und zu einem mobilen Endgerät entsprechen.

Statusbeschreibung

Status	Beschreibung
I-Wartet (W)	Synchronisationsnachrichten werden im Smart-Sync-Eingang empfangen und abgelegt; für jede Synchronisationsnachricht wird ein Worklist-Item angelegt, und für das entsprechende Gerät wird ein Handler angestoßen.
I-Teilweise verarbeitet (P)	Worklist-Item wird vom Synchronizer verarbeitet.
I-Fertig (F)	Eingangsverarbeitung ist abgeschlossen. Der Status I-Fertig umfasst jene Upload-Nachrichten, die den Status Conflict haben. Ob eine Nachricht den Status Konflikt hat oder nicht kann anhand einer der Hander-Worklist untergeordneten Synchronizer-Worklist herausgefunden werden.
I-Fehler (E)	Fehler bei Eingangsverarbeitung aufgetreten. Es kann sich um einen Anwendungs- oder einen Synchronisationsfehler handeln.
I-Ignorieren (I)	Worklist-Item wird als abgeschlossen markiert und daher ignoriert. Worklist-Items, deren Status I-Fehler oder I-Wartet lautet, können manuell in den Status I-Ignorieren geändert werden.
J-Wartet	Als Ergebnis des Reports MEREP_DISTRIBUTOR werden Synchronistationsnachrichten angelegt
J-Teilweise verarbeitet	Von MEREP_DISTRIBUTOR angelegte Synchronisationsnachrichten werden verarbeitet.
J-Fertig	Die Verarbeitung ist abgeschlossen. Die Synchronisationsnachrichten können bei der nächsten Synchronisation zum Client übertragen werden.
J-Fehler	Fehler bei der Verarbeitung aufgetreten. Es kann sich um einen Anwendungs- oder einen Synchronisationsfehler handeln.
J-Ignorieren	Die von MEREP_DISTRIBUTOR angelegte Nachricht ist gekennzeichnet als vollständig und wird damit ignoriert.
O-Wartet (W)	Synchronisationsnachrichten werden als Antwort auf Eingangsnachrichten (Worklist-Item(s)) angelegt und im Smart-Sync-Ausgang abgelegt.
O-Versendet (S)	Synchronisationsnachrichten werden pro Request des Endgeräts in MI-Container umgewandelt. Ist der Status einer Ausgangsnachricht O-Versendet, wurden die Daten erfolgreich heruntergeladen. Aktualisierungen auf dem Client können aufgrund von technischen oder anwendungsbezogenen Gründen fehlgeschlagen sein, aber es wurde bestätigt, dass die Nachricht auf dem Client-Gerät angekommen ist.
O-Fehler (E)	Fehler bei Ausgangsverarbeitung aufgetreten.

 

Nachrichtenumwandlung

Nachrichten werden zwischen den mobilen Endgeräten und der SAP MI Server Component während der Synchronisation umgewandelt.

Unterschiedliche Nachrichtenformate in den jeweiligen Phasen

Phase	Umwandlung	Beschreibung
Ablage lokaler Gerätedaten	Rohdaten (serialisierte Datei, lokale Datenbank usw.)
Smart-Sync-Nachricht	XML	Client verwendet XML-Daten, wenn Daten an die SAP MI Server Component gesendet und vom Server empfangen werden.
MI-Container	<Feld> <Feldwert> Wertepaar	Die Smart-Synchronization-Nachricht wird in den MI-Container gepackt, wenn sie über das Netzwerk zwischen der SAP MI Client Component und der SAP MI Server Component übertragen wird.
Smart-Synchronization-Eingang	XML + Worklist-Item	Wenn eine Smart-Sync-Nachricht von einem Gerät empfangen wird, werden die XML-Daten vom ME-Container als String gelesen und im Smart-Sync-Eingang abgelegt. Gleichzeitig wird ein Worklist-Item generiert, das einem Nachrichtenkopf entspricht und in der SAP MI Server Component abgelegt.
Smart-Synchronization-Ausgang	XML + Worklist-Item	Nachrichten von Smart-Synchronization werden im Smart-Sync-Ausgang im XML-Format abgelegt. Die XML-Daten werden zusammen mit dem Metadaten mithilfe eines SyncBO abgelegt.