Ansicht
Dokumentation

Mehrmandantenfähigkeit des APO ( RELNAPO_30A_SP1_FCS_CLNT )

ABAP Short Reference   BAL Application Log Documentation  
Diese Dokumentation steht unter dem Copyright der SAP AG.

Kurztext

Mehrmandantenfähigkeit des APO

Mandantenkonzept

Das Mandantenkonzept, wie es auch in der R/3-Basis des APO enthalten ist, wird beschrieben als ein juristisch und organisatorisch eigenständiger Teilnehmer im R/3 System, bei dem alle betriebswirtschaftlichen Daten gegenüber anderen Mandanten geschützt sind. Auf dem Anmeldebild des R/3-Systems erscheint der Mandant als qualifizierender Begriff, der eine Aufteilung des physischen R/3-Systems in mehrere logische Anwendungssysteme bewirkt. Diese können bezüglich ihrer Daten isoliert und völlig unabhängig voneinander betrieben werden.

Insbesondere bedeutet dies, mehrere Mandanten gegeneinander so zu isolieren,

• daß die Daten jedes Mandanten gegen Einsichtnahme und Änderung gegenüber anderen Mandanten geschützt sind (datenmäßige Isolation)

• daß sich zwei arbeitende Mandanten während des gesamten Systembetriebs nicht stören oder sonst in irgendeiner Form beeinflussen (funktionale Isolation)

• daß es jederzeit möglich ist, die Mandantenkonfiguration des Systems zu ändern, also einen weiteren Mandanten zusätzlich hinzuzunehmen, einen bestehenden zu löschen oder hinsichtlich seiner Customizing-Einstellungen zu ändern (Autarkheit).

