SAP-Wissen: Client in bestehende CUA / ZBV aufnehmen

(Last Updated On: 13. Januar 2015)

Ich bin derzeit auf der Suche nach einer neuen Arbeitsstelle in einer SAP-Beratungsfirma. Wenn Ihnen dieser Beitrag trotz der Hastigkeit seiner Erstellung gefällt und Sie in einer führenden Position sind – scheuen Sie sich nicht, mich zu kontaktieren 😉

Was ist eine ZBV / CUA und wie funktioniert sie?

CUA steht für Central User Administration, ZBV für Zentrale Benutzerverwaltung. Beide kürzel bedeuten also das selbe. mit einer CUA ist es möglich, in einem einzigen System die Benutzerstammdaten einer gesamten Systemlandschaft ( also mit mehreren Hosts, auf denen verschiedene SAP-Lösungen betrieben werden) zu verwalten. Dies sorgt für eine einfachere Verwaltung, ein einfacheres Backup, bessere Aufallsicherheit und Portbierbarkeit eines Systems sowie für eine generell einfacher gehaltene Administration. Änderungen in einer CUA werden automatisch auf alle im System angebundenen Child Nodes weitergereicht, so dass diese davon unterrichtet werden und Änderungen an Usereinstellungen somit sofort mitkriegen.

Zum Verteilen dieser Einstellungen wird eine funktionierende ALE (application Link Enablin) Landschaft voraugsesetzt.  Diese hält die Daten konsistent und kümmert isch auch um die Regelung des Datenverkehrs. Eine ALE Systemgruppe wird von der CUA genutzt um Userdaten zwischen dem Zentralsystem und seinen Kind- oder auch Satellitensystemen über das ALE zu teilen. Deswegen macht es sinn, sich zuerst mit grundlegenden Informationen über ALE Integration Technology zu informieren. Dabei werden die Daten asynchron zwischen den Anwendungssystemen  innerhalb der CUA-Landschaft ausgetauscht. Dadurch ist sichergestellt, dass ein Zielsystem auch dann noch die nötigen informationen bekommt, wenn es bei der Erstverteilung nicht erreichbar war.

Eines der Systeme in der CUA-Landschaft wird als sogenanntes Zentralsystem definiert. Das ist meist ein System, auf dem der SAP Solution Manager läuft. Das Zentralsystem wird dann mit jedem einzelnen Satellitensystem verbunden. Die Satellitensysteme sind nicht untereinander verbunden. Das Zentralsystem selbst enthält ein eigenes Kindsystem, das sich ebenfalls Daten aus der CUA holt. So pflegen sich die User des auf dem Zentralsystem installierten SolMan beispielswiese über die CUA. Als Zentralsystem sollte immer das System mit dem neuesten Kernel und  Support Package Stack verwendet werden.

Eine Dokumentation über CUA Administration bekommt Ihr in der SAP Library im Pfad SAP NetWeaver / Security / Identity Mangement / Users and Roles / Central User Administration.

wir gehen von folgendem Szenario aus:

  • Ihr habt einen Client / einen mandanten in einem SAP ERP 6 / ECC System und wollt diesen in eine bestehende CUA / ZBV aufnehmen, die auf einem Solutin Manager System läuft. in unserem Beispiel ist das Kindsystem ein SAP ERP 6 IDES System mit der SID ID2 und dem mandanten 810.
  • in unserem Beispiel läuft die CUA-ADministration auf Mandant 900 des Solution Managers mit SID SM1 und wir wollen den Mandanten 810 eines SAP ERP 6 IDES-Systems SID ID2 anbinden.

Eine Central User Administration aufsetzen

Um eien CUA aufzusetzen, muss man die folgenden Schritte durchführen

  • Erstellen eines Administrators
  • Die Mandanten in den Systemen erstellen
  • Die Logischen Systeme spezifieren
  • Die Logischen Systeme zu einem Mandanten zuweisen
  • Die Systemuser erstellen
  • Die RFC Destinations erstellen
  • Die CUA selbst erstellen
  • Distribution Paramter für die Felder einstellen
  • Die Firmenadresse synchronisieren
  • die User transferieren

Erstellen eines Administrators

In einem klomplett neune System muss man erst einen Administrationsuser erstellen, mit dem wir später einige Schritte, wie beispielswiese das Definieren logischer Systeme, durchführen können. Standardnutzer wie DDIC  oder SAP* sind dafür nicht vorgesehen, weil sie zu den Display-Usern gehören. einen solchen alternativen Administrationsbenutzer brauchen wir sowohl auf dem Zentralsystem, welches das CUA verwaltet, als auch auf dem Kindsystem, welches wir an das CUA anbinden wollen. in der Regel ist das aber gängig, weil sich normalerweise jeder SAP-Administrator einen extra Account mit seinen Credentials erstellt. Aber bei einigen Unternehmen nimmt man immer nur die Standarduser SAP* und DDIC her, was in diesem Fall nicht funktionieren würde und aus Sicherheitsgründen auch nicht zu empfehlen ist.

