MobileFirst Server in einem Anwendungsserver installieren

improve this page | report issue

Übersicht

Die Installation der Komponenten können Sie mit Ant-Tasks, dem Server Configuration Tool oder manuell ausführen. Informieren Sie sich über die Voraussetzungen und die Einzelheiten des Installationsprozesses, damit Sie die Komponenten erfolgreich im Anwendungsserver installieren können.

Bevor Sie die Komponenten im Anwendungsserver installieren, müssen Sie sicherstellen, dass die Datenbanken und Tabellen für die Komponenten erstellt und einsatzbereit sind. Weitere Informationen finden Sie unter Datenbanken einrichten.

Die Servertopologie für die Installation der Komponenten muss ebenfalls definiert werden (siehe Topologien und Netzabläufe).

Fahren Sie mit folgenden Abschnitten fort:

Voraussetzungen für den Anwendungsserver

Wählen Sie aus den folgenden Abschnitten den für Ihren Anwendungsserver aus und informieren Sie sich über die Voraussetzungen, die erfüllt sein müssen, bevor Sie die MobileFirst-Server-Komponenten installieren.

Voraussetzungen für Apache Tomcat

MobileFirst Server stellt gewisse Anforderungen an die Konfiguration von Apache Tomcat, die in den folgenden Abschnitten ausführlich erläutert werden.
Stellen Sie sicher, dass die folgenden Bedingungen erfüllt sind:

  • Sie verwenden eine unterstützte Version von Apache Tomcat (siehe Systemvoraussetzungen).
  • Apache Tomcat wird mit JRE 7.0 oder einer aktuelleren Version ausgeführt.
  • Die JMX-Konfiguration lässt die Kommunikation zwischen dem Verwaltungsservice und der Laufzeitkomponente zu. Für die Kommunikation wird RMI verwendet. Lesen Sie dazu weiter unten den Abschnitt JMX-Verbindung für Apache Tomcat konfigurieren.

Sie müssen eine sichere JMX-Verbindung für den Apache-Tomcat-Anwendungsserver konfigurieren.

Mit dem Server Configuration Tool und den Ant-Tasks können Sie eine sichere JMX-Standardverbindung konfigurieren. Die Konfiguration umfasst die Definition eines fernen JMX-Ports und die Definition von Authentifizierungseigenschaften. Das Tool und die Tasks ändern die Dateien Tomcat-Installationsverzeichnis/bin/setenv.bat und Tomcat-Installationsverzeichnis/bin/setenv.sh und fügen CATALINA_OPTS die folgenden Optionen hinzu:

-Djava.rmi.server.hostname=localhost
-Dcom.sun.management.jmxremote.port=8686
-Dcom.sun.management.jmxremote.authenticate=false
-Dcom.sun.management.jmxremote.ssl=false

Hinweis: 8686 ist ein Standardwert. Der Wert für diesen Port kann geändert werden, wenn der Port auf dem Computer nicht verfügbar ist.

  • Die Datei setenv.bat wird verwendet, wenn Sie für den Start von Apache Tomcat Tomcat-Installationsverzeichnis/bin/startup.bat oder Tomcat-Installationsverzeichnis/bin/catalina.bat verwenden.
  • Die Datei setenv.sh wird verwendet, wenn Sie für den Start von Apache Tomcat Tomcat-Installationsverzeichnis/bin/startup.sh oder Tomcat-Installationsverzeichnis/bin/catalina.sh verwenden.

Wenn Sie Apache Tomcat mit einem anderen Befehl starten, wird diese Datei möglicherweise nicht verwendet. Wenn Sie den Windows Service Installer von Apache Tomcat installiert haben, wird setenv.bat nicht vom Servicestarter verwendet.

Wichtiger Hinweis: Diest Konfiguration ist standardmäßig nicht sicher. Zum Sichern der Konfiguration müssen Sie die Schritte 2 und 3 der folgenden Prozedur manuell ausführen.

Apache Tomcat manuell konfigurieren:

  1. Für eine einfache Konfiguration fügen Sie CATALINA_OPTS die folgenden Optionen hinzu: 
    -Djava.rmi.server.hostname=localhost
-Dcom.sun.management.jmxremote.port=8686
-Dcom.sun.management.jmxremote.authenticate=false
-Dcom.sun.management.jmxremote.ssl=false
  2. Informationen zum Aktivieren der Authentifizierung finden Sie in der Benutzerdokumentation zu Apache Tomcat (SSL Support - BIO and NIO und SSL Configuration HOW-TO).
  3. Fügen Sie für eine JMX-Konfiguration mit aktiviertem SSL die folgenden Optionen hinzu: 
    -Dcom.sun.management.jmxremote=true
-Dcom.sun.management.jmxremote.port=8686
-Dcom.sun.management.jmxremote.ssl=true
-Dcom.sun.management.jmxremote.authenticate=false
-Djava.rmi.server.hostname=localhost  
-Djavax.net.ssl.trustStore=<Keystore-Position>
-Djavax.net.ssl.trustStorePassword=<Keystore-Kennwort>
-Djavax.net.ssl.trustStoreType=<Keystore-Typ>
-Djavax.net.ssl.keyStore=<Keystore-Position>
-Djavax.net.ssl.keyStorePassword=<Keystore-Kennwort>
-Djavax.net.ssl.keyStoreType=<Keystore-Typ>
    Hinweis: Der Port 8686 kann geändert werden.

  4. Wenn die Tomcat-Instanz hinter einer Firewall ausgeführt wird, muss der JMX-Remote-Lifecycle-Listener konfiguriert werden. Suchen Sie in der Dokumentation zu Apache Tomcat nach JMX Remote Lifecycle Listener.

    Außerdem müssen dem Abschnitt "Context" in der Datei server.xml für die Anwendung "Verwaltungsservices" wie im folgenden Beispiel gezeigt die folgenden Umgebungseigenschaften hinzugefügt werden:

    <Context docBase="mfpadmin" path="/mfpadmin ">
    <Environment name="mfp.admin.rmi.registryPort" value="registryPort" type="java.lang.String" override="false"/>
    <Environment name="mfp.admin.rmi.serverPort" value="serverPort" type="java.lang.String" override="false"/>
</Context>
    Erläuterungen zum vorherigen Beispiel:
    • Für registryPort muss der Wert angegeben werden, den das Attribut rmiRegistryPortPlatform des JMX-Remote-Lifecycle-Listeners hat.
    • Für serverPort muss der Wert angegeben werden, den das Attribut rmiServerPortPlatform des JMX-Remote-Lifecycle-Listeners hat.
  5. Wenn Sie Apache Tomcat mit dem Apache Tomcat Windows Service Installer installiert haben, anstatt die Optionen zu CATALINA_OPTS hinzuzufügen, führen Sie Tomcat-Installationsverzeichnis/bin/Tomcat7w.exe aus und fügen Sie die Optionen auf der Registerkarte Java des Fensters Properties hinzu. Eigenschaften von Apache Tomcat 7

Voraussetzungen für WebSphere Application Server Liberty

IBM Mobile Foundation stellt gewisse Anforderungen an die Konfiguration des Liberty-Servers, die in den folgenden Abschnitten ausführlich erläutert werden.

Stellen Sie sicher, dass die folgenden Bedingungen erfüllt sind:

  • Sie verwenden eine unterstützte Version von Liberty (siehe Systemvoraussetzungen).
  • Liberty wird mit JRE 7.0 oder einer aktuelleren Version ausgeführt. JRE 6.0 wird nicht unterstützt.
  • Einige Liberty-Versionen unterstützen die Features von Java EE 6 und von Java EE 7. Das Liberty-Feature jdbc-4.0 ist beispielsweise Teil von Java EE 6, wohingegen das Lieberty-Feature jdbc-4.1 Teil von Java EE 7 ist. MobileFirst Server Version 8.0.0 kann mit Features von Java EE 6 oder Java EE 7 installiert werden. Wenn Sie jedoch in demselben Liberty-Server eine ältere Version von MobileFirst Server ausführen möchten, müssen Sie die Features von Java EE 6 verwenden. Bis Version 7.1.0 bietet MobileFirst Server keine Unterstützung für Features von Java EE 7.
  • JMX muss konfiguriert sein (siehe unten Abschnitt JMX-Verbindung für WebSphere Application Server Liberty Profile konfigurieren).
  • Bei einer Installation in einer Produktionsumgebung auf Windows-, Linux- oder UNIX-Systemen können Sie den Liberty-Server als Dienst starten. In dem Fall geschieht Folgendes: Die MobileFirst-Server-Komponenten werden beim Computerstart automatisch gestartet. Der Prozess, der den Liberty-Server ausführt, wird nicht gestoppt, wenn sich der Benutzer, der den Prozess gestartet hat, abmeldet.
  • MobileFirst Server Version 8.0.0 kann nicht in einem Liberty-Server implementiert werden, der die implementierten MobileFirst-Server-Komponenten der Vorgängerversion enthält.
  • Bei einer Installation in einer Umgebung mit Liberty-Verbund müssen der Controler und die Cluster-Member des Liberty-Verbunds konfiguriert werden (siehe Configuring a Liberty collective).

MobileFirst Server setzt die Konfiguration einer sicheren JMX-Verbindung voraus.

  • Mit dem Server Configuration Tool und den Ant-Tasks können Sie eine sichere JMX-Standardverbindung konfigurieren. Die Konfiguration umfasst die Generierung eines selbst signierten SSL-Zertifikats mit einer Gültigkeit von 365 Tagen. Diese Konfiguration ist nicht für den Produktionseinsatz vorgesehen.
  • Zum Konfigurieren der sicheren JMX-Verbindung für den Produktionseinsatz folgen Sie den Anweisungen unter Sichere JMX-Verbindung zum Liberty-Profil konfigurieren.
  • Das Feature "rest-connector" ist für WebSphere Application Server, Liberty Core und weitere Editionen von Liberty verfügbar, aber es ist auch möglich, einen Liberty-Server mit einem Teil der verfügbaren Features zu packen. Geben Sie den folgenden Befehl ein, um zu prüfen, ob das Feature "rest-connector" in Ihrer Installation von Liberty verfügbar ist: 
                        
Liberty-Installationsverzeichnis/bin/productInfo featureInfo
    Hinweis: Vergewissern Sie sich, dass die Ausgabe dieses Befehls restConnector-1.0 enthält.

Voraussetzungen für WebSphere Application Server und WebSphere Application Server Network Deployment

MobileFirst Server stellt gewisse Anforderungen an die Konfiguration von WebSphere Application Server und WebSphere Application Server Network Deployment, die in den folgenden Abschnitten ausführlich erläutert werden.
Stellen Sie sicher, dass die folgenden Bedingungen erfüllt sind:

  • Sie verwenden eine unterstützte Version von WebSphere Application Server (siehe Systemvoraussetzungen).
  • Der Anwendungsserver wird mit JRE 7.0 ausgeführt. WebSphere Application Server verwendet standardmäßig das SDK von Java 6.0. Wie Sie zum SDK von Java 7.0 wechseln können, erfahren Sie unter Switching to Java 7.0 SDK in WebSphere Application Server.
  • Die Verwaltungssicherheit ist aktiviert. Die MobileFirst Operations Console, der MobileFirst-Server Verwaltungsservice und der MobileFirst-Server-Konfigurationsservice sind mit Sicherheitsrollen geschützt. Weitere Informationen finden Sie im Artikel Sicherheit aktivieren.
  • Die JMX-Konfiguration lässt die Kommunikation zwischen dem Verwaltungsservice und der Laufzeitkomponente zu. Die Kommunikation verwendet SOAP. Für WebSphere Application Server Network Deployment kann RMI verwendet werden. Weitere Informationen finden Sie unten im Abschnitt JMX-Verbindung für WebSphere Application Server und WebSphere Application Server Network Deployment konfigurieren.

MobileFirst Server setzt die Konfiguration einer sicheren JMX-Verbindung voraus.

  • Die MobileFirst Server muss für die Durchführung von JMX-Operationen auf den SOAP-Port oder RMI-Port zugreifen. Standardmäßig ist der SOAP-Port in einer WebSphere-Application-Server-Instanz aktiv. Die MobileFirst Server verwendet standardmäßig den SOAP-Port. Wenn der SOAP- und der RMI-Port inaktiviert sind, kann die MobileFirst Server nicht ausgeführt werden.
  • RMI wird nur in Verbindung mit WebSphere Application Server Network Deployment unterstützt. Von einem eigenständigen Profil oder einer Server-Farm mit WebSphere Application Server wird RMI nicht unterstützt.
  • Sie müssen die Verwaltungssicherheit und die Anwendungssicherheit aktivieren.

Dateisystemvoraussetzungen

Wenn Sie die MobileFirst Server in einem Anwendungsserver installieren möchten, müssen die MobileFirst-Installationstools von einem Benutzer mit bestimmten Dateisystemzugriffsrechten ausgeführt werden.
Zu den Installationstools gehören folgende:

  • IBM Installation Manager
  • Server Configuration Tool
  • Ant-Tasks für die Implementierung von MobileFirst Server

Für WebSphere Application Server Liberty Profile müssen Sie berechtigt sein, die folgenden Aktionen auszuführen:

  • Dateien im Liberty-Installationsverzeichnis lesen
  • Dateien im Konfigurationsverzeichnis des Liberty-Servers (in der Regel usr/servers/Servername) erstellen, Sicherungskopien erstellen und die Dateien server.xml und jvm.options modifizieren
  • Dateien und Verzeichnisse im Liberty-Verzeichnis für gemeinsam genutzte Ressourcen (in der Regel usr/shared) erstellen
  • Dateien im Liberty-Serververzeichnis apps (in der Regel usr/servers/Servername/apps) erstellen

Für WebSphere Application Server Full Profile und WebSphere Application Server Network Deployment müssen Sie berechtigt sein, die folgenden Aktionen auszuführen:

  • Dateien im Installationsverzeichnis von WebSphere Application Server lesen
  • Konfigurationsdatei des ausgewählten WebSphere Application Server Full Profile oder des Deployment-Manager-Profils lesen
  • Befehl wsadmin ausführen
  • Dateien im Konfigurationsverzeichnis profiles erstellen (Die Installationstools stellen Ressourcen in dieses Verzeichnis, z. B. gemeinsame Bibliotheken oder JDBC-Treiber.)

Für Apache Tomcat müssen Sie berechtigt sein, die folgenden Aktionen auszuführen:

  • Konfigurationsverzeichnis lesen
  • Sicherungsdateien erstellen und Dateien im Konfigurationsverzeichnis modifizieren, z. B. server.xml und tomcat-users.xml
  • Sicherungsdateien erstellen und Dateien im Verzeichnis bin modifizieren, z. B. setenv.bat
  • Dateien im Verzeichnis lib erstellen
  • Dateien im Verzeichnis webapps erstellen

Der Benutzer, der den Anwendungsserver ausführt, muss bei allen genannten Anwendungsservern berechtigt sein, die Dateien zu lesen, die von dem Benutzer, der die MobileFirst-Installationstools ausgeführt hat, erstellt wurden.

Installation mit dem Server Configuration Tool

Sie können die MobileFirst-Server-Komponenten mit dem Server Configuration Tool in Ihrem Anwendungsserver installieren.

Das Server Configuration Tool kann die Datenbank einrichten und die Komponenten in einem Anwendungsserver installieren. Dieses Tool ist für Einzelbenutzer bestimmt. Die Konfigurationsdateien werden auf Platte gespeichert. Das Verzeichnis, in dem sie gespeichert werden, kann über die Menüoptionen File → Preferences modifiziert werden. Die Dateien dürfen nur von jeweils einer Instanz des Server Configuration Tool verwendet werden. Das Tool kann den gleichzeitigen Zugriff auf dieselbe Datei nicht handhaben. Wenn Sie mehrere Instanzen des Tools haben, die auf dieselbe Datei zugreifen, könnten die Daten verlorengehen. Weitere Informationen zum Erstellen und Einrichten der Datenbanken mit dem Tool finden Sie unter Datenbanktabellen mit dem Server Configuration Tool erstellen. Bereits vorhandene Datenbanken werden vom Tool erkannt. Das Tool überprüft dafür das Vorhandensein und den Inhalt einiger Testtabellen, ohne diese Datenbanktabellen zu modifizieren.

Unterstützte Betriebssysteme

Sie können das Server Configuration Tool verwenden, wenn Sie eines der folgenden Betriebssysteme verwenden:

  • Windows x86 oder x86-64
  • macOS x86-64
  • Linux x86 oder Linux x86-64

Das Tool ist für andere Betriebssysteme nicht verfügbar. Sie können Ant-Tasks für die Installation der MobileFirst-Server-Komponenten verwenden (siehe Installation mit Ant Tasks).

Das Startprogramm für das SCT (Server Configuration Tool) für Mac OS setzt voraus, dass die traditionelle Java SE 6 Runtime installiert ist. Beim Starten des Starprogramms für das SCT unter Mac OS könnte folgende Nachricht angezeigt werden:

Nachricht des SCT unter Mac OS

Sie können die folgenden Ausweichmaßnahmen ergreifen, um diese Nachricht zu umgehen, und für die Ausführung des SCT die ausführbare Datei nutzen. In dem Fall müssen Sie nicht die SE 6 Runtime installieren.

Ausweichmaßnahme 1

  • Klicken Sie mit der rechten Maustaste auf das Startprogramm ServerConfigurationTool.

  • Wählen Sie Show Package Contents aus.

    Paktinhalt anzeigen

  • Klicken Sie auf Contents > MacOS.
  • Klicken Sie auf die ausführbare Datei für ServerConfigurationTool, um das SCT zu starten.

Ausweichmaßnahme 2

Sie können auf Ihrem Computer problemlos sowohl Java SE 8 als auch Java SE 6 installiert haben.

  • Wenn bei Verwendung des SCT-Startprogramms das Popup-Fenster erscheint, klicken Sie auf More Info.
  • Sie werden zur Apple-Unterstützungssite weitergeleitet. Dort erfahren Sie, wie Sie die Java SE 6 Runtime erhalten können.
  • Folgen Sie den Anweisungen, installieren Sie die Java SE 6 Runtime und starten Sie dann das SCT-Startprogramm.

Unterstützte Topologien

