MobileFirst Server konfigurieren

Übersicht

Nachfolgend finden Sie Informationen zur Sicherungs- und Wiederherstellungsrichtlinie, zur Optimierung der MobileFirst-Server-Konfiguration und zum Anwenden von Zugriffsbeschränkungen und Sicherheitsoptionen.

Fahren Sie mit folgenden Abschnitten fort:

• Endpunkte von MobileFirst Server (Produktionsserver)
• MobileFirst Server für die Aktivierung von TLS Version 1.2 konfigurieren
• Benutzerauthentifizierung für die MobileFirst-Server-Verwaltung konfigurieren
• Liste der JNDI-Eigenschaften für die MobileFirst-Server-Webanwendungen
• Datenquellen konfigurieren
• Protokollierungs- und Überwachungsmechanismen konfigurieren
• Mehrere Laufzeiten konfigurieren
• Lizenzüberwachung konfigurieren
• SSL-Konfiguration von WebSphere Application Server und HTTP-Adapter

Endpunkte von MobileFirst Server (Produktionsserver)

Sie können für die Endpunkte von IBM MobileFirst Server. Whitelists und Blacklists erstellen.

Hinweis: Informationen zu den von der Mobile Foundation zugänglich gemachten URLs werden als Richtlinie bereitgestellt. Organisationen müssen sicherstellen, dass die URLs ausgehend von Whitelists und Blacklists in einer Unternehmensstruktur getestet werden.

MobileFirst Server für die Aktivierung von TLS Version 1.2 konfigurieren

Sie müssen die folgenden Anweisungen ausführen, wenn MobileFirst Server mit Geräten kommunizieren können soll, die von den SSL-Protokollen nur TLS (Transport Layer Security) Version 1.2 unterstützen.

Mit welchen Schritten MobileFirst Server konfiguriert werden muss, um Transport Layer Security (TLS) Version 1.2 zu ermöglichen, hängt davon ab, wie MobileFirst Server eine Verbindung zu Geräten herstellt.

• Wenn sich MobileFirst Server hinter einem Reverse Proxy befindet, der SSL-verschlüsselte Pakete von Geräten vor der Weitergabe an den Anwendungsserver entschlüsselt, müssen Sie für Ihren Reverse Proxy die Unterstützung für TLS Version 1.2 aktivieren. Falls Sie IBM HTTP Server als Reverse Proxy verwenden, lesen Sie die Anweisungen unter IBM HTTP Server sichern.
• Wenn MobileFirst Server direkt mit Geräten kommuniziert, hängen die für die Aktivierung vn TLS Version 1.2 erforderlichen Konfigurationsschritte davon ab, ob Sie Apache Tomcat, WebSphere Application Server Liberty Profile oder WebSphere Application Server Full Profile als Anwendungsserver verwenden.

Apache Tomcat

1. Vergewissern Sie sich, dass die Java Runtime Environment (JRE) TLS Version 1.2 unterstützt. Stellen Sie sicher, dass Sie eine der folgenden JRE-Versionen haben:
   • Oracle JRE 1.7.0_75 oder eine aktuellere JRE
   • Oracle JRE 1.8.0_31 oder eine aktuellere JRE
2. Bearbeiten Sie die Datei conf/server.xml. Modifizieren Sie das Connector-Element, das den HTTPS-Port deklariert, so, dass das Attribut sslEnabledProtocols den Wert sslEnabledProtocols="TLSv1.2,TLSv1.1,TLSv1,SSLv2Hello" hat.

WebSphere Application Server Liberty Profile

1. Vergewissern Sie sich, dass die Java Runtime Environment (JRE) TLS Version 1.2 unterstützt.

   • Wenn Sie ein IBM Java-SDK verwenden, stellen Sie sicher, dass das Patch zum Beseitigen der Anfälligkeit für POODLE angewendet wurde. Die älteste Version des IBM Java-SDK, die das Patch für Ihre Version von WebSphere Application Server enthält, finden Sie im Security Bulletin: Vulnerability in SSLv3 affects IBM WebSphere Application Server (CVE-2014-3566).

     Hinweis: Sie können die im Sicherheitsbulletin aufgelisteten Versionen oder aktuellere Versionen verwenden.

   • Wenn Sie ein Java-SDK von Oracle verwenden, stellen Sie sicher, dass Sie über eine der folgenden Versionen verfügen:

     • Oracle JRE 1.7.0_75 oder eine aktuellere JRE
     • Oracle JRE 1.8.0_31 oder eine aktuellere JRE
2. Wenn Sie ein IBM Java-SDK verwenden, bearbeiten Sie die Datei server.xml.
   • Fügen Sie die folgende Zeile hinzu: <ssl id="defaultSSLConfig" keyStoreRef="defaultKeyStore" sslProtocol="SSL_TLSv2"/>
   • Fügen Sie das Attribut sslProtocol="SSL_TLSv2" zu allen vorhandenen <ssl>-Elementen hinzu.

WebSphere Application Server Full Profile

1. Vergewissern Sie sich, dass die Java Runtime Environment (JRE) TLS Version 1.2 unterstützt.

Stellen Sie sicher, dass auf Ihr IBM Java-SDK das Patch zur Beseitigung der Anfälligkeit für POODLE angewendet wurde. Die älteste Version des IBM Java-SDK, die das Patch für Ihre Version von WebSphere Application Server enthält, finden Sie im Security Bulletin: Vulnerability in SSLv3 affects IBM WebSphere Application Server (CVE-2014-3566). > Hinweis: Sie können die im Sicherheitsbulletin aufgelisteten Versionen oder aktuellere Versionen verwenden.

1. Melden Sie sich bei der Administrationskonsole von WebSphere Application Server an und klicken Sie auf Sicherheit → Verwaltung von SSL-Zertifikaten und Schlüsseln → SSL-Konfigurationen.
2. Modifizieren Sie jede aufgelistete SSL-Konfiguration so, dass TLS Version 1.2 ermöglicht wird.
   • Wählen Sie eine SSL-Konfiguration aus und klicken Sie unter Weitere Eigenschaften auf Einstellungen für Datenschutzniveau.
   • Wählen Sie in der Liste Protokoll den Eintrag SSL_TLSv2 aus.
   • Klicken Sie auf Anwenden und speichern Sie die Änderungen.

Benutzerauthentifizierung für die MobileFirst-Server-Verwaltung konfigurieren

Für die MobileFirst-Server-Verwaltung ist die Benutzerauthentifizierung erforderlich. Sie können die Benutzerauthentifizierung konfigurieren und eine Authentifizierungsmethode auswählen. Die Konfigurationsprozedur richtet sich nach dem Webanwendungsserver, den Sie verwenden.