dazu loggen wir uns auf dem künftigen CUA als User SAP* mit dem Standardpasswort PASS ein.

wir wählen dann Tools / Administration / User Maintenance / Users (oder Transaktion SU01) und erstellen einen User und geben ihm für das System selbst das Profil SAP_ALL. in unserem Beispiel ist das der user DDIC_CP, den wir aus einer kopie des users DDIC erstellt haben. Dieser muss im Reiter Logon Data im Feld User Type den Typ Dialog eingestellt haben.

2014-11-05_15h17_18

 

Jetzt braucht der neue Administrationsbenutzer auf dem Zentralsystem für das logische System dieses Mandanten das Profil SAP_ALL und der neue Administrationsbenutzer auf dem Kindsystem für das logische System seines Mandanten ebenfalls das Profil SAP_ALL. normalerweise existiert für das eigene System bereits ein logisches System im Format <SID>CLNT<Mandant>, so dass wir in der Transaktion SU01 nur den Reiter Profiles aufrufen müssen und dem User das Profil zuweisen müssen. 2014-11-05_15h19_58

 

 

Falls es das logische System noch nicht gibt, erfahrt ihr weiter unten in dem Kapitel „Erstellen der logischen Systeme“. Das müsst Ihr aber dann mit dem User SAP* machen, da euer neuer Administrationsbenutzer ja noch keine Rechte hat.

Danach sollten wir noch den User SAP* gegen unberechtigten Zugriff schützen. Das ist in diesem SAP Artikel beschrieben.

 

Erstellen der benötigten Systems User

Um einen mandanten mit einer CUA / ZBV zu verbinden, braucht ihr auf beiden Systemen entsprechende User unabhängig von dem gerade erstellten Administratiosnnutzer.

  • in dem CUA-Mandanten auf dem Solution manager braucht ihr einen User, der für die anfrage von Satellitensystemen an das CUA nötig ist.
  • wenn ihr mehrere CUA’s miteinander vernetzt, braucht ihr auf dem CUA-System außerdem einen User für die kommunikation von CUA zu CUA.
  • Auf dem Satellitensystem / CUA-Client braucht ihr einen User für die Anbindung zur CUA.

Alle diese User brauchen das Profil SAP_ALL.

Was sind Systembenutzer (system users)

System users werden auch CPIC User in älteren Versionen genannt und werden für die interne kommunikation der Systeme in einer ALE Gruppe benötigt, um Daten über das ALE-System zu verteilen. Diese Systembenutezr werden in den Zielsystemen definiert (also in den Satellitensystemen, die die Daten bekommen sollen) und werden danach wiederum in den RFC Destinations der satellitensysteme eingetragen. Um die Sicherheit der Systemlandschaft zu erhöhen, sollte man nur Systembenutzer mit hohen sicherheitseinschränkungen erstellen, kombiniert mit einer speziellen Rolle für System User.

Prinzipiell wäre eine USER ID ausreichend und könnt für alle Systembenutzer genutzt werden.Es ist aber praktischer, für jede RFC Destination einen extra Systemuser zu haben, da man diesen Nutzer für die jeweilige RFC Verbindung dann extra pflegen kann (Passwort ändern usw). Es sollte also genau so viele Systembenutzer wie RFC Destinations in unserem System geben. Für Systembenutzer werden deshalb auch keine Lizenzaufschläge berechnet.

Um die Verwaltung der Systembenutzer zu vereinfachen, sollte man sich an folgende Konvention zur Namensvergabe halten:

  • im Zentralsystem wählen wir die Konvention CUA_<System ID>. Dieser System User werden in den RFC Destinations der Satellitensysteme  – von eben diesem zum Zentralsystem –  genutzt
  • in den anderen SAtellitensdystemen ist die Namenskonvention CUA_<System ID>_<Client>. Diese Systembenutzer werden im Zentralsystem in den RFC Destinations  – vom Zentralsystem zum Satellitensystem – genutzt.

zuerst erstellen wir den User CUA_SM1 auf unserem Zentralsystem SM1. dieser nutzer wird in allen logischen Systemen des Zentralsystems als Systembenutzer verwendet.

wir erstellen eien Sytemuser CUA_<System ID>_<Client> in jedem Satellitensystem für jede RFC Connection vom Zentralsystem zum Kindsystem. wir erstellen also auf ID2 im mandant 810 einen User CUA_ID2_810 mit unserem neuen Administrationsuser aus dem ersten Schritt oder mit SAP*, vergeben dort grundlegende infmrationen zur Adrese, ein Initialpasswort und einen User Type Communication. Dieser Typ hat den Vorteil, dass sich dieser User ab sofort nicht mehr in eine Menüführung einloggen kann, sondern ausschließlich für die RFc-Verbindung genutzt wird. Man kann ihn also nicht mehr so leicht über beispielsweise falsche Passworteingaben im Logon-Bildschirm sperren.