Das Server Configuration Tool installiert die MobileFirst-Server-Komponenten mit folgenden Topologien:

  • Alle Komponenten (MobileFirst Operations Console, MobileFirst-Server-Verwaltungsservice und -Liveaktualisierungsservice sowie die MobileFirst-Laufzeit) werden in einem Anwendungsserver installiert. Bei einer Installation in einem Cluster mit WebSphere Application Server Network Deployment können Sie jedoch für den Verwaltungs- und Liveaktualisierungsservice und für die Laufzeit einen anderen Cluster angeben. Bei einem Liberty-Verbund werden die MobileFirst Operations Console, der Verwaltungsservice und der Liveaktualisierungsservice in einem Verbundcontroller und die Laufzeit in einem Verbundmember installiert.
  • Wenn der MobileFirst-Server-Push-Service installiert werden soll, muss er auch in demselben Server installiert werden. Bei einer Installation in einem Cluster mit WebSphere Application Server Network Deployment kann für den Push-Service jedoch ein anderer Cluster angegeben werden. Bei einem Liberty-Verbund wird der Push-Service in einem Liberty-Member installiert. Dabei kann es sich um das Member handeln, in dem auch die Laufzeit installiert ist.
  • Alle Komponenten verwenden dasselbe Datenbanksystem und denselben Benutzer. Bei Verwendung von DB2 verwenden alle Komponenten zudem dasselbe Schema.
  • Das Server Configuration Tool installiert die Komponenten für einen Einzelserver, außer bei einer asymmetrischen Implementierung in einem Liberty-Verbund und in WebSphere Application Server Network Deployment. Wenn die Installation auf mehreren Servern erfolgen soll, muss nach Ausführung des Tools eine Farm konfiguriert werden. In WebSphere Application Server Network Deployment ist keine Server-Farmkonfiguration erforderlich.

Für andere Topologien oder Datenbankeinstellungen können Sie die Komponenten mit Ant-Tasks oder manuell installieren.

Server Configuration Tool ausführen

Bevor Sie das Server Configuration Tool ausführen, müssen die folgenden Bedingungen erfüllt sein:

  1. Starten Sie das Server Configuration Tool.
    • Nutzen Sie unter Linux den Direktaufruf Applications → IBM MobileFirst Platform Server → Server Configuration Tool.
    • Klicken Sie unter Windows auf Start → Programme → IBM MobileFirst Platform Server → Server Configuration Tool.
    • Öffnen Sie unter macOS eine Shell-Konsole. Navigieren Sie zu MFP-Server-Installationsverzeichnis/shortcuts und geben Sie ./configuration-tool.sh ein.
    • MFP-Server-Installationsverzeichnis ist das Verzeichnis, in dem Sie MobileFirst Server installiert haben.
  2. Wählen Sie File → New Configuration aus, um eine MobileFirst-Server-Konfiguration zu erstellen.
    • Geben Sie im Fenster Configuration Details das Kontextstammverzeichnis des Verwaltungsservice und der Laufzeitkomponente ein. Außerdem sollten Sie eine Umgebungs-ID eingeben. Eine Umgebungs-ID wird in professionellen Anwendungsfällen verwendet, z. B., wenn in einem Anwendungsserver oder in einer WebSphere-Application-Server-Zelle mehrere Instanzen von MobileFirst Server installiert werden.
    • Entscheiden Sie im Fenster Console Settings, ob die MobileFirst Operations Console installiert werden soll. Wenn die Konsole nicht installiert ist, müssen Sie für die Interaktion mit dem MobileFirst-Server-Verwaltungsservice Befehlszeilentools (mfpdev oder mfpadm) oder die REST-API verwenden.
    • Wählen Sie im Fenster Database Selection das zu verwendende Datenbankmanagementsystem aus. Alle Komponenten verwenden denselben Datenbanktyp und dieselbe Datenbankinstanz. Weitere Informationen zu den Fenstern für Datenbankangaben finden Sie unter Datenbanktabellen mit dem Server Configuration Tool erstellen.
    • Wählen Sie im Fenster Application Server Selection den Anwendungsservertyp für die Implementierung von MobileFirst Server aus.
  3. Wählen Sie im Fenster Application Server Settings den Anwendungsserver aus. Gehen Sie dann wie folgt vor:
    • Installation in WebSphere Application Server Liberty:
      • Geben Sie das Liberty-Installationsverzeichnis und den Namen des Servers für die Installation von MobileFirst Server ein.
      • Sie können einen Standardbenutzer für die Anmeldung bei der Konsole erstellen. Dieser Benutzer wird in der Liberty-Basisregistry erstellt. Für eine Produktionsinstallation sollten Sie die Option Create a default user abwählen und den Benutzerzugriff nach der Installation konfigurieren. Weitere Informationen finden Sie unter Benutzerauthentifizierung für die MobileFirst-Server-Verwaltung konfigurieren.
      • Wählen Sie den Implementierungstyp aus: Standalone deployment (Standardeinstellung) oder Server farm deployment oder Liberty collective deployment.
      Wenn Sie die Option "Liberty collective deployment" ausgewählt haben, gehen Sie wie folgt vor:
      • Machen Sie folgende Angaben:
        • Liberty-Verbundserver, auf dem die MobileFirst Operations Console und der Liveaktualisierungsservice installiert sind. Der Server muss ein Liberty-Verbundcontroller sein.
        • Liberty-Verbundserver, auf dem die Laufzeit installiert ist. Der Server muss ein Liberty-Verbundmember sein.
        • Liberty-Verbundserver, auf dem der Push-Service installiert ist. Der Server muss ein Liberty-Verbundmember sein.
      • Geben Sie die Server-ID des Members ein. Jedes Member des Verbunds muss eine andere Kennung haben.
      • Geben Sie den Clusternamen der Verbundmember ein.
      • Geben Sie den Hostnamen und die HTTPS-Portnummer des Controllers ein. Die Werte müssen mit denen übereinstimmen, die im Element variable in der Datei server.xml des Liberty-Verbundcontrollers definiert sind.
      • Geben Sie den Benutzernamen und das Kennwort des Controlleradministrators ein.
    • Installation in WebSphere Application Server oder WebSphere Application Server Network Deployment:
      • Geben Sie das Installationsverzeichnis für WebSphere Application Server ein.
      • Wählen Sie das WebSphere-Application-Server-Profil aus, in dem Sie MobileFirst Server installieren möchten. Wählen Sie bei einer Installation in WebSphere Application Server Network Deployment das Profil des Deployment Manager aus. Im Deployment-Manager-Profil können Sie einen Geltungsbereich auswählen (Server oder Cluster). Bei Auswahl von Cluster müssen Sie Folgendes angeben:
        • Liberty-Verbundserver, auf dem die Laufzeit installiert ist.
        • Liberty-Verbundserver, auf dem die MobileFirst Operations Console und der Liveaktualisierungsservice installiert sind.
        • Liberty-Verbundserver, auf dem der Push-Service installiert ist.
      • Geben Sie eine Administratoranmelde-ID und das zugehörige Kennwort ein. Der Benutzer mit Administratorberechtigung muss eine Administratorrolle haben.
      • Wenn Sie die Option Declare the WebSphere Administrator as an administrator user in MobileFirst Operations Console auswählen, wird der für die Installation von MobileFirst Server verwendete Benutzer der Verwaltungssicherheitsrolle der Konsole zugeordnet, die sich mit Administratorrechten bei der Konsole anmelden kann. Dieser Benutzer wird auch der Sicherheitsrolle des Liveaktualisierungsservice zugeordnet. Der Benutzername und das Kennwort werden als JNDI-Eigenschaften (mfp.config.service.user und mfp.config.service.password) des Verwaltungsservice definiert.
      • Wenn Sie die Option Declare the WebSphere Administrator as an administrator user in MobileFirst Operations Console nicht auswählen, müssen Sie vor der Verwendung von MobileFirst Server die folgenden Schritte ausführen:
        • Ermöglichen Sie die Kommunikation zwischen dem Verwaltungsservice und dem Liveaktualisierungsservice.
          • Ordnen Sie einen Benutzer der Sicherheitsrolle configadmin des Liveaktualisierungsservice zu.
          • Geben Sie die Anmelde-ID und das Kennwort dieses Benutzers mit den JNDI-Eigenschaften (mfp.config.service.user und mfp.config.service.password) des Verwaltungsservice an.
          • Ordnen Sie den Sicherheitsrollen des Verwaltungsservice und der MobileFirst Operations Console Benutzer zu (siehe Benutzerauthentifizierung für die MobileFirst-Server-Verwaltung konfigurieren).
    • Installation in Apache Tomcat:
      • Geben Sie das Installationsverzeichnis von Apache Tomcat ein.
      • Geben Sie den für die JMX-Kommunikation mit RMI verwendeten Port ein. Der Standardport ist 8686. Das Server Configuration Tool modifiziert zum Öffnen dieses Ports die Datei Tomcat-Installationsverzeichnis/bin/setenv.bat oder Tomcat-Installationsverzeichnis/bin/setenv.sh. Wenn Sie den Port manuell öffnen wollen oder bereits in setenv.bat oder setenv.sh über Code zum Öffnen des Ports verfügen, verwenden Sie das Tool nicht. Verwenden Sie stattdessen Ant-Tasks für die Installation. Bei der Installation mit Ant-Tasks gibt es eine Option für das manuelle Öffnen des RMI-Ports.
      • Erstellen Sie einen Standardbenutzer für die Anmeldung bei der Konsole. Dieser Benutzer wird auch in der Konfigurationsdatei tomcat-users.xml erstellt. Für eine Produktionsinstallation sollten Sie die Option Create a default user abwählen und den Benutzerzugriff nach der Installation konfigurieren. Weitere Informationen finden Sie unter Benutzerauthentifizierung für die MobileFirst-Server-Verwaltung konfigurieren.
  4. Wählen Sie im Fenster Push Service Settings die Option Install the Push service aus, wenn der Push-Service im Anwendungsserver installiert werden soll. Das Kontextstammverzeichnis ist imfpush. Definieren Sie die folgenden Parameter, um die Kommunikation zwischen dem Push-Service und dem Verwaltungsservice zu ermöglichen:
    • Geben Sie die URL des Push-Service und die URL der Laufzeit ein. Diese URL kann für eine Installation in Liberty, Apache Tomcat oder einem eigenständigen WebSphere Application Server automatisch berechnet werden. Dafür wird die URL der Komponente (Laufzeit oder Push-Service) auf dem lokalen Server verwendet. Wenn Sie die Installation in WebSphere Application Server Network Deployment ausführen oder die Kommunikation über einen Web-Proxy oder Load Balancer erfolgt, müssen Sie die URL manuell eingeben.
    • Geben Sie die ID und den geheimen Schlüssel der vertraulichen Clients für die OAuth-Kommunikation zwischen den Services ein. Andernfalls generiert das Tool Standardwerte und zufällige Kennwörter.
  5. Wählen Sie im Fenster Analytics Settings die Option Enable the connection to the Analytics server aus, wenn MobileFirst Analytics installiert wird. Geben Sie die folgenden Verbindungseinstellungen ein:
    • URL der Analysekonsole
    • URL des Analytics-Servers (Analytics-Datenservice)
    • Anmelde-ID und Kennwort des Benutzers, der Daten auf dem Analytics-Server veröffentlichen darf
    Das Tool konfiguriert die Laufzeit und den Push-Service für das Senden von Daten an den Analytics-Server.
  6. Klicken Sie auf Deploy, um mit der Installation fortzufahren.

Nach erfolgreicher Installation in Apache Tomcat oder Liberty Profile müssen Sie den Anwendungsserver neu starten.

Wenn Apache Tomcat als Dienst gestartet wird, kann die Datei setenv.bat oder setenv.sh mit der Anweisung zum Öffnen von RMI möglicherweise nicht gelesen werden. In dem Fall wird MobileFirst Server unter Umständen nicht ordnungsgemäß funktionieren. Wie die erforderlichen Variablen definiert werden, erfahren Sie unter JMX-Verbindung für Apache Tomcat konfigurieren.

In WebSphere Application Server Network Deployment werden die Anwendungen installiert, aber nicht gestartet. Sie müssen sie manuell starten. Diesen Schritt können Sie in der Administrationskonsole von WebSphere Application Server ausführen.

Speichern Sie die Konfigurationsdatei im Server Configuration Tool. Möglicherweise benötigen Sie sie später für die Installation vorläufiger Fixes. Die Menüoptionen für die Anwendung eines vorläufigen Fix sind Configurations > Replace the deployed WAR files.

Fixpack mit dem Server Configuration Tool anwenden

Wenn MobileFirst Server mit dem Server Configuration Tool installiert wurde und Sie die Konfigurationsdatei aufbewahrt haben, können Sie beim Anwenden eines Fixpacks oder eines vorläufigen Fix die Konfigurationsdatei wiederverwenden.

  1. Starten Sie das Server Configuration Tool.
    • Nutzen Sie unter Linux den Direktaufruf Applications → IBM MobileFirst Platform Server → Server Configuration Tool.
    • Klicken Sie unter Windows auf Start → Programme → IBM MobileFirst Platform Server → Server Configuration Tool.
    • Öffnen Sie unter macOS eine Shell-Konsole. Navigieren Sie zu MFP-Server-Installationsverzeichnis/shortcuts und geben Sie ./configuration-tool.sh ein.
    • MFP-Server-Installationsverzeichnis ist das Verzeichnis, in dem Sie MobileFirst Server installiert haben.
  2. Klicken Sie auf Configurations → Replace the deployed WAR files und wählen Sie eine vorhandene Konfiguration aus, um das Fixpack oder einen vorläufigen Fix anzuwenden.

Installation mit Ant-Tasks

Sie können die MobileFirst-Server-Komponenten mit Ant-Tasks in Ihrem Anwendungsserver installieren.

Die Beispielkonfigurationsdateien für die Installation von MobileFirst Server finden Sie im Verzeichnis MFP-Installationsverzeichnis/MobileFirstServer/configuration-samples.

Sie können auch eine Konfiguration mit dem Server Configuration Tool erstellen und File → Export Configuration as Ant Files… auswählen, um die Ant-Dateien zu exportieren. Für die Ant-Beispieldateien gelten dieselben Einschränkungen wie für das Server Configuration Tool:

  • Alle Komponenten (MobileFirst Operations Console, MobileFirst-Server-Verwaltungsservice und -Liveaktualisierungsservice, die MobileFirst-Server-Artefakte sowie die MobileFirst-Foundation-Laufzeit) müssen in einem Anwendungsserver installiert werden. Bei einer Installation in einem Cluster mit WebSphere Application Server Network Deployment können Sie jedoch für den Verwaltungs- und Liveaktualisierungsservice und für die Laufzeit einen anderen Cluster angeben.
  • Wenn der MobileFirst-Server-Push-Service installiert werden soll, muss er auch in demselben Server installiert werden. Bei einer Installation in einem Cluster mit WebSphere Application Server Network Deployment kann für den Push-Service jedoch ein anderer Cluster angegeben werden.
  • Alle Komponenten verwenden dasselbe Datenbanksystem und denselben Benutzer. Bei Verwendung von DB2 verwenden alle Komponenten zudem dasselbe Schema.
  • Das Server Configuration Tool installiert die Komponenten für einen Einzelserver. Wenn die Installation auf mehreren Servern erfolgen soll, muss nach Ausführung des Tools eine Farm konfiguriert werden. Die Server-Farmkonfiguration wird von WebSphere Application Server Network Deployment nicht unterstütz.

Sie können mit Ant-Tasks die Ausführung der Services von MobileFirst Server in einer Server-Farm konfigurieren. Für die Aufnahme Ihres Servers in eine Farm müssen Sie bestimmte Attribute angeben, mit denen Ihr Anwendungsserver entsprechend konfiguriert wird. Weitere Informationen zum Konfigurieren einer Server-Farm mit Ant-Tasks finden Sie unter Server-Farm mit Ant-Tasks installieren.

Für andere unterstützte Topologien (siehe Topologien und Netzabläufe) können Sie die Ant-Beispieldateien modifizieren.

Es handelt sich um folgende Ant-Tasks:

Eine Übersicht über die Installation mit der Beispielkonfigurationsdatei und den Beispiel-Taks finden Sie unter MobileFirst Server im Befehlszeilenmodus installieren.

Sie können eine Ant-Datei mit der Ant-Distribution ausführen, die Teil der Produktinstallation ist. Wenn Sie beispielsweise einen Cluster mit WebSphere Application Server Network Deployment und IBM DB2 als Datenbank verwenden, können Sie die Ant-Datei MFP-Installationsverzeichnis/MobileFirstServer/configuration-samples/configure-wasnd-cluster-db2.xml verwenden. Wenn Sie die Datei bearbeitet und alle erforderlichen Eigenschaften eingegeben haben, können Sie im Verzeichnis MFP-Installationsverzeichnis/MobileFirstServer/configuration-samples die folgenden Befehle ausführen:

  • MFP-Installationsverzeichnis/shortcuts/ant -f configure-wasnd-cluster-db2.xml help - Mit diesem Befehl wird die Liste aller gültigen Ziele der Ant-Datei für die Installation, Deinstallation oder Aktualisierung von Komponenten angezeigt.
  • MFP-Installationsverzeichnis/shortcuts/ant -f configure-wasnd-cluster-db2.xml install - Mit diesem Befehl wird MobileFirst Server in dem Cluster mit WebSphere Application Server Network Deployment und DB2 als Datenquelle installiert. Dabei werden die in den Eigenschaften der Ant-Datei angegebenen Parameter verwendet.


Erstellen Sie nach der Installation eine Kopie der Ant-Datei, die Sie später für die Anwendung eines Fixpacks nutzen können.

Fixpack mit Ant-Dateien anwenden

Aktualisierung mit der Ant-Beispieldatei

Wenn Sie eine der Ant-Beispieldateien aus dem Verzeichnis MFP-Installationsverzeichnis/MobileFirstServer/configuration-samples für die Installation von MobileFirst Server verwendet haben, können Sie eine Kopie dieser Ant-Datei für die Anwendung eines Fixpacks nutzen. Als Kennwort können Sie 12 Sterne (*) anstelle des tatsächlichen Wertes angeben. Sie werden dann zur Eingabe des Kennworts aufgefordert, wenn die Ant-Datei ausgeführt wird.

  1. Überprüfen Sie den Wert der Eigenschaft mfp.server.install.dir in der Ant-Datei. Er muss auf das Verzeichnis zeigen, das das Produkt mit dem angewendeten Fixpack enthält. Aus diesem Verzeichnis werden die aktualisierten MobileFirst-Server-WAR-Dateien verwendet.
  2. Führen Sie den Befehl MFP-Installationsverzeichnis/shortcuts/ant -f Ihre_Ant-Datei update aus.

Aktualisierung mit eigener Ant-Datei

Wenn Sie Ihre eigene Ant-Datei verwenden, muss sie für alle Installations-Tasks (installmobilefirstadmin, installmobilefirstruntime und installmobilefirstpush) eine entsprechende Aktualisierungs-Task mit den gleichen Parametern enthalten. Die zugehörigen Aktualisierungs-Tasks sind updatemobilefirstadmin, updatemobilefirstruntime und updatemobilefirstpush.

  1. Überprüfen Sie den Klassenpfad des Elements taskdef für die Datei mfp-ant-deployer.jar. Der Pfad muss auf die Datei mfp-ant-deployer.jar einer MobileFirst-Server-Installation mit angewendetem Fixpack zeigen. Die aktualisierten MobileFirst-Server-WAR-Dateien werden standardmäßig von der Position der Datei mfp-ant-deployer.jar verwendet.
  2. Führen Sie die Aktualisierungs-Tasks (updatemobilefirstadmin, updatemobilefirstruntime und updatemobilefirstpush) in Ihrer Ant-Datei aus.