Wichtiger Hinweis: Wenn Sie einen eigenständigen WebSphere Application Server Full Profile verwenden, müssen Sie in der globalen Sicherheit eine andere Authentifizierungsmethode als SWAM (Simple WebSphere Authentication Mechanism) verwenden. Sie können LTPA (Lightweight Third-Party Authentication) nutzen. Wenn Sie SWAM verwenden, kann es zu nerwarteten Authentifizierungsfehlern kommen.

Nachdem das Installationsprogramm die Webanwendungen für die MobileFirst-Server-Verwaltung im Webanwendungsserver implementiert hat, müssen Sie die Authentifizierung konfigurieren.

Für die MobileFirst-Server-Verwaltung sind die folgenden Java-EE-Sicherheitsrollen (Java Platform, Enterprise Edition) definiert:

• mfpadmin
• mfpdeployer
• mfpoperator
• mfpmonitor

Diese Rollen müssen den entsprechenden Benutzergruppen zugeordnet werden. Der Benutzer mit der Rolle mfpmonitor kann Daten anzeigen, aber nicht ändern. In der folgenden Tabelle sind die MobileFirst-Rollen und ihre Funktion für Produktionsserver aufgelistet.

Implementierung

MobileFirst-Server-Verwaltung

Anwendungsmanagement

Im Grunde können alle Rollen GET-Anforderungen absetzen. Die Rollen mfpadmin, mfpdeployer und mfpmonitor können außerdem POST- und PUT-Anforderungen absetzen. Die Rollen mfpadmin und mfpdeployer könen darüber hinaus DELETE-Anforderungen absetzen.

Anforderungen in Bezug auf Push-Benachrichtigungen

Inaktivierung

Wenn Sie sich für eine Authentifizierungsmethode über ein Benutzerrepository wie LDAP entscheiden, können Sie die MobileFirst Server-Verwaltung so konfigurieren, dass Sie die Benutzer und Gruppen mit dem Benutzerrepository verwenden können, um die Zugriffssteuerungsliste (Access Control List, ACL) der MobileFirst Server-Verwaltung zu definieren. Die erforderliche Vorgehensweise ist abhängig vom Typ und von der Version des verwendeten Webanwendungsservers.

WebSphere Application Server Full Profile für die MobileFirst-Server-Verwaltung konfigurieren

Konfigurieren Sie die Sicherheit, indem Sie für beide Webanwendungen die Java-EE-Rollen der MobileFirst-Server-Verwaltung einer Gruppe von Benutzern zuordnen.

Die grundlegenden Informationen für die Benutzerkonfiguration werden in der Konsole von WebSphere Application Server definiert. Die Konsole wird normalerweise über die Adresse https://localhost:9043/ibm/console/ aufgerufen.

1. Wählen Sie Sicherheit → Globale Sicherheit aus.
2. Wählen Sie Assistent für die Sicherheitskonfiguration aus, um die Benutzer zu konfigurieren. Sie können einzelne Benutzeraccounts verwalten, wenn Sie Benutzer und Gruppen → Benutzer verwalten auswählen.
3. Ordnen Sie die Rollen mfpadmin, mfpdeployer, mfpmonitor und mfpoperator einer Gruppe von Benutzern zu.
   • Wählen Sie Server → Servertypen → WebSphere-Anwendungsserver aus.
   • Wählen Sie den Server aus.
   • Wählen Sie auf der Registerkarte Konfiguration die Optionen Anwendungen → Unternehmensanwendungen aus.
   • Wählen Sie MobileFirst_Administration_Service aus.
   • Wählen Sie auf der Registerkarte Konfiguration die Optionen Details → Zuordnung von Sicherheitsrollen zu Benutzern/Gruppen aus.
   • Passen Sie die Angaben nach Bedarf an.
   • Klicken Sie auf OK.
   • Wiederholen Sie die Schritte für die Zuordnung der Rollen für die Konsolenwebanwendung. Wählen Sie dieses Mal MobileFirst_Administration_Console aus.
   • Klicken Sie auf Speichern, um die Änderungen zu speichern.

WebSphere Application Server Liberty Profile für die MobileFirst-Server-Verwaltung konfigurieren

In WebSphere Application Server Liberty Profile werden die Rollen mfpadmin, mfpdeployer, mfpmonitor und mfpoperator in der Konfigurationsdatei server.xml des Servers konfiguriert.

Sie müssen die Datei server.xml bearbeiten, um die Sicherheitsrollen zu konfigurieren. Erstellen Sie im Element <application-bnd> jedes <application>-Elements <security-role>-Elemente. Jedes Element <security-role> ist für die Rollen mfpadmin, mfpdeployer, mfpmonitor und mfpoperator bestimmt. Ordnen Sie die Rollen dem passenden Benutzergruppennamen zu, in diesem Beispiel mfpadmingroup, mfpdeployergroup, mfpmonitorgroup oder mfpoperatorgroup. Diese Gruppen werden mit dem Element <basicRegistry> definiert. Sie können dieses Element entweder anpassen oder ganz durch ein <ldapRegistry>-Element oder ein <safRegistry>-Element ersetzen.

Anschließend sollten Sie einen Verbindungspool für die Verwaltungsdatenbank konfigurieren, um bei einer großen Anzahl von installierten Anwendungen (z. B. 80 Anwendungen) gute Antwortzeiten zu erzielen.

1. Bearbeiten Sie die Datei server.xml. Beispiel:

   <security-role name="mfpadmin">
      <group name="mfpadmingroup"/>
   </security-role>
   <security-role name="mfpdeployer">
      <group name="mfpdeployergroup"/>
   </security-role>
   <security-role name="mfpmonitor">
      <group name="mfpmonitorgroup"/>
   </security-role>
   <security-role name="mfpoperator">
      <group name="mfpoperatorgroup"/>
   </security-role>
   
   <basicRegistry id="mfpadmin">
      <user name="admin" password="admin"/>
      <user name="guest" password="guest"/>
      <user name="demo" password="demo"/>
      <group name="mfpadmingroup">
        <member name="guest"/>
        <member name="demo"/>
      </group>
      <group name="mfpdeployergroup">
        <member name="admin" id="admin"/>
      </group>
      <group name="mfpmonitorgroup"/>
      <group name="mfpoperatorgroup"/>
   </basicRegistry>
   

2. Definieren Sie die Größe für AppCenterPool:

   <connectionManager id="AppCenterPool" minPoolSize="10" maxPoolSize="40"/>
   

