Beispiel für die Stammdatenverteilung (SAP-Bibliothek - ALE-Einführung und Administration)

Beispiel für die Stammdatenverteilung

Die Stammdatenverteilung soll am Beispiel der Materialstammpflege erläutert werden. Alle Szenarien der Stammdatenverteilung sind analog zur Materialstammdatenverteilung aufgebaut.

Die Funktionstypen Materialstammpflege und Materialstammpflege-Kopie liegen in verteilten Systemen.

Die Kopieverwaltung befindet sich bei zentraler Pflege direkt im dezentralen System. Bei mehreren Pflegesystemen (z.B. je Sicht auf das Material) ist die Kopieverwaltung auf dem Referenzsystem. Dieses verteilt dann die Stammdatenänderungen auf alle anderen dezentralen Systeme.

Zwischen diesen Funktionstypen werden Nachrichten übermittelt.

Beim PUSH-Prinzip erfolgt die Kommunikation mit dem Nachrichtentyp MATMAS (Diese Nachricht enthält zu verteilende Daten des Materialstamms).
Beim PULL-Prinzip wird zwischen der Materialstamm-Kopieverwaltung und dem Materialstammpflege-Original die Nachricht MATFET übermittelt. (Diese Nachricht ist eine Aufforderung an das Original, Materialstammdaten zu senden.)

Folgende Filter steuern die Verteilung:

Klassen (z.B. klassifizierte Materialnummern für die Verteilung an bestimmte Systeme).

Filterobjekte: Organisationseinheiten (Verkaufsorganisation, Werk).

Als Teil des Customizing des ALE legt der Kunde im Verteilungsmodell pro Nachrichtentyp fest, welche Felder in welcher Anwendungstabelle verteilungsrelevant sind.

Verteilungsmodell Materialstammdatenverteilung. Es wird das Filterobjekt "Werk" verwendet. Da im System LYON Werk 001 verwaltet wird, erhält LYON die Materialstammdaten für Werk 001.

Prüfung auf Verteilungsrelevanz

Der Inhalt des Änderungsbelegs wird vom Änderungsbelegwesen an das SMD-Tool weitergereicht. Pro Belegposition wird überprüft, ob die Kombination aus geändertem Feld und Tabelle einem Nachrichtentyp zugeordnet ist.

Änderungszeiger schreiben

Sind die Felder verteilungsrelevant, werden vom SMD-Tool Änderungszeiger geschrieben und in den Tabellen BDCP und BDCPS abgelegt. Änderungszeiger sind im wesentlichen die Schlüsselfelder der Tabelle, in der sich das geänderte Feld befindet. Über das Customizing des ALE kann der Kunde die verteilungsrelevanten Felder festlegen.

Eine Erzeugung von Änderungszeigern findet nur statt, wenn sowohl ALE als auch der Nachrichtentyp aktiv sind.

Versenden von Änderungen

Zum Verteilen von geänderten Stammdaten müssen die Änderungszeiger weiterverarbeitet werden. Dabei werden, abhängig vom Nachrichtentyp, Stamm-IDocs erzeugt und zum Versenden an die ALE-Schicht weitergegeben.

Dazu dient das Program RBDMIDOC. Üblicherweise wird RBDMIDOC automatisch durch einen Hintergrund-Job ausgeführt, wobei ein Hintergrund-Job pro Nachrichtentyp einzuplanen ist.

Abhängig von der Einstellung der Partnervereinbarungen kann es notwendig sein, das Versenden von IDocs durch Ausführen des Programms RSEOUT00 explizit anzustoßen. Im Hintergrund-Job, der RBDMIDOC ausführt, kann dies in einem zweiten Schritt geschehen. Weitere Informationen zu diesen Funktionen finden Sie im R/3-Einführungsleitfaden:

Basis
Application Link Enabling (ALE)
Geschäftsprozesse modellieren und implementieren
Verteilung von Stammdaten konfigurieren
Replikation von geänderten Daten einrichten
IDoc-Erzeugung aus Änderungszeigern einplanen

Für den Aufbau des Master-IDocs gelten folgende Regeln:

Das Master-IDoc beinhaltet alle IDoc-Segmente, in deren Feldern eine Änderung aufgetreten ist.
Das Master-IDoc beinhaltet alle Mußsegmente des IDocs.
Die diesen Segmenten übergeordneten Muttersegmente werden versendet.
Die IDoc-Segmente werden vollständig verschickt, d.h. alle Felder werden mit Daten gefüllt.

Hinweis für das Einlesen von Änderungen

Beim Stammdateneingang kann man verhindern, daß Senderfelder auf Felder im Empfangssystem eingespielt werden. Wie diese Einstellung vorgenommen werden kann, erfahren Sie im Customizing:

Basis
Application Link Enabling (ALE)
Geschäftsprozesse modellieren und implementieren
Datenumsetzung zwischen Sender und Empfänger einstellen

Bei IDocs der Nachrichtentypen MATMAS, DEBMAS oder CREMAS sowie allen anderen IDocs die ein CALL TRANSACTION bei der Eingangsverarbeitung vewenden, werden Felder im empfangenden R/3-System nicht überschrieben, wenn im entsprechenden IDoc-Feld die Konstante "/" steht.