Modifizieren der Ant-Beispieldateien

Sie können die im Verzeichnis MFP-Installationsverzeichnis/MobileFirstServer/configuration-samples bereitgestellten Ant-Beispieldateien an Ihre Installationsanforderungen anpassen.
In den folgenden Abschnitten erfahren Sie, wie Sie die Ant-Beispieldateien modifizieren und die Installation an Ihre Anforderungen anpassen können:

  1. Zusätzliche JNDI-Eigenschaften angeben
  2. Vorhandene Benutzer angeben
  3. Liberty-Java-EE-Version angeben
  4. JDBC-Eigenschaften der Datenquelle angeben
  5. Ant-Dateien auf einem Computer ohne MobileFirst Server ausführen
  6. Ziele für WebSphere Application Server Network Deployment angeben
  7. RMI-Port für Apache Tomcat manuell konfigurieren

Zusätzliche JNDI-Eigenschaften angeben

Die Ant-Tasks installmobilefirstadmin, installmobilefirstruntime und installmobilefirstpush deklarieren die Werte für JNDI-Eigenschaften, die erforderlich sind, damit die Komponenten funktionieren. Mit diesen JNDI-Eigenschaften werden die JMX-Kommunikation und die Links zu anderen Komponenten definiert (z. B. zum Liveaktualisierungsservice, zum Push-Service, zum Analyseservice oder zum Autorisierungsserver). Sie können aber auch Werte für andere JNDI-Eigenschaften definieren. Verwenden Sie dafür das Element <property> der drei genannten Tasks. Eine Liste der JNDI-Eigenschaften finden Sie unter:

Beispiel:

<installmobilefirstadmin ..>
    <property name="mfp.admin.actions.prepareTimeout" value="3000000"/>
</installmobilefirstadmin>

Vorhandene Benutzer angeben

Die Ant-Task installmobilefirstadmin ertellt standardmäßig Benutzer.

  • In WebSphere Application Server Liberty definiert sie einen Liberty-Administrator für die JMX-Kommunikation.
  • In einem beliebigen Anwendungsserver definiert sie einen Benutzer für die Kommunikation mit dem Liveaktualisierungsservice.

Wenn Sie keinen neuen Benutzer erstellen, sondern einen vorhandenen Benutzer verwenden möchten, können Sie wie folgt vorgehen:

  1. Geben Sie im Element <jmx> einen Benutzer und ein Kennwort an und setzen Sie das Attribut createLibertyAdmin auf den Wert “false”. Beispiel:

    <installmobilefirstadmin ...>
    <jmx libertyAdminUser="myUser" libertyAdminPassword="password" createLibertyAdmin="false" />
    ...

  2. Geben Sie im Element <configuration> einen Benutzer und ein Kennwort an und setzen Sie das Attribut createConfigAdminUser auf den Wert “false”. Beispiel:

     <installmobilefirstadmin ...>
     <configuration configAdminUser="myUser" configAdminPassword="password" createConfigAdminUser="false" />
     ...

Der von den Ant-Beispieldateien erstellte Benutzer wird den Sicherheitsrollen des Verwaltungsservice und der Konsole zugeordnet. Dieser Benutzer kann sich also nach der Installation bei MobileFirst Server anmelden. Wenn Sie dieses Verhalten ändern möchten, entfernen Sie das Element <user> aus den Ant-Beispieldateien. Alternativ dazu können Sie das Attribut password aus dem Element <user> entfernen, damit der Benutzer nicht in der lokalen Registry des Anwendungsservers erstellt wird.

Liberty-Java-EE-Version angeben

Einige Distributionen von WebSphere Application Server Liberty unterstützen Features von Java EE 6 oder Java EE 7. Standardmäßig erkennen die Ant-Tasks automatisch, welche Features installiert werden müssen. Das Liberty-Feature jdbc-4.0 wird beispielsweise für Java EE 6 und das Feature jdbc-4.1 für Java EE 7 installiert. Wenn die Liberty-Installation Features sowohl von Java EE 6 als auch von Java EE 7 unterstützt, können Sie die Verwendung einer bestimmten Version der Features durchsetzen. Angenommen, Sie planen, MobileFirst Server Version 8.0.0 und Version 7.1.0 auf demselben Liberty-Server auszuführen. Bis Version 7.1.0 unterstützt MobileFirst Server nur Features von Java EE 6.

Wenn Sie also die Verwendung der Features von Java EE 6 erzwingen wollen, verwenden Sie das Attribut jeeversion des Elements <websphereapplicationserver>. Beispiel:

<installmobilefirstadmin execute="${mfp.process.admin}" contextroot="${mfp.admin.contextroot}">
    [...]
    <applicationserver>
      <websphereapplicationserver installdir="${appserver.was.installdir}"
        profile="Liberty" jeeversion="6">

JDBC-Eigenschaften der Datenquelle angeben

Sie können die Eigenschaften der JDBC-Verbindung mit dem Element <property> eines Elements <database> angeben. Dieses Element ist in den Ant-Tasks configureDatabase, installmobilefirstadmin, installmobilefirstruntime und installmobilefirstpush verfügbar. Beispiel:

<configuredatabase kind="MobileFirstAdmin">
    <db2 database="${database.db2.mfpadmin.dbname}"
        server="${database.db2.host}"
        instance="${database.db2.instance}"
        user="${database.db2.mfpadmin.username}"
        port= "${database.db2.port}"
        schema = "${database.db2.mfpadmin.schema}"
        password="${database.db2.mfpadmin.password}">

       <property name="commandTimeout" value="10"/>
    </db2>

Ant-Dateien auf einem Computer ohne MobileFirst Server ausführen

Wenn Sie die Ant-Tasks auf einem Computer ohne installierten MobileFirst Server ausführen möchten, benötigen Sie Folgendes:

  • Ant-Installation
  • Kopie der Datei mfp-ant-deployer.jar für den fernen Computer. Diese Bibliothek enthält die Definition der Ant-Tasks.
  • Angabe der zu installierenden Ressourcen. Stanardmäßig werden die WAR-Dateien aus dem Umfeld von mfp-ant-deployer.jar verwendet. Sie können die Position dieser WAR-Dateien jedoch angeben. Beispiel:
<installmobilefirstadmin execute="true" contextroot="/mfpadmin" serviceWAR="/usr/mfp/mfp-admin-service.war">
  <console install="true" warFile="/usr/mfp/mfp-admin-ui.war"/>

Weitere Informationen zur Verwendung von Ant-Tasks für die Installation der einzelnen MobileFirst-Server-Komponenten finden Sie in den Referenzinformationen zur Installation.

Ziele für WebSphere Application Server Network Deployment angeben

Für die Installation in WebSphere Application Server Network Deployment muss der Deployment Manager als WebSphere-Application-Server-Profil angegeben werden. Die Implementierung ist in folgenden Konfigurationen möglich:

  • Cluster
  • Einzelserver
  • Zelle (alle Server einer Zelle)
  • Knoten (alle Server eines Knotens)

Die Beispieldateien (z. B. configure-wasnd-cluster-DBMS.xml, configure-wasnd-server-DBMS.xml und configure-wasnd-node-DBMS.xml) enthalten die Deklaration für die Implementierung in den einzelnen Zielarten. Weitere Informationen zur Verwendung von Ant-Tasks für die Installation der einzelnen MobileFirst-Server-Komponenten finden Sie in den Referenzinformationen zur Installation.

Hinweis: Ab Version 8.0.0 wird keine Beispielkonfigurationsdatei für eine WebSphere-Application-Server-Network-Deployment-Zelle bereitgestellt.

RMI-Port für Apache Tomcat manuell konfigurieren

Die Ant-Tasks modifizieren standardmäßig die Datei setenv.bat oder setenv.sh, um den RMI-Port zu öffnen. Wenn Sie den RMI-Port lieber manuell öffnen möchten, fügen Sie in den Tasks installmobilefirstadmin, updatemobilefirstadmin und uninstallmobilefirstadmin das Attribut tomcatSetEnvConfig mit dem Wert “false” zum Element <jmx> hinzu.

MobileFirst-Server-Komponenten manuell installieren

Sie können die MobileFirst-Server-Komponenten manuell in Ihrem Anwendungsserver installieren.
In den folgenden Abschnitten finden Sie vollständige Informationen, die Sie durch den Prozess für die Installation der Komponenten in den unterstützten Anwendungen in der Produktion führen.

Manuelle Installation in WebSphere Application Server Liberty

Vergewissern Sie sich, dass die unter Voraussetzungen für WebSphere Application Server Liberty dokumentierten Voraussetzungen erfüllt sind.

Topologieeinschränkungen

Der MobileFirst-Server-Verwaltungsservice und -Liveaktualisierungsservice sowie die MobileFirst-Laufzeit müssen in einem Anwendungsserver installiert werden. Das Kontextstammverzeichnis des Liveaktualisierungsservice wird wie folgt definiert: “Kontextstammverzeichnis_des_Verwaltungsserviceconfig”. Das Kontextstammverzeichnis des Push-Service muss imfpush sein. Weitere Informationen zu den Einschränkungen finden Sie unter Einschränkungen für die MobileFirst-Server-Komponenten und für MobileFirst Analytics.

Anwendungsservereinstellungen

Sie müssen das Element webContainer so konfigurieren, dass die Servlets sofort geladen werden. Diese Einstellung ist für die Initialisierung mit JMX erforderlich. Beispiel: <webContainer deferServletLoad="false"/>

Um Probleme durch Zeitlimitüberschreitungen zu vermeiden, die in einigen Liberty-Versionen die Startsequenz für die Laufzeit und den Verwaltungsservice unterbrechen, können Sie das Standardelement executor ändern. Legen Sie für die Attribute coreThreads und maxThreads große Werte fest. Beispiel:

<executor id="default" name="LargeThreadPool"
  coreThreads="200" maxThreads="400" keepAlive="60s"
  stealPolicy="STRICT" rejectedWorkPolicy="CALLER_RUNS"/>

Sie können auch das Element tcpOptions konfigurieren und das Attribut soReuseAddr auf true setzen: <tcpOptions soReuseAddr="true"/>

Für MobileFirst-Server-Anwendungen erforderliche Liberty-Features

Für Java EE 6 oder Java EE 7 können Sie die folgenden Features verwenden.

MobileFirst-Server-Verwaltungsservice

  • jdbc-4.0 (jdbc-4.1 für Java EE 7)
  • appSecurity-2.0
  • restConnector-1.0
  • usr:MFPDecoderFeature-1.0

MobileFirst-Server-Push-Service

  • jdbc-4.0 (jdbc-4.1 für Java EE 7)
  • servlet-3.0 (servlet-3.1 für Java EE 7)
  • ssl-1.0
  • usr:MFPDecoderFeature-1.0

MobileFirst-Laufzeit

  • jdbc-4.0 (jdbc-4.1 für Java EE 7)
  • servlet-3.0 (servlet-3.1 für Java EE 7)
  • ssl-1.0
  • usr:MFPDecoderFeature-1.0

Globale JNDI-Einträge

Die folgenden globalen JNDI-Einträge sind erforderlich, um die JMX-Kommunikation zwischen der Laufzeit und dem Verwaltungsservice zu konfigurieren:

  • mfp.admin.jmx.host
  • mfp.admin.jmx.port
  • mfp.admin.jmx.user
  • mfp.admin.jmx.pwd
  • mfp.topology.platform
  • mfp.topology.clustermode

Diese globalen JNDI-Einträge werden mit der folgenden Syntax definiert. Den Einträgen wird kein Kontextstammverzeichnis vorangestellt. Beispiel: <jndiEntry jndiName="mfp.admin.jmx.port" value="9443"/>

Hinweis: Verwenden Sie beim Definieren der JNDI-Werte die Syntax ‘“075”’, um die Werte vor einer einer automatischen Konvertierung zu schützen, bei der 075 in 61 oder 31.500 in 31.5 konvertiert werden würde.

Weitere Informationen zu den JNDI-Eigenschaften für den Verwaltungsservice finden Sie in der Liste der JNDI-Eigenschaften für den MobileFirst-Server-Verwaltungsservice.

Lesen Sie für eine Farmkonfiguration auch die folgenden Artikel:

Klassenladeprogramm

Das Klassenladeprogramm für alle Anwendungen muss mit der Delegierung “Übergeordnete zuletzt” (parentLast) arbeiten. Beispiel:

<application id="mfpadmin" name="mfpadmin" location="mfp-admin-service.war" type="war">
  [...]
  <classloader delegation="parentLast">
  </classloader>
</application>

Benutzerfeature Kennwort-Decoder

Kopieren Sie den Kennwort-Decoder in Ihr Liberty-Profil. Beispiel:

  • Auf UNIX- und Linux-Systemen:

    mkdir -p LIBERTY_HOME/wlp/usr/extension/lib/features
cp Produktinstallationsverzeichnis/features/com.ibm.websphere.crypto_1.0.0.jar LIBERTY_HOME/wlp/usr/extension/lib/
cp Produktinstallationsverzeichnis/features/MFPDecoderFeature-1.0.mf LIBERTY_HOME/wlp/usr/extension/lib/features/

  • Auf Windows-Systemen:

    mkdir LIBERTY_HOME\wlp\usr\extension\lib
copy /B Produktinstallationsverzeichnis\features\com.ibm.websphere.crypto_1.0.0.jar
LIBERTY_HOME\wlp\usr\extension\lib\com.ibm.websphere.crypto_1.0.0.jar
mkdir LIBERTY_HOME\wlp\usr\extension\lib\features
copy /B Produktinstallationsverzeichnis\features\MFPDecoderFeature-1.0.mf
LIBERTY_HOME\wlp\usr\extension\lib\features\MFPDecoderFeature-1.0.mf

Konfigurationsdetails

Der Verwaltungsservice wird als WAR-Anwendung bereitgestellt, die Sie im Anwendungsserver implementieren können. Sie müssen für diese Anwendung einige Konfigurationsschritte in der Datei server.xml ausführen. Die WAR-Datei für den Verwaltungsservice ist MFP-Installationsverzeichnis/MobileFirstServer/mfp-admin-service.war. Das Kontextstammverzeichnis können Sie ganz nach Wunsch festlegen. Normalerweise wird der Name /mfpadmin verwendet.

Obligatorische JNDI-Eigenschaften

Wenn Sie die JNDI-Eigenschaften definieren, müssen die Namen mit dem Kontextstammverzeichnis des Verwaltungsservice als Präfix versehen werden. Das folgende Beispiel veranschaulicht die Deklaration von mfp.admin.push.url, wenn der Verwaltungsservice mit dem Kontextstammverzeichnis /mfpadmin installiert ist:

<jndiEntry jndiName="mfpadmin/mfp.admin.push.url" value="http://localhost:9080/imfpush"/>

Wenn der Push-Service installiert ist, müssen Sie die folgenden JNDI-Eigenschaften konfigurieren:

  • mfp.admin.push.url
  • mfp.admin.authorization.server.url
  • mfp.push.authorization.client.id
  • mfp.push.authorization.client.secret
  • mfp.admin.authorization.client.id
  • mfp.admin.authorization.client.secret

Die JNDI-Eigenschaften für die Kommunikation mit dem Konfigurationsservice sind folgende:

  • mfp.config.service.user
  • mfp.config.service.password

Weitere Informationen zu den JNDI-Eigenschaften finden Sie in der Liste der JNDI-Eigenschaften für den MobileFirst-Server-Verwaltungsservice.

Datenquelle

Als JNDI-Name der Dateiquelle für den Verwaltungsservice muss jndiName=Kontextstammverzeichnis/jdbc/mfpAdminDS definiert werden. Das folgende Beispiel zeigt einen Fall, bei dem der Verwaltungsservice mit dem Kontextstammverzeichnis /mfpadmin installiert ist und eine relationale Datenbank verwendet:

<dataSource jndiName="mfpadmin/jdbc/mfpAdminDS" transactional="false">
  [...]
</dataSource>

Deklarieren Sie die folgenden Rollen im Element application-bnd der Anwendung:

  • mfpadmin
  • mfpdeployer
  • mfpmonitor
  • mfpoperator

Der Liveaktualisierungsservice wird als WAR-Anwendung bereitgestellt, die Sie im Anwendungsserver implementieren können. Sie müssen für diese Anwendung einige Konfigurationsschritte in der Datei server.xml ausführen. Informieren Sie sich unter Manuelle Installation in WebSphere Application Server Liberty über die allgemeinen Konfigurationsdetails für alle Services, bevor Sie mit den hier beschriebenen Schritten fortfahren.

Die WAR-Datei für den Liveaktualisierungsservice ist MFP-Installationsverzeichnis/MobileFirstServer/mfp-live-update.war. Das Kontextstammverzeichnis des Liveaktualisierungsservice wird wie folgt definiert: "Kontextstammverzeichnis_des_Verwaltungsserviceconfig". Wenn das Kontextstammverzeichnis des Verwaltungsservice beispielsweise /mfpadmin ist, muss der Liveaktualisierungsservice das Kontextstammverzeichnis /mfpadminconfig haben.

Datenquelle

Der JNDI-Name der Datenquelle für den Liveaktualisierungsservice muss wie folgt definiert werden: "Kontextstammverzeichnis/jdbc/ConfigDS". Das folgende Beispiel zeigt einen Fall, bei dem der Liveaktualisierungsservice mit dem Kontextstammverzeichnis /mfpadminconfig installiert ist und eine relationale Datenbank verwendet:

<dataSource jndiName="mfpadminconfig/jdbc/ConfigDS" transactional="false">
  [...]
</dataSource>

Deklarieren Sie im Element application-bnd der Anwendung die Rolle configadmin. Dieser Rolle muss mindestens ein Benutzer zugeordnet sein. Der Benutzer und sein Kennwort müssen in den folgenden JNDI-Eigenschaften des Verwaltungsservice angegeben werden:

  • mfp.config.service.user
  • mfp.config.service.password

Die Konsole wird als WAR-Anwendung bereitgestellt, die Sie im Anwendungsserver implementieren können. Sie müssen für diese Anwendung einige Konfigurationsschritte in der Datei server.xml ausführen. Informieren Sie sich unter Manuelle Installation in WebSphere Application Server Liberty über die allgemeinen Konfigurationsdetails für alle Services, bevor Sie mit den hier beschriebenen Schritten fortfahren.

Die WAR-Datei für die Konsole ist MFP-Installationsverzeichnis/MobileFirstServer/mfp-admin-ui.war. Das Kontextstammverzeichnis können Sie ganz nach Wunsch festlegen. Normalerweise wird der Name /mfpconsole verwendet.

Obligatorische JNDI-Eigenschaften

Wenn Sie die JNDI-Eigenschaften definieren, müssen die Namen mit dem Kontextstammverzeichnis der Konsole als Präfix versehen werden. Das folgende Beispiel veranschaulicht die Deklaration von mfp.admin.endpoint, wenn die Konsole mit dem Kontextstammverzeichnis /mfpconsole installiert ist:

<jndiEntry jndiName="mfpconsole/mfp.admin.endpoint" value="*://*:*/mfpadmin"/>

Die Eigenschaft mfp.admin.endpoint hat normalerweise den Wert *://*:*/Kontextstammverzeichnis_des_Verwaltungsservice.
Weitere Informationen zu JNDI-Eigenschaften finden Sie unter JNDI-Eigenschaften für die MobileFirst Operations Console.

Sicherheitsrollen

Deklarieren Sie die folgenden Rollen im Element application-bnd der Anwendung:

  • mfpadmin
  • mfpdeployer
  • mfpmonitor
  • mfpoperator
Jeder Benutzer, der einer Sicherheitsrolle der Konsole zugeordnet ist, muss der gleichen Sicherheitsrolle des Verwaltungsservice zugeordnet sein.

Die Laufzeit wird als WAR-Anwendung bereitgestellt, die Sie im Anwendungsserver implementieren können. Sie müssen für diese Anwendung einige Konfigurationsschritte in der Datei server.xml ausführen. Informieren Sie sich unter Manuelle Installation in WebSphere Application Server Liberty über die allgemeinen Konfigurationsdetails für alle Services, bevor Sie mit den hier beschriebenen Schritten fortfahren.

Die WAR-Datei für die Laufzeit ist MFP-Installationsverzeichnis/MobileFirstServer/mfp-server.war. Das Kontextstammverzeichnis können Sie ganz nach Wunsch festlegen. Das Standardkontextstammverzeichnis ist /mfp.

Obligatorische JNDI-Eigenschaften

Wenn Sie die JNDI-Eigenschaften definieren, müssen die Namen mit dem Kontextstammverzeichnis der Laufzeit als Präfix versehen werden. Das folgende Beispiel veranschaulicht die Deklaration von mfp.analytics.url, wenn die Laufzeit mit dem Kontextstammverzeichnis /mobilefirst installiert ist:

<jndiEntry jndiName="mobilefirst/mfp.analytics.url" value="http://localhost:9080/analytics-service/rest"/>

Sie müssen die Eigenschaft mobilefirst/mfp.authorization.server definieren. Beispiel: 

<jndiEntry jndiName="mobilefirst/mfp.authorization.server" value="embedded"/>

Wenn MobileFirst Analytics installiert ist, müssen Sie die folgenden JNDI-Eigenschaften definieren:

  • mfp.analytics.url
  • mfp.analytics.console.url
  • mfp.analytics.username
  • mfp.analytics.password

Weitere Informationen zu den JNDI-Eigenschaften finden Sie in der Liste der JNDI-Eigenschaften für die MobileFirst-Laufzeit.

Datenquelle

Als JNDI-Name der Datenquelle für die Laufzeit muss jndiName=Kontextstammverzeichnis/jdbc/mfpDS definiert werden. Das folgende Beispiel zeigt einen Fall, bei dem die Laufzeit mit dem Kontextstammverzeichnis /mobilefirst installiert ist und eine relationale Datenbank verwendet:

<dataSource jndiName="mobilefirst/jdbc/mfpDS" transactional="false">
  [...]
</dataSource>

Der Push-Service wird als WAR-Anwendung bereitgestellt, die Sie im Anwendungsserver implementieren können. Sie müssen für diese Anwendung einige Konfigurationsschritte in der Datei server.xml ausführen. Informieren Sie sich unter Manuelle Installation in WebSphere Application Server Liberty über die allgemeinen Konfigurationsdetails für alle Services, bevor Sie mit den hier beschriebenen Schritten fortfahren.

Die WAR-Datei für den Push-Service ist MFP-Installationsverzeichnis/PushService/mfp-push-service.war. Sie müssen /imfpush als Kontextstammverzeichnis festlegen. Andernfalls können die Clientgeräte keine Verbindung zu dem Service herstellen, denn das Kontextstammverzeichnis ist im SDK fest codiert.

Obligatorische JNDI-Eigenschaften

Wenn Sie die JNDI-Eigenschaften definieren, müssen die Namen mit dem Kontextstammverzeichnis des Push-Service als Präfix versehen werden. Das folgende Beispiel veranschaulicht die Deklaration von mfp.push.analytics.user, wenn der Push-Service mit dem Kontextstammverzeichnis /imfpush installiert ist:

<jndiEntry jndiName="imfpush/mfp.push.analytics.user" value="admin"/>
Sie müssen die folgenden Eigenschaften definieren:
  • mfp.push.authorization.server.url
  • mfp.push.authorization.client.id
  • mfp.push.authorization.client.secret
  • mfp.push.services.ext.security: Der Wert muss com.ibm.mfp.push.server.security.plugin.OAuthSecurityPlugin lauten.
  • mfp.push.db.type: Der Wert für eine relationale Datenbank muss DB sein.
Wenn MobileFirst Analytics konfiguriert ist, definieren Sie die folgenden JNDI-Eigenschaften:
  • mfp.push.analytics.endpoint
  • mfp.analytics.username
  • mfp.analytics.password
  • mfp.push.services.ext.analytics: Der Wert muss com.ibm.mfp.push.server.analytics.plugin.AnalyticsPlugin lauten.
Weitere Informationen zu den JNDI-Eigenschaften finden Sie in der Liste der JNDI-Eigenschaften für den MobileFirst-Server-Push-Service.

Die Artefaktkomponente wird als WAR-Anwendung bereitgestellt, die Sie im Anwendungsserver implementieren können. Sie müssen für diese Anwendung einige Konfigurationsschritte in der Datei server.xml ausführen. Informieren Sie sich unter Manuelle Installation in WebSphere Application Server Liberty über die allgemeinen Konfigurationsdetails für alle Services, bevor Sie mit den hier beschriebenen Schritten fortfahren.

Die WAR-Datei für diese Komponente ist MFP-Installationsverzeichnis/MobileFirstServer/mfp-dev-artifacts.war. Sie müssen /mfp-dev-artifacts als Kontextstammverzeichnis festlegen.

Manuelle Installation in einem WebSphere-Application-Server-Liberty-Verbund

Vergewissern Sie sich, dass die unter Voraussetzungen für WebSphere Application Server Liberty dokumentierten Voraussetzungen erfüllt sind.

Topologieeinschränkungen

Der MobileFirst-Server-Verwaltungsservice und -Liveaktualisierungsservice sowie die MobileFirst Operations Console müssen in einem Liberty-Verbundcontroller installiert werden. Die MobileFirst-Laufzeit und der MobileFirst-Server-Push-Service müssen in jedem Member des Liberty-Verbundclusters installiert werden.

Das Kontextstammverzeichnis des Liveaktualisierungsservice wird wie folgt definiert: “Kontextstammverzeichnis_des_Verwaltungsserviceconfig”. Das Kontextstammverzeichnis des Push-Service muss imfpush sein. Weitere Informationen zu den Einschränkungen finden Sie unter Einschränkungen für die MobileFirst-Server-Komponenten und für MobileFirst Analytics.

Anwendungsservereinstellungen

Sie müssen das Element webContainer so konfigurieren, dass die Servlets sofort geladen werden. Diese Einstellung ist für die Initialisierung mit JMX erforderlich. Beispiel: <webContainer deferServletLoad="false"/>

Um Probleme durch Zeitlimitüberschreitungen zu vermeiden, die in einigen Liberty-Versionen die Startsequenz für die Laufzeit und den Verwaltungsservice unterbrechen, können Sie das Standardelement executor ändern. Legen Sie für die Attribute coreThreads und maxThreads große Werte fest. Beispiel:

<executor id="default" name="LargeThreadPool"
  coreThreads="200" maxThreads="400" keepAlive="60s"
  stealPolicy="STRICT" rejectedWorkPolicy="CALLER_RUNS"/>

Sie können auch das Element tcpOptions konfigurieren und das Attribut soReuseAddr auf true setzen: <tcpOptions soReuseAddr="true"/>

Für MobileFirst-Server-Anwendungen erforderliche Liberty-Features

Für Java EE 6 oder Java EE 7 müssen Sie die folgenden Features hinzufügen.

MobileFirst-Server-Verwaltungsservice

  • jdbc-4.0 (jdbc-4.1 für Java EE 7)
  • appSecurity-2.0
  • restConnector-1.0
  • usr:MFPDecoderFeature-1.0

MobileFirst-Server-Push-Service

  • jdbc-4.0 (jdbc-4.1 für Java EE 7)
  • servlet-3.0 (servlet-3.1 für Java EE 7)
  • ssl-1.0
  • usr:MFPDecoderFeature-1.0

MobileFirst-Laufzeit

  • jdbc-4.0 (jdbc-4.1 für Java EE 7)
  • servlet-3.0 (servlet-3.1 für Java EE 7)
  • ssl-1.0
  • usr:MFPDecoderFeature-1.0

Globale JNDI-Einträge

Die folgenden globalen JNDI-Einträge sind erforderlich, um die JMX-Kommunikation zwischen der Laufzeit und dem Verwaltungsservice zu konfigurieren:

  • mfp.admin.jmx.host
  • mfp.admin.jmx.port
  • mfp.admin.jmx.user
  • mfp.admin.jmx.pwd
  • mfp.topology.platform
  • mfp.topology.clustermode
  • mfp.admin.serverid

Diese globalen JNDI-Einträge werden mit der folgenden Syntax definiert. Den Einträgen wird kein Kontextstammverzeichnis vorangestellt. Beispiel: <jndiEntry jndiName="mfp.admin.jmx.port" value="9443"/>

Hinweis: Verwenden Sie beim Definieren der JNDI-Werte die Syntax ‘“075”’, um die Werte vor einer einer automatischen Konvertierung zu schützen, bei der 075 in 61 oder 31.500 in 31.5 konvertiert werden würde.

Klassenladeprogramm

Das Klassenladeprogramm für alle Anwendungen muss mit der Delegierung “Übergeordnete zuletzt” (parentLast) arbeiten. Beispiel:

<application id="mfpadmin" name="mfpadmin" location="mfp-admin-service.war" type="war">
  [...]
  <classloader delegation="parentLast">
  </classloader>
</application>

Benutzerfeature Kennwort-Decoder

Kopieren Sie den Kennwort-Decoder in Ihr Liberty-Profil. Beispiel:

  • Auf UNIX- und Linux-Systemen:

    mkdir -p LIBERTY_HOME/wlp/usr/extension/lib/features
cp Produktinstallationsverzeichnis/features/com.ibm.websphere.crypto_1.0.0.jar LIBERTY_HOME/wlp/usr/extension/lib/
cp Produktinstallationsverzeichnis/features/MFPDecoderFeature-1.0.mf LIBERTY_HOME/wlp/usr/extension/lib/features/

  • Auf Windows-Systemen:

    mkdir LIBERTY_HOME\wlp\usr\extension\lib
copy /B Produktinstallationsverzeichnis\features\com.ibm.websphere.crypto_1.0.0.jar
LIBERTY_HOME\wlp\usr\extension\lib\com.ibm.websphere.crypto_1.0.0.jar
mkdir LIBERTY_HOME\wlp\usr\extension\lib\features
copy /B Produktinstallationsverzeichnis\features\MFPDecoderFeature-1.0.mf
LIBERTY_HOME\wlp\usr\extension\lib\features\MFPDecoderFeature-1.0.mf

    Konfigurationsdetails

Der Verwaltungsservice wird als WAR-Anwendung bereitgestellt, die Sie im Controller des Liberty-Verbunds implementieren können. Sie müssen für diese Anwendung einige Konfigurationsschritte in der Datei server.xml des Liberty-Verbundcontrollers ausführen.

Informieren Sie sich unter Manuelle Installation in einem WebSphere-Application-Server-Liberty-Verbund über die allgemeinen Konfigurationsdetails für alle Services, bevor Sie mit den hier beschriebenen Schritten fortfahren.

Die WAR-Datei für den Verwaltungsservice ist MFP-Installationsverzeichnis/MobileFirstServer/mfp-admin-service-collecitve.war. Das Kontextstammverzeichnis können Sie ganz nach Wunsch festlegen. Normalerweise wird der Name /mfpadmin verwendet.

Obligatorische JNDI-Eigenschaften

Wenn Sie die JNDI-Eigenschaften definieren, müssen die Namen mit dem Kontextstammverzeichnis des Verwaltungsservice als Präfix versehen werden. Das folgende Beispiel veranschaulicht die Deklaration von mfp.admin.push.url, wenn der Verwaltungsservice mit dem Kontextstammverzeichnis /mfpadmin installiert ist:

<jndiEntry jndiName="mfpadmin/mfp.admin.push.url" value="http://localhost:9080/imfpush"/>

Wenn der Push-Service installiert ist, müssen Sie die folgenden JNDI-Eigenschaften konfigurieren:

  • mfp.admin.push.url
  • mfp.admin.authorization.server.url
  • mfp.push.authorization.client.id
  • mfp.push.authorization.client.secret
  • mfp.admin.authorization.client.id
  • mfp.admin.authorization.client.secret

Die JNDI-Eigenschaften für die Kommunikation mit dem Konfigurationsservice sind folgende:

  • mfp.config.service.user
  • mfp.config.service.password

Weitere Informationen zu den JNDI-Eigenschaften finden Sie in der Liste der JNDI-Eigenschaften für den MobileFirst-Server-Verwaltungsservice.

Datenquelle

Als JNDI-Name der Dateiquelle für den Verwaltungsservice muss jndiName=Kontextstammverzeichnis/jdbc/mfpAdminDS definiert werden. Das folgende Beispiel zeigt einen Fall, bei dem der Verwaltungsservice mit dem Kontextstammverzeichnis /mfpadmin installiert ist und eine relationale Datenbank verwendet:

<dataSource jndiName="mfpadmin/jdbc/mfpAdminDS" transactional="false">
  [...]
</dataSource>

Sicherheitsrollen

Deklarieren Sie die folgenden Rollen im Element application-bnd der Anwendung:

  • mfpadmin
  • mfpdeployer
  • mfpmonitor
  • mfpoperator

Der Liveaktualisierungsservice wird als WAR-Anwendung bereitgestellt, die Sie im Controller des Liberty-Verbunds implementieren können. Sie müssen für diese Anwendung einige Konfigurationsschritte in der Datei server.xml des Liberty-Verbundcontrollers ausführen.

Informieren Sie sich unter Manuelle Installation in einem WebSphere-Application-Server-Liberty-Verbund über die allgemeinen Konfigurationsdetails für alle Services, bevor Sie mit den hier beschriebenen Schritten fortfahren.

Die WAR-Datei für den Liveaktualisierungsservice ist MFP-Installationsverzeichnis/MobileFirstServer/mfp-live-update.war. Das Kontextstammverzeichnis des Liveaktualisierungsservice wird wie folgt definiert: "Kontextstammverzeichnis_des_Verwaltungsserviceconfig". Wenn das Kontextstammverzeichnis des Verwaltungsservice beispielsweise /mfpadmin ist, muss der Liveaktualisierungsservice das Kontextstammverzeichnis /mfpadminconfig haben.

Datenquelle

Als JNDI-Name der Datenquelle für den Liveaktualisierungsservice muss /Kontextstammverzeichnis/jdbc/ConfigDS definiert werden. Das folgende Beispiel zeigt einen Fall, bei dem der Liveaktualisierungsservice mit dem Kontextstammverzeichnis /mfpadminconfig installiert ist und eine relationale Datenbank verwendet:

<dataSource jndiName="mfpadminconfig/jdbc/ConfigDS" transactional="false">
  [...]
</dataSource>

Sicherheitsrollen

Deklarieren Sie im Element application-bnd der Anwendung die Rolle configadmin. Dieser Rolle muss mindestens ein Benutzer zugeordnet sein. Der Benutzer und sein Kennwort müssen in den folgenden JNDI-Eigenschaften des Verwaltungsservice angegeben werden:

  • mfp.config.service.user
  • mfp.config.service.password

Die Konsole wird als WAR-Anwendung bereitgestellt, die Sie im Controller des Liberty-Verbunds implementieren können. Sie müssen für diese Anwendung einige Konfigurationsschritte in der Datei server.xml des Liberty-Verbundcontrollers ausführen.

Informieren Sie sich unter Manuelle Installation in WebSphere Application Server Liberty über die allgemeinen Konfigurationsdetails für alle Services, bevor Sie mit den hier beschriebenen Schritten fortfahren.

Die WAR-Datei für die Konsole ist MFP-Installationsverzeichnis/MobileFirstServer/mfp-admin-ui.war. Das Kontextstammverzeichnis können Sie ganz nach Wunsch festlegen. Normalerweise wird der Name /mfpconsole verwendet.

Obligatorische JNDI-Eigenschaften

Wenn Sie die JNDI-Eigenschaften definieren, müssen die Namen mit dem Kontextstammverzeichnis der Konsole als Präfix versehen werden. Das folgende Beispiel veranschaulicht die Deklaration von mfp.admin.endpoint, wenn die Konsole mit dem Kontextstammverzeichnis /mfpconsole installiert ist:

<jndiEntry jndiName="mfpconsole/mfp.admin.endpoint" value="*://*:*/mfpadmin"/>

Die Eigenschaft mfp.admin.endpoint hat normalerweise den Wert *://*:*/Kontextstammverzeichnis_des_Verwaltungsservice.
Weitere Informationen zu JNDI-Eigenschaften finden Sie unter JNDI-Eigenschaften für die MobileFirst Operations Console.

Sicherheitsrollen

Deklarieren Sie die folgenden Rollen im Element application-bnd der Anwendung:

  • mfpadmin
  • mfpdeployer
  • mfpmonitor
  • mfpoperator
Jeder Benutzer, der einer Sicherheitsrolle der Konsole zugeordnet ist, muss der gleichen Sicherheitsrolle des Verwaltungsservice zugeordnet sein.

Die Laufzeit wird als WAR-Anwendung bereitgestellt, die Sie in den Cluster-Membern des Liberty-Verbunds implementieren können. Sie müssen für diese Anwendung einige Konfigurationsschritte in der Datei server.xml jedes Cluster-Members des Liberty-Verbunds ausführen.

Informieren Sie sich unter Manuelle Installation in einem WebSphere-Application-Server-Liberty-Verbund über die allgemeinen Konfigurationsdetails für alle Services, bevor Sie mit den hier beschriebenen Schritten fortfahren.

Die WAR-Datei für die Laufzeit ist MFP-Installationsverzeichnis/MobileFirstServer/mfp-server.war. Das Kontextstammverzeichnis können Sie ganz nach Wunsch festlegen. Das Standardkontextstammverzeichnis ist /mfp.

Obligatorische JNDI-Eigenschaften

Wenn Sie die JNDI-Eigenschaften definieren, müssen die Namen mit dem Kontextstammverzeichnis der Laufzeit als Präfix versehen werden. Das folgende Beispiel veranschaulicht die Deklaration von mfp.analytics.url, wenn die Laufzeit mit dem Kontextstammverzeichnis /mobilefirst installiert ist:

<jndiEntry jndiName="mobilefirst/mfp.analytics.url" value="http://localhost:9080/analytics-service/rest"/>

Sie müssen die Eigenschaft mobilefirst/mfp.authorization.server definieren. Beispiel: 

<jndiEntry jndiName="mobilefirst/mfp.authorization.server" value="embedded"/>

Wenn MobileFirst Analytics installiert ist, müssen Sie die folgenden JNDI-Eigenschaften definieren:

  • mfp.analytics.url
  • mfp.analytics.console.url
  • mfp.analytics.username
  • mfp.analytics.password

Weitere Informationen zu den JNDI-Eigenschaften finden Sie in der Liste der JNDI-Eigenschaften für die MobileFirst-Laufzeit.

Datenquelle

Als JNDI-Name der Datenquelle für die Laufzeit muss jndiName=Kontextstammverzeichnis/jdbc/mfpDS definiert werden. Das folgende Beispiel zeigt einen Fall, bei dem die Laufzeit mit dem Kontextstammverzeichnis /mobilefirst installiert ist und eine relationale Datenbank verwendet:

<dataSource jndiName="mobilefirst/jdbc/mfpDS" transactional="false">
  [...]
</dataSource>

Der Push-Service wird als WAR-Anwendung bereitgestellt, die Sie in einem Cluster-Member eines Liberty-Verbunds oder in einem Liberty-Server implementieren können. Wenn Sie den Push-Service in einem Liberty-Server installieren, lesen Sie die Informationen im Abschnitt Konfigurationsdetails für den MobileFirst-Server-Push-Service Manuelle Installation in WebSphere Application Server Liberty.

Wenn der MobileFirst-Server-Push-Service in einem Liberty-Verbund installiert wird, kann er in demselben Cluster wie die Laufzeit oder in einem anderen Cluster installiert werden.

Sie müssen für diese Anwendung einige Konfigurationsschritte in der Datei server.xml jedes Cluster-Members des Liberty-Verbunds ausführen. Informieren Sie sich unter Manuelle Installation in einem WebSphere-Application-Server-Liberty-Verbund über die allgemeinen Konfigurationsdetails für alle Services, bevor Sie mit den hier beschriebenen Schritten fortfahren.

Die WAR-Datei für den Push-Service ist MFP-Installationsverzeichnis/PushService/mfp-push-service.war. Sie müssen /imfpush als Kontextstammverzeichnis festlegen. Andernfalls können die Clientgeräte keine Verbindung zu dem Service herstellen, denn das Kontextstammverzeichnis ist im SDK fest codiert.

Obligatorische JNDI-Eigenschaften

Wenn Sie die JNDI-Eigenschaften definieren, müssen die Namen mit dem Kontextstammverzeichnis des Push-Service als Präfix versehen werden. Das folgende Beispiel veranschaulicht die Deklaration von mfp.push.analytics.user, wenn der Push-Service mit dem Kontextstammverzeichnis /imfpush installiert ist:

<jndiEntry jndiName="imfpush/mfp.push.analytics.user" value="admin"/>
Sie müssen die folgenden Eigenschaften definieren:
  • mfp.push.authorization.server.url
  • mfp.push.authorization.client.id
  • mfp.push.authorization.client.secret
  • mfp.push.services.ext.security: Der Wert muss com.ibm.mfp.push.server.security.plugin.OAuthSecurityPlugin lauten.
  • mfp.push.db.type: Der Wert für eine relationale Datenbank muss DB sein.
Wenn MobileFirst Analytics konfiguriert ist, definieren Sie die folgenden JNDI-Eigenschaften:
  • mfp.push.analytics.endpoint
  • mfp.analytics.username
  • mfp.analytics.password
  • mfp.push.services.ext.analytics: Der Wert muss com.ibm.mfp.push.server.analytics.plugin.AnalyticsPlugin lauten.
Weitere Informationen zu den JNDI-Eigenschaften finden Sie in der Liste der JNDI-Eigenschaften für den MobileFirst-Server-Push-Service.

Die Artefaktkomponente wird als WAR-Anwendung bereitgestellt, die Sie im Controller des Liberty-Verbunds implementieren können. Sie müssen für diese Anwendung einige Konfigurationsschritte in der Datei server.xml des Liberty-Verbundcontrollers ausführen. Informieren Sie sich unter Manuelle Installation in WebSphere Application Server Liberty über die allgemeinen Konfigurationsdetails für alle Services, bevor Sie mit den hier beschriebenen Schritten fortfahren.

Die WAR-Datei für diese Komponente ist MFP-Installationsverzeichnis/MobileFirstServer/mfp-dev-artifacts.war. Sie müssen /mfp-dev-artifacts als Kontextstammverzeichnis festlegen.

Manuelle Installation in Apache Tomcat

Vergewissern Sie sich, dass die unter Voraussetzungen für Apache Tomcat dokumentierten Voraussetzungen erfüllt sind.

Topologieeinschränkungen

Der MobileFirst-Server-Verwaltungsservice und -Liveaktualisierungsservice sowie die MobileFirst-Laufzeit müssen in einem Anwendungsserver installiert werden. Das Kontextstammverzeichnis des Liveaktualisierungsservice wird wie folgt definiert: “Kontextstammverzeichnis_des_Verwaltungsserviceconfig”. Das Kontextstammverzeichnis des Push-Service muss imfpush sein. Weitere Informationen zu den Einschränkungen finden Sie unter Einschränkungen für die MobileFirst-Server-Komponenten und für MobileFirst Analytics.

Anwendungsservereinstellungen

Sie müssen das **Valve-Element für Single Sign-On ** aktivieren. Beispiel:

<Valve className="org.apache.catalina.authenticator.SingleSignOn"/>

Bei Bedarf können Sie das Speicherrealm aktivieren, wenn die Benutzer in tomcat-users.xml definiert sind. Beispiel:

```xml

  ``` #### Konfigurationsdetails

Der Verwaltungsservice wird als WAR-Anwendung bereitgestellt, die Sie im Anwendungsserver implementieren können. Sie müssen für diese Anwendung einige Konfigurationsschritte in der Datei server.xml des Anwendungsservers ausführen.

Informieren Sie sich unter Manuelle Installation in Apache Tomcat über die allgemeinen Konfigurationsdetails für alle Services, bevor Sie mit den hier beschriebenen Schritten fortfahren.

Die WAR-Datei für den Verwaltungsservice ist MFP-Installationsverzeichnis/MobileFirstServer/mfp-admin-service.war. Das Kontextstammverzeichnis können Sie ganz nach Wunsch festlegen. Normalerweise wird der Name /mfpadmin verwendet.

Obligatorische JNDI-Eigenschaften

Die JNDI-Eigenschaften werden im Element Environment des Anwendungskontexts definiert. Beispiel: 

<Environment name="mfp.admin.push.url" value="http://localhost:8080/imfpush" type="java.lang.String" override="false"/>

Wenn Sie die JMX-Kommunikation mit der Laufzeit ermöglichen wollen, definieren Sie die folgenden JNDI-Eigenschaften:

  • mfp.topology.platform
  • mfp.topology.clustermode

Wenn der Push-Service installiert ist, müssen Sie die folgenden JNDI-Eigenschaften konfigurieren:

  • mfp.admin.push.url
  • mfp.admin.authorization.server.url
  • mfp.push.authorization.client.id
  • mfp.push.authorization.client.secret
  • mfp.admin.authorization.client.id
  • mfp.admin.authorization.client.secret

Die JNDI-Eigenschaften für die Kommunikation mit dem Konfigurationsservice sind folgende:

  • mfp.config.service.user
  • mfp.config.service.password

Weitere Informationen zu den JNDI-Eigenschaften finden Sie in der Liste der JNDI-Eigenschaften für den MobileFirst-Server-Verwaltungsservice.

Datenquelle

Die Datenquelle (jdbc/mfpAdminDS) wird im Element **Context** als Ressource deklariert. Beispiel: 

<Resource name="jdbc/mfpAdminDS" type="javax.sql.DataSource" .../>

Sicherheitsrollen

Die für den Verwaltungsservice verfügbaren Sicherheitsrollen sind:

  • mfpadmin
  • mfpdeployer
  • mfpmonitor
  • mfpoperator

Der Liveaktualisierungsservice wird als WAR-Anwendung bereitgestellt, die Sie im Anwendungsserver implementieren können. Sie müssen für diese Anwendung einige Konfigurationsschritte in der Datei server.xml ausführen.

Informieren Sie sich unter Manuelle Installation in Apache Tomcat über die allgemeinen Konfigurationsdetails für alle Services, bevor Sie mit den hier beschriebenen Schritten fortfahren.

Die WAR-Datei für den Liveaktualisierungsservice ist MFP-Installationsverzeichnis/MobileFirstServer/mfp-live-update.war. Das Kontextstammverzeichnis des Liveaktualisierungsservice wird wie folgt definiert: "Kontextstammverzeichnis_des_Verwaltungsserviceconfig". Wenn das Kontextstammverzeichnis des Verwaltungsservice beispielsweise /mfpadmin ist, muss der Liveaktualisierungsservice das Kontextstammverzeichnis /mfpadminconfig haben.

Datenquelle

Als JNDI-Name der Datenquelle für den Liveaktualisierungsservice muss /jdbc/ConfigDS definiert werden. Deklarieren Sie die Datenquelle im Element Context als Ressource.

Sicherheitsrollen

Für den LIveaktualisierungsservice ist die Sicherheitsrolle configadmin verfügbar.

Dieser Rolle muss mindestens ein Benutzer zugeordnet sein. Der Benutzer und sein Kennwort müssen in den folgenden JNDI-Eigenschaften des Verwaltungsservice angegeben werden:

  • mfp.config.service.user
  • mfp.config.service.password

Die Konsole wird als WAR-Anwendung bereitgestellt, die Sie im Anwendungsserver implementieren können. Sie müssen für diese Anwendung einige Konfigurationsschritte in der Datei server.xml des Anwendungsservers ausführen.

Informieren Sie sich unter Manuelle Installation in Apache Tomcat über die allgemeinen Konfigurationsdetails für alle Services, bevor Sie mit den hier beschriebenen Schritten fortfahren.

Die WAR-Datei für die Konsole ist MFP-Installationsverzeichnis/MobileFirstServer/mfp-admin-ui.war. Das Kontextstammverzeichnis können Sie ganz nach Wunsch festlegen. Normalerweise wird der Name /mfpconsole verwendet.

Obligatorische JNDI-Eigenschaften

Sie müssen die Eigenschaft mfp.admin.endpoint definieren. Diese Eigenschaft hat normalerweise den Wert *://*:*/Kontextstammverzeichnis_des_Verwaltungsservice.

Weitere Informationen zu JNDI-Eigenschaften finden Sie unter JNDI-Eigenschaften für die MobileFirst Operations Console.

Sicherheitsrollen

Die für diese Anwendung verfügbaren Sicherheitsrollen sind:

  • mfpadmin
  • mfpdeployer
  • mfpmonitor
  • mfpoperator

Die Laufzeit wird als WAR-Anwendung bereitgestellt, die Sie im Anwendungsserver implementieren können. Sie müssen für diese Anwendung einige Konfigurationsschritte in der Datei server.xml ausführen.

Informieren Sie sich unter Manuelle Installation in Apache Tomcat über die allgemeinen Konfigurationsdetails für alle Services, bevor Sie mit den hier beschriebenen Schritten fortfahren.

Die WAR-Datei für die Laufzeit ist MFP-Installationsverzeichnis/MobileFirstServer/mfp-server.war. Das Kontextstammverzeichnis können Sie ganz nach Wunsch festlegen. Das Standardkontextstammverzeichnis ist /mfp.

Obligatorische JNDI-Eigenschaften

Sie müssen die Eigenschaft mfp.authorization.server definieren. Beispiel: 

<Environment name="mfp.authorization.server" value="embedded" type="java.lang.String" override="false"/>

Wenn Sie die JMX-Kommunikation mit dem Verwaltungsservice ermöglichen wollen, definieren Sie die folgenden JNDI-Eigenschaften:

  • mfp.topology.platform
  • mfp.topology.clustermode

Wenn MobileFirst Analytics installiert ist, müssen Sie die folgenden JNDI-Eigenschaften definieren:

  • mfp.analytics.url
  • mfp.analytics.console.url
  • mfp.analytics.username
  • mfp.analytics.password

Weitere Informationen zu den JNDI-Eigenschaften finden Sie in der Liste der JNDI-Eigenschaften für die MobileFirst-Laufzeit.

Datenquelle

Der JNDI-Name der Datenquelle für die Laufzeit muss wie folgt definiert werden: /jdbc/mfpDS. Deklarieren Sie die Datenquelle im Element Context als Ressource.

Der Push-Service wird als WAR-Anwendung bereitgestellt, die Sie im Anwendungsserver implementieren können. Sie müssen für diese Anwendung einige Konfigurationsschritte ausführen. Informieren Sie sich unter Manuelle Installation in Apache Tomcat über die allgemeinen Konfigurationsdetails für alle Services, bevor Sie mit den hier beschriebenen Schritten fortfahren.

Die WAR-Datei für den Push-Service ist MFP-Installationsverzeichnis/PushService/mfp-push-service.war. Sie müssen /imfpush als Kontextstammverzeichnis festlegen. Andernfalls können die Clientgeräte keine Verbindung zu dem Service herstellen, denn das Kontextstammverzeichnis ist im SDK fest codiert.

Obligatorische JNDI-Eigenschaften

Sie müssen die folgenden Eigenschaften definieren:

  • mfp.push.authorization.server.url
  • mfp.push.authorization.client.id
  • mfp.push.authorization.client.secret
  • mfp.push.services.ext.security: Der Wert muss com.ibm.mfp.push.server.security.plugin.OAuthSecurityPlugin lauten.
  • mfp.push.db.type: Der Wert für eine relationale Datenbank muss DB sein.

Wenn MobileFirst Analytics konfiguriert ist, definieren Sie die folgenden JNDI-Eigenschaften:

  • mfp.push.analytics.endpoint
  • mfp.analytics.username
  • mfp.analytics.password
  • mfp.push.services.ext.analytics: Der Wert muss com.ibm.mfp.push.server.analytics.plugin.AnalyticsPlugin lauten.
Weitere Informationen zu den JNDI-Eigenschaften finden Sie in der Liste der JNDI-Eigenschaften für den MobileFirst-Server-Push-Service.

Die Artefaktkomponente wird als WAR-Anwendung bereitgestellt, die Sie im Anwendungsserver implementieren können. Sie müssen für diese Anwendung einige Konfigurationsschritte in der Datei server.xml des Anwendungsservers ausführen. Informieren Sie sich unter Manuelle Installation in Apache Tomcat über die allgemeinen Konfigurationsdetails für alle Services, bevor Sie mit den hier beschriebenen Schritten fortfahren.

Die WAR-Datei für diese Komponente ist MFP-Installationsverzeichnis/MobileFirstServer/mfp-dev-artifacts.war. Sie müssen /mfp-dev-artifacts als Kontextstammverzeichnis festlegen.

Manuelle Installation in WebSphere Application Server und WebSphere Application Server Network Deployment

Vergewissern Sie sich, dass die unter Voraussetzungen für WebSphere Application Server und WebSphere Application Server Network Deployment dokumentierten Voraussetzungen erfüllt sind.

Topologieeinschränkungen

Eigenständiger WebSphere Application Server
Der MobileFirst-Server-Verwaltungsservice und -Liveaktualisierungsservice sowie die MobileFirst-Laufzeit müssen in einem Anwendungsserver installiert werden. Das Kontextstammverzeichnis des Liveaktualisierungsservice wird wie folgt definiert: “Kontextstammverzeichnis_des_Verwaltungsserviceconfig”. Das Kontextstammverzeichnis des Push-Service muss imfpush sein. Weitere Informationen zu den Einschränkungen finden Sie unter Einschränkungen für die MobileFirst-Server-Komponenten und für MobileFirst Analytics.

WebSphere Application Server Network Deployment
Der Deployment Manager muss aktiv sein, wenn MobileFirst Server ausgeführt wird. Der Deployment Manager wird für die JMX-Kommunikation zwischen der Laufzeit und dem Verwaltungsservice verwendet. Der Verwaltungsservice und der Liveaktualisierungsservice müssen in demselben Anwendungsserver installiert sein. Die Laufzeit kann in einem anderen Server als der Verwaltungsservice installiert werden. Dieser andere Server muss sich jedoch in derselben Zelle befinden.

Anwendungsservereinstellungen

Die Verwaltungssicherheit und die Anwendungssicherheit müssen aktiviert sein. Sie können die Anwendungssicherheit in der Administrationskonsole von WebSphere Application Server aktivieren:

  1. Melden Sie sich bei der Administrationskonsole von WebSphere Application Server an.
  2. Klicken Sie auf Sicherheit → Globale Sicherheit. Stellen Sie sicher, dass die Option Verwaltungssicherheit aktivieren ausgewählt ist.

  3. Stellen Sie sicher, dass die Option Anwendungssicherheit aktivieren ausgewählt ist. Die Anwendungssicherheit kann nur aktiviert werden, wenn die Verwaltungssicherheit aktiviert ist.

  4. Klicken Sie auf OK.
  5. Speichern Sie die Änderungen.

Weitere Informationen finden Sie in der Dokumentation zu WebSphere Application Server unter Sicherheit aktivieren .

Die Klassenladerrichtlinie des Servers muss die Delegierung “übergeordneter zuletzt” unterstützen. Die WAR-Dateien von MobileFirst Server müssen im Klassenladermodus “übergeordneter zuletzt” installiert werden. Überprüfen Sie wie folgt die Klassenladerrichtlinie:

  1. Melden Sie sich bei der Administrationskonsole von WebSphere Application Server an.
  2. Klicken Sie auf Server → Servertypen → WebSphere-Anwendungsserver und wählen Sie den für die Mobile Foundation verwendeten Server aus.
  3. Wenn die Klassenladerrichtlinie auf Mehrere gesetzt ist, müssen Sie nichts tun.
  4. Wenn die Klassenladerrichtlinie auf Einer und der Modus für das Laden von Klassen auf Mit dem lokalen Klassenlader geladene Klassen zuerst (übergeordneter zuletzt) gesetzt ist, müssen Sie nichts tun.
  5. Wenn die Klassenladerrichtlinie auf Einer und der Modus für das Laden von Klassen auf Mit dem übergeordneten Klassenlader geladene Klassen zuerst gesetzt ist, ändern Sie die Klassenladerrichtlinie in Mehrere. Setzen Sie außerdem die Reihenfolge der Klassenlader aller Anwendungen mit Ausnahme der MobileFirst-Server-Anwendungen auf Mit dem übergeordneten Klassenlader geladene Klassen zuerst.

Klassenladeprogramm

Das Klassenladeprogramm für alle MobileFirst-Server-Anwendungen muss mit der Delegierung “Übergeordnete zuletzt” (parentLast) arbeiten.