3. Definieren Sie im Element <dataSource> eine Referenz auf den Verbindungsmanager:

   <dataSource id="MFPADMIN" jndiName="mfpadmin/jdbc/mfpAdminDS" connectionManagerRef="AppCenterPool">
   ...
   </dataSource>
   

Apache Tomcat für die MobileFirst-Server-Verwaltung konfigurieren

Sie müssen die Java-EE-Sicherheitsrollen für die MobileFirst-Server-Verwaltung im Apache-Tomcat-Webanwendungsserver konfigurieren.

1. Wenn Sie die MobileFirst-Server-Verwaltung manuell installiert haben, deklarieren Sie die folgenden Rollen in der Datei conf/tomcat-users.xml:

   <role rolename="mfpadmin"/>
   <role rolename="mfpmonitor"/>
   <role rolename="mfpdeployer"/>
   <role rolename="mfpoperator"/>
   

2. Fügen Sie den ausgewählten Benutzern Rollen hinzu, z. B.:

   <user name="admin" password="admin" roles="mfpadmin"/>
   

3. Sie können die Benutzer wie in der Apache Tomcat-Dokumentation unter Realm Configuration HOW-TO beschrieben definieren.

Liste der JNDI-Eigenschaften für die MobileFirst-Server-Webanwendungen

Konfigurieren Sie die JNDI-Eigenschaften für die MobileFirst-Server-Webanwendungen, die im Anwendungsserver implementiert sind.

• Liste der JNDI-Eigenschaften für die MobileFirst-Server-Webanwendungen konfigurieren
• Liste der JNDI-Eigenschaften für den MobileFirst-Server-Verwaltungsservice
• Liste der JNDI-Eigenschaften für den MobileFirst-Server-Liveaktualisierungsservice
• Liste der JNDI-Eigenschaften für die MobileFirst-Laufzeit
• Liste der JNDI-Eigenschaften für den MobileFirst-Server-Push-Service

JNDI-Eigenschaften für MobileFirst-Server-Webanwendungen konfigurieren

Sie können JNDI-Eigenschaften für die im Anwendungsserver implementierten MobileFirst-Server-Webanwendungen konfigurieren.
Sie haben die folgenden Möglichkeiten, die JNDI-Umgebungseinträge festzulegen:

• Konfigurieren Sie die Serverumgebungseinträge. Die Konfigurationsschritte für die Serverumgebungseinträge hängen wie folgt vom verwendeten Anwendungsserver ab:

  • WebSphere Application Server:
    1. Navigieren Sie in der Administrationskonsole von WebSphere Application Server zu Anwendungen → Anwendungstypen → WebSphere-Unternehmensanwendungen → Anwendungsname → Umgebungseinträge für Webmodule.
    2. Geben Sie im Feld Wert Werte ein, die für Ihre Serverumgebung geeignet sind.

    

  • WebSphere Application Server Liberty:

    Bearbeiten Sie die Datei server.xml unter Liberty-Installationsverzeichnis/usr/servers/Servername und deklarieren Sie wie folgt die JNDI-Eigenschaften:

    <application id="App-Kontextstammverzeichnis" name="App-Kontextstammverzeichnis" location="App-WAR-Name.war" type="war">
          ...
    </application>
    <jndiEntry jndiName="App-Kontextstammverzeichnis/Name_der_JNDI-Eigenschaft" value="Wert_der_JNDI-Eigenschaft" />
    

    Das Kontextstammverzeichnis (im obigen Beispiel App-Kontextstammverzeichnis) ist die Verbindung zwischen dem JNDI-Eintrag und einer bestimmten MobileFirst-Anwendung. Wenn mehrere MobileFirst-Anwendungen in demselben Server vorhanden sind, können Sie bestimmte JNDI-Einträge für jede Anwendung mit dem Kontextpfadpräfix definieren.

    Hinweis: Einige Eingenschaften werden in WebSphere Application Server global definiert, ohne dass das Kontextstammverzeichnis als Präfix für den Eigenschaftsnamen verwendet wird. Eine Liste dieser Eigenschaften finden Sie unter Globale JNDI-Einträge.

    Die Namen aller anderen JNDI-Eigenschaften müssen mit dem Konstextstammverzeichis der Anwendung als Präfix versehen sein.

    • Das Kontextstammverzeichnis für den Liveaktualisierungsservice muss /[Kontextstammverzeichnis_des_Verwaltungsservice]config lauten. Wenn das Kontextstammverzeichnis des Verwaltungsservice beispielsweise /mfpadmin ist, muss der Liveaktualisierungsservice das Kontextstammverzeichnis /mfpadminconfig haben.
    • Für den Push-Service müssen Sie /imfpush als Kontextstammverzeichnis festlegen. Andernfalls können die Clientgeräte keine Verbindung zu dem Service herstellen, denn das Kontextstammverzeichnis ist im SDK fest codiert.
    • Für den MobileFirst-Verwaltungsservice, die MobileFirst Operations Console und die MobileFirst-Laufzeit können Sie das Kontextstammverzeichnis ganz nach Wunsch definieren. Die Standardwerte lauten /mfpadmin für den MobileFirst-Verwaltungsservice, /mfpconsole für die MobileFirst Operations Console und /mfp für die MobileFirst-Laufzeit.

    Beispiel:

    <application id="mfpadmin" name="mfpadmin" location="mfp-admin-service.war" type="war">
          ...
    </application>
    <jndiEntry jndiName="mfpadmin/mfp.admin.actions.prepareTimeout" value = "2400000" />
    

  • Apache Tomcat:

    Bearbeiten Sie die Datei server.xml unter Tomcat-Installationsverzeichnis/conf und deklarieren Sie wie folgt die JNDI-Eigenschaften:

    <Context docBase="app_context_root" path="/app_context_root">
          <Environment name="Name_der_JNDI-Eigenschaft" override="false" type="java.lang.String" value="Wert_der_JNDI-Eigenschaft"/>
    </Context>
    

    • Das Präfix für den Kontextpfad ist nicht erforderlich, weil die JNDI-Einträge innerhalb des Elements <Context> einer Anwendung definiert werden.
    • Die Angabe override="false" ist obligatorisch.
    • Das Attribut type hat immer den Wert java.lang.String, sofern für die Eigenschaft nichts anderes angegeben ist.

    Beispiel:

    <Context docBase="app_context_root" path="/app_context_root">
          <Environment name="mfp.admin.actions.prepareTimeout" override="false" type="java.lang.String" value="2400000"/>
    </Context>
    

