Ansicht
Dokumentation

RN1_SYNC_CORDERTYPES - Synchronisierung der Auftragstypen

BAL_S_LOG - Application Log: Log header data   CPI1466 during Backup  
Diese Dokumentation steht unter dem Copyright der SAP AG.

Verwendung

Dieser Report führt die Synchronisation der Schlüsselfelder von Auftragstypen Klinischer Aufträge zweier unterschiedlicher Systeme durch; vorzugsweise zwischen Qualitätssicherungssystem (Q-System) und Produktivsystem (P-System).

Beachten Sie, dass Sie den Report unbedingt durchführen müssen, wenn Sie das Klinische System vor Release 4.72 bereits im Einsatz haben und erstmalig auf Release 4.72 oder größer wechseln. Wenn Sie das Klinische System erst ab Release 4.72 einsetzen, ist die Durchführung des Reports nicht erforderlich.

Sie müssen den Report für jeden installierten Mandanten im System unbedingt einmal ausführen, um die Transportfunktionalität in der Stammdatentransaktion zur Pflege von Auftragstypen überhaupt nutzen zu können. Bei einem Releasewechsel migrieren Sie jedes System innerhalb der Systemlandschaft unabhängig vom jeweils anderen. Beim erstmaligen Releasewechsel von einem Release kleiner 4.72 auf ein Release 4.72 oder größer müssen Sie die alten Vormerktypen in Auftragstypen migrieren. Dabei werden für die neu angelegten Objekte zum Teil automatisch technische Schlüsselfelder generiert, die von System zu System unterschiedlich sind, wodurch ein Transport dieser Daten nicht sinnvoll ist, da dieser zu Inkonsistenzen führen würde.

Der Report nimmt eine Synchronisation dieser unterschiedlichen Schlüsselfelder in Form einer Rückwärtssynchronisation vor, um die Integrität der Produktivdaten zu gewährleisten. Rückwärtssynchronisation bedeutet, dass die Daten der Auftragstypen vom P-System in das Q-System übernommen werden und anschließend mit den bereits zuvor am Q-System eingerichteten zusätzlichen Daten über einen Transportauftrag wieder in das P-System übertragen werden. Es werden demnach die Schlüssel vom Q-System durch die Schlüssel des P-Systems ersetzt.

Voraussetzungen

Die Migration von Vormerktypen in Auftragstypen wurde im Rahmen eines Releasewechsel auf Release 4.72 oder größer ausgeführt. Siehe auch Report RN1UTL49 und Report N1_MIGPRG.

Folgende Einstellungen müssen auf beiden Systemen identisch sein:

• Mandantennummern

• Statusschemata

• Organisationseinheiten

• Hierarchie der Organisationseinheiten

• Kontexte (Tabellen NCXTY und NCXTYT)

Diesbezüglich gibt es einen Spezialfall, der eine Synchronisierung verhindert: Im Rahmen des Releasewechsels wird der Report RN1UTL49 ausgeführt, um alte Vormerktypen in Auftragstypen bzw. neue Vormerktypen zu migrieren.

Standardmäßig wird ein Kontexteintrag vom Typ "Anforderungen" mit einem Schlüssel, bestehend aus dem Präfix "RQ" und einer laufenden Nummer, versehen. Wenn dieser Schlüssel bereits existiert, vergibt das System einen neuen Schlüssel mit der nächst höheren laufenden Nummer. Dadurch ist es möglich, dass der Schlüssel auf beiden an der Synchronisation beteiligten Systemen unterschiedlich ist.

Dieser Fall kann jedoch nur dann eintreten, wenn die Kontextdefinitionen, deren Schlüssel mit "RQ" beginnt, nicht synchron gehalten wurden (z. B. durch manuelle Änderungen).

• Einrichtungen

• Anforderungstypen

• registrierte Servicedefnitionen für den Objekttyp Klinischer Auftragstyp (Tabelle N1WSASSOC)

Funktionsumfang

Unterstütze Systemlandschaften