2014-11-05_15h45_16

sowie ein Profil SAP_ALL. Dazu gehen wir unter Profile auf eine neue Zeile und gehen auf die Papiere, um eine übersicht der Profile zu laden

2014-11-05_16h11_37

Das Profil SAP_ALL befindet sich in dieser Liste im Reiter „Sammelprofile“ oder „composite Profiles“

2014-11-05_16h12_36

 

Im Zentralsystem fügen wir unserem CUA_SM1 jetzt die Rollen SAP_BC_USR_CUA_SETUP_CENTRAL und SAP_BC_USR_CUA_CENTRAL.

In allen anderen logischen SYtemen erstellen wir jeweils einen Systembenutezr mti den Rollen SAP_BC_USR_CUA_SETUP_CLIENT und SAP_BC_USR_CUA_CLIENT.

diese Rollen entahtlen keine menüeinträge, sondern nur Authentifzierungsdaten, da sihc die Systembenutzer nicht im Dialogmodus einloggen können. einige Felder für die authorisationsdaten enthalten einen ASterisk (*) weil das System eventuell komplette Authorisierung für für Teile des Systems braucht. Die Rollen weißen wir in der Transaktion Profile Generator (PFCG) zu. Die oben genantnen Standard-Rollen kopieren wir in den Customer namespace der jeweiligen System User.. die SETUP-Rollen rbauchen wir nur während des Setups der CUA.

Da sErstellen geht folgendermaßen vonstatten:

Wir loggen uns in das Zentralsystem als ein Administrationsnutzer und wählen die Transkaation SU01. Wir erstellen den user CUA_ADM der vom Zentralsystem für den User Transfer SCUG genutzt wird und die mehreren System Users für die RFC Destinations ide wir in den kindsysteemen erstellen. Allen System usern geben wir ein initialpasswort und edn user Typ communication. Wir weißen den Systemusern auf dem Zentralsystem für die Kindsyteme und ddem System User CUA_ADm die rollen Z_SAP_BC_USR_CUA_SETP_CENTRAL und Z_SAP_BC_USR_CUA_CENTRAL zu. Dcen Usern für das Zentralsystem auf den Kindsystemen weißen wir die Rollen Z_SAP_BC_USR_CUA_SETP_CLIENT und Z_SAP_BC_USR_CUA_CLIENT zu.

 

User erstellen könnt ihr mit der Transaktion SC01. Erstellt den User entweder von hand oder kopiert ihn au einem Standardnutzer wie DDIC und passt danach bestimte einstellungen an. Der User muss beispielsweise den Typ „dialogbenutzer“ haben und braucht eben das entsprechende Profil SAP_ALL.

Erstellen des anzubindenden Mandanten

In der Regel habt ihr den Mandanten, den Ihr anbinden wollt, bereits erstellt. Prüfen könnt ihr das mit der Transaktion SCC4 auf dem anzubindenden System. Ein anzubindendes System wird auch CUA-Client oder Satellitensystem (sattelite system) genannt. Die Transaktion zeigt alle existierenden mandatne. Wenn der mandant noch nicht erstellt ist, könnt ihr das natürlich machen. Einen mandaten kann man grundsätzlich von vorne erstellen mit einem leeren Template als Basis. Drückt dazu auf das Stift/Brille-Icon, um den Änderungmodus in SCC4 zua ktivieren und macht in einer neuen Zeile einen neuen Eintrag mit der mandantennummer, die ihr haben wollt.  Man kann einen neuen mandanten aber auch über Mandantenexport und anschließenden -import erstellen.

 

Erstellen der logischen Systeme

Mandanten, die von der ZBV verwaltet werden, werden im System als logische Systeme angesprochen. Deshalb muss erstmal auf dem anzubindenen System ein logisches System angelegt und anschließend einem bestehenden Mandanten auf dem anzubindenden System zugewiesen werden. Wir brauchen afu dem Zentralsystem ein logisches System für jedes CUA-System, also für das Zentralsystem selbst und alle daran angebundenen Klienten. Und auf dem jeweiligen Kind-System brauchen wir ein logisches System für das Zentralsystem sowie für das Satellitensystem selbst. Das Anlegen geht dort in der Transaktion SCC4. Wir können erstmal prüfen, ob dafür schon ein logishces System besteht. Einfach den amndanten markieren und auf das Lupe-Symbol (details). dann seht ihr in der spalte Logisches System, ob es daüfr bereits ein System gibt.