Wenn Sie die Delegierung des Klassenladeprogramms nach der Installation einer Anwendung auf “übergeordneter zuletzt” setzen wollen, gehen Sie wie folgt vor:

  1. Klicken Sie auf den Link Anwendungen verwalten oder klicken Sie auf Anwendungen → Anwendungstypen → WebSphere-Unternehmensanwendungen.
  2. Klicken Sie auf die MobileFirst-Server-Anwendung. Der Name der Anwendung ist standardmäßig der Name der WAR-Datei.
  3. Klicken Sie im Abschnitt Detaileigenschaften auf den Link Laden von Klassen und Erkennung von Dateiaktualisierungen.
  4. Wählen Sie im Fenster Reihenfolge der Klassenlader die Option Mit dem lokalen Klassenlader geladene Klassen zuerst (übergeordneter zuletzt) aus.
  5. Klicken Sie auf OK.
  6. Klicken Sie im Abschnitt Module auf den Link Module verwalten.

  7. Klicken Sie auf das Modul.

  8. Wählen Sie für das Feld Reihenfolge der Klassenlader die Option Mit dem lokalen Klassenlader geladene Klassen zuerst (übergeordneter zuletzt) aus.
  9. Klicken Sie zweimal auf OK, um die Auswahl zu bestätigen und zum Fenster Konfiguration für die Anwendung zurückzugelangen.
  10. Klicken Sie auf Speichern, um die Änderungen dauerhaft zu speichern.

Konfigurationsdetails

Der Verwaltungsservice wird als WAR-Anwendung bereitgestellt, die Sie im Anwendungsserver implementieren können. Sie müssen für diese Anwendung einige Konfigurationsschritte in der Datei server.xml des Anwendungsservers ausführen.

Informieren Sie sich unter Manuelle Installation in WebSphere Application Server und WebSphere Application Server Network Deployment über die allgemeinen Konfigurationsdetails für alle Services, bevor Sie mit den hier beschriebenen Schritten fortfahren.

Die WAR-Datei für den Verwaltungsservice ist MFP-Installationsverzeichnis/MobileFirstServer/mfp-admin-service.war. Das Kontextstammverzeichnis können Sie ganz nach Wunsch festlegen. Normalerweise wird der Name /mfpadmin verwendet.

Obligatorische JNDI-Eigenschaften

Sie können JNDI-Eigenschaften in der Administrationskonsole von WebSphere Application Server-Administration festlegen. Navigieren Sie zu Anwendungen → Anwendungstypen → WebSphere-Unternehmensanwendungen → Anwendungsname → Umgebungseinträge für Webmodule und legen Sie die Einträge fest.

Wenn Sie die JMX-Kommunikation mit der Laufzeit ermöglichen wollen, definieren Sie die folgenden JNDI-Eigenschaften:

WebSphere Application Server Network Deployment
  • mfp.admin.jmx.dmgr.host
  • mfp.admin.jmx.dmgr.port: SOAP-Port des Deployment Manager
  • mfp.topology.platform: Legen Sie den Wert WAS fest.
  • mfp.topology.clustermode: Legen Sie den Wert Cluster fest.
  • mfp.admin.jmx.connector: Legen Sie den Wert SOAP fest.
Eigenständiger WebSphere Application Server
  • mfp.topology.platform: Legen Sie den Wert WAS fest.
  • mfp.topology.clustermode: Legen Sie den Wert Standalone fest.
  • mfp.admin.jmx.connector: Legen Sie den Wert SOAP fest.

Wenn der Push-Service installiert ist, müssen Sie die folgenden JNDI-Eigenschaften konfigurieren:

  • mfp.admin.push.url
  • mfp.admin.authorization.server.url
  • mfp.push.authorization.client.id
  • mfp.push.authorization.client.secret
  • mfp.admin.authorization.client.id
  • mfp.admin.authorization.client.secret

Die JNDI-Eigenschaften für die Kommunikation mit dem Konfigurationsservice sind folgende:

  • mfp.config.service.user
  • mfp.config.service.password

Weitere Informationen zu den JNDI-Eigenschaften finden Sie in der Liste der JNDI-Eigenschaften für den MobileFirst-Server-Verwaltungsservice.

Datenquelle

Erstellen Sie eine Datenquelle für den Verwaltungsservice und ordnen Sie sie jdbc/mfpAdminDS zu.

Startreihenfolge

Der Verwaltungsservice muss vor der Laufzeit gestartet werden. Sie können die Reihenfolge im Abschnitt Startverhalten festlegen. Setzen Sie die Position in der Startreihenfolge für den Verwaltungsservice beispielsweise auf 1 und für die Laufzeit auf 2.

Sicherheitsrollen

Die für den Verwaltungsservice verfügbaren Sicherheitsrollen sind:

  • mfpadmin
  • mfpdeployer
  • mfpmonitor
  • mfpoperator

Der Liveaktualisierungsservice wird als WAR-Anwendung bereitgestellt, die Sie im Anwendungsserver implementieren können. Sie müssen für diese Anwendung einige Konfigurationsschritte in der Datei server.xml ausführen.

Informieren Sie sich unter Manuelle Installation in WebSphere Application Server und WebSphere Application Server Network Deployment über die allgemeinen Konfigurationsdetails für alle Services, bevor Sie mit den hier beschriebenen Schritten fortfahren.

Die WAR-Datei für den Liveaktualisierungsservice ist MFP-Installationsverzeichnis/MobileFirstServer/mfp-live-update.war. Das Kontextstammverzeichnis des Liveaktualisierungsservice wird wie folgt definiert: "Kontextstammverzeichnis_des_Verwaltungsserviceconfig". Wenn das Kontextstammverzeichnis des Verwaltungsservice beispielsweise /mfpadmin ist, muss der Liveaktualisierungsservice das Kontextstammverzeichnis /mfpadminconfig haben.

Datenquelle

Erstellen Sie eine Datenquelle für den Liveaktualisierungsservice und ordnen Sie sie jdbc/ConfigDS zu.

Sicherheitsrollen

Für diese Anwendung ist die Rolle configadmin definiert.

Dieser Rolle muss mindestens ein Benutzer zugeordnet sein. Der Benutzer und sein Kennwort müssen in den folgenden JNDI-Eigenschaften des Verwaltungsservice angegeben werden:

  • mfp.config.service.user
  • mfp.config.service.password

Die Konsole wird als WAR-Anwendung bereitgestellt, die Sie im Anwendungsserver implementieren können. Sie müssen für diese Anwendung einige Konfigurationsschritte in der Datei server.xml des Anwendungsservers ausführen.

Informieren Sie sich unter Manuelle Installation in WebSphere Application Server und WebSphere Application Server Network Deployment über die allgemeinen Konfigurationsdetails für alle Services, bevor Sie mit den hier beschriebenen Schritten fortfahren.

Die WAR-Datei für die Konsole ist MFP-Installationsverzeichnis/MobileFirstServer/mfp-admin-ui.war. Das Kontextstammverzeichnis können Sie ganz nach Wunsch festlegen. Normalerweise wird der Name /mfpconsole verwendet.

Obligatorische JNDI-Eigenschaften

Sie können JNDI-Eigenschaften in der Administrationskonsole von WebSphere Application Server-Administration festlegen. Navigieren Sie zu Anwendungen → Anwendungstypen → WebSphere-Unternehmensanwendungen → Anwendungsname → Umgebungseinträge für Webmodule und legen Sie die Einträge fest.

Sie müssen die Eigenschaft mfp.admin.endpoint definieren. Diese Eigenschaft hat normalerweise den Wert *://*:*/Kontextstammverzeichnis_des_Verwaltungsservice.

Weitere Informationen zu JNDI-Eigenschaften finden Sie unter JNDI-Eigenschaften für die MobileFirst Operations Console.

Sicherheitsrollen

Die für diese Anwendung verfügbaren Sicherheitsrollen sind:

  • mfpadmin
  • mfpdeployer
  • mfpmonitor
  • mfpoperator
Jeder Benutzer, der einer Sicherheitsrolle der Konsole zugeordnet ist, muss der gleichen Sicherheitsrolle des Verwaltungsservice zugeordnet sein.

Die Laufzeit wird als WAR-Anwendung bereitgestellt, die Sie im Anwendungsserver implementieren können. Sie müssen für diese Anwendung einige Konfigurationsschritte in der Datei server.xml ausführen.

Informieren Sie sich unter Manuelle Installation in WebSphere Application Server und WebSphere Application Server Network Deployment über die allgemeinen Konfigurationsdetails für alle Services, bevor Sie mit den hier beschriebenen Schritten fortfahren.

Die WAR-Datei für die Laufzeit ist MFP-Installationsverzeichnis/MobileFirstServer/mfp-server.war. Das Kontextstammverzeichnis können Sie ganz nach Wunsch festlegen. Das Standardkontextstammverzeichnis ist /mfp.

Obligatorische JNDI-Eigenschaften

Sie können JNDI-Eigenschaften in der Administrationskonsole von WebSphere Application Server-Administration festlegen. Navigieren Sie zu Anwendungen → Anwendungstypen → WebSphere-Unternehmensanwendungen → Anwendungsname → Umgebungseinträge für Webmodule und legen Sie die Einträge fest.

Sie müssen die Eigenschaft mfp.authorization.server mit dem Wert "embedded" definieren.
Wenn Sie die JMX-Kommunikation mit dem Verwaltungsservice ermöglichen wollen, definieren Sie außerdem die folgenden JNDI-Eigenschaften:

WebSphere Application Server Network Deployment
  • mfp.admin.jmx.dmgr.host: Hostname des Deployment Manager
  • mfp.admin.jmx.dmgr.port: SOAP-Port des Deployment Manager
  • mfp.topology.platform: Legen Sie den Wert WAS fest.
  • mfp.topology.clustermode: Legen Sie den Wert Cluster fest.
  • mfp.admin.jmx.connector: Legen Sie den Wert SOAP fest.
Eigenständiger WebSphere Application Server
  • mfp.topology.platform: Legen Sie den Wert WAS fest.
  • mfp.topology.clustermode: Legen Sie den Wert Standalone fest.
  • mfp.admin.jmx.connector: Legen Sie den Wert SOAP fest.

Wenn MobileFirst Analytics installiert ist, müssen Sie die folgenden JNDI-Eigenschaften definieren:

  • mfp.analytics.url
  • mfp.analytics.console.url
  • mfp.analytics.username
  • mfp.analytics.password

Weitere Informationen zu den JNDI-Eigenschaften finden Sie in der Liste der JNDI-Eigenschaften für die MobileFirst-Laufzeit.

Startreihenfolge

Die Laufzeit muss nach dem Verwaltungsservice gestartet werden. Sie können die Reihenfolge im Abschnitt Startverhalten festlegen. Setzen Sie die Position in der Startreihenfolge für den Verwaltungsservice beispielsweise auf 1 und für die Laufzeit auf 2.

Datenquelle

Erstellen Sie eine Datenquelle für die Laufzeit und ordnen Sie sie jdbc/mfpDS zu.

Der Push-Service wird als WAR-Anwendung bereitgestellt, die Sie im Anwendungsserver implementieren können. Sie müssen für diese Anwendung einige Konfigurationsschritte ausführen. Informieren Sie sich unter Manuelle Installation in WebSphere Application Server und WebSphere Application Server Network Deployment über die allgemeinen Konfigurationsdetails für alle Services, bevor Sie mit den hier beschriebenen Schritten fortfahren.

Die WAR-Datei für den Push-Service ist MFP-Installationsverzeichnis/PushService/mfp-push-service.war. Sie müssen /imfpush als Kontextstammverzeichnis festlegen. Andernfalls können die Clientgeräte keine Verbindung zu dem Service herstellen, denn das Kontextstammverzeichnis ist im SDK fest codiert.

Obligatorische JNDI-Eigenschaften

Sie können JNDI-Eigenschaften in der Administrationskonsole von WebSphere Application Server-Administration festlegen. Navigieren Sie zu Anwendungen → Anwendungstypen → WebSphere-Unternehmensanwendungen → Anwendungsname → Umgebungseinträge für Webmodule und legen Sie die Einträge fest.

Sie müssen die folgenden Eigenschaften definieren:

  • mfp.push.authorization.server.url
  • mfp.push.authorization.client.id
  • mfp.push.authorization.client.secret
  • mfp.push.services.ext.security: Der Wert muss com.ibm.mfp.push.server.security.plugin.OAuthSecurityPlugin lauten.
  • mfp.push.db.type: Der Wert für eine relationale Datenbank muss DB sein.

Wenn MobileFirst Analytics konfiguriert ist, definieren Sie die folgenden JNDI-Eigenschaften:

  • mfp.push.analytics.endpoint
  • mfp.analytics.username
  • mfp.analytics.password
  • mfp.push.services.ext.analytics: Der Wert muss com.ibm.mfp.push.server.analytics.plugin.AnalyticsPlugin lauten.

Weitere Informationen zu den JNDI-Eigenschaften finden Sie in der Liste der JNDI-Eigenschaften für den MobileFirst-Server-Push-Service.

Datenquelle

Erstellen Sie die Datenquelle für den Push-Service und ordnen Sie sie jdbc/imfPushDS zu.

Die Artefaktkomponente wird als WAR-Anwendung bereitgestellt, die Sie im Anwendungsserver implementieren können. Sie müssen für diese Anwendung einige Konfigurationsschritte in der Datei server.xml des Anwendungsservers ausführen. Informieren Sie sich unter Manuelle Installation in WebSphere Application Server und WebSphere Application Server Network Deployment über die allgemeinen Konfigurationsdetails für alle Services, bevor Sie mit den hier beschriebenen Schritten fortfahren.

Die WAR-Datei für diese Komponente ist MFP-Installationsverzeichnis/MobileFirstServer/mfp-dev-artifacts.war. Sie müssen /mfp-dev-artifacts als Kontextstammverzeichnis festlegen.

Server-Farm installieren

Sie können Ihre Server-Farm mit Ant-Tasks, mit dem Server Configuration Tool oder manuell installieren.

Konfiguration einer Server-Farm planen

Zum Planen der Konfiguration einer Server-Farm müssen Sie den Anwendungsserver wählen, die MobileFirst-Datenbanken konfigurieren und die WAR-Dateien der MobileFirst-Server-Komponenten auf jedem Server der Farm implementieren. Sie können entscheiden, ob Sie das Server Configuration Tool, Ant-Tasks oder manuelle Operationen ausführen wollen, um die Server-Farm zu konfigurieren.

Wenn Sie die Installation einer Server-Farm planen, lesen Sie zuerst die Informationen unter Einschränkungen für den MobileFirst-Server-Verwaltungsservice und -Liveaktualisierungsservice sowie für die MobileFirst-Laufzeit und insbesondere im Abschnitt Server-Farmtopologie.

In der Mobile Foundation setzt sich eine Server-Farm aus mehreren eigenständigen Anwendungsservern zusammen, die weder eingebunden sind, noch von einer verwaltenden Komponente eines Anwendungsservers verwaltet werden. MobileFirst Server stellt intern ein Farm-Plug-in als Mittel für die Erweiterung eines Anwendungsservers bereit, sodass dieser als Member in eine Server-Farm aufgenommen werden kann.

Deklaration einer Server-Farm

Deklarieren Sie in den folgenden Fällen eine Server-Farm:

  • MobileFirst Server wird in mehreren Tomcat-Anwendungsservern installiert.
  • MobileFirst Server wird auf mehreren Servern mit WebSphere Application Server, jedoch nicht in WebSphere Application Server Network Deployment installiert.
  • MobileFirst Server wird auf mehreren Servern mit WebSphere Application Server Liberty installiert.

Deklarieren Sie in den folgenden Fällen keine Server-Farm:

  • Ihr Anwendungsserver ist eigenständig.
  • Es werden mehrere Anwendungsserver mithilfe von WebSphere Application Server Network Deployment eingebunden.

Warum muss eine Farm deklariert werden?

Jedes Mal, wenn in der MobileFirst Operations Console oder mithilfe der MobileFirst-Server-Verwaltungsservices eine Verwaltungsoperation ausgeführt wird, muss diese Operation in allen Instanzen einer Laufzeit repliziert werden. Ein Beispiel für eine solche Verwaltungsoperation ist das Hochladen einer neuen Version einer App oder eines Adapters. Die Replikation erfolgt über JMX-Aufrufe, die von der Instanz der Verwaltungsservices, die die Operation verarbeitet, ausgeführt werden. Der Verwaltungsservice muss Kontakt zu allen Laufzeitinstanzen im Cluster aufnehmen. In den Umgebungen, die oben unter Deklaration einer Server-Farm aufgelistet sind, kann nur mit JMX Kontakt zur Laufzeit aufgenommen werden, wenn eine Farm konfiguriert ist. Wenn ohne ordnungsgemäße Konfiguration der Farm ein Server zu einem Cluster hinzugefügt wird, befindet sich die Laufzeit dieses Servers nach jeder Verwaltungsoperation in einem inkonsistenten Zustand, bis der Server neu gestartet wird.

Server-Farm mit dem Server Configuration Tool installieren

Mit dem Server Configuration Tool können Sie jeden Server in der Farm gemäß den Anforderungen eines einzelnen Anwendungsservers konfigurieren, der für jedes Member der Server-Farm verwendet wird.

Wenn Sie mit dem Server Configuration Tool eine Server-Farm installieren möchten, erstellen Sie zunächst eigenständige Server und konfigurieren Sie die Truststores dieser Server für eine sichere gegenseitige Kommunikation. Mit dem Tool führen Sie dann die folgenden Operationen aus:

  • Gemeinsame Datenbankinstanz für die MofileFirst-Server-Komponenten konfigurieren
  • MobileFirst-Server-Komponenten auf den einzelnen Servern implementieren
  • Konfiguration des Servers so modifizieren, dass der Server ein Member der Server-Farm wird