• Wenn Sie für die Installation Ant-Tasks verwenden, können Sie die Werte der JNDI-Eigenschaften auch zur Installationszeit festlegen.

  Bearbeiten Sie die XML-Konfigurationsdatei für die Ant-Tasks unter MFP-Installationsverzeichnis/MobileFirstServer/configuration-samples und deklarieren Sie die Werte für die JNDI-Eigenschaften mit dem Element property innerhalb folgender Tags:

  • <installmobilefirstadmin> für die MobileFirst-Server-Verwaltung, die MobileFirst Operations Console und den Liveaktualisierungsservice. Weitere Informationen finden Sie unter Ant-Tasks für die Installation der MobileFirst Operations Console, der MobileFirst-Server-Artefakte, des MobileFirst-Server-Verwaltungsservice und des Liveaktualisierungsservice.
  • <installmobilefirstruntime> für die Konfigurationseigenschaften der MobileFirst-Laufzeit. Weitere Informationen finden Sie unter Ant-Tasks für die Installation der MobileFirst-Laufzeitumgebungen.
  • <installmobilefirstpush> für die Konfiguration des Push-Service. Weitere Informationen finden Sie unter Ant-Tasks für die Installation des MobileFirst-Server-Push-Service.

  Beispiel:

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

Liste der JNDI-Eigenschaften für den MobileFirst-Server-Verwaltungsservice

Wenn Sie die Verwaltungsservices von MobileFirst Server und die MobileFirst Operations Console für Ihren Anwendungsserver konfigurieren, definieren Sie optionale oder obligatorische JNDI-Eigenschaften, insbesondere für Java Management Extensions (JMX).

Für die Webanwendung für Verwaltungsservices, mfp-admin-service.war, können die folgenden Eigenschaften festgelegt werden:

JNDI-Eigenschaften für den Verwaltungsservice: JMX

JNDI-Eigenschaften für den Verwaltungsservice: Zeitlimit

JNDI-Eigenschaften für den Verwaltungsservice: Protokollierung

JNDI-Eigenschaften für den Verwaltungsservice: Proxys

JNDI-Eigenschaften für den Verwaltungsservice: Topologien

JNDI-Eigenschaften für den Verwaltungsservice: relationale Datenbank

JNDI-Eigenschaften für den Verwaltungsservice: Lizenzierung

JNDI-Eigenschaften für den Verwaltungsservice: JNDI-Konfigurationen

Der Verwaltungsservice verwendet einen Liveaktualisierungsservice als Hilfseinrichtung, um verschiedene Konfigurationen zu speichern. Mit diesen Eigenschaften legen Sie fest, wie der Liveaktualisierungsservice erreicht werden kann.

JNDI-Eigenschaften für den Verwaltungsservice: Liveaktualisierungsservice

Der Verwaltungsservice verwendet einen Push-Service als Hilfseinrichtung, um verschiedene Push-Einstellungen zu speichern. Mit diesen Eigenschaften legen Sie fest, wie der Push-Service erreicht werden kann. Da der Push-Service mit dem OAuth-Sicherheitsmodell geschützt ist, müssen Sie verschiedene Eigenschaften definieren, um in OAuth vertrauliche Clients zu ermöglichen.

JNDI-Eigenschaften für den Verwaltungsservice: Push-Service

JNDI-Eigenschaften für die MobileFirst Operations Console

Für die Webanwendung für die MobileFirst Operations Console, mfp-admin-ui.war, können die folgenden Eigenschaften festgelegt werden:

Liste der JNDI-Eigenschaften für den MobileFirst-Server-Liveaktualisierungsservice

Wenn Sie den MobileFirst-Server-Liveaktualisierungsservice für Ihren Anwendungsserver konfigurieren, können Sie die folgenden JNDI-Eigenschaften festlegen. In der folgenden Tabelle sind die JNDI-Eigenschaften für den Liveaktualisierungsservice für die relationale IBM Datenbank aufgelistet.

Informationen zum Festlegen dieser Eigenschaften finden Sie unter JNDI-Eigenschaften für MobileFirst-Server-Webanwendungen konfigurieren.

Liste der JNDI-Eigenschaften für die MobileFirst-Laufzeit

Wenn Sie die MobileFirst-Server-Laufzeit für Ihren Anwendungsserver konfigurieren, müssen Sie die folgenden optionalen oder obligatorischen JNDI-Eigenschaften festlegen.
In der folgenden Tabelle sind die MobileFirst-Eigenschaften aufgelistet, die immer als JNDI-Einträge verfügbar sind:

Liste der JNDI-Eigenschaften für den MobileFirst-Server-Push-Service

Datenquellen konfigurieren

Hier können Sie sich über Details der Datenquellenkonfiguration für die unterstützten Datenbanken informieren.

• Größe des DB2-Transaktionsprotokolls steuern
• Nahtloses Failover mit DB2 HADR für MobileFirst-Server- und Application-Center-Datenquellen konfigurieren
• Behandlung von veralteten Verbindungen
• Veraltete Daten nach dem Erstellen oder Löschen von Apps in der MobileFirst Operations Console

Größe des DB2-Transaktionsprotokolls steuern

Wenn Sie eine Anwendung mit einer Größe von mindestens 40 MB über die IBM MobileFirst Operations Console implementieren, könnten Sie einen Fehler transaction log full empfangen.

Die folgende Systemausgabe ist ein Beispiel für den Fehlercode transaction log full.

DB2 SQL Error: SQLCODE=-964, SQLSTATE=57011

Der Inhalt jeder Anwendung ist in der MobileFirst-Verwaltungsdatenbank gespeichert.

Die Anzahl der aktiven Protokolldateien wird von den Datenbankkonfigurationsparametern LOGPRIMARY und LOGSECOND definiert und die Größe der Protokolldateien vom Datenbankkonfigurationsparameter LOGFILSIZ. Eine Transaktion darf keinen größeren Protokollspeicherbereich als LOGFILSZ * (LOGPRIMARY + LOGSECOND) * 4096 KB belegen.

Der Befehl DB2 GET DATABASE CONFIGURATION liefert unter anderem Informationen zur Größe der Protokolldateien und zur Anzahl der primären und sekundären Protokolldateien.

Möglicherweise müssen Sie den DB2-Protokollspeicherbereich ausgehend von der größten implementierten MobileFirst-Anwendung vergrößern.

Erhöhen Sie mit dem Befehl DB2 update db cfg den Wert des Parameters LOGSECOND.Speicherbereich wird nicht bei Aktivierung der Datenbank, sondern bei Bedarf zugeordnet.

Nahtloses Failover mit DB2 HADR für MobileFirst-Server- und Application-Center-Datenquellen konfigurieren