Logische Systeme haben bestenfalls die folgende namenskonvention: <SystemID>CLNT<Mandant>.

wir müssen nun also auf dem Kindsystem prüfen, ob es bereits ein Logisches System für das Kindsystem selbst gibt (ID2CLNT810) und für das Zentralsystem (SM1CLNT900).

in unserem Beispiel würde man in der Liste z. b. so den Eintrag für SM1 finden:

2014-11-05_14h24_15

und jetzt schauen wir auf dem Zentralsystem nach, ob es dort bereits ein Logisches System für sich selbst (SM1CLNT900) und für das Kindsystem gibt (ID2CLNT810). in unserem Beispiel gibt esin logisches System für SM1CLNT900, aber noch keines für ID2CLNT810

gibt es noch kein logisches System, geht auf im Feld Logisches System auf die ikone mit den zwei Papieren, um eine übersicht der bestehenden Logischen Systeme aufzuzeigen.

2014-10-31_16h39_33

Geht nun auf das Ikon mit dem Papier – Create Values – und überspringt den Schritt, in dem ihr ein projekt angeben sollt.

2014-10-31_16h40_56

 

Daruafhin öffnet sich ein Fenster mit IMG Activities.

wählt dort Set Up Logical Systems

2014-10-31_16h45_07

 

Nun wählt Ihr Define Logical System und geht auf Execute

2014-10-31_17h02_33

Klick tide warnung weg, dass diese Aktion mandatenunabhängig ist.

2014-10-31_17h03_33

 

Ihr habt wieder eine Übersicht der logischen Systeme, könnt aber nun den Button New Entries anklicken

2014-10-31_17h04_20

Nun könnt ihr ein neues logisches System anlegen. Damit das geht, müssen die bisherigen Einträge für die logischen Systeme alle voraussetzungen erfüllen. War Ein Kollege hier unachtsam, reagioert das System an dieser Stelle mit einer Fehlermeldung „Please fill in all required fields“. Das Sytem will einfach, dass Sie zu jedem System einen Namen hinzufügen. Machen Sie das, und probieren Sie es erneut, dann müssten Sie ein Fenster bekommen, mit dem Sie ein neues Logisches System definieren können. Einige User wie DDIC beispielsweise sind aber beispielsweise nicht dazu vorgesehen, in Kundensystemen Änderungen vorzunehmen.

2014-11-05_14h28_57

In diesem Fall habt ihr den ersten Schritt nicht wirklich befolgt: Ihr solltet im ersten Schritt einen Administrationsnutzer erstellen, der eben diese Änderungen durchführen kann.

Nun definieren wir das logische System im neuen Fenster und gehen im Anschluss auf die Diskette zum Speichern

2014-11-05_15h15_25

die ghleiche Prüfung müssen wir auf dem Solution Manager wiederholen – gibt es zu dem CUA bereits ein logisches System und für den SM1 selbst ebenfalls schon eines?

Falls es ein logishces System bereits geht, darf man eventuell nicht außer Acht lassen, dass es vielleciht besser ist, das alte logische System zu löschen

Alternative: Das logische System direkt ohne Umwege erstellen über die Transaktion SALE / BD54

Anstatt über die Transaktion SCC4 können wir das Logishe System ohne vorherige Prüfung auch direkt über die Transaktion SALE erstellen. dort wählen wir dannIdoc Interface / Application Link Enabling (ALE) / Basic Settings /  Logical Systems / Define Logical System (Transaktion BD54). Alternativ dazu wiederum können wir die Tabellensicht V_TBDLS pflegen mit der Transaktion SM30.

Dort wählen wir dann Edit / New Entries. In der spalte LogSystem erstellen wir einen neuen logical name in Großbuchstaben.

Für die Vergabe eines Logical Names für ein logisches System empfiehlt sich folgende Konvention: <System ID>CLNT<Mandant>.

Nun haben wir ein logisches System erstellt, es ist aber dem Mandanten noch nicht zugeweisen. Man kann einen mandanten auch nur zu einem einzigen logischen System hinzufügen. Das müssen wir aber nur für die logischen Systeme machen, die das eigene System ansprechen – sprich das Kindsystem Id2 muss seinen eigenen mandanten 810 mit dem logischen System ID2CLNT810 verbinden und das Zentralsystem seinen eigenen M Mandanten 900 mit dem logischen System SM1CLNT900. In den meisten Fällen ist das bereits geschehen. Falls nicht, verbinden wir beide logische Systeme, fall snoch nicht geschehen, mit den entsprechenden Mandanten. Das geht in der Transaktion SCC4 wieder im Fenster Display IMG (steht für Display Implementation Guide), dort liegt direkt unterhalb der eben genutzten tabelle Define Logical System  die Tabelle Assign Logical System to Client

2014-10-31_17h08_25