Die Synchronisierung der Schlüsselfelder von Auftragstypen und damit die Anbindung der Klinischen Auftragstypen an das Transportwesen kann immer nur zwischen zwei Systemen (z. B. P-System, Q-System oder Q-System, Entwicklungssystem (E-System)) mit identischer Mandantennummer erfolgen. Andere Systemlandschaften (z. B. P-Mandant, Q-Mandant innerhalb eines Systems) bzw. andere Transportschienen (z. B. zwischen Mandanten unterschiedlicher Systeme mit unterschiedlicher Mandantennummer oder auch zwischen Mandanten des gleichen Systems) werden nicht unterstützt.

Genereller Ablauf des Reports

Der Report muss für jeden Mandanten im System und für alle Systeme zwischen denen eine Transportschiene definiert ist (z. B. Q-System und P-System) ausgeführt werden.

• Am Beginn des Reports werden die Eingaben am Selektionsbildschirm auf ihre Gültigkeit geprüft. (Gültigkeit der RFC-Destination, Gültigkeit der Pfad-/Dateiangabe)

• Nach Start des Reports wird ein Transportauftrag erfragt, der für den Rücktransport in das P-System dient. Stimmt das Zielsystem des gewählten Transportauftrages mit dem System der angegebenen RFC-Destination nicht überein, so wird die Verarbeitung abgebrochen.

• Das System bricht die Verarbeitung auch ab, wenn mindestens einer der folgenden Fälle zutrifft:

• Die beiden Systeme sind bereits synchronisiert.

• Bei dem System, auf dem der Report läuft, handelt es sich um ein Produktivsystem.

• Beim Verbindungsaufbau zum P-System tritt ein Fehler auf.

• Abgleichvorgang

• Abgleich der Designelemente von P-System und Q-System wie folgt:

Für alle Designelemente, die sowohl am P-System als auch am Q-System vorhanden sind (gleicher technischer Schlüssel oder gleiche Bezeichnung in Verbindung mit gleichem Designelementtyp - einspaltig, zweispaltig) werden die Schlüssel vom P-System übernommen. Alle Designelemente, die nur am P-System vorhanden sind, werden in das Q-System übernommen. Alle Designelemente, die nur am Q-System vorhanden sind, bleiben unverändert und werden auch nicht beim anschließenden Initialtransport in das P-System übernommen. Durch die Änderungen der Schlüssel am Q-System müssen in den Auftragstypen des Q-Systems, die nur am Q-System existieren, auch die Einträge in der Tabelle N1CORDTYPA angepasst werden (Registerkarte Strukturierung - Zuordnung Designelement zu Auftragstyp).

• Abgleich der Auftragstypen mit allen abhängigen Daten

Der Abgleich der Auftragstypen unterteilt sich (aus Sicht des P-Systems) in drei Abschnitte:

1. Auftragstypen mit gleichem technischen Schlüssel (migrierte Vormerktypen)
2. Auftragstypen mit unterschiedlicher technischen Schlüssel aber gleicher Kurzbezeichnung
3. Auftragstypen sind nur am P-System vorhanden

Grundsätzlich läuft der Abgleich der Auftragstypen und abhängiger Tabellen immer nach dem gleichen Schema ab:

Bei Daten, die auf beiden Systemen vorhanden sind, werden die Daten vom Q-System genommen (aktueller), der Schlüssel jedoch vom P-System. Daten, die nur am P-System vorhanden sind, werden einfach auf das Q-System repliziert und Daten, die nur am Q-System vorhanden sind, werden nicht verändert, ausgenommen es ändern sich die Fremdschlüssel (z. B. Auftragstypid ändert sich auf Grund von Punkt 2).