Sie müssen das Feature für nahtloses Failover in WebSphere Application Server Liberty Profile und WebSphere Application Server aktivieren. Mit diesem Feature können Sie eine Ausnahme verwalten, wenn eine Datenbank ausfällt und vom DB2-JDBC-Treiber umgeleitet wird.

Hinweis: Das Failover mit DB2 HADR wird nicht für Apache Tomcat unterstützt.

Wenn Sie DB2 HADR verwenden und der DB2-JDBC-Treiber nach Feststellung eines Datenbankausfalls eine Clientumleitung durchführt, löst der Treiber bei dem ersten Versuch, eine vorhandene Verbindung zu nutzen, die Ausnahme com.ibm.db2.jcc.am.ClientRerouteException mit ERRORCODE=-4498 und SQLSTATE=08506 aus. Bevor die Anwendung diese Ausnahme empfängt, ordnet WebSphere Application Server sie der Ausnahme com.ibm.websphere.ce.cm.StaleConnectionException zu.

Die Anwendung müsste also die Ausnahme abfangen und die Transaktion erneut ausführen. Die MobileFirst-Laufzeitumgebung und die Application-Center-Laufzeitumgebung können die Ausnahme nicht verwalten, greifen jedoch auf ein Feature mit der Bezeichnung “nahtloses Failover” zurück. Zum Aktivieren dieses Features müssen Sie die JDBC-Eigenschaft enableSeamlessFailover auf “1” setzen.

Konfiguration von WebSphere Application Server Liberty Profile

Sie müssen die Datei server.xml bearbeiten und die Eigenschaft enableSeamlessFailover zum Element properties.db2.jcc der MobileFirst- und Application-Center-Datenquellen hinzufügen. Beispiel:

<dataSource jndiName="jdbc/WorklightAdminDS" transactional="false">
  <jdbcDriver libraryRef="DB2Lib"/>
  <properties.db2.jcc databaseName="WLADMIN"  currentSchema="WLADMSC"
                      serverName="db2server" portNumber="50000"
                      enableSeamlessFailover= "1"
                      user="worklight" password="worklight"/>
</dataSource>

Konfiguration von WebSphere Application Server

Führen Sie in der Administrationskonsole von WebSphere Application Server für jede MobileFirst- und Application-Center-Datenquelle die folgenden Schritte aus:

1. Navigieren Sie zu Ressourcen → JDBC → Datenquellen → Datenquellenname.
2. Wählen Sie Neu aus und fügen Sie die folgende angepasste Eigenschaft hinzu bzw. aktualisieren Sie den Wert, wenn es die Eigenschaft bereits gibt: enableSeamlessFailover : 1
3. Klicken Sie auf Anwenden.
4. Speichern Sie Ihre Konfiguration.

Weitere Informationen zum Konfigurieren einer Verbindung zu einer DB2-HADR-Datenbank finden Sie unter https://www.ibm.com/support/knowledgecenter/SSAW57_8.5.5/com.ibm.websphere.nd.multiplatform.doc/ae/tdat_db2_hadr.html?cp=SSAW57_8.5.5%2F3-3-6-3-3-0-7-3&lang=de”>Verbindung für eine HADR-aktivierte DB2-Datenbank konfigurieren.

Behandlung von veralteten Verbindungen

Konfigurieren Sie Ihren Anwendungsserver so, dass Probleme mit der Überschreibung von Datenbankzeitlimits vermieden werden.

Der Datenbankverbindungscode des Java-Anwendungsserverprofils generiert eine Ausnahme StaleConnectionException, wenn ein JDBC-Treiber einen nicht behebbaren Fehler für eine Verbindungsanforderung oder Operation zurückgibt. StaleConnectionException wird ausgelöst, wenn der Datenbankanbieter eine Ausnahme absetzt, um anzuzeigen, dass eine zurzeit im Verbindungspool enthaltene Verbindung nicht mehr gültig ist. Zu dieser Ausnahme kann es aus vielen Gründen kommen. Am häufigsten tritt die Ausnahme StaleConnectionException ein, wenn beim Abrufen von Verbindungen aus dem Datenbankverbindungspool festgestellt wird, dass das Zeitlimit für eine Verbindung überschritten ist oder dass eine länger ungenutzte Verbindung gelöscht wurde.

Sie können Ihren Anwendungsserver so konfigurieren, dass diese Ausnahme vermieden wird.

Apache-Tomcat-Konfiguration

MySQL
Die MySQL-Datenbank schließt ihre Verbindungen, wenn für eine Verbindung ein bestimmter Zeitraum ohne Aktivität abgelaufen ist. Dieses Zeitlimit wird mit der Systemvariablen wait_timeout definiert. Der Standardwert ist 28000 Sekunden (8 Stunden).

Wenn eine Anwendung versucht, eine Verbindung zur Datenbank herzustellen, nachdem MySQL die Verbindung geschlossen hat, wird die folgende Ausnahme generiert:

com.mysql.jdbc.exceptions.jdbc4.MySQLNonTransientConnectionException: No operations allowed after statement closed.

Bearbeiten Sie die Dateien server.xml und context.xml und fügen Sie für jedes <Resource>-Element die folgenden Eigenschaften hinzu:

• testOnBorrow=”true”
• validationQuery=”select 1”

Beispiel:

<Resource name="jdbc/AppCenterDS"
  type="javax.sql.DataSource"
  driverClassName="com.mysql.jdbc.Driver"
  ...
  testOnBorrow="true"
  validationQuery="select 1"
/>

Konfiguration von WebSphere Application Server Liberty Profile

Bearbeiten Sie die Datei server.xml und fügen Sie für jedes <dataSource>-Element (Laufzeit- und Application-Center-Datenbank) ein Element <connectionManager> mit der Eigenschaft agedTimeout hinzu:

<connectionManager agedTimeout="Zeitlimitwert"/>

Der Zeitlimitwert richtet sich im Wesentlichen nach der Anzahl gleichzeitig geöffneter Verbindungen, aber auch nach der Mindestanzahl und der maximalen Anzahl von Verbindungen im Pool. Sie müssen die verschiedenen connectionManager-Attribute also optimieren und die am besten geeigneten Werte finden. Weitere Informationen zum Element connectionManager finden Sie unter Liberty: Configuration elements in the server.xml file.

Hinweis: MySQL in Kombination mit WebSphere Application Server Liberty Profile oder WebSphere Application Server Full Profile ist keine unterstützte Konfiguration. Weitere Informationen finden Sie unter WebSphere Application Server Support Statement. Sie können IBM DB2 oder eine andere von WebSphere Application Server unterstützte Datenbank verwenden, um die Vorteile einer Konfiguration zu nutzen, die vollständig vom IBM Support unterstützt wird.