Geht ihr hier auf execute, bkeommt ihr wieder eine Warnung, dass die Tabelle cross-client ist (wegklicken). Dann erhaltet ihr eine Tabelle mit Zuordnungen von Clients zu logischen Systemen. hier könnt Ihr einen entsprechenden Eintrag tätigen. nun ist das logishce System mit dem Mandanten des Systems verbunden. Macht das bitte auf beiden Systemen.

wir müssen natürlich jedem Mandanten / Klienten, der in die CUA aufgenommen werden soll, ein logisches System zuweisen.

Hier im Bild zu sehen: der mandantn 900 zeigt uns in seinen Details, dass er mit dem Logischen System SM1CLNT900 verbunden ist, wunderbar.

2014-11-05_15h26_33

 Erstellen der RFC Destinations

Dazu loggen wir uns auf dem zentralsystem  (SM1) ein. im implemenmtation Guide (Transaktion SALE) wählen wir Sending and Receiving Systems – Systems in Network – Define Target systems for RFC Calls (Transaktion SM59)

das Sytsem zeigt den Bildschirm Display and Configuration of RFC Connections.

2014-11-05_17h32_54

Wir erweitern die Sicht ABAP Connections und suchen nach der RFCC Destination mit dem namen des Sattelitensystems, in unserem Fall ID2CLNT810

Wenn das Satellitensystem nicht in der Liste ist, müssen wir diese RFC Destination erstellen. Der RFC Destinaion geben wir den selben namen wie dem logischen System (ID2CLNT810) und geben den namen in Großbuchstaben ein. Als Verbindungstyp kommt 3 ein. Diese Zahl steht für eine Verbindung zu einem ABAP System – was richtig ist, weil wir uns auf den ABAP-Stack des ERP IDES-Systems auf ID2 verbinden wollen.

2014-11-05_17h36_33

 

 

Wenn das Kindsystem in der Liste ist, müssen wir den Namen des existierenden Systembenutzers herausfinden. Dazu wählen wir das Satellitensystem und wählen Edit / change. Das System zeigt jetzt RFC Destination <logical system name>. Der Systemuser des Satelittensystems ist im Logon & Security Reiter im Feld User hinterlegt.

Ansonsten, wenn die RFC Destination noch nicht angelegt war, legen wir die Informationen nun im Reiter Logon & Security selbst an. Dort kommt unter Client der Mandant des anzubindenden Kindsystems  (810) rein. Unter User schreiben wir den auf diesem Kindsystem zu diesem Zweck erstellten User rein (CUA_ID2_800)

2014-11-05_17h44_00

 

Im Reiter TEchnical Settings müssen wir jetzt noch im Feld Target Host den Hostname des Zielsystems (id2.yourdomain.com) und unter System Number die Instanznummer (hier im Beispiel 00) des Systems eingeben.

2014-11-05_17h53_35

Jetzt haben wir gerade eine RFC Destination von SM1 nach ID2 angelegt. das selbe machen wir jetzt auf dem Kindsystem ID2, um eine Verbindung von ID2 nach SM1 herzustellen.

 Die Central User Administration selbst erstellen (falls noch nicht vorahnden)

Voraussetzung ist, dass die logischen Systeme, System User und RFC Destinations bereits definiert sind. Sollten wir bereits die CUA erstellt haben und nur noch die Kindsysteme neu einbinden wollen, können wir den Report RSDELCUA mit der Option Reorganize CUA Tables im Zentralsystem und den relevanten Kindsystemen ausführen. Dadurch löschen wir alle DAten der früheren CUA über die Kindsysteme und stellen sicher dass es keine Inkonsistenzen gibt wenn wir die Kindsysteme neu einbinden.

Wir loggen uns in das Zentralsystem ein und öffnen wieder die Transaktion SALE. wir wählen Modeling and Implementing Business Processes / Predefined ALE Business Processes / Corss-Application business Processses / Central user Administration / Select Model View für Centrla Administration (transaktion SCUA).

Logische Systeme in CUA einbinden

Das geht wieder über die Transkation CUA

2014-11-05_17h58_55

 

Im Hauptbildschirm von SCUA einfach auf den Stift (edit) gehen und im daruaffolgendne Fenster in einer neuen Zeile das Logische System auswählen (ID2CLNT810)

2014-11-05_18h00_28

 

Wenn wir jetzt auf Save selected Systems gehen, müsste das systme dort auftauchen. wir bekommen wenig später automatisch die Display Logs angezeigt.

2014-11-05_18h05_23

Normalerweise sieht man in disem Display Blog dann Einträge wie:

  • ALE distirbution Model saved
  • Central ujser ADministration was acitvated
  • Text comparison saved