Diese Abgleichstrategie wird auf alle Tabellen angewandt außer auf die Tabelle N1CORDTYPA (Zuordnung Designelemente/Bausteine zu Auftragstyp). Dies ist auf Grund technischer Restriktionen nicht möglich, da das Programm etwaige ausgetauschte Designelemente zusammenfinden müsste. Es wird daher, um die Integrität der Produktivdaten weiterhin zu gewährleisten, die Strukturierung des P-Systems übernommen. Etwaige bereits durchgeführte Einstellungen auf der Registerkarte Strukturierung am Q-System werden dadurch überschrieben. Dadurch kann es im ungünstigsten Fall zu Inkonsistenzen innerhalb dieser Auftragstypen/Vormerktypen kommen (z. B. es sind weiterhin statusabhängige Methoden definiert, der Baustein ist jedoch den Auftragstypen/Vormerktypen nicht mehr zugeordnet), die Sie in weiterer Folge manuell korrigieren müssen.

Hinweis: Um dieses Verhalten zu vermeiden, gibt es prinzipiell zwei Möglichkeiten: Eine manuelle Vorabsynchronisierung am P-System oder ein neuerliches Customizing am Q-System nach erfolgter Synchronisierung und anschließenden Transport.

Einen weiteren Spezialfall stellt die Tabelle N1CORDTSTA dar, welche die den Auftragstypen zugeordneten Statusschemata enthält. Wenn einem Auftragstyp am P-System ein Statusschema zugeordnet ist, das dem gleichen Auftragstyp am Q-System nicht mehr zugeordnet ist, hat das zur Folge, dass der Auftragstyp inkonsistent sein könnte, da dieser nun zwei Statusschemata beinhalten könnte, deren Gültigkeitsdaten sich überschneiden.

Hinweis: Um solche Inkonsistenzen zu vermeiden, muss darauf geachtet werden, dass die am P-System vorhandenen Statuschemata auch am Q-System vorhanden sind.

Auf Grund der speziellen Abgleichstrategie der Tabelle N1CORDTYPA folgt die Tabelle N1COMPCON (Bausteinkonfiguration) der gleichen Strategie, da diese Tabelle von der Tabelle N1CORDTYPA direkt abhängt.

Der Abgleich der Tabelle N1CORDTWS als auch der Tabellen N1CORDTPL und N1CORDTPLT sieht vor, dass bei Vorhandensein von Daten am P-System, diese auch übernommen werden und die bestehenden Daten am Q-System entfernt werden. Wenn keine Daten am P-System vorhanden sein sollten, so verbleiben im Falle der Tabelle N1CORDTWS die Daten des Q-Systems erhalten. Einträge am Q-System in den Tabellen N1CORDTPL und N1CORDTPLT werden entfernt, sofern die Schlüssel der Auftragstypen unterschiedlich sind.

• Nach Durchführung des Abgleichvorgangs werden die Auftragstypen, die zuvor am P-System vorhanden waren, mit allen abhängigen Daten in den zuvor angelegten Transportauftrag übernommen.

• Anlegen einer Protokollierungsdatei, die einerseits die Datenbankänderungen am Q-System und andererseits die in das P-System transportierten Daten protokolliert. Sie legen den Pfad-/Dateinamen der Protokolldatei im Selektionsbildschirm fest.

• Tatsächliches Verbuchen der Änderungen am Q-System.

Synchronisierung bei einer Systemlandschaft mit E-System, Q-System und P-System

Sie haben Transportwege vom E-System nach Q-System und vom Q-System nach P-System eingerichtet. Folgendes Vorgehen ist erforderlich, um alle Systeme zu synchronisieren:

1. Im ersten Schritt führen Sie eine Synchronisierung vom Q-System nach E-System durch. Der Report wird dabei auf dem E-System gestartet. Die Tabellenschlüssel werden vom Q-System auf das E-System übertragen.

Als Vorbereitung für die Verwendung des Klinischen Auftrages richten Sie auf dem Q-System neue Auftragstypen ein oder ändern bestehende Auftragstypen.

