Installation der DeltaSynchronisation

Überblick

Dieses Thema beschreibt die Installation der DeltaSync für den Statusabgleich zwischen SAP IS-U und B2B/CCM.

Installation in der B2B

Vor der Installation auf SAP Seite sollte der RFCService30 in der B2B installiert werden.

Außerdem muss die Extension B3P_CCM_CHANNELS angelegt und nicht leer sein. Als Inhalt reicht ein “#”.

Installation der Transporte in IS-U

Die im CRISP Downloadcenter bereitgestellten Transporte und bcsets müssen in das SAP System installiert, bzw. transportiert werden. Dies erledigt ein Basis-Administrator über das Transportmanagement (Transaktion se10), bzw. über die Verwaltung der bcsets ( scpr3 / scpr20).

Für einen erfolgreichen Transport muss sowohl der Inhalt des Auftrags als auch der Auftrag selbst freigegeben werden.

Die Transporte enthalten unter anderem die Vorschalttransaktion ZNLICCM_B2B2SAP.


	Alle Anwender müssen Zugriff auf diese Transaktion haben, um den Absprung nutzen zu können.

Einrichtung der RFC Verbindung von SAP nach B2B/CCM

Transaktion sm59 öffnen, neuen TCP Port erstellen.

Wichtig ist hierbei:

Die Programm-Id, welche in SAP und B2B gleich gepflegt sein muss. Empfohlener Wert: b2bbp
Die Flagge “registriertes Serverprogramm”
Die Gateway-Optionen enthalten als “service” den TCP port (der auch in der services Datei gelistet sein muss). Hier defaultmäßig sapgw00 wählen.
Wenn SAP auf einem Cluster installiert ist, muss als Gatewayhost der MessageServer eingetragen werden.

Der entsprechende Eintrag in der services Datei ist unten aufgeführt. Wenn SAP Server oder gui installiert sind, sind diese Einträge gepflegt. Ansonsten entsprechend erstellen (sapgw00 = TCP Port 3300)

Ein Verbindungstest aus SAP IS-U wird erst dann erfolgreich sein, wenn der RFC Service in der B2B eingerichtet ist, und diese anschließend neu gestartet wurde.

Konfiguration der DeltaSync

Die bcsets zur Delta sync (bereitgestellt im CRISP Downloadcenter) müssen eingespielt werden, diese Rechte hat normalerweise nur der Basis Administrator.

Transaktion sm30 für Tabellenpflege öffnen. Die Tabellennamen beginnen alle mit ZNLI*.

Tabelle ZNLICCM_DSLPARA

Diese Tabelle enthält die Grundkonfiguration der DeltaSync.

Das Laufverhalten der Delta Synchronisation kann parametrisiert werden. Hierzu können folgende Parameter in der Tabelle ZNLICCM_DSLPARA über die Transaktion SM30 hinterlegt werden:

Parameter	Beschreibung	Muss-Parameter
SYNCH_OBJ	Parameter zur Auswahl der zu synchronisierenden Objekte (IDoc, Datenaustauschaufgabe, Wechselbeleg, Workflow)	Ja
BWS_DAYS	Parameter zur zeitlichen Begrenzung der Nachrichten zu einem Multi-Nachrichten Objekt (z.B. Wechselbeleg für Stammdatenänderung	Nein
EXSTAT_IDOC	Parameter zur Unterdrückung der Synchronisierung von IDocs in einem bestimmten Status. Dies ist wichtig für manuelle Klärung! (s.u.)	Nein
SYNCCL	Angabe der Synchronisationsklasse	Ja
TRACETIME	Es werden zusätzliche Angaben zur Laufzeit (Dauer von Methodenaufrufen in den Spool bzw. die Ausgabe geschrieben	Nein
NO_SYNC_BEFORE	Objekte, die vor diesem Datum erstellt wurden, werden in der Synchronisation nicht berücksichtigt.	Ja
ACTBTC	Anzahl der maximale gleichzeitig aktiven Programmläufe im Hintergrund	Nein
EMAIL_ERR	Emailadresse für den Versand einer Hinweis Email bei Erreichen der maximalen Anzahl von aktiven Programmläufen im Hintergrund	Nein
DETDAT	Anzahl der Wochen von heute in die Vergangenheit zur Bestimmung des Löschdatum	Nein
SYNC_ALL	Nicht übertragene Daten aus anderen Betrachtungzeiträumen werden übertragen	Nein
REL_WORKITEM	Für die Synchronisation relevante Workflowmuster angeben *(Pflichtparameter, wenn für SYNCHOBJ der Wert CHK_DELTA_WORKFLOW_NEW verwendet wird	Nein

Parameter SYNCH_OBJ

Im Moment wird die Synchronisation von Idoc-Nachrichten, Datenaustauschprozessen, Wechselbelegen und Workflow zum Wechselbeleg unterstützt. Wenn alle Objekte betrachtet werden sollen, ist die Tabelle wie folgt zu pflegen:

Parameter	Position	Wert Parameter
SYNCH_OBJ	1	CHK_DELTA_IDOC
SYNCH_OBJ	2	CHK_DELTA_DATEX
SYNCH_OBJ	3	CHK_DELTA_SWITCHDOC / CHK_DELTA_COMMONLAYER (Bei Verwendung von CommonLayer/PDOCs muss hier CHK_DELTA_COMMONLAYER stehen)
SYNCH_OBJ	4	CHK_DELTA_WORKFLOW / CHK_DELTA_WORKFLOW_NEW (Bei Verwendung von CHK_DELTA_WORKFLOW_NEW muss der PArameter REL_WORKITEM gepflegt werden!)

Wichtig: Das Feld “Position” beschreibt die Rangfolge der Datenermittlung. Für einen optimalen Programmlauf ist diese Reihenfolge einzuhalten.

Parameter SYNCCL

Über diesen Parameter wird gesteuert, welche Klasse die Verarbeitung übernimmt. Um Besonderheiten zu berücksichtigen, können eigene Klassen angelegt werden. Die Klasse muss von der Klasse ZNLICCMCL_DELTASYNC erben (siehe Beispiel ZNLICCMCL_DELTASYNC_EXAMPLE).

Parameter	Position	Wert Parameter
SYNCCL	1	ZNLICCMCL_DELTASYNC

Parameter BWS_DAYS

Der Wechselbeleg kann über einen langen Zeitraum aktiv sein (z.B. Wechselbelege für Änderungsmitteilungen). Wenn eine neue Nachricht eingeht, ändert sich womöglich der Wechselbeleg und die Delta-Findung sucht zum geänderten Wechselbeleg die Daten. Zur Einschränkung des Suchzeitraums der Daten kann der Parameter gesetzt werden (Einheit = Tage). Es werden dann nur Nachrichten zum Beleg in diesem Zeitraum (Zeitraum = Änderungszeitpunkt Beleg/zugehöriger WF bis Änderungszeitpunkt Beleg/zugehöriger WF minus -Tage) berücksichtigt.

Parameter	Position	Wert Parameter
BWS_DAYS	1	30

Parameter EXSTAT_IDOC

Über diesen Parameter können Nachrichten schon bei der Selektion ausgeschlossen werden. Eine Übertragung an die B2B findet damit nicht statt.

Es muss Kunden- bzw. Installationsspezifisch ermittelt werden, welche IDOC Statuswerte etwa ein manuelles Clearing repräsentieren. Diese dürfen nicht synchronisiert werden, da sie sonst überschrieben werden.

Beispielhaft bleiben hier Nachrichten im Status 41 oder 59 unberücksichtigt und werden somit nicht synchronisiert.

Parameter	Position	Wert Parameter
EXSTAT_IDOC	1	41
EXSTAT_IDOC	2	59

EXSTAT_IDOC

Parameter TRACETIME

Zur Analyse der Laufzeit kann der Parameter auf „X“ gesetzt werden. Über GET RUN TIME wird dann die Ausführungszeit einzelner Programmblöcke ausgegeben bzw. in den Spool geschrieben.

Parameter	Position	Wert Parameter
TRACETIME	1	X

Parameter NO_SYNC_BEFORE

Dieser Parameter gibt den Stichtag an, vor dem keine Objekte selektiert werden.

Parameter	Position	Wert Parameter
NO_SYNC_BEFORE	1	20140101

Parameter ACTBTC

Über diesen Parameter wird gesteuert, wie viele Programme „ZNLICCM_B3P_DELTASYNC_JOB“ gleichzeitig im Hintergrund laufen dürfen. Ist der Parameter nicht gesetzt, wird automatisch der Wert auf 1 gesetzt. Wird die Anzahl überschritten, wird der neue Job beendet. Vor der Beendigung wird noch ein Statuseintrag geschrieben und eine Email versendet (nur wenn SAPConnect aktiv ist). Der Empfänger der wird über den Parameter EMAIL_ERR festgelegt.

Parameter	Position	Wert Parameter
ACTBTC	1	2

Es wird folgender Eintrag in den Spool geschrieben:

Parameter EMAIL_ERR

Über diesen Parameter können Empfänger Email Adressen angegeben werden, die im Fall einer Überschreitung der maximal zulässigen aktiven Programme im Hintergrund informiert werden. Es können mehrere Empfänger hinterlegt werden. Für den Versand der Email muss SAPConnect aktiv sein.

Parameter	Position	Wert Parameter
EMAIL_ERR	1	mmuster@muster.de
EMAIL_ERR	2	gmuster@muster.de

Die Email enthält folgende Informationen

Parameter DELDAT

Damit der Datenbestand nicht zu groß wird, kann der Datenbestand ganz oder teilweise gelöscht werden. Für das teilweise Löschen des Datenbestands kann der Parameter DELDAT gesetzt werden. Hier wird die Anzahl in Wochen angegeben, die rückwirkend vom heutigen Tagen das Datum zum Löschen bestimmt. Alle Daten mit letzten Änderungen vor dem ermittelten Löschdatum werden aus dem Datenbestand der Deltasynchronisation gelöscht. Zum Löschen muss der Report ZNLICCM_B3P_DELTASYNC_JOB_ADM ausgeführt werden.

Parameter	Position	Wert Parameter
DELDAT	1	5


	Hier werden alle DeltaSync-Daten älter als 5 Woche gelöscht.

Parameter SYNC_ALL

Ist dieser Parameter gesetzt, werden immer alle noch nicht übertragenen Daten (Betrachtungszeitraum steht im Status SER) übertragen. Standardmäßig sollte dies nicht gesetzt sein.

Vorgängerläufe, die im Status SIN oder SAB sind, werden durch Änderung des aktuellen Betrachtungszeitraums automatisch berücksichtigt. Der Parameter spielt hierfür keine Rolle.

Parameter	Position	Wert Parameter
SYNC_ALL	1	X (Wenn gesetzt werden soll)

Parameter REL_WORKITEM

Unter diesem Parameter müssen die zu monitorenden Workflowmuster hinterlegt werden, wenn unter dem Parameter SYNCH_OBJ die Methode CHK_DELTA_WORKFLOW_NEW eingetragen wurde.

Als Workflowmuster muss immer nur der Hauptworkflow hinterlegt werden.

Parameter	Position	Wert Parameter
REL_WORKITEM	1	WS<Nummer>

Tabelle ZNLICCM_EDISEG

Abhängig vom verwendeten Idoc-Basistyp kann die Referenz- und BDEW-Nummer in unterschiedlichen Segmenten und Feldern sein. Die Festlegung erfolgt je Idoc-Basistyp in der Tabelle ZNLICCM_DSEDISEG (Transaktion SM30). Ein grundlegendes Customizing für die Standard Basistypen wird über die BCSets ZNLICCM_DELTA_SYNC_01 und ZNLICCM_DELTA_SYNC_02 bereitgestellt (Transaktion SCPR20).

An der folgenden Abbildung soll die Pflege erklärt werden.

Die Ermittlung für Referenz- und BDEW-Nummer erfolgt stufenweise immer im Zusammenhang. Sollte aufgrund der Nachrichtenbeschaffenheit ein Zusammenhang für die Nachricht nicht zutreffen, kann eine weitere Ermittlungsstufe hinterlegt werden.

Beispiel (Erläuterung zur Abbildung)

Eingehende Nachrichten:

BDEW-Nummer -> Lesen Segment /ISIDEX/E1VDEWUNB_1 – Feld „RECEIVER“
Referenz-Nummer -> Lesen Segment /ISIDEX/E1VDEWUNB_1 – Feld „REFNR“

Sollte eine der beiden Nummern nicht ermittelt werden können, erfolgt die Ermittlung wie folgt:

BDEW-Nummer -> Lesen Segment /IDEXGE/E1VDEWNAD_7 – Feld „PARTNER“, wenn im Feld „ACTION“ der Wert „MR“ steht
Referenz-Nummer -> Lesen Segment /ISIDEX/E1VDEWUNH_1 – Feld „REFERENCENUMBER“

Ausgehende Nachrichten:

BDEW-Nummer -> Lesen Segment /ISIDEX/E1VDEWUNB_1 – Feld „SENDER“
Referenz-Nummer -> Lesen Segment /ISIDEX/E1VDEWUNB_1 – Feld „REFNR“

Sollte eine der beiden Nummern nicht ermittelt werden können, erfolgt die Ermittlung wie folgt:

BDEW-Nummer -> Lesen Segment /IDEXGE/E1VDEWNAD_7 – Feld „PARTNER“, wenn im Feld „ACTION“ der Wert „MS“ steht
Referenz-Nummer -> Lesen Segment /ISIDEX/E1VDEWUNH_1 – Feld „REFERENCENUMBER“


	Wichtig: Die Pflege muss für alle betroffenen Nachrichtentypen (IDoc-Basistyp) erfolgen. Wenn modifizierte Basistypen verwendet werden, muss dieses Mapping ggf. angepasst werden.

Tabelle ZNLICCM_DSSTAT01

Je Objekttyp kann festgelegt werden, wie der Status auf den Gesamtstatus übertragen werden soll. Das Mapping wird in der Tabelle ZNLICCM_DSSTAT01 abgelegt. Soll für einen Objekttyp kein Statusmapping auf den Gesamtstatus erfolgen, so darf für den Objekttyp kein Eintrag erfasst werden.

Für folgende Objekttypen kann ein Statusmapping erfolgen:

Idoc (via Idoc-Status und Idoc-Statusgruppe) (Objekttyp = IDOC oder IDOC_SG)
Datenaustauschaufgabe (Objekttyp ISUTASK)
Wechselbeleg (Objekttyp ISUSWITCHD)
Workflow (Objekttyp Workitem)

Die o.g. Werte können über das BCSet ZNLICCM_DELTA_SYNC_STAT_SAP2B2B (Über Transaktion SCPR20) eingespielt werden.

Kundeneigene Implementation der Statussync

Um Besonderheiten (z.B. Mapping B2B Status auf Idoc Status) zu berücksichtigen kann eine eigene Klasse angelegt werden. Die Klasse muss von der Klasse ZNLICCMCL_DELTASYNC erben. Nachdem die Klasse angelegt ist, können folgende Methoden redefiniert werden (Beispiel siehe Klasse ZNLICCMCL_DELTASYNC_EXAMPLE).

- CHK_AGGREGATED_IDOC_INBOUND

In dieser Methode sind Prüfbedingungen für den Ausschluss von aggregierten Eingangs-Idocs enthalten.

- CHK_AGGREGATED_IDOC_OUTBOUND

In dieser Methode sind Prüfbedingungen für den Ausschluss von aggregierten Ausgangs-Idocs enthalten.

- EXC_IDOC_UPDATE

In dieser Methode sind Regeln definiert, die das Ändern des Status von ausgehenden Idocs durch Statusinformationen der B2B unterdrücken.

- DET_IDOC_STATUS

In dieser Methode wird der für ausgehende Idocs zu setzende Status anhand der von der B2B übertragenen Daten ermittelt. Sollte der Status für z.B. positive CONTRL abweichend gesetzt werden, so ist diese Methode zu redefinieren.

- BUILD_FIELDCAT_HDR

In dieser Methode wird die Anzeige der übertragenen Daten festgelegt.

Job Initialisieren (vor dem ersten Lauf)

Der Startzeitpunkt wird über den Report „ZNLICCM_B3P_DELTASYNC_JOB_ADM“ (Transaktion se38) festgelegt. Im Rahmen der Festlegung kann der bereits synchronisierte Datenbestand gelöscht werden. Dies sollte in Abhängigkeit der Datenmenge regelmäßig durchgeführt werden.

Alternativ kann direkt über den Report ZNLICCM_B3P_DELTASYNC_JOB eine initiale Befüllung stattfinden.

Job ausführen

Der Report ZNLICCM_B3P_DELTASYNC_JOB ausführen.

Nr	Beschreibung
1	Report ausführen, Variante wählen und Version in Erfahrung bringen.
2	Damit ausgehende Nachrichten für das B2B Statusmonitoring berücksichtigt werden, muss das Kennzeichen für ausgehende Nachrichten gesetzt werden. Wenn das Kennzeichen für ausgehende Nachrichten gesetzt ist, muss auch der Empfängerport (RCVPOR) angegeben werden. Der Port kann den IDOCS entnommen werden (Transaktion se05, bzw. we21)
3	Damit eingehende Nachrichten für das B2B Statusmonitoring berücksichtigt werden, muss das Kennzeichen für eingehende Nachrichten gesetzt werden. Wenn das Kennzeichen für eingehende Nachrichten gesetzt ist, muss auch der Senderport (SNDPOR) angegeben werden.
4	Unter Verbindungsparameter ist die RFC Destination zur B2B an zugegeben. Ist keine RFC Destination hinterlegt, werden die Daten bei der Programmausführung nur selektiert und nicht übertragen.
5	Die Auswahl des Betrachtungszeitraum ermöglicht vier verschiedene Varianten - Dauer in Minuten Das Startdatum wird aus der Log-Tabelle ermittelt. Der Benutzer kann nur die Dauer in Minuten angeben - Startdatum wählen Der Benutzer wählt das Startdatum und die Startzeit, sowie die Dauer. Durch Setzen des Flags „Initiale Befüllung“ wird vom angegebenen Startdatum/-zeit bis zum aktuellen Datum/Zeit synchronisiert - Fester Zeitraum Der Benutzer kann Start und Enddatum angeben. Durch Angabe der Startzeit und Endzeit findet eine weitere Einschränkung statt. Ohne diese Angabe erfolgt die Synchronisation über ganze Tage. Sollte hierbei das Startdatum in einen bereits synchronisierten Zeitraum fallen, wird eine Fehlermeldung ausgegeben. - Letzter Lauf bis Datum/Zeit Der Benutzer gibt ein festes Datum und Uhrzeit für das Ende vor. Das Startdatum und die Uhrzeit wird aus der Log-Tabelle gelesen. - Letzter Lauf bis jetzt Durch diese Einstellung wird immer bis zum aktuellen Zeitpunkt synchronisiert. Der Betrachtungszeitraum richtet sich somit nach dem Intervall der Jobeinplanung
6	Einschränkung auf bestimmte Nachrichtentypen und –varianten kann die Auswahl von Nachrichten für die Übertragung weiter eingrenzen. Ist hier eine Angabe vorgenommen, werden nur Nachrichten mit dem angegeben Nachrichtentyp und- variante übermittelt
7	Testlauf ermöglicht einen Lauf inkl. Der Übertragung ohne den Datenbestand im IS-U fortzuschreiben. Über das Kennzeichen „Z-Tabellen Logging“ werden zusätzliche Laufzeitinformationen in die Tabelle „ZNLICCM_DSJOBLOG“ geschrieben. Das Kennzeichen sollte nur gesetzt werden, werden eine Fehleranalyse erforderlich ist.

Job einplanen

Die Datenermittlung und Übertragung an die B2B erfolgt über den Report „ZNLICCM_B3P_DELTASYNC_JOB“. Bei der Einplanung muss keine Zeit angegeben werden, da der Betrachtungszeitraum über eine Steuertabelle bestimmt wird.

Wichtig: Die Jobeinplanung (z.B. alle 15 Minuten) muss mit dem gewählten Betrachtungszeitraum übereinstimmen, da durch jeden Programmlauf ein neuer Eintrag in der Logtabelle geschrieben wird und somit der nächste Betrachtungszeitraum bestimmt wird. D.h. Paralleleinplanungen sind nicht möglich.

Beispiel: Eintrag in Steuertabelle (Initialbefüllung):

MANDT	DATUM	UHRZEIT	DATUM	UHRZEIT	STATUS
100	01.01.2013	10:00:00	01.01.2013	10:01:00	SSU

Bei einem Betrachtungszeitraum von 15 Minuten muss der Job für 10:16:00 eingeplant werden und die folgenden Jobs jeweils mit 15 Minuten Abstand. Der erste Job betrachtet dann den Zeitraum 10:01:00 bis 10:16:00. Der folgende Job 10:16:00 bis 10:31:00 usw.

Es muss eine Variante des Reports definiert werden, welche über die Transaktion se36 eingeplant wird.

Siehe auch

StatusSynchronisation und Absprung in SAP IS-U

View Me Edit Me