Folgendermaßen können wir prüfen, ob alles geklappt hat: Wir loggen uns auf dem Kindsystem (ID2) ein, öffnen Transaktion SALE und wählen Modeling and implementing Business Processes / Predefined ALE Business Processses / Cross-Application Business Processses / central user Administration / select model View for Central ADministration (Transaktion SCUA)

um zu prüfen dass das distribution model verteilt wurde, wählen wir Distribution Model / display strucutre oder gehen im Hauptbildschirm der Transaktion SCUA auf die Brille oder den Stift

2014-11-06_15h00_00

Wenn alles geklappt hat, müsten erstmal die eingebundenen Systeme mit grünen statusleuchten ausgestattet sein und in der Übersicht auftauchen. In dieser Übersicht tauchen auch veraltete logische Systeme auf, die wir noch aus früheren Konfigurationen in einer alten CUA drin haben können. Diese könennw ri markieren und mit einem Klick auf die Minus-Schaltfläche löschen. Eventuell geht das nicht, weil da eine Meldung kommt  „Cannot delete: Target system <altes logisches System> is part of an active CUA“. in diesem Fall müsst ihr das logische System erst in der Transkation WE20 – Partner Profiles – Partner Type LS – <altes Logisches System> auswählen und mit KLick auf den papierkorb löschen. Dann müsst ihr in der Transaktion BD64 unter Central User Administration – <SID> Client <Mandant der CUA> ebenfalls den Eintrag für das logische System löschen – dazu wiederum müsst ihr in der baumarchitektur bis zum logischen System durchklicken und dann die Unterknoten, die Namen haben wie „User Copy“ etc. löschen. Wenn ihr nämlich auf das logische System selbst klickt und auf den appeirkorb geht, erhaltet ihr die meldung „Action cannot be carried out on target node“ – ihr müsst stattdessen alle Unterknoten löschen und dann auf Refresh – dann ist das System verschwunden.. Danach müsst ihr den Eintrag in der Transkation BD54 ebenfalls löschen. Dann müsst ihr in der Transaktion WE21 unter Ports / Transactional RFCs den Idoc-Record für das logische System finden. Dazu müsst ihr euch durch die Knoten mit Namen wie A000000XX klicken und den finden, dessen RFC Destination den Namen des altne logischen Sytems hat, und diesen dann löschen. wenn ihr dann das Logische System jetzt final in SCUA löschen könnt, könnt ihr es endgültig in der Transaktion SALE unter Define Logical Systems löschen. Damit ist es nun endgültig verschwunden.

Jetzt müssten wir desweiteren sehen,d ass wir keine User master Records in den Kindsystemen mehr erstlelen können (SU01). Wir können aber user verwlaten und löschen die bereit sauf dem Kindsystem existieren bevor wir es in die CUA integriert haben.

Wir können es auch so testen: wir loggen uns im Zentralsystem ein (SM1), gehen in die Transaktion SU01, erstellen einen Testuser mit irgendeinem beliebigen Namen. Wir geben ihk eine Adresse und ein intiialpasswort, wie bereits bekannt, und gehen dann in den Reiter Systems, um ihn als System das Kindsystem zuzuweisen.

2014-11-05_18h11_42

wenig später, nachdem wir mit dem Disketten-Symbol den Eintrag nun gespeichert haben, müssten wir uns auf ID2-810 mit idesem User und seinem Initialpasswort einloggen können. Wenn das der Fall ist, funktioniert die CUa-Distribution.

 

Field Distribution Parameter einstellen

Beim Einsatz einer CUa kann man Distribution Paramter in der Transkation SCUM nutzen um festzulegen welche indivuduellen Teile eines User master Records gefpelgt werden sollen:

  • im Zentralsystem
  • Lokal auf dem child Node (Local)
  • im child Note mit automatischer Verteilung zum Zentralsystem und den anderen CUA Kindsystemen

Jedes Eingabefeld in der User Maintenance transaktion SU01 hat ein Feldattribut, das wir einmla im Zentralsystem mit der Transkation SCUM während des customizens setzen können. So weit wie möglich sollten wir dann den Field Maintenance indikator danach nicht mehr ändern. Wenn wir eine Distribution von lokal auf global umstellen, werden beispielsweise Rolleneinstellungen des Kindsystems durch die CUa überschribeen.

Um die Einstellunge zu machen führen wir folgendes durch:

wir loggen uns auf dem ztentralsystem ein und gehen ind ie Transaktion SALE . Wir wählen Modeling and implementing Business Processses / Predefined ALE Business Processses / Cross-application Business Processes / Central user Administration / set Distirbution PArmeters for Fields (transkation SCUM).-

DAs System zeigt nun den Bildschirm User Disitrbution Field Selection, mit Reitern der Felder dessen Verteilungsparamter gesetzt werden kann. Um zusöätzliche Felder anzuzeigen, drückt man die Bild unten taste