Weitere Informationen finden Sie im White-Paper Mehrmandantenfähigkeit des R/3 Systems im SAPNet (Bestellnummer: 50014215(9602/01).

Mandantenfähigkeit

Mit dem APO wird eine mandantenfähige R/3-Basis ausgeliefert, die ab APO 3.0A auch von den APO-Applikationen unterstützt wird. Damit wird es möglich sein, mehrere Mandanten in APO zu betreiben. Dies ist vor allem im Entwicklungs-, Test- und Schulungsbetrieb von Vorteil, da dadurch der Verwaltungsaufwand für die Systemadministration deutlich gesenkt werden kann.

Wie auch für das Mandantenkonzept des R/3 gilt jedoch, daß einige zentrale Ressourcen, die funktionale Grundelemente der Software darstellen, weiterhin mandantenunabhängig bleiben. Daraus resultieren Einschränkungen bezüglich der Mandantenfähigkeit des APO, die beim Einsatz mehrerer Mandanten berücksichtigt werden müssen. Zudem können einige Verwaltungsfunktionen für den Mehrmandantenbetrieb mit dem APO-Release 3.0A noch nicht in vollem Umfang genutzt werden.

Mandantenunabhängiges Customizing

Die im folgenden angeführten technischen und globalen Einstellungen sind für den Mehrmandantenbetrieb als unkritisch einzustufen.

Im Gegensatz dazu stehen funktionale Einstellungen im Customizing, die Einfluß auf betriebswirtschaftliche Prozesse nehmen, aber dennoch mandantenunabhängig bleiben. Solche Einstellungen gibt es sowohl im CORE R/3 als auch im APO. Es handelt sich dabei in der Regel um Änderungen am ABAP Repository, welches mandantenunabhängig ist.

Speziell im APO-Umfeld entsteht durch das Generieren von BW-InfoCubes mandantenunabhängiges Coding, auf welches nur über einen einzigen Mandanten zugegriffen werden kann. Davon sind alle Applikationen des APO betroffen, die BW-InfoCubes als Datenbasis nutzen, insbesondere:

• Demand Planning Absatzplanung (DP)

• Supply Network Planning (SNP)

• Kontingentierung (ATP), wenn mit Daten aus BW-InfoCubes versorgt

• Collaborative Demand and Supply Planning kooperierende Absatz- und Beschaffungsplanung (CP)

• Network Design (ND), wenn mit Daten aus BW-InfoCubes versorgt

Diese Applikationen können nicht oder nur eingeschränkt im Mehrmandantenbetrieb genutzt werden.
Der in diesem Zusammenhang verwendete Mandant wird implizit durch das erstmalige Aufrufen einer BWApplikation (DP, SNP, ND etc.) festgelegt und kann nachträglich nicht mehr geändert werden. Rufen Sie beispielsweise erstmalig DP im Mandanten 001 auf, so können DP und SNP auch in Zukunft ausschließlich im Mandanten 001 genutzt werden.

Die Menge der mandantenübergreifenden Customizing Einstellungen läßt sich zunächst unterteilen in drei Kategorien:

• Technische Einstellungen

Bei dieser Kategorie handelt es sich um Einstellungen zur technischen Abstimmung des Systems auf die verfügbaren Ressourcen, um technische Konfigurationen und um Einstellungen von Systemprofilparametern. Sie haben keinerlei Auswirkung auf betriebswirtschaftliche Funktionen der Anwendung.

• Globale Einstellungen

Solche Einstellungen sind in der Regel unabhängig von einem speziellen Unternehmen und deshalb unabhängig von einem speziellen Mandanten. Beispiele hierfür sind Währungsdefinitionen, DÜVO- und Finanzamtschlüssel. Für den Betrieb eines Mehrmandantensystems bedeutet dies verminderten Pflegeaufwand, da die Pflege nur einmal pro physischem System und nicht redundant pro Mandant erfolgen muß.

• Änderungen am ABAP Repository

Funktionale Erweiterungen, welche Änderungen am ABAP Repository darstellen, entstehen durch Generierung von Coding, Nutzung von User-Exits sowie Modifikation von ausgeliefertem SAP-Coding. In diesem Fall handelt es sich um Änderungen an betriebswirtschaftlichen Geschäftsprozessen mit systemweiter Gültigkeit. Normalerweise können diese mandantenunabhängigen Einstellungen über Namenskonventionen zentral abgegrenzt werden.

Verwaltungsfunktionen

Das Anlegen und Kopieren von Mandanten des APO kann analog zum Vorgehen bei einem Core-R/3-System durchgeführt werden.

Die Übernahme von Applikationsdaten in den Zielmandanten wird nicht empfohlen, da das Kopieren und Synchronisieren der mandantenabhängigen liveCache Daten mit den mandantenabhängigen APO-Datenbankdaten in APO Release 3.0A noch nicht möglich ist. Daher empfehlen wir, bei der Mandantenkopie lediglich das Customizing in den Zielmandanten mitzunehmen und die Anwendungsdaten aus externen Quellen zu beziehen.

Keinesfalls darf als Zielmandant der Mandant 000 oder der Mandant 066 angegeben werden.

Voraussetzung für die Initialisierung (und damit die Nutzung) eines liveCache-Mandanten ist das Anlegen einer RFC-Verbindung zu diesem Mandanten und die Berechtigung SAP_ALL.

Beachten Sie dazu die Hinweise im Upgrade-Leitfaden.

Nutzungsumfang

Ein Mehrmandantensystem erscheint dann angezeigt, wenn die partizipierenden Mandanten wenige Änderungen an ABAP-Repository-Objekten vornehmen.
Dies ist nicht der Fall, wenn in einem Mandanten eine Vielzahl von Einstellungen am ABAP Repository vorgenommen werden oder BW-InfoCube-abhängige Applikationen zum Einsatz kommen (DP, SNP).

Auslieferungssystem und Mandantenstruktur

Mit der Systeminstallation wird bei Ihnen ein SAP-System mit den folgenden Mandanten eingerichtet:

• Mandant 000

In diesem Mandanten sind für alle Tabellen Voreinstellungen vorhanden. Für die Tabellen, in denen Sie Ihre Organisationsstruktur ablegen, sind Mustereinträge vorhanden. SAP aktualisiert mit jedem System-Upgrade und mit jedem Release-Wechsel die Voreinstellungen.

In diesem Mandanten dürfen Sie nicht arbeiten.

• Mandant 001

Der Mandant 001 ist inhaltsgleich mit dem Mandanten 000. In diesem Mandanten können Sie das Customizing durchführen und die Standardauslieferung gemäß Ihren Anforderungen anpassen.

• Mandant 066

Der Mandant 066 wird leer ausgeliefert und ist ausschließlich dem SAP-Service für System-Monitoring vorbehalten.

In diesem Mandanten dürfen Sie nicht arbeiten.

Upgrade

Wegen der Umstellung des APO auf Mandantenabhängigkeit werden beim Upgrade auf APO 3.0A etwa 600 APO-Tabellen auf der Datenbank angepaßt. Dabei werden die Daten der umgestellten Tabellen in den im System definierten Produktivmandanten umgesetzt.

Normalerweise sind APO-Systeme vor APO Rel. 3.0A standalone und mandantenunabhängig, d.h., normalerweise ist vorab kein Produktivmandant in einem APO-System eingestellt. Ist kein Produktivmandant eingestellt, so muß vor dem Upgrade in jedem Fall ein Produktivmandant definiert werden. Es wird empfohlen, Mandant 001 als Produktivmandant einzustellen. Keinesfalls darf der Fall eintreten, daß die Daten in den Mandanten 000 (kein Produktivmandant definiert) oder in den Mandanten 066 (Mandant 066 als Produktivmandant definiert) umgesetzt werden.

Beim Upgrade werden die Daten der Tabellen, die mandantenabhängig werden, in den Produktivmandanten umgesetzt. Das bedeutet, daß alle Customizing-Einstellungen aus dem Release 2.0A nach dem Upgrade im Produktivmandanten zu finden sind.
Das SAP-Customizing wird beim Upgrade in den Mandanten 000 importiert. Das heißt, die zu Release 3.0A neuen Mustereinträge sind nicht im Produktivmandanten zu finden. Diese neuen Einträge müssen erst in den Produktivmandanten transportiert werden, um APO-3.0A-Funktionen dort nutzbar zu machen.

Voraussetzung für die Initialisierung (und damit die Nutzung) eines liveCache-Mandanten ist das Anlegen einer RFC-Verbindung zu diesem Mandanten und die Berechtigung SAP_ALL.

Beachten Sie dazu die Hinweise im Upgrade-Leitfaden.

Kundeneigene Entwicklungen und Modifikationen

Gibt es Eigenentwicklungen im System und darunter Dictionary-Objekte, die analog zu APO Release 3.0A auf Mandantenabhängigkeit umgestellt werden müssen, dann sollte diese Umstellung der kundeneigenen Objekte nach dem Upgrade erfolgen.

Wurden Modifikationen an APO-Objekten durchgeführt, die in APO-Release 3.0A mandantenabhängig werden, so muß beim Modifikationsabgleich dafür gesorgt werden, daß diese Objekte in jedem Fall mandantenabhängig werden.
Wird nicht dafür gesorgt, daß diese APO-Objekte mandantenabhängig werden, so kann es zu Aktivierungsfehlern, Datenverlust und Laufzeitfehlern kommen.

Beachten Sie dazu die Hinweise im Upgrade-Leitfaden.

PERFORM Short Reference   CPI1466 during Backup  
Diese Dokumentation steht unter dem Copyright der SAP AG.

Length: 11274 Date: 20240426 Time: 093830     sap01-206 ( 209 ms )