MobileFirst Server setzt die Konfiguration einer sicheren JMX-Verbindung voraus.

  1. Bereiten Sie die Anwendungsserver vor, die als Server-Farmmember konfiguriert werden sollen.
    • Wählen Sie zum Konfigurieren der Member der Server-Farm den Anwendungsservertyp aus. Die Mobile Foundation unterstützt in Server-Farmen die folgenden Anwendungsserver:
      • WebSphere Application Server Full Profile
        Hinweis: In einer Farmtopologie können Sie den RMI-JMX-Connector nicht verwenden. In dieser Topologie unterstützt die Mobile Foundation nur den SOAP-Connector.
      • WebSphere Application Server Liberty Profile
      • Apache Tomcat
      Informationen zu den unterstützten Versionen der Anwendungsserver finden Sie in den Systemvoraussetzungen.
      Wichtiger Hinweis: Die Mobile Foundation unterstützt nur homogene Server-Farmen. Eine Server-Farm wird als homogen eingestuft, wenn sie Anwendungsserver desselben Typs miteinander verbindet. Der Versuch, unterschiedliche Typen von Anwendungsservern zuzuordnen, könnte zur Laufzeit zu einem unvorhersehbaren Verhalten führen. Eine Farm von Tomcat-Servern und Servern mit WebSphere Application Server Full Profile ist beispielsweise eine ungültige Konfiguration.
    • Richten Sie so viele eigenständige Server ein, wie Sie Member in der Farm benötigen.
      • Jeder dieser eigenständigen Server muss mit derselben Datenbank kommunizieren. Sie müssen sicherstellen, dass jeder von diesen Servern verwendete Port nicht von einem anderen Server, der auf demselben Host konfiguriert ist, verwendet wird. Diese Beschränkung gilt für die Ports, die von den Protokollen HTTP, HTTPS, REST, SOAP und RMI verwendet werden.
      • In jedem dieser Server müssen der MobileFirst-Server-Verwaltungsservice, der MobileFirst-Server-Liveaktualisierungsservice und mindestens eine MobileFirst-Laufzeit implementiert sein.
      • Witere Informationen zum Einrichten eines Servers finden Sie unter Einschränkungen für den MobileFirst-Server-Verwaltungsservice und -Liveaktualisierungsservice sowie für die MobileFirst-Laufzeit.
    • Tauschen Sie die Unterzeichnerzertifikate aus, die sich im Truststore der einzelnen Server befinden.

      Hinweis: Dieser Schritt ist für Farmen obligatorisch, die WebSphere Application Server Full Profile oder Liberty verwenden, da die Sicherheit aktiviert sein muss. Bei Liberty-Farmen muss außerdem die LTPA-Konfiguration auf jedem Server repliziert werden, damit das Single Sign-on funktioniert. Folgen Sie für diese Konfugration der Anleitung in Schritt 6 unter Server-Farm manuell konfigurieren.
  2. Führen Sie das Server Configuration Tool für jeden Server der Farm aus. Alle Server müssen dieselben Datenbanken verwenden. In der Anzeige Application Server Settings müssen Sie den Implementierungstyp Server Farm Deployment auswählen. Weitere Informationen zum Tool finden Sie unter Server Configuration Tool ausführen.

Server-Farm mit Ant-Tasks installieren

Mit Ant-Tasks können Sie jeden Server in der Farm gemäß den Anforderungen eines einzelnen Anwendungsservers konfigurieren, der für jedes Member der Server-Farm verwendet wird.

Wenn Sie mit Ant-Tasks eine Server-Farm installieren möchten, erstellen Sie zunächst eigenständige Server und konfigurieren Sie die Truststores dieser Server für eine sichere gegenseitige Kommunikation. Führen Sie dann Ant-Tasks aus, um die gemeinsame Datenbankinstanz für die MofileFirst-Server-Komponenten zu konfigurieren. Abschließend müssen Sie Ant-Tasks ausführen, um die MobileFirst-Server-Komponenten auf jedem Server zu implementieren und die Konfiguration der einzelnen Server so zu modifizieren, dass sie Member der Server-Farm werden.

MobileFirst Server setzt die Konfiguration einer sicheren JMX-Verbindung voraus.

  1. Bereiten Sie die Anwendungsserver vor, die als Server-Farmmember konfiguriert werden sollen.
    • Wählen Sie zum Konfigurieren der Member der Server-Farm den Anwendungsservertyp aus. Die Mobile Foundation unterstützt in Server-Farmen die folgenden Anwendungsserver:
      • WebSphere Application Server Full Profile. Hinweis: In einer Farmtopologie können Sie den RMI-JMX-Connector nicht verwenden. In dieser Topologie unterstützt die Mobile Foundation nur den SOAP-Connector.
      • WebSphere Application Server Liberty Profile
      • Apache Tomcat
      Informationen zu den unterstützten Versionen der Anwendungsserver finden Sie in den Systemvoraussetzungen.
      Wichtiger Hinweis: Die Mobile Foundation unterstützt nur homogene Server-Farmen. Eine Server-Farm wird als homogen eingestuft, wenn sie Anwendungsserver desselben Typs miteinander verbindet. Der Versuch, unterschiedliche Typen von Anwendungsservern zuzuordnen, könnte zur Laufzeit zu einem unvorhersehbaren Verhalten führen. Eine Farm von Tomcat-Servern und Servern mit WebSphere Application Server Full Profile ist beispielsweise eine ungültige Konfiguration.
    • Richten Sie so viele eigenständige Server ein, wie Sie Member in der Farm benötigen.

      Jeder dieser eigenständigen Server muss mit derselben Datenbank kommunizieren. Sie müssen sicherstellen, dass jeder von diesen Servern verwendete Port nicht von einem anderen Server, der auf demselben Host konfiguriert ist, verwendet wird. Diese Beschränkung gilt für die Ports, die von den Protokollen HTTP, HTTPS, REST, SOAP und RMI verwendet werden.

      In jedem dieser Server müssen der MobileFirst-Server-Verwaltungsservice, der MobileFirst-Server-Liveaktualisierungsservice und mindestens eine MobileFirst-Laufzeit implementiert sein.

      Weitere Informationen zum Einrichten eines Servers finden Sie unter Einschränkungen für den MobileFirst-Server-Verwaltungsservice und -Liveaktualisierungsservice sowie für die MobileFirst-Laufzeit.
    • Tauschen Sie die Unterzeichnerzertifikate aus, die sich im Truststore der einzelnen Server befinden.

      Hinweis: Dieser Schritt ist für Farmen obligatorisch, die WebSphere Application Server Full Profile oder Liberty verwenden, da die Sicherheit aktiviert sein muss. Bei Liberty-Farmen muss außerdem die LTPA-Konfiguration auf jedem Server repliziert werden, damit das Single Sign-on funktioniert. Folgen Sie für diese Konfugration der Anleitung in Schritt 6 unter Server-Farm manuell konfigurieren
      .
  2. Konfigurieren Sie die Datenbank für den Verwaltungs- und Liveaktualisierungsservice und für die Laufzeit.
    • Entscheiden Sie, welche Datenbank verwendet werden soll, und wählen Sie die Ant-Task zum Erstellen und Konfigurieren der Datenbank im Verzeichnis MFP-Installationsverzeichnis/MobileFirstServer/configuration-samples aus.
      • Verwenden Sie für DB2 create-database-db2.xml.
      • Verwenden Sie für MySQL create-database-mysql.xml.
      • Verwenden Sie für Oracle create-database-oracle.xml.
      Hinweis: Verwenden Sie nicht die Derby-Datenbank in einer Farmtopologie, weil die Derby-Datenbank immer nur jeweils eine Verbindung erlaubt.
    • Bearbeiten Sie die Ant-Datei und geben Sie alle erforderlichen Eigenschaften für die Datenbank ein.

      Legen Sie für die Konfiguration der von den MobileFirst-Server-Komponenten verwendeten Datenbank Werte für die folgenden Eigenschaften fest:
      • Setzen Sie mfp.process.admin auf true, um die Datenbank für den Verwaltungs- und Liveaktualisierungsservice zu konfigurieren.
      • Setzen Sie mfp.process.runtime auf true, um die Datenbank für die Laufzeit zu konfigurieren.
    • Führen Sie die folgenden Befehle im Verzeichnis MFP-Installationsverzeichnis/MobileFirstServer/configuration-samples aus. Ersetzen Sie die Datei create-database-ant-file.xml durch den Namen der von Ihnen gewählten Ant-Datei. MFP-Installationsverzeichnis/shortcuts/ant -f create-database-ant-file.xml admdatabases und MFP-Installationsverzeichnis/shortcuts/ant -f create-database-ant-file.xml rtmdatabases.

      Da die MobileFirst-Server-Datenbanken von den Anwendungsservern einer Farm gemeinsam genutzt werden, müssen diese beiden Befehle unabhängig von der Anzahl der Server in der Farm nur einmal ausgeführt werden.
    • Wenn Sie eine weitere Laufzeit installieren möchten, müssen Sie eine weitere Datenbank mit einem anderen Datenbanknamen oder -schema konfigurieren. Bearbeiten Sie dazu die Ant-Datei. Modifizieren Sie die Eigenschaften und führen Sie den folgenden Befehl unabhängig von der Anzahl der Farm-Server einmal aus: MFP-Installationsverzeichnis/shortcuts/ant -f create-database-ant-file.xml rtmdatabases.
  3. Implementieren Sie den Verwaltungsservice, den Liveaktualisierungsservice und die Laufzeit auf den Servern und konfigurieren Sie die Server als Member einer Server-Farm.
    • Wählen Sie im Verzeichnis MFP-Installationsverzeichnis/MobileFirstServer/configuration-samples die zu Ihrem Anwendungsserver und zu Ihrer Datenbank passende Ant-Datei aus, um den Verwaltungsservice, den Liveaktualisierungsservice und die Laufzeit auf den Servern zu implementieren.

      Wählen Sie beispielsweise für eine Implementierung auf einem Liberty-Server mit DB2-Datenbank die Datei configure-liberty-db2.xml aus. Erstellen Sie für jedes Farmmember eine Kopie dieser Datei.

      Hinweis: Bewahren Sie diese Dateien nach dem Konfigurieren auf. Sie können sie später wiederverwenden, wenn Sie ein Upgrade für die bereits implementierten MobileFirst-Server-Komponenten durchführen oder die Komponenten auf den Farmmembern deinstallieren.
    • Bearbeiten Sie jede Kopie der Ant-Datei. Geben Sie die Eigenschaften für die Datenbank ein, die Sie in Schritt 2 verwendet haben. Geben Sie zusätzlich die erforderlichen Eigenschaften für den Anwendungsserver ein.

      Wenn Sie den Server als ein Server-Farmmember konfigurieren möchten, legen Sie die Werte für die folgenden Eigenschaften fest:
      • Setzen Sie mfp.farm.configure auf true.
      • mfp.farm.server.id: Eine Kennung, die Sie für dieses Farmmember definieren. Jeder Server in der Farm muss eine eigene, eindeutige Kennung haben. Wenn zwei Server der Farm die gleiche Kennung haben, könnte sich die Farm unvorhersehbar verhalten.
      • mfp.config.service.user: Benutzername für den Zugriff auf den Liveaktualisierungsservice. Der Benutzername muss für alle Member der Farm der gleiche sein.
      • mfp.config.service.password: Kennwort für den Zugriff auf den Liveaktualisierungsservice. Das Kennwort muss für alle Member der Farm das gleiche sein.
      Legen Sie für die Implementierung der WAR-Dateien der MobileFirst-Server-Komponenten auf dem Server Werte für die folgenden Eigenschaften fest:
      • Setzen Sie mfp.process.admin auf true, um die WAR-Dateien für den Verwaltungs- und Liveaktualisierungsservice zu implementieren.
      • Setzen Sie mfp.process.runtime auf true, um die WAR-Datei für die Laufzeit zu implementieren.

      Hinweis:Wenn Sie auf den Servern der Farm mehr als eine Laufzeit installieren wollen, geben Sie das Attribut "id" an und setzen Sie das Attribut in den Ant-Tasks installmobilefirstruntime, updatemobilefirstruntime und uninstallmobilefirstruntime auf einen für jede Laufzeit eindeutigen Wert.
      Beispiel: 
      <target name="rtminstall">
    <installmobilefirstruntime execute="true" contextroot="/runtime1" id="rtm1">
    • Führen Sie für jeden Server die folgenden Befehle aus. Ersetzen Sie die Datei configure-appserver-database-ant-file.xml durch den Namen der von Ihnen gewählten Ant-Datei. MFP-Installationsverzeichnis/shortcuts/ant -f configure-appserver-database-ant-file.xml adminstall und MFP-Installationsverzeichnis/shortcuts/ant -f configure-appserver-database-ant-file.xml rtminstall

      Mit diesen Befehlen werden die Ant-Tasks installmobilefirstadmin und installmobilefirstruntime ausgeführt. Weitere Informationen zu diesen Tasks finden Sie unter Ant tasks for installation of MobileFirst Operations Console, MobileFirst Server artifacts, MobileFirst Server administration, and live update services and Ant-Tasks für die Installation von MobileFirst-Laufzeitumgebungen.
    • Wenn Sie eine weitere Laufzeit installieren möchten, führen Sie die folgenden Schritte aus:
      • Erstellen Sie eine Kopie der Ant-Datei, die Sie in Schritt 3.b konfiguriert haben.
      • Bearbeiten Sie die Kopie. Legen Sie ein eindeutiges Kontextstammverzeichnis fest und setzen Sie das Attributid für installmobilefirstruntime, updatemobilefirstruntime und uninstallmobilefirstruntime auf einen Wert, der sich von dem der anderen Laufzeitkonfiguration unterscheidet.
      • Führen Sie auf jedem Server der Farm den folgenden Befehl aus. Ersetzen Sie configure-appserver-database-ant-file2.xml durch den Namen der von Ihnen bearbeiteten Ant-Datei: MFP-Installationsverzeichnis/shortcuts/ant -f configure-appserver-database-ant-file2.xml rtminstall.
      • Wiederholen Sie diesen Schritt für jeden Server der Farm.
  4. Führen Sie für alle Server einen Neustart durch.

Server-Farm manuell konfigurieren

Sie müssen jeden Server in der Farm gemäß den Anforderungen eines einzelnen Anwendungsservers konfigurieren, der für jedes Member der Server-Farm verwendet wird.

Wenn Sie eine Server-Farm planen, erstellen Sie zunächst eigenständige Server, die mit derselben Datenbankinstanz kommunizieren. Modifizieren Sie die Konfiguration dieser Server dann so, dass sie Member einer Server-Farm werden.

  1. Wählen Sie zum Konfigurieren der Member der Server-Farm den Anwendungsservertyp aus. Die Mobile Foundation unterstützt in Server-Farmen die folgenden Anwendungsserver:
    • WebSphere Application Server Full Profile
      Hinweis: In einer Farmtopologie können Sie den RMI-JMX-Connector nicht verwenden. In dieser Topologie unterstützt die Mobile Foundation nur den SOAP-Connector.
    • WebSphere Application Server Liberty Profile
    • Apache Tomcat
    Informationen zu den unterstützten Versionen der Anwendungsserver finden Sie in den Systemvoraussetzungen.
    Wichtiger Hinweis: Die Mobile Foundation unterstützt nur homogene Server-Farmen. Eine Server-Farm wird als homogen eingestuft, wenn sie Anwendungsserver desselben Typs miteinander verbindet. Der Versuch, unterschiedliche Typen von Anwendungsservern zuzuordnen, könnte zur Laufzeit zu einem unvorhersehbaren Verhalten führen. Eine Farm von Tomcat-Servern und Servern mit WebSphere Application Server Full Profile ist beispielsweise eine ungültige Konfiguration.
  2. Entscheiden Sie, welche Datenbank verwendet werden soll. Folgende Optionen stehen zur Auswahl:
    • DB2
    • MySQL
    • Oracle
    MobileFirst Server-Datenbanken werden von den Anwendungsservern einer Farm gemeinsam genutzt. Das bedeutet Folgendes:
    • Sie erstellen die Datenbank unabhängig von der Anzahl der Server in der Farm nur einmal.
    • Sie können die Derby-Datenbank nicht in einer Farmtopologie verwenden, weil die Derby-Datenbank immer nur jeweils eine Verbindung erlaubt.
    Weitere Informationen zu Datenbanken finden Sie unter Datenbanken einrichten.
  3. Richten Sie so viele eigenständige Server ein, wie Sie Member in der Farm benötigen.
    • Jeder dieser eigenständigen Server muss mit derselben Datenbank kommunizieren. Sie müssen sicherstellen, dass jeder von diesen Servern verwendete Port nicht von einem anderen Server, der auf demselben Host konfiguriert ist, verwendet wird. Diese Beschränkung gilt für die Ports, die von den Protokollen HTTP, HTTPS, REST, SOAP und RMI verwendet werden.
    • In jedem dieser Server müssen der MobileFirst-Server-Verwaltungsservice, der MobileFirst-Server-Liveaktualisierungsservice und mindestens eine MobileFirst-Laufzeit implementiert sein.
    • Wenn jeder dieser Server ordnungsgemäß in einer eigenständigen Topologie funktioniert, können Sie die Server zu Membern einer Server-Farm machen.
  4. Stoppen Sie alle Server, die Member der Farm werden sollen.
  5. Konfigurieren Sie jeden Server entsprechend dem Anwendungsservertyp.
    Sie müssen einige JNDI-Eigenschaften ordnungsgemäß definieren. In einer Server-Farmtopologie müssen die JNDI-Eigenschaften mfp.config.service.user und mfp.config.service.password aller Farmmember den gleichen Wert haben. Für Apache Tomcat müssen Sie außerdem überprüfen, ob die JVM-Argumente richtig definiert sind.
    • WebSphere Application Server Liberty Profile
      Legen Sie in der Datei server.xml die im folgenden Beispielcode gezeigten JNDI-Eigenschaften fest. 
      <jndiEntry jndiName="mfp.topology.clustermode" value="Farm"/>
<jndiEntry jndiName="mfp.admin.serverid" value="farm_member_1"/>
<jndiEntry jndiName="mfp.admin.jmx.user" value="myRESTConnectorUser"/>
<jndiEntry jndiName="mfp.admin.jmx.pwd" value="password-of-rest-connector-user"/>
<jndiEntry jndiName="mfp.admin.jmx.host" value="93.12.0.12"/>
<jndiEntry jndiName="mfp.admin.jmx.port" value="9443"/>
      Für diese Eigenschaften müssen die richtigen Werte festgelegt werden:
      • mfp.admin.serverid: Die Kennung, die Sie für dieses Farmmember definiert haben. Diese Kennung muss für jedes Farmmember eindeutig sein.
      • mfp.admin.jmx.user und mfp.admin.jmx.pwd: Diese Werte müssen mit den Berechtigungsnachweisen eines im Element administrator-role deklarierten Benutzers übereinstimmen.
      • mfp.admin.jmx.host: Setzen Sie diesen Parameter auf die IP-Adresse oder den Hostnamen, die bzw. den ferne Member für den Zugriff auf diesen Server verwenden. Der Parameter darf daher nicht auf localhost gesetzt werden. Der Name dieses Hosts wird von den anderen Farmmembern verwendet. Der Host muss für alle Farmmember erreichbar sein.
      • mfp.admin.jmx.port: Setzen Sie diesen Parameter auf den Server-HTTPS-Port, der für die JMX-REST-Verbvindung verwendet wird. Sie finden den Wert im Element httpEndpoint der Datei server.xml.
    • Apache Tomcat
      Modifizieren Sie die Datei conf/server.xml. Legen Sie im Verwaltungsservicekontext und in jedem Laufzeitkontext die folgenden JNDI-Eigenschaften fest. 
      <Environment name="mfp.topology.clustermode" value="Farm" type="java.lang.String" override="false"/>