Wir können nun die folgenden Einstellungen wählen

GlobalWir können die Daten ausschließlich in dem Zentralsystem pflegen. Die Daten werdne dann automatisch an das Kindsystem weitergegben. Diese Felder akzeptieren keine Eingaben im Kindsystem und können daher nur angezeigt werden. Alle anderne Felder die nicht auf „global“ gesetzt werden akzeptieren Eingaben sowohl im Zentral- als auch im Kindsystem und unterschieden sich nur durch eine unterschiedlcihe Verteilung der Änderungen
ProposalDie Standardwerte im Zentralsystem werden autoamtisch an das kindsystem übertragen wenn ein user erstellt wird. Nach der verteilung klönnen die Daten NUR LOKAL verwlatet werden und werden danach nicht mehr verteilt wenn wir die Daten im Zentral- oder Kindsystem ändern
RetValWir können die Daten sowohl zentral als auch lokal ändern. Nach jedem lokalen Ändern der Daten werden die Ämderngen an das Zentralsystem geschickt und von da aus zu a nderen Systemen
EverywhereWir könen die Daten sowohl zentral als auch lokal ändern. Aber die änderungen die im Zentralsystem gemacht werden werdne auch an andere Systeme weitergeleitet, während lokale Änderungen in den Kindsystemen nicht verteilt werden.

wir speichern unsere einstellungen

Interessant ist in diesem Zusammenhang noch der Reiter Locks 

Diese Einstellujng bestimmt, ob man Sperren eines Users auch als lokaelr Administrator entfernen kann oder dies explizit im Zentralsystem machen muss.

es gibt hierbei verschiedene Einstellungen bezüglich der Sperreinträge für User, auf die ich hier nicht genauer eingehen werde.

Firmenadressen synchronisieren

DAs Zentralsystem muss jetzt informationen über alle gültigen Firmenadressen haben. diese werden dann an alle Kindsysteme verteilt so dass es einen konstitnetne status über die Firmenadressen in der gesamten CUA-LAndschaft gibt. So wird sichegrestellt, dass jeder systemübergreifende Firemandressschlüssel einzigartig ist und dass firmenadressen mit dem selben Namen, auhc die selbeVoraussetzung ist, dass bereits alle Firmenadressen in der Transaktion SUCOMP in der CUA-LAndschaft angelegt wurden.

Als erstes räumen wir alle Firmenadressen sämtlciher Systeme mit dem Report RSADRCK2 in Verbindung mit der SAP Note 439122 auf. Wenn Dateninkonsistenzen gefunden werden entfernen wir sie manuell.

Danach loggen wir usn in das Zentralsystem ein, gehen in die Transkation SALE und wählen Modeling and implementing / Predefine ALE BUsiness Processes / central user Administraiton / Transfer Users form new systems (Trtansaktion SCUG). Nun wird der bildschirm Central suer Administraiton STrucutre angezeigt.

Wir wählen den ersten Child Node den wir mit dem Zentralsystem snychorniseren wollen und wählen den Button iSynchronize Comapndy Adresses in the Central SYstemI. Es erscheint CUA: Synchronization of the Company Adresses, in welchem das SYtem eine Liste anzeigt in welcher die Firmenadressen der ausgewählten Kidnsystmeen mit dem Zentralsystem verlgichen werdne. Alle Firmenadresen die im Zentral- oder Kindsystem gehalten wurden, tauchen in dieser Liste auf. Wir gehen nun alle Unterlisten durch, welche jeweils die Adressen im Zentralsystem und in den Kindsystemen getrennt auflisten. Es gibt dabei folgende Kategorien

In Central Sstem OnlyDiese Firmenadressen existieren nur im Zentralsystem. Wir können sie sofort verteilen indiem wir Distribute to Child System wählen oder das automatische Verteilen später erlauben
In Child System onlydiese firmenadressen exisiteren nur in den child nodes, nicht im Zentralsystem. Wir haben foglende optionen. Wenn die Adresse korrekt ist und bentögit wird, könne wir sie dem zentralsystem hinzufügen indem wir die Firma des Kindsystems auswählen und dann auf Copy from Child System gehen. Wenn die Adresse hingegen inkorrekt ist oder nicht bneötigt wird, können wir sie im Kindsytem über die Transaktion SUCOMP löschen
Different Company AdressesDiese Adressen existieren sowohl zentral als auch lokal auf einem Child Node und ahebn den selben firmen adress Schlüssel, unterschieden sich aber in den ersten beidne Feldern des Firmennamens. wir müssen daher den sytemübergreifenden Adressschlüssel auf konsistenz prüfen. Wenn die Daten inkonsistent sind, aber der adressschlüssel die selbe firma referenziert in  ebiden systemen, müssen wir die daten synchronisieren, indem wir die Firma vom Zentralsystem wählen und Distirbute to Child Systems wählen oder sie automatisch verteilen lassen. Wenn Sie inkonsistent sind, aber zwei verschiedene Firmen nur den selben Company Adresss Key nutzen, löschen wir die inkonsistenz im kindsystem über die transkation SUCOMP.
Identical Company Adressesdiese Firmenadressen exisiteren zentral und lokal, und die ersten beiden Felder des Firmennamens sind identisch. Wir müssen die firmenadressdatan vergleichen und entweder Copy from Child System wählen, wenn die daten im kindsystema ktuelelr sind, oder Distribute to Child System wenn das im Zentralsystem aktueller ist. Wenn es in beiden Systemen unterschiedliche Felder gibt, die jeweils aktuelelr sind, müssen wir dies manuell synchronisieren
Company Adresses Already SynchornizedDieses Resultat wird während der synchronisation angezeigt.