Veraltete Daten nach dem Erstellen oder Löschen von Apps in der MobileFirst Operations Console

Wenn Sie in einem Tomcat 8 Application Server eine MySQL-Datenbank verwenden, wird für einige Serviceaufrufe der MobileFirst Operations Console ein Fehler 404 zurückgegeben.

Wenn Sie in einem Tomcat 8 Application Server mit einer MySQL-Datenbank arbeiten und in der MobileFirst Operations Console eine App löschen oder eine neue App hinzufügen, sehen Sie nach mehrfacher Aktualisierung der Konsolenanzeige möglicherweise veraltete Daten. Benutzer könnten beispielsweise eine bereits gelöschte App in der Liste sehen.

Sie können dieses Problem umgehen, indem Sie die Isolationsstufe in der Datenquelle oder im Datenbankmanagementsystem auf READ_COMMITTED setzen.

Die Bedeutung von READ_COMMITTED ist in der MySQL-Dokumentation unter http://dev.mysql.com/doc/refman/5.7/en/innodb-transaction-isolation-levels.html erläutert.

• Wenn Sie die Isolationsstufe in der Datenquelle auf READ_COMMITTED setzen möchten, müssen Sie die Tomcat-Konfigurationsdatei server.xml modifizieren. Fügen Sie im Abschnitt <Resource name=”jdbc/mfpAdminDS” …/> das Attribut defaultTransactionIsolation=”READ_COMMITTED” hinzu.
• Wenn Sie die Isolationsstufe im Datenbankmanagementsystem global auf READ_COMMITTED setzen möchten, lesen Sie sich die Seite SET TRANSACTION Syntax in der MySQL-Dokumentation unter http://dev.mysql.com/doc/refman/5.7/en/set-transaction.html durch.

Konfiguration von WebSphere Application Server Full Profile

DB2 oder Oracle
Wenn Sie Probleme mit veralteten Verbindungen auf ein Minimum reduzieren möchten, überprüfen Sie in der Administrationskonsole von WebSphere Application Server die Verbindungspoolkonfiguration für jede Datenquelle.

1. Melden Sie sich bei der Administrationskonsole von WebSphere Application Server an.
2. Wählen Sie Ressourcen → JDBC-Provider → Datenbank-JDBC-Provider → Datenquellen → Ihre_Datenquelle → Eigenschaften des Verbindungspools aus.
3. Setzen Sie Mindestanzahl von Verbindungen auf den Wert 0.
4. Setzen Sie das Bereinigungsintervall auf einen Wert, der kleiner als der Wert für das Zeitlimit für nicht verwendete Verbindungen ist.
5. Stellen Sie sicher, dass die Eigenschaft Löschrichtlinie auf (die Standardeinstellung) Gesamter Pool gesetzt ist.

Weitere Informationen finden Sie unter Connection pool settings.

MySQL

1. Melden Sie sich bei der Administrationskonsole von WebSphere Application Server an.
2. Wählen Sie Ressourcen → JDBC → Datenquellen aus.
3. Gehen Sie für jede MySQL-Datenquelle wie folgt vor:
   • Klicken Sie auf die Datenquelle.
   • Wählen Sie unter Weitere Eigenschaften die Option Eigenschaften des Verbindungspools aus.

   • Ändern Sie den Wert der Eigenschaft Zeitlimit für veraltete Verbindungen. Der Wert muss kleiner sein als der Wert für die MySQL-Systemvariable wait_timeout, damit die Verbindungen bereinigt werden, bevor sie von MySQL geschlossen werden.

   • Klicken Sie auf OK.

Hinweis: MySQL in Kombination mit WebSphere Application Server Liberty Profile oder WebSphere Application Server Full Profile ist keine unterstützte Konfiguration. Weitere Informationen finden Sie unter WebSphere Application Server Support Statement. Sie können IBM DB2 oder eine andere von WebSphere Application Server unterstützte Datenbank verwenden, um die Vorteile einer Konfiguration zu nutzen, die vollständig vom IBM Support unterstützt wird.

Protokollierungs- und Überwachungsmechanismen konfigurieren

Die Mobile Foundation schreibt Fehler, Warnungen und Informationsnachrichten in eine Protokolldatei. Der zugrunde liegende Protokollierungsmechanismus ist je nach Anwendungsserver verschieden.

MobileFirst Server

Die Mobile Foundation (oder kurz MobileFirst Server) verwendet das Standardpaket java.util.logging. Die gesamte MobileFirst-Protokollierung erfolgt standardmäßig in den Protokolldateien des Anwendungsservers. Sie können die Protokollierung von MobileFirst Server mit den in jedem Anwendungsserver verfügbaren Standardtools steuern. Wenn Sie beispielsweise in WebSphere Application Server Liberty die Traceprotokollierung aktivieren möchten, fügen Sie zur Datei server.xml ein Element “trace” hinzu. Wenn Sie die Traceprotokollierung in WebSphere Application Server aktivieren möchten, aktivieren Sie in der Protokollierungsanzeige der Konsole den Trace für MobileFirst-Protokolle.

Die Namen aller MobileFirst-Protokolle beginnen mit com.ibm.mfp.
Die Namen der Application-Center-Protokolle beginnen mit com.ibm.puremeap.

Weitere Informationen zu den Protokollierungsmodellen der einzelnen Anwendungsserver und zur Position der Protokolldateien finden Sie in der Dokumentation zum jeweiligen Anwendungsserver. Vergleichen Sie dazu die Angaben in der folgenden Tabelle.

Zuordnung der Protokollstufen

MobileFirst Server verwendet die API java.util.logging. Die Zuordnung der Protokollierungsstufen sieht wie folgt aus:

• WL.Logger.debug: FINE
• WL.Logger.info: INFO
• WL.Logger.warn: WARNING
• WL.Logger.error: SEVERE

Überwachungstools für Protokolle

Für Apache Tomcat können Sie IBM Operations Analytics - Log Analysis oder andere Überwachungstools für Protokolldateien nach Industrienorm verwenden, um Protokolle zu überwachen und Fehler und Warnungen hervorzuheben.

Verwenden Sie für WebSphere Application Server die Protokollanzeigefunktionen, die um IBM Knowledge Center beschrieben sind. Die URLs sind auf dieser Seite in der Tabelle im MobileFirst-Server-Abschnitt aufgelistet.

Back-End-Konnektivität

Wenn Sie den Trace für die Überwachung der Back-End-Konnektivität aktivieren möchten, lesen Sie die Dokumentation zu Ihrer Anwendungsserverplattform auf dieser Seite in der Tabelle im Abschnitt MobileFirst Server. Verwenden Sie das Paket com.ibm.mfp.server.js.adapter und setzen Sie die Protokollstufe auf FINEST.

