| Passwort vergessen?
FICO Grundlagen
Karriere
Artikel
Auswertungen
Strategie
Demos
Seminarkalender
Forum
Add-On
Zertifizierung
Buecher
FICO - Fun
tell a friend


Werbung
Sie sind nicht angemeldet.  Anmelden



SAP
Single client
  •  
Bewertung abgeben
 1
26.10.16 07:58
exberliner 
Single client

Hallo Zusammen,

letztens ist in inem Gespräch ein Prejekt "Single client" genannt worden. Ich habe mal etwas gegoogelt und ich könnte mir vorstellen, dass damit gemeint ist mehrere Systeme bzw. Mandanten zu konsolidieren.

In dem Zuge habe ich auch etwas gelesen über das Vorgehen mehrere Mandanten im D-System anzulegen: config-only, ABAP und Unit Test etc.
Sowas habe ich aber noch nie gesehen bisher - ist so ein Konzept gängige Praxis? Ich hatte letztens auch schon mal den Begriff "Golden client" gehört, und hier ist der Begriff wieder aufgetaucht. Wobei es von "Golden client" scheinbar auch verschiedene Definitionen gibt.

Kennt Ihr sowas, was haltet Ihr davon?

Danke
Exberliner

31.10.16 10:12
MrBojangles 
Re: Single client

Hallo exberliner,

ja - ist durchaus nicht unüblich, im Development-System einen Mandanten rein fürs Customizing und Entwicklung zu haben (Golden Client), d.h. ohne Stamm- und Bewegungsdaten (Ausnahmen bestätigen dabei die Regel, z.B. Sachkonten braucht man auch im Golden Client) und einen oder mehrere andere für die Durchführung von Funktionstest, in denen auch Testdaten und -belege angelegt werden können/sollen. Darüber hinaus gibt es üblicherweise noch einen "Sandbox"-Mandanten. Details findest Du in der SAP-Doku z.B. hier:
https://help.sap.com/saphelp_nw70/helpda...m&node_id=8

Weiterhin viel Freude mit SAP...
Cheers
MrB.
Blog

31.10.16 10:39
exberliner 
Re: Single client

Danke Mr. Bojangles.

Kannst Du mir noch sagen, was Du als Vorteil siehst wenn man das so macht? Wie gesagt, ich kenne bisher nur 3-Systemlandschaften mit je einem Mandanten, wenn man mal 000 und 066 weglässt. Das einzige was ich mir vorstellen könnte, wäre das man eine Sicherung hat (Golden Client) auf die man immer zurückgehen kann und Customizing löschen kann, weil ja keine Daten da sind. Oft läßt SAP das ja zu und man erzeugt dadurch ein inkonsistentes System...

31.10.16 12:36
MrBojangles 
Re: Single client

...ist sicherlich ein Vorteil. Ich finde es immer ganz gut, wenn im Mandanten, in dem die Einstellungen vorgenommen werden, keine Bewegungsdaten vorhanden sind. Dadurch ist man zum einen "freier" im Customizing, weil man nicht auf bereits gebuchte Belege Rücksicht nehmen muss und man hat eine "saubere" Quelle, um bei Bedarf einen neuen Funktionstest-Mandanten aufzusetzen, wenn man den Test-Mandanten durch krumme Stamm- und Bewegungsdaten vermurkst hat.

Weiterhin viel Freude mit SAP...
Cheers
MrB.
Blog

10.01.19 14:43
exberliner 
Re: Single client / Golden client

Hi MrB, und an alle Anderen,

...und wieder kommt das Thema Golden Client hoch

Wir diskutieren das DEV System neu aufzubauen, worin mehrere Mandanten produktiv sind. In dem Zuge kam die Idee wieder hoch einen Golden Client einzurichten.

Wenn man das tut - was wäre die Empfehlung in einer 3-System-Landschaft:
1) das reguläre Entwicklungssystem (Entwicklung+Customizing) Stamm- und Bewegungsdatenfrei zu halten ODER
2) Stamm- und Bewegungsdaten zuzulassen für Unit-Tests (wie heute auch) und ein Golden Client System vorzuhalten, in das die
Entwicklungs- und Customizingtransporte zusätzlich einlaufen. Das käme dann Deiner Idee entgegen, MrB, das E-System schnell aufbauen zu können, wenn es vermurkst wird.
Der Golden Client müsste dann ein extra System sein denke ich, kein zusätzlicher Mandant im Entwicklungssystem, da es ja Änderungen am Repository gibt bzw. mandantenübergreifendes Customizing. Und die Frage ist, wann dieses zusätzliche Golden Client-System dann die Änderungen erhält: zum Zeitpunkt des Transports in das QAS oder PRD-System.