das wiederholen wir mit allen child nodes und wählen jeweils den synchronize company adresses button im zentralsystem. Nachdme wir alle korrekten und benötigtne firmenadressen in das zentralsystem snychornisiert haben, wählen wir Back um die adressverteilung im Zentralsystem zu starten. Im Zentralsystem wählen wir dann den Button Distirbute -Syncronized company adresses to Target Systems.  Es erscheint der Schirm CUA: synchornization of the Comapyn Adresses

Wir wählen Distirbute to all child Systems. Ein Log erschient dass anzeigt ob die Vertileung egstrtet wurde.

Um das Resultat zu prüfen, wählenw ir Back und dann Synchornize Comapny Darresses in the Central Systems. Alle firmenadressen sind gelistet unter Company Adressesa already Synchonrized mit infomrationen über das Verteilungsresultat.

Usergruppen synchronisieren

damt wir die Möglcihekti haben User von einem Child Note und vom Zentralsystem zu kopieren oder um User vom Zentralsystem auf ein Child System zu kopieren, muss die User Gruppe die dem User zugewiesen ist in alleln Systemen sein, in die der User existiert.

Wir müssen die usergurppen, falls nocht icht vorhanden, auf jeden FAll erstlelen. Das geht über transaktion SUGR. Wir vergleichen die user gruppen der rlevanten systeme und stellen fest ob usergurppen feheln. dann erstellen wir die fehlendne gruppen im system amnuell.

Users aus neuen System transferien

Wenn man ein neues System in das Verteilungsmodell reinnimmt, müssen wir sichergehen dass die user master records im neuen system in das zentralsystem übertragen werden.

Voraussetzung: Die Firmenadressen wurden bereits synchornisiert.

Loggt euch in das Zentralsystem ein, geht in die Trnasaktion Sale, wählt Modeling and implementing Business processes / Predefined ALE Business Processes / central user Administration / Transfer Users from new Systems (transaktion SCUG).

Das sYstem ezigt dne schirm Central user Administraiton STrucutre display mit einer baumsturktur der Systeme im Verteilermodell. die systeme mit dem indikator New enthalten user master Records die noch nicht in der CUA drin sind.

Wir wählen alle user unter new und changed und wählen dann transfer users. Das wiedehrolen wir für alle child nodes von denen wir user transferien wolen. Nachdem der user transfer fertig ist, entfernenw rid ie rollen Z_SAP_BC_CUA_SETP_CENTRAL und Z_SAP_BC_USR_CUA_SETP_CLIENt von den system users. Diese Rollenw erdne nur gebraucht um eine CUa aufzusetzen, nicht zum Betreiben.  mit der Transkation SCUl prüfen wir ob die Verteilung erfoglreich war.

Andreas Loibl ist SAP-Berater, Ethical Hacker und Online Marketing Manager und schreibt auf seinem Blog DaFRK Blog über verschiedene Themen in den Sektoren Projektmanagement, Informationstechnik, Persönlichkeitsentwicklung, Finanzen und Zeitmanagement.

DaFRK

Andreas Loibl ist SAP-Berater, Ethical Hacker und Online Marketing Manager und schreibt auf seinem Blog DaFRK Blog über verschiedene Themen in den Sektoren Projektmanagement, Informationstechnik, Persönlichkeitsentwicklung, Finanzen und Zeitmanagement.

Das könnte Dich auch interessieren …

1 Antwort

  1. 21. Juni 2017

    […] im Jahr 2014 habe ich Ihnen erklärt, wie Sie eine zentrale Benutzerverwaltung einrichten. Häufig handelt es sich hierbei um eine Technical Usage eines SAP NetWeaver AS ABAP Systems, das […]

Schreibe einen Kommentar

Deine E-Mail-Adresse wird nicht veröffentlicht.

Diese Website verwendet Akismet, um Spam zu reduzieren. Erfahre mehr darüber, wie deine Kommentardaten verarbeitet werden.