MobileFirst Server in einem Anwendungsserver installieren
Ü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).
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.
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:
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:
Für eine einfache Konfiguration fügen Sie CATALINA_OPTS die folgenden Optionen hinzu:
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:
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.
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.
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:
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.
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:
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.
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:
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.
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:
Die Datenbanken und Tabellen für die Komponenten sind erstellt und einsatzbereit (siehe Datenbanken einrichten).
Die Servertopologie für die Installation der Komponenten ist festgelegt (siehe Topologien und Netzabläufe).
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.
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.
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.
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.
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.
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.
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.
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.
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.
Ü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.
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.
Ü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.
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:
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:
Geben Sie im Element <configuration> einen Benutzer und ein Kennwort an und setzen Sie das Attribut createConfigAdminUser auf den Wert “false”. Beispiel:
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:
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:
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:
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.
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.
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:
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.
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:
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:
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:
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:
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:
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:
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:
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:
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
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:
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.
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.
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:
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:
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.
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:
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:
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.
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:
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.
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:
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:
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:
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.
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:
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:
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:
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.
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:
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.
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
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:
Melden Sie sich bei der Administrationskonsole von WebSphere Application Server an.
Klicken Sie auf Sicherheit → Globale Sicherheit. Stellen Sie sicher, dass die Option Verwaltungssicherheit aktivieren ausgewählt ist.
Stellen Sie sicher, dass die Option Anwendungssicherheit aktivieren ausgewählt ist. Die Anwendungssicherheit kann nur aktiviert werden, wenn die Verwaltungssicherheit aktiviert ist.
Klicken Sie auf OK.
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:
Melden Sie sich bei der Administrationskonsole von WebSphere Application Server an.
Klicken Sie auf Server → Servertypen → WebSphere-Anwendungsserver und wählen Sie den für die Mobile Foundation verwendeten Server aus.
Wenn die Klassenladerrichtlinie auf Mehrere gesetzt ist, müssen Sie nichts tun.
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.
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:
Klicken Sie auf den Link Anwendungen verwalten oder klicken Sie auf Anwendungen → Anwendungstypen → WebSphere-Unternehmensanwendungen.
Klicken Sie auf die MobileFirst-Server-Anwendung. Der Name der Anwendung ist standardmäßig der Name der WAR-Datei.
Klicken Sie im Abschnitt Detaileigenschaften auf den Link
Laden von Klassen und Erkennung von Dateiaktualisierungen.
Wählen Sie im Fenster
Reihenfolge der Klassenlader die Option Mit dem lokalen Klassenlader geladene Klassen
zuerst (übergeordneter zuletzt) aus.
Klicken Sie auf OK.
Klicken Sie im Abschnitt Module auf
den Link Module verwalten.
Klicken Sie auf das Modul.
Wählen Sie für das Feld
Reihenfolge der Klassenlader die Option Mit dem lokalen Klassenlader geladene Klassen
zuerst (übergeordneter zuletzt) aus.
Klicken Sie zweimal auf OK, um die Auswahl zu bestätigen und zum Fenster
Konfiguration für die Anwendung zurückzugelangen.
Klicken Sie auf
Speichern, um die Änderungen dauerhaft zu speichern.
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.
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:
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:
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.
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:
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.
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.
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.
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:
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.
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.
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.
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.
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.
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.
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.
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.
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
.
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.
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:
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
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.
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.
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.
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.
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.
Stoppen Sie alle Server, die Member der Farm werden sollen.
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.
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.
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.
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:
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.
Starten Sie alle Server der Farm.
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.
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.
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:
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:
Lizenzüberwachung
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.