Prüfprotokoll für Verwaltungsoperationen

Die MobileFirst Operations Console speichert ein Prüfprotokoll für Anmeldung, Abmeldung und alle Verwaltungsoperationen, z. B. die Implementierung von Apps oder Adaptern oder das Sperren von Apps. Sie können das Prüfprotokoll inaktivieren, indem Sie die JNDI-Eigenschaft mfp.admin.audit der Webanwendung für den MobileFirst-Verwaltungsservice (mfp-admin-service.war) auf “false” setzen.

Wenn das Prüfprotokoll aktiviert ist, können Sie es von der MobileFirst Operations Console herunterladen. Klicken Sie dazu in der Fußzeile der Seite auf den Link Prüfprotokoll.

Probleme bei der Anmeldung und der Authentifizierung

Aktivieren Sie zur Diagnose von Anmelde- und Authentifizierungsproblemen das Paket com.ibm.mfp.server.security für Traces und setzen Sie die Protokollstufe auf FINEST.

Mehrere Laufzeiten konfigurieren

Sie können MobileFirst Server mit mehreren Laufzeiten konfigurieren und in der MobileFirst Operations Console eine visuelle Abgrenzung der Anwendungstypen erstellen.

Hinweis: Eine Mobile-Foundation-Server-Instanz, die mit dem IBM Cloud-Service “Mobile Foundation” erstellt wurde, bietet keine Unterstützung für mehrere Laufzeiten. Im IBM Cloud-Service müssen Sie stattdessen mehrere Serviceinstanzen erstellen.

Fahren Sie mit folgenden Abschnitten fort:

• Mehrere Laufzeiten in WebSphere Liberty Profile konfigurieren
• In verschiedenen Laufzeiten Anwendungen registrieren und Adapter implementieren
• Laufzeitkonfigurationen exportieren und importieren

Mehrere Laufzeiten in WebSphere Liberty Profile konfigurieren

1. Öffnen Sie die Datei server.xml des Anwendungsservers. Normalerweise befindet sich die Datei im Ordner [Anwendungsserver]/usr/servers/Servername/. Wenn Sie beispielsweise das MobileFirst Developer Kit verwenden, finden Sie die Datei unter [Installationsordner]/mfp-server/usrs/servers/mfp/server.xml.

2. Fügen Sie ein zweites Element application hinzu:

   <application id="second-runtime" name="second-runtime" location="mfp-server.war" type="war">
        <classloader delegation="parentLast">
            </classloader>
   </application>
   

3. Fügen Sie eine zweite Gruppe von JNDI-Einträgen hinzu:

   <jndiEntry jndiName="second-runtime/mfp.analytics.url" value='"http://localhost:9080/analytics-service/rest"'/>
   <jndiEntry jndiName="second-runtime/mfp.analytics.console.url" value='"http://localhost:9080/analytics/console"'/>
   <jndiEntry jndiName="second-runtime/mfp.analytics.username" value='"admin"'/>
   <jndiEntry jndiName="second-runtime/mfp.analytics.password" value='"admin"'/>
   <jndiEntry jndiName="second-runtime/mfp.authorization.server" value='"embedded"'/>
   

4. Fügen Sie ein zweites Element dataSource hinzu:

   <dataSource jndiName="second-runtime/jdbc/mfpDS" transactional="false">
        <jdbcDriver libraryRef="DerbyLib"/>
        <properties.derby.embedded databaseName="${wlp.install.dir}/databases/second-runtime" user='"MFPDATA"'/>
   </dataSource>
   

   Hinweis:

   • Stellen Sie sicher, dass dataSource auf ein anderes Datenbankschema zeigt.
   • Vergewissern Sie sich, dass für die neue Laufzeit eine andere Datenbankinstanz erstellt wurde.
   • Fügen Sie in der Entwicklungsumgebung zum untergeordneten Element properties.derby.embedded den Eintrag createDatabase="create" hinzu.

5. Starten Sie den Anwendungsserver neu.

In verschiedenen Laufzeiten Anwendungen registrieren und Adapter implementieren

Wenn ein MobileFirst Server mit mehreren Laufzeiten konfiguriert ist, verläuft die Registrierung von Anwendungen und die Implementierung von Adaptern etwas anders.

• Registrierung und Implementierung über die MobileFirst Operations Console
• Registrierung und Implementierung über die Befehlszeile

Registrierung und Implementierung über die MobileFirst Operations Console

Wenn Sie diese Aktionen in der MobileFirst Operations Console ausführen, müssen Sie jetzt die Ziellaufzeit für die Registrierung oder Implementierung auswählen.

Registrierung und Implementierung über die Befehlszeile

Wenn Sie diese Aktionen mit dem Befehlszeilentool (mfpdev) ausführen, müssen Sie jetzt den Namen der Ziellaufzeit für die Registrierung oder Implementierung hinzufügen.

Registrierung einer Anwendung: mfpdev app register <Servername> <Laufzeitname>.

mfpdev app register local second-runtime

Implementierung eines Adapters: mfpdev adapter deploy <Servername> <Laufzeitname>.

mfpdev adapter deploy local second-runtime

• In der MobileFirst CLI ist local der Name der Standardserverdefinition. Ersetzen Sie local durch den Namen einer Serverdefinition, die als Ziel für die Registrierung oder Implementierung verwendet werden soll.
• Laufzeitname ist der Name der Ziellaufzeit für die Registrierung oder Implementierung.

Weitere Informationen können Sie mit den folgenden help-Befehlen der CLI abrufen:

• mfpdev help server add
• mfpdev help app register
• mfpdev help adapter deploy

Laufzeitkonfigurationen exportieren und importieren

Mit den REST-APIs des MobileFirst-Server-Verwaltungsservice können Sie eine Laufzeitkonfiguration exportieren und in einen anderen MobileFirst Server importieren.

Sie können beispielsweise eine Laufzeitkonfiguration in einer Entwicklungsumgebung definieren, dann die Konfiguration exportieren und die Konfiguration schließlich für ein Schnell-Setup in eine Testumgebung importieren. In der Testumgebung können Sie die Definition der Konfiguration an die Umgebungsanforderungen anpassen.

In den API-Referenzinformationen erfahren Sie, welche REST-APIs zur Verfügung stehen.

Lizenzüberwachung konfigurieren

Die Lizenzüberwachung ist standardmäßig aktiviert. In den folgenden Abschnitten erfahren Sie, wie Sie die Lizenzüberwachung konfigurieren können. Weitere Informationen zur Lizenzüberwachung finden Sie unter Lizenzüberwachung.