Ehrlich gesagt, habe ich das in den Firmen in denen ich gearbeitet habe noch nicht gesehen, und sehe ich den Sinn eines Golden Client immer noch nicht.

Danke für Input...
Exberliner

Zuletzt bearbeitet am 10.01.19 14:50

12.01.19 11:07
MrBojangles 
Re: Single client

Hallo Exberliner,

also ich kenne das (aus mehreren Kundeninstallationen verschiedenster Branchen) typischerweise so:

DEV
Mandant 100 - Customizing/Entwicklung (bewegungsdatenfrei, nur obligatorische Stammdaten, z.B. Sachkonten, "Golden Client")
Mandant 200 - Funktionstestmandant (gesperrt für Cust./Entwicklung, wird per SCC1 aus Mdt. 100 mit Customizing versorgt, Frei zur Anlage von Stamm- und Bewegungsdaten)
Mandant 900 - Sandbox (offen für Customizing ohne Transportanschluss, wird ggf. zyklisch gelöscht und aus 100 neu aufgebaut)
...

QAS
Mandant 100 - QS
Mandant 200ff. - QSx - für spez. Testszenarien (z.B. Lasttest, Migration, Schnittstellen-Tests und so weiter.)
Mandant xxx - Schulung
...

PRD
Mdt. 100 - Prod

Transportwege: DEV/100 - alle QAS-Mandanen - PRD/100

Natürlich gibt es auch noch zig. andere Spielarten, z.B. eigenes Sandbox-System und so weiter. Bin allerdings kein Basis-Mann, vlt. solltet ihr Euch Beratung holen...

Weiterhin viel Freude mit SAP...
Cheers
MrB.
Blog

Zuletzt bearbeitet am 12.01.19 11:08

16.01.19 10:24
exberliner 
Re: Single client

Vielen Dank, Mr.B. Ich denke da auch immer an mandantenübergreifendes Customizing, wenn mehrere Mandanten im Einsatz sind. So wie bei Dir beschrieben. Aber im Grunde ist das eher selten, und vielleicht in der Praxis kein Problem.

Jetzt haben wir in allen Systemen vier produktive Mandanten. Das bedeutet, wir bräuchten bei diesem Szenario 12 Mandanten (100, 200, 900 x 4). Das hört sich recht aufwändig an, so eine Systemlandschaft aufzubauen und zu betreiben.
Und hast Du schon mal eine Systemlandschaft gesehen, nur mit Golden Client, also ohne Funktionstest und Sandbox? Das wird bei uns diskutiert, und ich wüsste nicht, was da der Vorteil sein soll... Abgesehen von dem, was Du geschrieben hast:

...ist sicherlich ein Vorteil. Ich finde es immer ganz gut, wenn im Mandanten, in dem die Einstellungen vorgenommen werden, keine Bewegungsdaten vorhanden sind. Dadurch ist man zum einen "freier" im Customizing, weil man nicht auf bereits gebuchte Belege Rücksicht nehmen muss und man hat eine "saubere" Quelle, um bei Bedarf einen neuen Funktionstest-Mandanten aufzusetzen, wenn man den Test-Mandanten durch krumme Stamm- und Bewegungsdaten vermurkst hat.

Nochmal danke,
Exberliner

Zuletzt bearbeitet am 16.01.19 10:26

16.01.19 10:52
MrBojangles 
Re: Single client

Hallo exberliner,
Systeme mit mehreren produktiven Mandanten (in einem System) hatte ich noch nicht und in die Diskussion mische ich mich nicht ein...
hier nur nochmal die SAP-Empfehlung für eine (typische) 3-System-Landschaft: https://help.sap.com/doc/saphelp_nw73/7....39/frameset.htm

Weiterhin viel Freude mit SAP...
Cheers
MrB.
Blog

16.01.19 11:47
exberliner 
Re: Single client

Danke für Deinen Input, auch die SAP-Hilfeseite ist sehr interessant.
Bei unser Konstellation mit mehreren produktiven Mandanten bleibe ich erstmal dabei: Entwicklung und Funktionstest im DEV-Mandanten, also keine Trennung von Entwicklung und Funktionstest. Weitere Tests und Abnahmetest durch den Fachbereich im QAS.

 1
Entwicklungssystem   Funktionstest   3-System-Landschaft   Schnittstellen-Tests   Funktionstestmandant   Mandanten   Test-Mandanten   Kundeninstallationen   Transportanschluss   3-Systemlandschaften   Bewegungsdaten   Customizingtransporte   Exberliner   Customizing   mandantenübergreifendes   Entwicklung   Bewegungsdatenfrei   Systemlandschaft   Funktionstest-Mandanten   Development-System

SAP