Der Unterschied zwischen Standard- und Compact-Deployment

Im Gespräch mit Kollegen kam das Thema Compact-Deployment auf.
Vereinfacht gesagt, ist das Ganze hochinteressant, wenn man ein mehr oder weniger komplettes EPM-System auf einem Notebook installiert.

Wer schon mal vor einer Kundenpräsentation 30 Minuten und mehr warten musste, bevor Workspace die Anmeldung erlaubte, weiß, was ich meine.

Für die Installation auf Kundensystemen mit entsprechend ausgestatteten Servern ist nach wie vor das Standard- oder das Rapid-Deployment die erste Wahl. Dort sind die System-Ressourcen größer und, gaaanz wichtig, jeder EPM-Service sollte zur Sicherstellung des reibungslosen Betriebs als eigener Prozess laufen, damit er im Fehlerfall einzeln gestoppt werden kann.

Andernfalls könnte man in die Verlegenheit kommen, bei Problemen z.B. mit dem EAS (den nur wenige Kollegen nutzen), das komplette EPM-System neu starten zu müssen.
Keine schöne Vorstellung auf Produktiv-Systemen.

Ergänzend weise ich darauf hin, dass es weitere, hier nicht beschriebene Unterschiede und Voraussetzungen gibt, die in der Oracle-Dokumentation nachgelesen werden können.

Es gibt

• die Standard-Installation und -Konfiguration ==> Standard-Deployment
• die Rapid-Installation und -Konfiguration ==> Rapid-Deployment
• die Compact-Installation und -Konfiguration ==> Compact-Deployment

Standard-Deployment bedeutet, alle Produkte werden installiert und laufen in einer eigenen Web-Applikation. Erkennbar ist das später daran, dass jedes Produkt (z.B. Workspace, EAS, Planning,…) mit einem eigenen Port in der URL aufgerufen wird. Entschieden wird das im Rahmen des Konfigurations-Prozesses, die Installation für das Standard-Deployment entspricht der bekannten Installations-Routine.
Als Standard-Einstellung ist Option „Stellen Sie die JAVA-Web-Anwendungen auf einem…..“ deaktiviert, die Produkte werden wie gezeigt deployed.

Rapid-Deployment bedeutet, dass es gewisse Einstellungen gibt, mit denen ein bestimmtes Produkt-Bundle (z.B. Essbase mit Planning oder Essbase mit HFM) schnell installiert werden kann, da automatisch die benötigten Zusatzprodukte mitinstalliert / konfiguriert werden (z.B. Financial Reporting, Essbase Studio). Das Setup geht schnell, das Deployment der einzelnen Produkte entspricht aber dem Standard-Deployment.

Compact-Deployment bedeutet, dass alle Produkte wie üblich installiert werden, die Unterscheidung erfolgt während der Konfiguration.
Dort kann Option „Stellen sie die JAVA-Web-Anwendungen auf einem…..“ aktiviert werden, alle markierten Produkte laufen später in einer gemeinsamen Web-Applikation, erkennbar daran, dass alle Produkte (z.B. Workspace, EAS, Planning,…) mit dem gleichen Port in der URL aufgerufen werden, default-Port ist 9000 (statt der bekannten 19000, 10080, 13080, 28080,…)

Im einem der folgenden Konfigurationsschritte den „Embedded WebLogic HTTP Server“ anstatt dem „Oracle Http-Server“ wählen.

Das ist es schon. Übrigens, ein weiteres Merkmal des Compact-Deployment ist das Fehlen der gewohnten Skripte zum Starten und Stoppen der Dienste. In Verzeichnis ..\user_projects\epmsystem1\bin gibt es kein Skript startEssbaseAdminServer.bat / .sh, wenn der EAS im Compact-Deployment deployed wurde. Der Dienst wird automatisch und untrennbar mit Skript startEPMServer.bat gestartet.

Ich selber habe mir das auf meinem Thinkpad so eingerichtet, dass Produkte, die ich regelmäßig benötige, in einer gemeinsamen Web-Applikation laufen (Foundation, Essbase, EAS, Planning) und Produkte, die ich nur sporadisch hoch fahre, jeweils in separate Web-Applikationen deploye (Financial Reporting, Web Analysis, Interactive Reporting,….).

Die Vorteile sind

• deutlich schnellere Startzeiten (wenige Minuten statt halbe oder ganze Stunden)
• deutlich weniger Dienste, die abhängig voneinander zu starten sind
• weniger RAM-Bedarf, das gesamte System läuft schneller

Die möglichen Nachteile nehme ich gerne in Kauf

• macht eine Web-Applikation Probleme, sind alle darin laufenden Produkte betroffen
• leichte Performance-Einbußen, weil nur eine JVM verwendet wird