ZBV Waschzettel

Die Geister mögen sich streiten ob man die ZBV noch benötigt oder nicht. Ich bin der Meinung dass sie immer noch hilfreich sein kann, selbst bei ganz kleinen SAP Landschaften. Insbesondere Zugangsdaten zu Mandanten, in denen man sich nur selten anmeldet, geraten schnell in Vergessenheit. Handelt es sich um den Mandanten 000 und man muss Support Packages einspielen, so ist man dankbar, wenn man den Zugang unkompliziert freischalten kann.

Die Aktivierung der ZBV (z.B. in einem vorhandenen Solution Manager Mandanten) bietet ausreichend Sicherheit gegen eine typische Fehlerkette getreu Murphys Law.

  • Man hat sein Passwort vergessen
  • man hat sein Passwort nicht notiert
  • eine Kollegin hat Urlaub
  • ein Kollege hat sein Passwort ebenfalls vergessen
  • der Rest der Welt hat in diesem System und diesem Mandanten  keinen Benutzer

Nicht schön!  Natürlich leisten Passwortrichtlinien ebenfalls ihren Beitrag zur allgemeinen Verwirrung. Hier also der Waschzettel für die Einrichtung der ZBV.

Grundlagen

Für eine funktionierende ZBV benötigt man Benutzer mit Rechten im Zentralsystem sowie in den Tochtersystemen und dazwischen RFC Verbindungen in beide Richtungen. Dazu sollten logische Systeme angelegt und zugeordnet sein. Dies wird hier aber nicht weiter erklärt. Bevor Sie anfangen etwas in den Systemen anzulegen empfehle ich eine Namenskonvention für Benutzer und RFC Verbindungen zu definieren, falls dies nicht bereits geschehen ist.

Vom Zentralsystem zu den Tochtersystemen benötigen Sie je eine RFC Verbindung pro Mandant. Von den Tochtersystemen zum Zentralsystem genügt eine RFC Verbindung pro Tochtersystem. Bedenken Sie bitte, dass das Zentralsystem auch gleichzeitig Tochtersystem ist.

Benutzer

In jedem Mandanten eines jeden Tochtersystems (SID)

  • Benutzer vom Typ KOMMUNIKATION oder SYSTEM (je nachdem ob sie Kennworte regelmäßig ändern wollen, oder nicht) nach der Namenskonvention CUA_SID_CLIENT anlegen.
  • Dem Benutzer die Rollen SAP_BC_USR_CUA_SETUP_CLIENT  und SAP_BC_USR_CUA_CLIENT zuordnen. Sie dürfen sich auch gerne vorab Z-Rollen dieser SAP-Rollen bauen. Wird von SAP so empfohlen. So oder so müssen die Profile zu den Rollen generiert werden, also einen prüfenden Blick auf die Profile werfen!

Im Arbeitsmandanten (100) des Zentralsystems

  • Benutzer vom Typ KOMMUNIKATION oder SYSTEM nach der Namenskonvention CUA_SID anlegen. Hier ist natürlich die SID des Tochtersystems gemeint.
  • Dem Benutzer die Rollen SAP_BC_USR_CUA_SETUP_CENTRAL  und SAP_BC_USR_CUA_CLENTRAL zuordnen. Und auch hier Profile prüfen nicht vergessen.

Zur Erinnerung die Benutzertypen sowie die technischen Eigenschaften

Eigenschaft Dialog Kommunikation System Service
GUI Anmeldung Ja Nein Nein Ja
RFC Anmeldung Ja Ja Ja Ja
Erzwingen Kennwortänderung Ja Ja Nein Nein
Kennwortablauf Ja Ja Nein Nein
Anmeldetickets Ja Ja Nein Nein

RFC Verbindungen anlegen

Da zwei Systeme für eine Anleitung genügen (Zentral- und Tochtersystem) belasse ich es dabei. Weitere Tochtersysteme werden analog angebunden.

  • Zentralsystem: CTR Mandant 100
  • Tochtersysteme: DGT Mandant 000 und 100, CTR Mandant 000 und 100

Es hat sich bewährt die Namen der RFC Verbindungen an die Namen der logischen Systeme anzupassen. Das sind CTRCLNT000, CTRCLNT100, DGTCLNT000 und DGTCLNT100. Zuerst im Arbeitsmandanten (100) des Zentralsystems je eine RFC Verbindung zu jedem Mandanten eines Tochtersystems anlegen.

  • Destination: Name des logischen Systems (z.B.: DGTCLNT100)
  • Verbindungstyp: 3
  • Anmeldung: zuvor angelegter Benutzer (z.B.: CUA_DGT_100) mit Mandant und Kennwort
  • Zielmaschine: den Hostnamen des Tochtersystems eintragen
  • Instanznummer: wie der Name schon sagt

Danach in jedem Mandanten eines jeden Tochtersystems eine RFC Verbindung zum Zentralsystem anlegen.

  • Destination: Name des logischen Systems (CTRCLNT100)
  • Verbindungstyp: 3
  • Anmeldung: zuvor angelegter Benutzer (z.B.: CUA_CTR) mit Mandant (100) und Kennwort
  • Zielmaschine: den Hostnamen des Zentralsystems eintragen
  • Instanznummer: wie der Name schon sagt

Verteilungsmodell