• Lizenzüberwachung für Clientgeräte und adressierbare Geräte konfigurieren
• Protokolldateien von IBM License Metric Tool konfigurieren

Lizenzüberwachung für Clientgeräte und adressierbare Geräte konfigurieren

Die Lizenzüberwachung für Clientgeräte und adressierbare Geräte ist standardmäßig aktiviert. Die Lizenzberichte sind in der MobileFirst Operations Console verfügbar. Sie können die folgenden JNDI-Eigenschaften angeben, um die Standardeinstellungen für die Lizenzüberwachung zu ändern.

Hinweis: Wenn in Ihrem Vertrag die Tokenlizenzierung vereinbart ist, lesen Sie auch die Informationen unter Installation und Konfiguration für Tokenlizenzierung.

Sie können die folgenden JNDI-Eigenschaften angeben, um die Standardeinstellungen für die Lizenzüberwachung zu ändern.

mfp.device.decommission.when
Anzahl von Tagen der Inaktivität, nach denen ein Gerät mit der Aufgabe für Gerätestilllegung stillgelegt wird. Für Lizenzberichte werden stillgelegte Geräte nicht als aktive Geräte gezählt. Der Standardwert für diese Eigenschaft liegt bei 90 Tagen. Legen Sie keinen Wert unter 30 Tagen fest, wenn Ihre Software auf der Basis von Clientgeräten oder adressierbaren Geräten lizenziert wird. Andernfalls sind die Lizenzberichte unter Umständen nicht ausreichend, um die Einhaltung der Lizenzvereinbarung nachzuweisen.

mfp.device.archiveDecommissioned.when
Ein Wert, der in Tagen definiert, wann stillgelegte Geräte bei Ausführung der Stilllegungsaufgabe in eine Archivdatei aufgenommen werden. Die archivierten Geräte werden in eine Datei im IBM MobileFirst-Server-Verzeichnis home\devices_archive geschrieben. Der Name der Datei enthält die Zeitmarke für den Erstellungszeitpunkt der Archivdatei. Der Standardwert liegt bei 90 Tagen.

mfp.device.decommissionProcessingInterval
Definiert, wie häufig eine Stilllegung durchgeführt wird (Intervall in Sekunden). Standardwert: 86400 (ein Tag). Bei der Stilllegung werden folgende Aktionen ausgeführt:

• Inaktive Geräte werden ausgehend von der Einstellung der Eigenschaft mfp.device.decommission.when stillgelegt.
• Ältere stillgelegte Geräte können ausgehend von der Einstellung der Eigenschaft mfp.device.archiveDecommissioned.when archiviert werden.
• Der Lizenzüberwachungsbericht wird generiert.

mfp.licenseTracking.enabled
Mit dem Wert dieser Eigenschaft wird die Lizenzüberwachung in der Mobile Foundation aktiviert oder inaktiviert. Die Lizenzüberwachung ist standardmäßig aktiviert. Aus Leistungsgründen können Sie dieses Flag inaktivieren, wenn die Mobile Foundation weder auf der Basis von Clientgeräten noch auf der Basis von adressierbaren Geräten lizienziert wird. Bei inaktivierter Geräteüberwachung sind auch die Lizenzberichte inaktiviert und es werden keine Lizenzmetriken generiert. In dem Fall weden nur Datensätze von IBM License Metric Tool für die Anwendungszählung generiert.

Weitere Informationen zur Angabe von JNDI-Eigenschaften finden Sie in der Liste der JNDI-Eigenschaften für die MobileFirst-Laufzeit.

Protokolldateien von IBM License Metric Tool konfigurieren

Die Mobile Foundation generiert SLMT-Dateien (IBM Software License Metric Tag). Versionen des IBM License Metric Tool, die SLMT unterstützen, können Berichte zum Lizenzbedarf generieren. Lesen Sie die folgenden Informationen, damit Sie wissen, wie die Position und die maximale Größe der generierten Dateien konfiguriert werden.

SLMT-Dateien (IBM Software License Metric Tag) sind standardmäßig in folgenden Verzeichnissen enthalten:

• Windows: %ProgramFiles%\ibm\common\slm
• UNIX und UNIX-ähnliche Betriebssysteme: /var/ibm/common/slm

Wenn die Verzeichnisse schreibgeschützt sind, werden die Dateien im Protokollverzeichnis des Anwendungsservers erstellt, in dem die MobileFirst-Laufzeitumgebung ausgeführt wird.

Sie können die Position und die Verwaltung der Dateien mit folgenden Eigenschaften konfigurieren:

• license.metric.logger.output.dir: Position der SLMT-Dateien
• license.metric.logger.file.size: Maximale Größe einer SLMT-Datei, bei deren Erreichung eine Rotation erfolgt. Die Standardgröße liegt bei 1 MB.
• license.metric.logger.file.number: Maximale Anzahl der SLMT-Archivdateien bei aktiver Rotation. Die Standardanzahl ist 10.

Wenn Sie die Standardwerte ändern möchten, müssen Sie eine Java-Eigenschaftendatei im Format Schlüssel=Wert erstellen und mit der JVM-Eigenschaft license_metric_logger_configuration den Pfad zu den Eigenschaften angeben.

Weitere Informationen zu Berichten des IBM License Metric Tool finden Sie unter Integration des IBM License Metric Tool.

SSL-Konfiguration von WebSphere Application Server und HTTP-Adapter

Sie können mit einer Einstellung dafür sorgen, dass HTTP-Adapter von der WebSphere-SSL-Konfiguration profitieren.

Standardmäßig machen HTTP-Adapter keinen Gebrauch von WebSphere-SSL mit der Verkettung des JRE-Truststores und des IBM MobileFirst-Platform-Server-Keystores (siehe Beschreibung unter Keystore von MobileFirst Server konfigurieren). Lesen Sie auch die Informationen unter SSL zwischen Adaptern und Back-End-Servern mit selbst signierten Zertifikaten konfigurieren.

Wenn HTTP-Adapter in der Lage sein sollen, die WebSphere-SSL-Konfiguration zu nutzen, müssen Sie die JNDI-Eigenschaft ssl.websphere.config auf true setzen. Diese Einstellung hat die folgenden Auswirkungen in der hier genannten Reihenfolge:

1. In WebSphere ausgeführte Adapter verwenden den WebSphere-Keystore und nicht den Keystore von MobileFirst Server.
2. Wenn die Eigenschaft ssl.websphere.alias gesetzt ist, verwendet der Adapter die SSL-Konfiguration, die dem mit dieser Eigenschaft angegebenen Alias zugeordnet ist.