1. Sie führen die Synchronisierung vom P-System nach Q-System durch. Der Report wird dabei am Q-System gestartet.
2. Sie schließen die Synchronisierung der Systeme mit einem weiteren Abgleich zwischen Q-System und E-System ab. Die nochmalige Durchführung des Synchronisationsreports zwischen Q-System und E-System ist nur dann möglich, wenn Sie den Eintrag in der Datenbanktabelle N1SYNC_SYSTEMS löschen, der die beiden zu synchronisierenden Systeme identifiziert.

Hinweis: Aufgrund der Rückwärtsynchronisation werden die Tabellenschlüssel im letzten Schritt vom Produktiv- auf das Qualitätssicherungssystem übertragen. Das kann dazu führen, dass Einstellungen im Bezug auf Auftragstypen, die Sie auf dem Q-System vorgenommen haben, wieder verloren gehen.

Selektion

Über das Selektionsbild müssen Sie folgende Daten für den Report erfassen:

• Quellsystem

Geben Sie eine RFC-Destination ein, die eine Verbindung zum P-System darstellt. Diese RFC-Destination muss zuvor über die Transaktion SM59 gepflegt werden. Es ist nicht notwendig, für jeden Mandanten eine eigene RFC-Destination zu definieren, da der Report automatisch die Daten vom aktuellen Mandanten verarbeitet.

• Testlauf

Sie legen fest, ob der Report im Testlauf durchgeführt werden soll. Im Testlauf werden keine Änderungen an der Datenbank vorgenommen.

• Pfad/Dateiname

Erfassen Sie eine Pfadangabe und einen Dateinamen für die Erstellung der Protokolldatei. Die an dem Quell- und Zielsystem durchgeführten Änderungen werden in der Protokolldatei festgehalten.

Standardvarianten

Ausgabe

Der Report ändert folgende Datenbanktabellen:

• N1CORDTYP (Auftragstyp/Vormerktyp)

• N1CORDTYPT (Texttabelle zu N1CORDTYP)

• N1CORDTYPA (Struktur des Auftragstypen/Vormerktypen)

• N1CORDTAV (Zuordnung möglicher Veranlasser zu einem Auftragstyp/Vormerktyp)

• N1CORDTTR (Zuordnung möglicher Adressaten zu einem Auftragstyp/Vormerktyp)

• N1CORDTS (Zuordnung möglicher Leistungen zu Adressaten eines Auftragstyps/Vormerktyps)

• N1CORDTSTA (Zuordnung Statusschemata zu einem Auftragstyp/Vormerktyp)

• N1CMETHSTA (Statusabhängige Methoden)

• N1SCRM (Statusabhängige Bildmodifikationen)

• N1CORDTYPAPCN (Terminvorgabe Abhängigkeiten)

• NOCTY (Zuordnung von Auswahllisten)

• NCXTY (Kontextdefinitionen)

• NCXTYT (Texttabelle zu NXCTY)

• NCTX (Kontext)

• N1VKG (Auftragspositionen/Vormerkpositionen)

• N1SYNC_SYSTEMS (Synchronisierungstabelle)

• N1DESEL (Designelemente)

• N1DESELT (Texttabelle zu N1DESEL)

• N1COMPCON (Tabelle der Bausteinkonfigurationen)

• N1CORDTWS (Zuordnung Inboundservice zu Klinischen Auftragstypen)

• N1CORDTPL (Auftragsvorlagen)

• N1CORDTPLT (Texttabelle zu N1CORDTPL)

Hinweis: Der Report löscht, ändert bzw. legt eine Vielzahl an Daten an. Es wird ausdrücklich empfohlen, die beteiligten Datenbanktabellen beider Systeme vor Ausführung des Reports und anschließender Durchführung des Initialtransports (Einspielen des Transportauftrages am Quell-System) zu sichern, um gegebenenfalls wieder den ursprünglichen Datenstand wieder herstellen zu können.

Aktivitäten

Beispiel

CL_GUI_FRONTEND_SERVICES - Frontend Services   General Data in Customer Master  
Diese Dokumentation steht unter dem Copyright der SAP AG.

Length: 16865 Date: 20240601 Time: 011446     sap01-206 ( 275 ms )