Im Zentralsystem Start der Transaktion SCUA und Angabe eines Namens für das Verteilungsmodell (z.B.: ZBV_UNTERNEHMEN). Dann auf 'Anlegen' klicken und alle Tochtersysteme angeben (z.B.: DGTCLNT100) und Angaben abspeichern. Ab jetzt können Benutzer nur noch in der ZBV gepflegt werden; wie genau das ist legen wir im nächsten Schritt fest.

Verteilungsparameter

In dieser Transaktion SCUM legt man fest wo die einzelnen Bereiche eines Benutzerstammsatzes gepflegt werden. Zur Auswahl stehen

  • im Zentralsystem
  • lokal im Tochtersystem
  • im Tochtersystem mit automatischer Rückverteilung an alle angebundenen Systeme

Dies wird gesteuert über die Einstellmöglichkeiten 

Einstellung Beschreibung
Global Die Daten werden im Zentralsystem gepflegt und an die Tochtersysteme verteilt.
Vorschlag Ein Vorschlagswert wird im Zentralsystem eingestellt und greift beim Anlegen eines neuen Benutzers. Nach der Verteilung werden die Werte lokal gepflegt.
Rückverteilung Daten können lokal und zentral gepflegt werden. Lokal gepflegte Daten werden ans Zentralsystem gesendet und von dort an die anderen Tochtersysteme verteilt.
Lokal Daten werden im Tochtersystem gepflegt und nicht verteilt.
Überall Daten können lokal und zentral (überall) gepflegt werden. Aber nur zentral gepflegte Daten werden an Tochtersysteme verteilt.

Zu dem Thema kann man kaum Empfehlungen geben. Ausschlaggebend ist die jeweilige Situation. Zwei Empfehlungen aus der Praxis

  • Für die Felder Drucker, Parameter und Gruppe (allgemein) wird die Einstellung Vorschlag empfohlen.
  • Für Felder mit Daten, die der Benutzer selbst pflegen kann wird die Einstellung Rückverteilung empfohlen.

Firmenadressen

Das Zentralsystem muss alle Firmenadressen kennen, die in den Tochtersystemen gepflegt sind. Andernfalls ist eine Verteilung nicht möglich. Mit der Transaktion SCUG kann man im Zentralsystem die Firmenadressen synchronisieren. Das bedeutet vom Zentralsystem in ein Tochtersystem bringen oder vom Tochtersystem ins Zentralsystem übernehmen. Findet man dabei Adressen, die man löschen möchten, kann dies im jeweiligen lokalen System mit der Transaktion SUCOMP durchgeführt werden. Dateninkonsistenzen in den Firmenadressen kann man mit dem Report RSADRCK2 feststellen und auch beheben lassen. Siehe dazu SAP Hinweis 439122.

Benutzergruppen

Damit Benutzer synchronisiert werden können, müssen zuvor die Benutzergruppen synchronisiert sein. Mit der Transaktion SUGR ermittelt man die vorhandenen Benutzergruppen in den Systemen und legt fehlende Gruppen manuell an. Wenn der SAP Hinweis 395841 im System ist, werden die Benutzergruppen bei Bedarf automatisch angelegt.

Benutzer

Dieser Schritt muss beim Aufsetzen der ZBV initial für jedes System durchgeführt werden und jedes Mal für ein System das neu in die ZBV aufgenommen wird. Dazu meldet man sich am Zentralsystem an und ruft die Transaktion SCUG auf. Für die Übernahme eines Benutzers, gibt es 4 Mögliche Situationen.

  • Neue Benutzer: Existieren nur auf dem Tochtersystem und können daher einfach ins Zentralsystem übernommen werden.
  • Bereits zentrale Benutzer: hier ist nichts weiter zu tun.
  • Identische Benutzer: haben die gleiche Benutzerkennung, aber z.B. andere Rollen/Profile, die Daten können ins Zentralsystem übernommen und verteilt werden.
  • Unterschiedliche Benutzer: diese haben zwar die gleich Benutzerkennung stellen aber verschieden Zugänge dar. Sprich werden von unterschiedlichen Personen gleichen Namens genutzt. In einem solchen Fall muss einer der Personen eine neue Benutzerkennung erhalten.

Wenn alle Benutzer eines Tochtersystems übernommen wurden stehen in de Funktionen Anlegen und Löschen von Benutzern in dem System nicht mehr zur Verfügung. Wenn die Benutzerübernahme an allen Systemen abgeschlossen ist können die *SETUP* Rollen den Benutzern wieder entzogen werden.

Protokolle

Die Transaktion SCUL dient der Kontrolle der IDoc Verteilung. Dabei werden für jeden Benutzer bis zu 3 USERCLONExx IDocs verschickt: Benutzerattribute USER, Profilzuordnung PROFILE und Rollenzuordnung  ACTGRP.  Es gibt 4 mögliche Kategorien/Farben.

  • Verteilung mit Fehlern (rot): IDoc konnte nicht verbucht werden.
  • Verteilung unbestätigt (grau): IDoc wurde im Tochtersystem noch nicht verarbeitet.
  • Verteilung mit Warnung (gelb): IDoc wurde mit Warnungen verbucht.
  • Fehlerfrei Verteilung (grün): IDoc wurde erfolgreich verbucht.

Bei allen nicht grünen Fällen muss die Ursache gefunden und beseitigt werden. Danach muss neu verteilt werden.

Viel Erfolg!

Autor: Dirk SchwilskiWebsite: /index.php/prof/profile-ds