Upgrade Management Tool

Mit dem Upgrade Management Tool (UMT) können Sie BO-Objekte - Benutzer, Gruppen und BO-Inhaltsobjekte - von der vorherigen Version der BI-Plattform in die aktualisierte Version importieren. Wenn Sie Ihre BO-Umgebung aktualisieren, haben Sie zwei Möglichkeiten, ein Upgrade durchzuführen.

  • Complete Upgrade - Sie können alle Objekte von der Quelle zum Ziel verschieben.

  • Incremental Upgrade - Sie können Objekte auch stapelweise verschieben.

UMT konfigurieren

Um UMT für ein Upgrade zu verwenden, müssen Sie UMT für eine bessere Leistung konfigurieren. Führen Sie den Befehl „Java –Xmx“ aus, während Sie das Upgrade Management Tool starten, um es mit Java Heap auszuführen. → Klicken Sie mit der rechten Maustaste auf UMT und gehen Sie zu Eigenschaften, wie unten erläutert.

Sie müssen den Pfad "Ziel" in den Editor kopieren und "Xmx" durch die für Ihr System konfigurierte Heap-Menge ersetzen, wie unten gezeigt.

Sie können Ihr Timeout auch im Upgrade Management Tool konfigurieren. Stellen Sie den folgenden Parameter ein -

Um das CORBA-Zeitlimit für UMT festzulegen, müssen Sie zur Eigenschaftendatei navigieren und den folgenden Eintrag hinzufügen. Die Eigenschaftendatei befindet sich in Ihrem BO-Installationsverzeichnis unter folgendem Pfad: "SAP BusinessObjects Enterprise XI 4.0 \ Java \ Apps \ UpgradeManagementTool \ Jars".

<entry key="umt.systemVar.backendCommunicationTimeoutInMS">630000</entry>

Es wird empfohlen, den Wert unter 630000 zu halten. Andernfalls kann es zu Fehlern bei der CMS-Anmeldung kommen.

Einrichten von Quelle und Ziel in UMT

Sie können Ihr Quell- und Ziel-CMS-System in UMT definieren und die Konnektivität überprüfen. Führen Sie das Upgrade Management Tool über alle Programme aus → Wählen Sie Inkrementelles Upgrade → Weiter. Der folgende Bildschirm erklärt dasselbe.

Geben Sie Ihren Quell- und Ziel-CMS-Namen ein und geben Sie die Anmeldeinformationen ein. Stellen Sie das Upgrade-Szenario aus der Dropdown-Liste bereit, wie unten gezeigt -

In UMT stehen verschiedene Upgrade-Szenarien zur Verfügung, z.

  • Live to Live - Dazu müssen sowohl das Quell- als auch das Zielsystem aktiv sein.

  • BIAR to Live - Mit dieser Option werden die Objekte aus dem BIAR-Dateiformat in das Live-Zielsystem importiert.

  • Live to BIAR - Mit dieser Option werden die Objekte im BIAR-Format aus dem Live-System exportiert.

Diese Szenarien können basierend auf dem Status Ihres Quell- und Zielsystems verwendet werden. Beide Systeme sind aktiv. Sie können ein Live-to-Live-Upgrade durchführen, ohne Objekte exportieren / importieren zu müssen.

In BO 4.2 hat UMT einige neue Funktionen wie folgt:

  • Sie können die Protokollebene in der Dropdown-Liste als niedrig, mittel und hoch definieren.

  • Wenn Sie die Protokollebene "Hoch" auswählen, werden alle Fehler, Warnungen und Fehler während des Vorgangs erfasst.

  • Sie können auch temporären Speicherplatz für jedes erforderliche Verzeichnis definieren und das UMT-Tool nach Änderungen neu starten.

  • Der temporäre Speicherplatz speichert normalerweise alle Einträge der Derby-Datenbank und nach Abschluss des Upgrades. Diese Dateien können entfernt werden.

Wenn Sie ein BO-Upgrade von BOXI 3.x auf BI 4.1 durchführen, können Sie mehrere Szenarien haben, um verschiedene Objekte, Inhalte, Benutzer usw. und den in jedem Szenario definierten Bereich zu migrieren. Gemäß der SAP-Empfehlung können die folgenden Iterationen verwendet werden:

Wiederholung Umfang

Wiederholung

# 1

In dieser Iteration wurden folgende Objekte mit ihren Abhängigkeiten migriert:

  • Benutzergruppen
  • Zugriffsebenen
  • Applications

Der gleiche Ansatz kann für alle Benutzergruppen und alle Zugriffsebenen in einer einzigen Iteration verwendet werden. Dies kann jedoch aufgrund der Anzahl der Objekte usw. zeitaufwändig sein. Daher wird empfohlen, die Anzahl der Iterationen basierend auf Ihren Repository-Objekten zu bestimmen.

Wiederholung

# 2

Die folgenden Objekte wurden für die Aktualisierung mit Abhängigkeiten berücksichtigt. Sie können diese Objekte für die Migration im Objektauswahlbildschirm auswählen -

  • Ordner und Objekte
  • Repository-Objekte
  • Universes

Für dieses Musterbuch haben wir die Migration in einer einzigen Iteration durchgeführt. Abhängig von der Anzahl der Iterationen basierend auf Ihren Repository-Objekten.

Wiederholung

#3

Im ersten Bildschirm "Filter auswählen" wurde der Zeitfilter entsprechend den Anforderungen eingestellt. In unserem Musterbuch wählen wir das Startdatum als 02/01/2016 und das Enddatum als 02/05/2016. Es werden also nur die folgenden Objekte aufgelistet und migriert:

  • Universum - Universum, das zwischen dem Startdatum und dem im Auswahlfilter angegebenen Datum geändert wurde
  • Web Intelligence-Berichte - Berichte, die zwischen dem im Auswahlfilter angegebenen Start- und Enddatum geändert wurden.

Wiederholung

# 4

Die folgenden Objekte wurden für ein Upgrade mit Abhängigkeiten berücksichtigt. Dies sind die Objekte, die für die Migration im Bildschirm Objektauswahl ausgewählt wurden.

  • Applications
  • Calendars
  • Unternehmenskategorien
  • Remoteverbindungen und Replikationsjobs
  • Repository-Objekte
  • Universes

In diesen Iterationen wurden alle Inhaltsabhängigkeiten (in Bezug auf alle Dokumente) so festgelegt, dass sie zuerst aktualisiert werden. Dies kann jedoch auch schrittweise erfolgen.

Beachten Sie, dass bereits migrierte Objekte nicht im Objektauswahlbildschirm aufgeführt werden. Auch in dieser Iteration verwenden wir die Funktion "Objekte, die bereits aktualisiert wurden" aus dem Auswahlfilterbildschirm ausblenden.

Wiederholung

# 5

Die folgenden Objekte wurden für ein Upgrade mit Abhängigkeiten ausgewählt:

  • Öffentliche Ordner und ihre Objekte, mit Ausnahme der Objekte, die in Iteration 2 aktualisiert wurden
  • QaaWS-Objekte
  • Events
  • Mobile Abonnements
  • Objektabhängigkeiten werden in UMT aufgelistet, aber später nicht mehr ausgewählt

Für dieses Musterbuch haben wir die Migration in einer einzigen Iteration durchgeführt. Abhängig von der Anzahl der Objekte kann diese Iteration jedoch zeitaufwändig sein. Daher wird empfohlen, die Anzahl der Iterationen basierend auf der Größe Ihres Repositorys und der Anzahl der Objekte zu bestimmen.