<Environment name="mfp.admin.serverid" value="farm_member_1" type="java.lang.String" override="false"/>
      Die Eigenschaft mfp.admin.serverid muss auf die Kennung gesetzt sein, die Sie für dieses Farm-Member definiert haben. Diese Kennung muss für jedes Farmmember eindeutig sein.
      Stellen Sie sicher, dass das JVM-Argument -Djava.rmi.server.hostname auf die IP-Adresse oder den Hostnamen gesetzt ist, die bzw. den ferne Member für den Zugriff auf diesen Server verwenden. Das Argument darf daher nicht auf localhost gesetzt werden. Außerdem müssen Sie sicherstellen, dass für das JVM-Argument -Dcom.sun.management.jmxremote.port ein Port definiert wird, der noch nicht für die Aktivierung von JMX-RMI-Verbindungen verwendet wird. Beide Argumente werden in der Umgebungsvariablen CATALINA_OPTS festgelegt.
    • WebSphere Application Server Full Profile
      Sie müssen im Verwaltungsservice und in jeder im Server implementierten Laufzeitanwendung die folgenden JNDI-Eigenschaften deklarieren.
      • mfp.topology.clustermode
      • mfp.admin.serverid
      Führen Sie in der WebSphere-Application-Server-Konsole die folgenden Schritte aus:
      • Wählen Sie Anwendungen → Anwendungstypen → Websphere-Unternehmensanwendungen aus.
      • Wählen Sie den Verwaltungsservice aus.
      • Klicken Sie unter Eigenschaften des Webmoduls auf Umgebungseinträge für Webmodule, um die JNDI-Eigenschaften anzuzeigen.
      • Legen Sie die Werte der folgenden Eigenschaften fest.
        • Setzen Sie mfp.topology.clustermode auf Farm.
        • Setzen Sie mfp.admin.serverid auf die ID, die Sie für dieses Farmmember gewählt haben. Diese Kennung muss für jedes Farmmember eindeutig sein.
        • Setzen Sie mfp.admin.jmx.user auf den Namen eines Benutzers, der Zugriff auf den SOAP-Connector hat.
        • Setzen Sie mfp.admin.jmx.pwd auf das Kennwort des in mfp.admin.jmx.user deklarierten Benutzers.
        • Setzen Sie mfp.admin.jmx.port auf den SOAP-Portwert.
      • Vergewissern Sie sich, dass mfp.admin.jmx.connector auf SOAP gesetzt ist.
      • Klicken Sie auf OK und speichern Sie die Konfiguration.
      • Nehmen Sie ähnliche Veränderungen für jede auf dem Server implementierte MobileFirst-Laufzeitumgebung vor.
  6. Tauschen Sie die Serverzertifikate aus den Truststores aller Farmmember aus. Der Austausch von Serverzertifikaten zwischen den Truststores ist obligatorisch für Farmen, die WebSphere Application Server Full Profile und WebSphere Application Server LIberty Profile verwenden, weil die Kommunikation zwischen den Servern in diesen Farmen mit SSL geschützt wird.
    • WebSphere Application Server Liberty Profile
      Sie können den Truststore mit IBM Dienstprogrammen wie Keytool oder iKeyman konfigurieren.
      • Weitere Informationen zu Keytool finden Sie in der Dokumentation zu IBM SDK Java Technology Edition im Abschnitt Keytool.
      • Weitere Informationen zu iKeyman finden Sie in der Dokumentation zu IBM SDK Java Technology Edition im Abschnitt iKeyman.
      Die Keystore- und Truststore-Position ist in der Datei server.xml definiert. Lesen Sie die Beschreibung der Attribute keyStoreRef und trustStoreRef unter SSL-Konfigurationsattribute. Standardmäßig befindet sich der Liberty-Profile-Keystore unter ${server.config.dir}/resources/security/key.jks. Wenn der Truststore-Verweis in der Datei server.xml fehlt oder nicht definiert ist, wird der mit keyStoreRef angegebene Keystore verwendet. Der Server verwendet den Standard-Keystore. Die Datei wird erstellt, wenn der Server zum ersten Mal ausgeführt wird. In dem Fall wird ein Standardzertifikat mit einem Gültigkeitszeitraum von 365 Tagen erstellt. Für die Produktion sollten Sie die Verwendung eines eigenen Zertifikats (ggf. einschließlich der Zwischenzertifikate) in Betracht ziehen oder das Verfallsdatum des generierten Zertifikats ändern.
      Hinweis: Wenn Sie die Position des Truststore bestätigen möchten, fügen Sie die folgende Deklaration zur Datei server.xml hinzu: 
      <logging traceSpecification="SSL=all:SSLChannel=all"/>
      Starten Sie schließlich den Server und suchen Sie in der Datei ${wlp.install.dir}/usr/servers/Servername/logs/trace.log nach Zeilen, die com.ibm.ssl.trustStore enthalten.
      • Importieren Sie die öffentlichen Zertifikate der anderen Server der Farm in den Truststore, auf den die Konfigurationsdatei server.xml des Servers verweist. Das Lernprogramm (MobileFirst Server im Grafikmodus installieren) enthält die Anweisungen für den Austausch der Zertifikate zwischen zwei Liberty-Servern einer Farm. Weitere Informationen finden Sie unter Farm mit zwei Liberty-Servern für MobileFirst Server erstellen in Schritt 5.
      • Starten Sie jede Instanz von WebSphere Application Server Liberty Profile neu, damit die Sicherheitskonfiguration wirksam wird. Die folgenden Schritte sind erforderlich, wenn Sie mit SSO arbeiten möchten.
      • Tauschen Sie die Unterzeichnerzertifikate aus, die sich im Truststore der einzelnen Server befinden.

        Hinweis: Dieser Schritt ist für Farmen obligatorisch, die WebSphere Application Server Full Profile oder Liberty verwenden, da die Sicherheit aktiviert sein muss. Bei Liberty-Farmen muss außerdem die LTPA-Konfiguration auf jedem Server repliziert werden, damit das Single Sign-on funktioniert. Führen Sie dazu die folgenden Konfigurationsschritte aus.
      • Starten Sie ein Member der Farm. Nach erfolgreichem Start des Liberty-Servers wird in der LTPA-Standardkonfiguration der LTPA-Keystore ${wlp.user.dir}/servers/Servername/resources/security/ltpa.keys generiert.
      • Kopieren Sie die Datei ltpa.keys in das Verzeichnis ${wlp.user.dir}/servers/Servername/resources/security jedes Farmmembers, um die LTPA-Keystores auf allen Farmmembern zu replizieren. Weitere Informationen zur LTPA-Konfiguration finden Sie unter LTPA im Liberty-Profil konfigurieren.
    • WebSphere Application Server Full Profile
      Konfigurieren Sie den Truststore in der Administrationskonsole von WebSphere Application Server.
      • Melden Sie sich bei der Administrationskonsole von WebSphere Application Server an.
      • Wählen Sie Sicherheit → Verwaltung von SSL-Zertifikaten und Schlüsseln aus.
      • Wählen Sie unter Zugehörige Elemente die Option Keystores und Zertifikate aus.
      • Stellen Sie sicher, dass der Eintrag SSL-Keystores im Feld Keystore-Nutzung ausgewählt ist. Jetzt können Sie die Zertifikate aller anderen Server in der Farm importieren.
      • Klicken Sie auf NodeDefaultTrustStore.
      • Wählen Sie unter Weitere Eigenschaften die Option Unterzeichnerzertifikate aus.
      • Klicken Sie auf Vom Port abrufen. Jetzt können Sie Kommunikations- und Sicherheitsdetails aller anderen Server in der Farm eingeben. Führen Sie für jedes der übrigen Farmmember die folgenden Schritte aus.
      • Geben Sie im Feld Host den Hostnamen oder die IP-Adresse des Servers ein.
      • Geben Sie im Feld Port den SSL-Port für HTTPS-Transport ein.
      • Wählen Sie unter SSL-Konfiguration für abgehende Verbindung die Option NodeDefaultSSLSettings aus.
      • Geben Sie im Feld Alias einen Alias für dieses Unterzeichnerzertifikat ein.
      • Klicken Sie auf Unterzeichnerdaten abrufen.
      • Überprüfen Sie die Informationen, die vom fernen Server abgerufen werden. Klicken Sie dann auf OK.
      • Klicken Sie auf Speichern.
      • Starten Sie den Server erneut.

Farmkonfiguration prüfen

Sie überprüfen den Status der Farmmember und stellen sicher, dass die Farm ordnungsgemäß konfiguriert ist.

  1. Starten Sie alle Server der Farm.
  2. Rufen Sie die MobileFirst Operations Console auf. Geben Sie beispielsweise http://Servername:Port/mfpconsole ein oder für HTTPS https://Hostname:sicherer_Port/mfpconsole. In der Seitenleiste der Konsole erscheint ein zusätzliches Menü Server-Farmknoten.
  3. Wenn Sie auf Server-Farmknoten klicken, können Sie auf die Liste der registrierten Farmmember und ihren Status zugreifen. Im folgenden Beispiel wird der mit Farmmember2 bezeichnete Knoten als inaktiv angesehen. Das bedeutet, dass ein Serverfehler vorliegen könnte und der Server möglicherweise gewartet werden muss.

Status von Farmknoten in der MobileFirst Operations Console

Lebenszyklus eines Server-Farmknotens

Sie können eine Signalrate und Zeitlimitwerte konfigurieren, damit mögliche Serverprobleme bei Farmmembern durch das Auslösen einer Statusänderung bei einem betroffenen Knoten angezeigt werden.

Server als Farmknoten registrieren und überwachen

Wenn ein als Farmknoten konfigurierter Server gestartet wird, registriert der Verwaltungsservice dieses Servers den Knoten automatisch als neues Farmmember.Wenn ein Farmmember beendet wird, wird die Registrierung dieses Members in der Farm automatisch aufgehoben.

Es gibt ein Überwachungssignalverfahren für den Fall, dass Farmmember beispielsweise wegen eines Stromausfalls oder eines Serverfehlers nicht mehr reagieren. In diesem Überwachungssignalverfahren senden MobileFirst-Laufzeiten in festgelegten regelmäßigen Abständen ein Überwachungssignal an die MobileFirst-Verwaltungsservices. Wenn der MobileFirst-Verwaltungsservice registriert, dass seit dem letzten Überwachungssignal von einem Farmmember zu viel Zeit vergangen ist, wird davon ausgegangen, dass das Farmmember inaktiv ist.

Als inaktiv angesehene Farmmember bedienen keine Anforderungen mobiler Anwendungen.

Wenn Knoten inaktiv sind, hindert das die übrigen Member nicht daran, Anfragen mobiler Anwendungen zu beantworten oder neue, über die MobileFirst Operations Console ausgelöste Verwaltungsoperationen zu akzeptieren.

Signalrate und Zeitlimitwerte konfigurieren

Sie können die Signalrate und Zeitlimitwerte konfigurieren, indem Sie die folgenden JNDI-Eigenschaften definieren:

  • mfp.admin.farm.heartbeat
  • mfp.admin.farm.missed.heartbeats.timeout


Weitere Informationen zu JNDI-Eigenschaften finden Sie in der Liste der JNDI-Eigenschaften für den MobileFirst-Server-Verwaltungsservice.

Scheduler der Mobile-Foundation-Laufzeit

Die Mobile-Foundation-Laufzeit verwendet Quartz Scheduler für einige geplante Aktivitäten.

Der Scheduler der Mobile-Foundation-Laufzeit führt die folgenden Aktivitäten aus:

  1. Lizenzüberwachung
  2. Erstellung von Prüfprotokollen

Die Ausführung des Schedulers wird von den beiden folgenden JNDI-Eigenschaften gesteuert:

  • mfp.licenseTracking.enabled
  • mfp.purgedata.enabled (eingeführt mit dem vorläufigen Fix 8.0.0.0-MFPF-IF201812191602-CDUpdate-04)

Diese JNDI-Eigenschaften sind standardmäßig für alle unterstützten Anwendungsserver aktiviert.

Hinweis: Wenn die Mobile Foundation in einem WebSphere Application Server ausgeführt wird, muss die JNDI-Eigenschaft mfp.licenseTracking.enabled aktiviert werden. Setzen Sie die Eigenschaft in der WAS-Konsole unter den Einträgen für die Laufzeitumgebung auf den Wert true.

Lizenzüberwachung

Die Lizenzüberwachung überwacht Metriken, die für die Lizenzierungsrichtlinie relevant sind. Dazu gehören Clientgeräte, adressierbare Geräte und installierte Apps. Mithilfe dieser Angaben wird bestimmt, ob die Nutung der Mobile Foundation im Rahmen der Lizenzberechtigung erfolgt. So können Verletzungen der Lizenzbestimmungen verhindert werden. Die Lizenzüberwachung hilft bei der Stilllegung von Geräten, die nicht mehr auf Mobile Foundation Server zugreifen, und unterstützt die Archivierung und Löschung alter MFP_PERSISTENT_DATA-Datensätze.

In der folgenden Tabelle sind die JNDI-Eigenschaften für Lizenzüberwachung aufgelistet.

JNDI-Eigenschaft Beschreibung
mfp.device.decommissionProcessingInterval Definiert, wie häufig eine Stilllegung durchgeführt wird (Intervall in Sekunden). Standardwert: 86400 (ein Tag).
mfp.device.decommission.when Anzahl von Tagen der Inaktivität, nach denen ein Clientgerät mit der Aufgabe für Gerätestilllegung stillgelegt wird. Standardwert: 90 Tage.
mfp.device.archiveDecommissioned.when Anzahl von Tagen der Inaktivität, nach denen ein stillgelegtes Clientgerät archiviert wird.
Diese Task schreibt die stillgelegten Clientgeräte in eine Archivdatei. Die archivierten Clientgeräte werden in eine Datei im MobileFirst-Server-Verzeichnis home\devices_archive geschrieben. Der Name der Datei
enthält die Zeitmarke für den Erstellungszeitpunkt der Archivdatei. Standardwert: 90 Tage.  
mfp.licenseTracking.enabled Mit dem Wert dieser Eigenschaft wird die Geräteüberwachung in der IBM Mobile Foundation aktiviert oder inaktiviert.
Aus Leistungsaspekten können Sie die Geräteüberwachung inaktivieren, wenn die IBM Mobile Foundation ausschließlich Business-to-Consumer-Apps (B2C) ausführt. Bei inaktivierter Geräteüberwachung sind
auch die Lizenzberichte inaktiviert und es werden keine Lizenzmetriken generiert.
Gültige Werte sind true (Standard) und false.		  

In den folgenden Artikeln finden Sie weitere Einzelheiten zur Lizenzüberwachung.

Ein Scheduler wird acht Stunden nach einem Serverstart ausgeführt. Wenn die Server beispielsweise heute um 23.00 Uhr gestartet werden, wird der Scheduler nicht morgen um 1.00 Uhr ausgeführt (wie es standardmäßig der Fall wäre), sondern erst übermorgen um 1.00 Uhr. Zwischen dem Start des Servers und der Ausführung des Schedulers müssen mindestens acht Stunden liegen.

Ab dem vorläufigen Fix 8.0.0.0-MFPF-IF201907091643 liegt der Abstand zwischen dem Serverstart und der Ausführung des Schedulers nicht mehr bei acht Stunden, sondern bei vier Stunden. Außerdem wurde mit diesem Fix die neue Eigenschaft mfp.scheduler.startHour eingeführt. Mithilfe dieser Eigenschaft kann der Kunde für die Ausführung des Schedulers eine andere als die Standardzeit (1.00 Uhr) festlegen. Die Eigenschaft kann auf einen Wert von 1 bis 23 gesetzt werden. Diese Eigenschaft stellt sicher, dass der Kunde den Start seines Schedulers in eine Zeit mit wenig Datenverkehr legen kann und dass der Scheduler unabhängig vom täglichen Start der Server ausgeführt wird. Ein Kunde, der seinen Server jede Nacht um 1.00 Uhr startet, kann mfp.scheduler.startHour auf den Wert 5 setzen. So wird ein vierstündiger Abstand zwischen dem Neustart des Servers und der Ausführung des Schedulers (um 5.00 Uhr) sichergestellt.

Sie sollten die Lizenzüberwachung aufgrund der datenbankintensiven Aktivitäten inaktivieren. Nur Kunden mit einem Lizenzierungsmodell für adressierbare Mobile-Foundation-Geräten müssen die Lizenzüberwachung ausführen.

Kunden, die die Lizenzüberwachung nicht aktiviert haben, können die Bereinigungsfunktion zum Löschen alter Datensätze und zur Bewahrung der Tabellen MFP_PERSISTENT_DATA und MFP_TRANSIENT_DATA nutzen.

Prüfprotokoll erstellen

Die Lizenzüberwachung speichert die letzte Ausführung und die Lizenzdaten in der Mobile-Foundation-Laufzeittabelle LICENSE_TERMS. Das Prüfprotokoll wird ausgehend vom letzten Berichtseintrag in dieser Tabelle erstellt. Berichte sind als .slmtag-Dateien im Protokollordner unter dem Serverinstallationsverzeichnis verfügbar.

Quartz-Update inaktivieren

In den Mobile-Foundation-Laufzeitbundles sind die erforderlichen Bibliotheken enthalten, zu denen auch einige Bibliotheken anderer Anbieter gehören. Die Mobile Foundation verwendet Quartz Job Schedulers und enthält die Datei quartz2.2.0.jar.

Quartz enthält eine Funktion zur Überprüfung auf Updates (update check), die eine Verbindung zum Server herstellt, um festzustellen, ob eine neue Quartz-Version für den Download verfügbar ist. Diese Überprüfung wird asynchron durchgeführt und hat ekeinen Einfluss auf die Start-/Initialisierungszeit von Quartz. Wenn die Verbindung nicht hergestellt werden kann, schlägt die Überprüfung ohne Folgeprobleme fehl. Wenn die Überprüfung durchgeführt und ein Update gefunden wird, wird dieses Upate in den Quartz-Protokollen als verfügbar aufgeführt.

Die Überprüfung auf Updates (update check) kann mit dem Flag org.quartz.scheduler.skipUpdateCheck = true inaktiviert werden. Bei einer Liberty-Implementierung der Mobile Foundation wird eine Datei jvm.options erstellt. Während der Implementierung mit dem Server Configuration Tool enthält die neu erstellte Datei jvm.options ab dem vorläufigen Fix 8.0.0.0-MFPF-IF201909190904 diese Eigenschaft. Kunden, die ältere vorläufige Fixes verwenden, können diese Eigenschaft zur Datei jvm.options hinzufügen. Bei WAS-Implementierungen (WebSphere Application Server) muss die oben angegebene JNDI-Eigenschaft über die WAS-Administrationskonsole zu der Umgebungseigenschaft der Mobile-Foundation-Anwendung hinzugefügt werden.

▲
Inclusive terminology note: The Mobile First Platform team is making changes to support the IBM® initiative to replace racially biased and other discriminatory language in our code and content with more inclusive language. While IBM values the use of inclusive language, terms that are outside of IBM's direct influence are sometimes required for the sake of maintaining user understanding. As other industry leaders join IBM in embracing the use of inclusive language, IBM will continue to update the documentation to reflect those changes.
Last modified on May 13, 2020