Konfigurationsänderungen in Deltaprüfpunkten suchen

Wenn automatische Repository-Prüfpunkte aktiviert sind, erstellt das Produkt bei jeder Änderung, die am Konfigurationsrepository vorgenommen wird, einen Deltaprüfpunkt. Eine komprimierte ZIP-Datei für den Deltaprüfpunkt enthält die vorherige und die nachfolgende Version der Konfigurationsdateien, die geändert wurden. Sie können den Inhalt der komprimierten Datei entpacken und anschließend die entpackten Dateien untersuchen, um zu ermitteln, welche Änderungen an der Konfiguration vorgenommen wurden.

Vorbereitende Schritte

Aktivieren Sie das Produkt, sodass Deltaprüfpunkte automatisch erstellt werden:

  1. Klicken Sie in der Administrationskonsole auf Systemverwaltung > Erweiterter Repository-Service.
  2. Wählen Sie Automatische Repository-Prüfpunkte aktivieren aus.
  3. Geben Sie für Tiefe automatisch generierter Prüfpunkte die Anzahl der beizubehaltenden Deltaprüfpunkte an.
  4. Speichern Sie die Änderungen.

Informationen zu diesem Vorgang

Sie können mit einem Deltaprüfpunkt kürzlich vorgenommene Änderungen an der Produktkonfiguration rückgängig machen.

Sie können mit einem Deltaprüfpunkt auch ermitteln, welche Änderungen an der Konfiguration vorgenommen wurden. In diesem Artikel wird beschrieben, wie der Inhalt eines extrahierten Deltarepositorys zu interpretieren ist, um Änderungen an der Konfiguration zu ermitteln.

Vorgehensweise

  1. Exportieren Sie einen Deltaprüfpunkt.
    1. Klicken Sie auf Systemverwaltung > Erweiterter Repository-Service > Repository-Prüfpunkte.
    2. Wählen Sie den Deltaprüfpunkt auf der Seite Repository-Prüfpunkte aus und klicken Sie auf Exportieren.
    3. Wählen Sie den Namen der komprimierten ZIP-Datei auf der Seite Repository-Prüfpunkte exportieren aus.
    4. Speichern Sie die Datei an einer bestimmten Position.
  2. Entpacken Sie die Dateien aus der exportierten komprimierten Datei.
  3. Untersuchen Sie die entpackten Dateien, um Änderungen an der Konfiguration zu ermitteln.

Beispiel

Lesen Sie die folgenden Informationen, um festzustellen, wie verschiedene Änderungen an der Produktkonfiguration in entpackten Dateien angezeigt werden:

Neue Konfigurationsdateien weisen das Suffix .ADDED auf
Wenn Konfigurationsdateien erstellt werden, ist die "before"-Version eine Markierungsdatei mit dem Suffix .ADDED, wie z. B. server.xml.ADDED, während die "after"-Version die tatsächliche Datei ist, die erstellt wird. Neue Konfigurationsdateien entstehen aus Aktionen wie z. B. dem Erstellen von Knoten, Clustern, Anwendungsservern, Anwendungen oder Service-Integration-Bus-Artefakten.
Gelöschte Konfigurationsdateien weisen das Suffix .DELETED auf
Wenn Konfigurationsdateien gelöscht werden, besteht die "before"-Version aus dem Inhalt der gelöschten Datei, während die "after"-Version eine Markierungsdatei mit dem Suffix .DELETED ist.
Geänderte Konfigurationsdateien weisen die Versionen before (vorher) und after (nachher) auf
Wenn vorhandene Konfigurationsdateien geändert werden, ist die "before"-Version die ursprüngliche Konfiguration, während die "after"-Version die Datei mit den vorgenommenen Änderungen ist. Änderungen an vorhandenen Konfigurationsdateien entstehen aus Aktionen wie z. B. der Erstellung oder Änderungen von Ressourcen oder der Änderung von JVM-Einstellungen (Java Virtual Machine).

Wenn die geänderten Dateien Text- oder XML-Dateien sind, können Sie ein Tool für den Textvergleich verwenden, um die Unterschiede zwischen der "before"- und der "after"-Version zu ermitteln. Ein grafisch orientiertes Tool für den Textvergleich, das die zwei Dateien nebeneinander im Vergleich anzeigt, ist für die Hervorhebung der Unterschiede effektiver. Wenn ein Konfigurationselement nur Änderungen des Attributs xmi:id aufweist, können Sie diese Änderungen ignorieren, weil sie keinerlei Verhalten ändern.

Sie können Tools für den Textvergleich nicht zum Vergleichen von Binärdateien wie z. B. Keystore- und Truststore-Dateien, binären Anwendungsdateien und gemeinsam genutzten Bibliotheken verwenden. Für Keystore- und Truststore-Dateien verwenden Sie iKeyman oder andere Tools für die Schlüsselverwaltung, um den Inhalt dieser Dateien auf Unterschiede in den Zertifikaten hin zu untersuchen. Binäre Anwendungsdateien oder gemeinsam genutzte JAR-Bibliotheksdateien (Java Archiv) vergleichen Sie manuell, indem Sie JAR- oder ZIP-Dienstprogramme zum Entpacken der Dateien verwenden.

Änderungen an der erweiterten Konfiguration des Repository-Service befinden sich in repository.xml-Dateien
Beim Aktivieren oder Ändern der Konfiguration des erweiterten Repository-Service weist das extrahierte Deltarepository eine Änderung der Datei repository.xml auf. Die entpackte komprimierte Datei weist beispielsweise folgenden Inhalt auf:
before/cells/isthmusCell03/repository/repository.xml
after/cells/isthmusCell03/repository/repository.xml

Die after-Version der Datei repository.xml enthält die aktualisierte Konfiguration. Im folgenden Beispiel enthält die after-Version einen aktualisierten Wert für autoCheckpointsDepth:

repositorycheckpoint:ExtendedRepositoryService xmi:version="2.0"
xmlns:xmi="http://www.omg.org/XMI"
xmlns:repositorycheckpoint="http://www.ibm.com/websphere/appserver/schemas/6.0/repositorycheckpoint.xmi"
xmi:id="ExtendedRepositoryService_1" checkpointRoot="${USER_INSTALL_ROOT}/checkpoints" 
  autoCheckpointsEnabled="true" autoCheckpointsDepth="50"/>
Das Hinzufügen eines Knotens führt zu drei before- und drei after-Dateiversionen
Beim Hinzufügen eines Knotens werden möglicherweise bis zu drei Deltaprüfpunkte erstellt. Die erste Repository-Änderung ist die Operation "addNode" selbst. Das "before"-Image enthält überwiegend Markierungsdateien im Format Dateiname.ADDED, um anzuzeigen, dass die Dateien zuvor nicht vorhanden waren. Das "after"-Image enthält die hinzugefügte Datei. Darüber hinaus ändert addNode auch die Konfiguration für Systemanwendungen sowie Sicherheitseinstellungen in der Datei security.xml. Beispiel:
before/cells/isthmusCell03/nodes/isthmusNode02/node.xml.ADDED
...
before/cells/isthmusCell03/applications/ibmasyncrsp.ear/deployments/ibmasyncrsp/deployment.xml
...
before/cells/isthmusCell03/security.xml
...
after/cells/isthmusCell03/nodes/isthmusNode02/node.xml
after/cells/isthmusCell03/applications/ibmasyncrsp.ear/deployments/ibmasyncrsp/deployment.xml
after/cells/isthmusCell03/security.xml

Zu den Änderungen an der Datei security.xml gehören Hinzufügungen zur SSL-Konfiguration und zu Keystores oder Truststores. Die Hinzufügung der neuen SSL-Konfiguration sieht wie folgt aus:

<repertoire xmi:id="SSLConfig_1326647216593" alias="NodeDefaultSSLSettings"
  managementScope="ManagementScope_1326647216593">
   <setting xmi:id="SecureSocketLayer_1326647216593" clientAuthentication="false" securityLevel="HIGH"
     enabledCiphers="" jsseProvider="IBMJSSE2" sslProtocol="SSL_TLS" keyStore="KeyStore_1326647216593"
     trustStore="KeyStore_2" trustManager="TrustManager_1326647216593"
     keyManager="KeyManager_1326647216593"/>
</repertoire>
...
<managementScopes xmi:id="ManagementScope_1326647216593"
  scopeName="(cell):isthmusCell03:(node):isthmusNode02" scopeType="node"/>
...

Keystores und Truststores auf Knotenebene sowie Trust-Manager sehen in etwa wie folgt aus:

<keyStores xmi:id="KeyStore_1326647216593" name="NodeDefaultKeyStore" password="{xor}CDo9Hgw="
  provider="IBMJCE" location="${CONFIG_ROOT}/cells/isthmusCell03/nodes/isthmusNode02/key.p12"
  type="PKCS12" fileBased="true" hostList="" description="Standard-Keystore fuer isthmusNode02"
  usage="SSLKeys" managementScope="ManagementScope_1326647216593"/>
   <keyStores xmi:id="KeyStore_1326647216594" name="NodeDefaultTrustStore"
     password="{xor}CDo9Hgw=" provider="IBMJCE"
     location="${CONFIG_ROOT}/cells/isthmusCell03/nodes/isthmusNode02/trust.p12" type="PKCS12"
     fileBased="true" hostList="" description="Standard-Truststore fuer isthmusNode02"
     usage="SSLKeys" managementScope="ManagementScope_1326647216593"/>
...
<trustManagers xmi:id="TrustManager_1326647216594" name="IbmX509" provider="IBMJSSE2"
  algorithm="IbmX509" managementScope="ManagementScope_1326647216593"/>
<trustManagers xmi:id="TrustManager_1326647216593" name="IbmPKIX" provider="IBMJSSE2"
  algorithm="IbmPKIX" trustManagerClass="" managementScope="ManagementScope_1326647216593">
  <additionalTrustManagerAttrs xmi:id="DescriptiveProperty_1326647216593"
    name="com.ibm.security.enableCRLDP" value="false" type="boolean" displayNameKey=""
    nlsRangeKey="" hoverHelpKey="" range="" inclusive="false" firstClass="false"/>
  ...
</trustManagers>
...
<keyManagers xmi:id="KeyManager_1326647216593" name="IbmX509" provider="IBMJSSE2"
  algorithm="IbmX509" keyManagerClass="" managementScope="ManagementScope_1326647216593"/>
  ...
  <sslConfigGroups xmi:id="SSLConfigGroup_1326647216593" name="isthmusNode02" direction="inbound"
    sslConfig="SSLConfig_1326647216593" managementScope="ManagementScope_1326647216593"/>
  <sslConfigGroups xmi:id="SSLConfigGroup_1326647216594" name="isthmusNode02" direction="outbound"
    sslConfig="SSLConfig_1326647216593" managementScope="ManagementScope_1326647216593"/>
  ...
  <properties xmi:id="Property_1326647216593" name="com.ibm.websphere.security.DeferTAItoSSO"
    value="com.ibm.ws.security.spnego.TrustAssociationInterceptorImpl"
    description="Trust-Association-Interceptors werden nach der Single-Sign-On-Benutzerprüfung aufgerufen."
    required="false"/>

Einige Systemanwendungen erhalten als Ziel neue Server auf dem neuen Knoten. Zu den Änderungen gehören möglicherweise neue Zielzuordnungen. Die Änderungen an der Anwendung "ibmasyncrsp" umfassen beispielsweise Änderungen an der Datei isthmusCell03/applications/ibmasyncrsp.ear/deployments/ibmasyncrsp/deployment.xml:

<targetMappings xmi:id="DeploymentTargetMapping_1326647226406" enable="true"
  target="ServerTarget_1326647226406"/>
  ...
  <targetMappings xmi:id="DeploymentTargetMapping_1326647226407"
    target="ServerTarget_1326647226406"/>
  ...
  <deploymentTargets xmi:type="appdeployment:ServerTarget" xmi:id="ServerTarget_1326647226406"
    name="server1" nodeName="isthmusNode02"/>

Wenn die automatische Plug-in-Generierung aktiviert ist, generiert das Produkt die Plug-in-Datei möglicherweise neu. Dies führt dazu, dass ein weiterer Deltaprüfpunkt erstellt wird, der in etwa wie folgt aussieht:

before/cells/plugin-cfg.xml.ADDED
after/cells/plugin-cfg.xml

Schließlich werden die Ports der Server auf dem neuen Knoten den Definitionen des virtuellen Hosts hinzugefügt:

before/cells/isthmusCell03/virtualhosts.xml
after/cells/isthmusCell03/virtualhosts.xml

Zu den Hinzufügungen zur Datei virtualhosts.xml gehört Folgendes:

<aliases xmi:id="HostAlias_1326647278546" hostname="*" port="9130"/>
<aliases xmi:id="HostAlias_1326647278609" hostname="*" port="9508"/>
<aliases xmi:id="HostAlias_1326647278671" hostname="*" port="5113"/>
<aliases xmi:id="HostAlias_1326647278718" hostname="*" port="5112"/>
Durch Erstellen von Clustern und Cluster-Membern werden cluster.xml-, serverindex.xml- und server.xml-Dateien geändert
Die Erstellung eines Clusters führt dazu, dass das Produkt die Datei cluster.xml dem Konfigurationsrepository hinzufügt. Durch die Erstellung eines Cluster-Members wird die Datei serverindex.xml des Knotens aktualisiert und eine neue Datei server.xml sowie zugehörige Konfigurationsdateien werden erstellt. Die Erstellung eines Clusters mit dem Namen TestCluster mit Membern auf zwei verschiedenen Knoten (TestCluster1_Node1_1 und TestCluster1_Node2_1) führt beispielsweise zu Änderungen in den folgenden Dateien:
before/cells/isthmusCell03/clusters/TestCluster1/cluster.xml.ADDED
before/cells/isthmusCell03/nodes/isthmusNode01/serverindex.xml
before/cells/isthmusCell03/nodes/isthmusNode02/serverindex.xml
before/cells/isthmusCell03/nodes/isthmusNode02/servers/TestCluster1_Node2_1/server.xml.ADDED
before/cells/isthmusCell03/nodes/isthmusNode01/servers/TestCluster1_Node1_1/server.xml.ADDED
...
after/cells/isthmusCell03/clusters/TestCluster1/cluster.xml
after/cells/isthmusCell03/nodes/isthmusNode01/serverindex.xml
after/cells/isthmusCell03/nodes/isthmusNode02/server
after/cells/isthmusCell03/nodes/isthmusNode02/servers/TestCluster1_Node2_1/server.xml
after/cells/isthmusCell03/nodes/isthmusNode01/servers/TestCluster1_Node1_1/server.xml
Durch Erstellen von Datenquellen werden resources.xml- und variables.xml-Dateien geändert
Durch die Erstellung einer Datenquelle ändert das Produkt die resources.xml- und variables.xml-Dateien. Beispiel:
before/cells/isthmusCell03/clusters/TestCluster1/resources.xml
before/cells/isthmusCell03/clusters/TestCluster1/variables.xml
after/cells/isthmusCell03/clusters/TestCluster1/resources.xml
after/cells/isthmusCell03/clusters/TestCluster1/variables.xml

In den Konfigurationsdateien wird wie folgt eine neue Factory angezeigt:

<factories xmi:type="resources.jdbc:CMPConnectorFactory" xmi:id="CMPConnectorFactory_1326647771671"
  name="TestCluster1DataSource_CF" authMechanismPreference="BASIC_PASSWORD"
  connectionDefinition="ConnectionDefinition_1054132487569" cmpDatasource="DataSource_1326647771656">
    <propertySet xmi:id="J2EEResourcePropertySet_1326647771671"/>
</factories>

In den Konfigurationsdateien wird wie folgt ein neuer JDBC-Provider mit einer Datenquelle angezeigt:

<resources.jdbc:JDBCProvider xmi:id="JDBCProvider_1326647771343"
  name="DB2 Universal JDBC Driver Provider (XA)"
  description="DB2-JCC-Provider für zweiphasiges Commit, der JDBC 3.0 unterstuetzt. Datenquellen,
    die diesen Provider verwenden, unterstützen die Verwendung von XA für die Ausführung einer
    zweiphasigen Commitverarbeitung. Die Verwendung eines Treibers des Typs 2 für den
    Anwendungsserver für z/OS wird für Datenquellen, die unter diesem Provider erstellt wurden,
    nicht unterstützt."
  providerType="DB2 Universal JDBC Driver Provider (XA)" isolatedClassLoader="false"
    implementationClassName="com.ibm.db2.jcc.DB2XADataSource" xa="true">
  ...
  <factories xmi:type="resources.jdbc:DataSource" xmi:id="DataSource_1326647771656"
    name="TestCluster1DataSource" jndiName="TestCluster1DataSource"
    description="DB2 Universal Driver Datasource"
    providerType="DB2 Universal JDBC Driver Provider (XA)" authMechanismPreference="BASIC_PASSWORD"
    authDataAlias="" manageCachedHandles="false" logMissingTransactionContext="true"
    xaRecoveryAuthAlias="" diagnoseConnectionUsage="false" relationalResourceAdapter="builtin_rra"
    statementCacheSize="10"
    datasourceHelperClassname="com.ibm.websphere.rsadapter.DB2UniversalDataStoreHelper">
    ...
  </factories>
</resources.jdbc:JDBCProvider>

Möglicherweise fällt Ihnen auf, dass einige Konfigurationselemente nur Änderungen von xml:id aufweisen. Diese Änderungen können Sie ignorieren. Die folgenden beiden Elemente weisen beispielsweise geänderte Werte für xml:id auf:

<displayNames xmi:id="DisplayName_1326647771359" value="WS_RdbResourceAdapter"/>
<displayNames xmi:id="DisplayName_1326647771360" value="WebSphere Default Messaging Provider"/>
Durch die Änderung von JVM-Einstellungen werden die server.xml-Dateien geändert
Das Produkt speichert Änderungen an den JVM-Einstellungen in der Datei server.xml:
before/cells/isthmusCell03/nodes/isthmusNode01/servers/TestCluster1_Node1_1/server.xml
after/cells/isthmusCell03/nodes/isthmusNode01/servers/TestCluster1_Node1_1/server.xml

Die folgenden Änderungen an den JVM-Einstellungen:

  • Ausführliche Garbage-Collection aktivieren
  • Anfangsgröße des Heapspeichers in 512 MB ändern
  • Maximale Größe des Heapspeichers in 768 MB ändern
  • Systemeigenschaft MyVar=MVal hinzufügen

führen wie folgt zu einer after-Version der Datei server.xml:

<jvmEntries xmi:id="JavaVirtualMachine_1326647543890" verboseModeClass="false"
  verboseModeGarbageCollection="true" verboseModeJNI="false" initialHeapSize="512"
  maximumHeapSize="768" runHProf="false" hprofArguments="" debugMode="false"
  debugArgs="-agentlib:jdwp=transport=dt_socket,server=y,suspend=n,address=7777"
  genericJvmArguments="-DMyVar=MyVal" executableJarFileName="" disableJIT="false">

Diese neue Version der Datei server.xml weist die zusätzlichen XML-Attribute executablejarFileName und disableJIT auf. Diese Attribute führen zu keiner Änderung im Verhalten, da ein verwalteter Anwendungsserver executableJarFileName nicht benötigt und JIT standardmäßig inaktiviert ist.

Durch das Erstellen eines Service Integration Bus werden SIB-Konfigurationsdateien geändert
Durch Erstellen eines Bus fügt das Produkt neue Dateien im Verzeichnis cells/Zellenname/buses/Busname hinzu und ändert die Busmemberkonfigurationen. Beispielsweise werden an der folgenden Datei Änderungen vorgenommen, nachdem ein Bus mit dem Namen TestBus mit Busmembern im Bereich TestCluster1 erstellt wurde:
before/cells/isthmusCell03/nodes/isthmusNode01/servers/TestCluster1_Node1_1/sib-service.xml
before/cells/isthmusCell03/nodes/isthmusNode02/servers/TestCluster1_Node2_1/sib-service.xml
before/templates/clusters/TestCluster1/servers/V8MemberTemplate/sib-service.xml
before/cells/isthmusCell03/coregroups/DefaultCoreGroup/coregroup.xml
before/cells/isthmusCell03/buses/TestBus/sib-authorisations.xml.ADDED
before/cells/isthmusCell03/buses/TestBus/sib-bus.xml.ADDED
before/cells/isthmusCell03/buses/TestBus/sib-destinations.xml.ADDED
before/cells/isthmusCell03/clusters/TestCluster1/sib-engines.xml.ADDED
after/cells/isthmusCell03/nodes/isthmusNode02/servers/TestCluster1_Node2_1/sib-service.xml
after/cells/isthmusCell03/nodes/isthmusNode01/servers/TestCluster1_Node1_1/sib-service.xml
after/templates/clusters/TestCluster1/servers/V8MemberTemplate/sib-service.xml
after/cells/isthmusCell03/coregroups/DefaultCoreGroup/coregroup.xml
after/cells/isthmusCell03/buses/TestBus/sib-authorisations.xml
after/cells/isthmusCell03/buses/TestBus/sib-bus.xml
after/cells/isthmusCell03/buses/TestBus/sib-destinations.xml
after/cells/isthmusCell03/clusters/TestCluster1/sib-engines.xml  

Änderungen an der Datei sib-service.xml für die vorhandenen Cluster-Member und für die Schablone auf Clusterebene aktivieren den SIBService. Im folgenden Beispiel wird durch das Aktivieren des SIBService die Eigenschaft enable auf true gesetzt:

sibservice:SIBService xmi:version="2.0" xmlns:xmi="http://www.omg.org/XMI"
  xmlns:sibservice="http://www.ibm.com/websphere/appserver/schemas/6.0/sibservice.xmi"
  xmi:id="SIBService_1" enable="true"/>
Fehler vermeiden Fehler vermeiden: Die after-Version der Konfigurationsdateien enthält möglicherweise Änderungen, durch die Kommentare aus der before-Version der Dateien entfernt werden.gotcha

Zusätzliche Konfigurationen werden in Abhängigkeit von den ausgewählten Richtlinien der Datei coregroup.xml hinzugefügt. Das folgende Beispiel zeigt das Hinzufügen einer Richtlinie für Hochverfügbarkeit:

<policies xmi:type="coregroup:OneOfNPolicy" xmi:id="OneOfNPolicy_1326648336750"
  name="TestCluster1.000-TestBus-3423A696EADD6FA7Policy"
  policyFactory="com.ibm.ws.hamanager.coordinator.policy.impl.OneOfNPolicyFactory"
  isAlivePeriodSec="120" quorumEnabled="false" failback="false" preferredOnly="false">
    <MatchCriteria xmi:id="MatchCriteria_1326648336765" name="type" value="WSAF_SIB"/>
    <MatchCriteria xmi:id="MatchCriteria_1326648336781" name="WSAF_SIB_MESSAGING_ENGINE"
       value="TestCluster1.000-TestBus"/>
</policies>
Durch Erstellen von Service-Integration-Bus-Zielen werden die sib-destinations.xml- und sib-engines.xml-Dateien geändert
Durch die Erstellung eines Ziels ändert das Produkt SIB-Konfigurationsdateien:
before/cells/isthmusCell03/buses/TestBus/sib-destinations.xml
before/cells/isthmusCell03/clusters/TestCluster1/sib-engines.xml
after/cells/isthmusCell03/buses/TestBus/sib-destinations.xml
after/cells/isthmusCell03/clusters/TestCluster1/sib-engines.xml

Die Datei sib-destinations.xml zeigt die Hinzufügung von SIBQueue:

<sibresources:SIBQueue xmi:id="SIBQueue_1326648599140" identifier="TestBusQeue1"
  uuid="0AA3CFB9BB0FFA92BE5BCB57" description="" overrideOfQOSByProducerAllowed="true"
  exceptionDestination="$DEFAULT_EXCEPTION_DESTINATION" sendAllowed="true" receiveAllowed="true">
    <localizationPointRefs xmi:id="SIBLocalizationPointRef_1326648599156" cluster="TestCluster1"
      engineUuid="3423A696EADD6FA7"/>
</sibresources:SIBQueue>

Die Datei sib-engines.xml zeigt die Hinzufügung von SIBQueueLocaliazationPoint:

<localizationPoints xmi:type="sibresources:SIBQueueLocalizationPoint"
  xmi:id="SIBQueueLocalizationPoint_1326648599156" identifier="TestBusQeue1@TestCluster1.000-TestBus"
  uuid="A55E76D18D6F4339" targetUuid="0AA3CFB9BB0FFA92BE5BCB57" highMessageThreshold="50000"/>

Die Verwendung von "targetUUID" korreliert mit der uuid von SIBQueue.

Durch Erstellen einer Warteschlangenverbindungsfactory wird die Datei resources.xml geändert
Das Produkt speichert Änderungen an Warteschlangenverbindungsfactorys in resources.xml-Dateien. Eine Warteschlangenverbindungsfactory, die auf der Clusterebene erstellt wurde, ändert die Datei resources.xml auf der Clusterebene:
before/cells/isthmusCell03/clusters/TestCluster1/resources.xml
after/cells/isthmusCell03/clusters/TestCluster1/resources.xml

Die Hinzufügung zur Datei resources.xml sieht wie folgt aus:

<factories xmi:type="resources.j2c:J2CConnectionFactory"
  xmi:id="J2CConnectionFactory_1326648753984" name="TestClusterQCF" jndiName="TestClusterQCF"
  description="" category="" authDataAlias="" manageCachedHandles="false"
  logMissingTransactionContext="false" xaRecoveryAuthAlias=""
  connectionDefinition="ConnectionDefinition_1326644816218">
  ...
</factories>
Durch Erstellen einer JMS-Warteschlange wird die Datei resources.xml geändert.
Durch Hinzufügen einer JMS-Warteschlange wird die Datei resources.xml geändert:
before/cells/isthmusCell03/clusters/TestCluster1/resources.xml
after/cells/isthmusCell03/clusters/TestCluster1/resources.xml

Durch Erstellen einer JMS-Warteschlange auf der Clusterebene wird die Datei resources.xml auf der Clusterebene geändert. Die Hinzufügung der Datei resources.xml sieht wie folgt aus:

<j2cAdminObjects xmi:id="J2CAdminObject_1326649181984" jndiName="jms/TestClusterQueue"
  name="TestClustereQueue" description="" adminObject="AdminObject_1326644816218">
  ...
</j2cAdminObjects>
Durch Implementieren einer Anwendung werden die Datei serverindex.xml und möglicherweise weitere Dateien geändert
Zur Anwendungsimplementierung gehören Änderungen an der Datei serverindex.xml der Zielknoten. Änderungen der Konfigurationen der Geschäftsanwendung und der Kompositionseinheit führen sogar bei Java EE-Anwendungen zu Änderungen der Dateien des Anwendungsverzeichnisses im Unterverzeichnis cells/Zellenname/applications/Anwendungsname. Beispielsweise verursacht die Implementierung der IVT-Anwendung in einem Cluster mit zwei Knoten Änderungen an den folgenden Dateien:
before/cells/isthmusCell03/nodes/isthmusNode01/serverindex.xml
before/cells/isthmusCell03/nodes/isthmusNode02/serverindex.xml
before/cells/isthmusCell03/blas/IVT Application/bver/BASE/bla.xml.ADDED
before/cells/isthmusCell03/cus/IVT Application/cver/BASE/controlOpDefs.xml.ADDED
before/cells/isthmusCell03/applications/IVT Application.ear/deployments/IVT Application/deployment.xml.ADDED
...
after/cells/isthmusCell03/nodes/isthmusNode01/serverindex.xml
after/cells/isthmusCell03/nodes/isthmusNode02/serverindex.xml
after/cells/isthmusCell03/blas/IVT Application/bver/BASE/bla.xml
after/cells/isthmusCell03/cus/IVT Application/cver/BASE/controlOpDefs.xml
after/cells/isthmusCell03/applications/IVT Application.ear/deployments/IVT Application/deployment.xml
...  

Die Hinzufügung zur Datei serverindex.xml auf jedem Knoten sieht wie folgt aus:

<deployedApplications>IVT Application.ear/deployments/IVT Application</deployedApplications>
Durch die Deinstallation einer Anwendung wird die Datei serverindex.xml geändert
Durch die Deinstallation einer Anwendung ändert das Produkt die Datei serverindex.xml, um die Anwendung zu entfernen und Anwendungsdateien zu löschen. In der exportierten komprimierten Datei wird an die gelöschten Dateien das Suffix .DELETED angehängt. Die folgenden Dateien sind von der Deinstallation der IVT-Anwendung von einem Cluster mit zwei Knoten betroffen:
before/cells/isthmusCell03/nodes/isthmusNode01/serverindex.xml
before/cells/isthmusCell03/nodes/isthmusNode02/serverindex.xml
before/cells/isthmusCell03/blas/IVT Application/bver/BASE/bla.xml
before/cells/isthmusCell03/cus/IVT Application/cver/BASE/controlOpDefs.xml
before/cells/isthmusCell03/applications/IVT Application.ear/deployments/IVT Application/deployment.xml
...
after/cells/isthmusCell03/nodes/isthmusNode01/serverindex.xml
after/cells/isthmusCell03/nodes/isthmusNode02/serverindex.xml
after/cells/isthmusCell03/blas/IVT Application/bver/BASE/bla.xml.DELETED
after/cells/isthmusCell03/cus/IVT Application/cver/BASE/controlOpDefs.xml.DELETED
after/cells/isthmusCell03/applications/IVT Application.ear/deployments/IVT Application/deployment.xml.DELETED
...
Durch Hinzufügen einer Zuordnung "Rolle-zu-Benutzer" wird die Datei admin-authz.xml geändert
Änderungen an der Verwaltungsberechtigung haben Auswirkungen auf die Datei admin-authz.xml:
before/cells/isthmusCell03/admin-authz.xml after/cells/isthmusCell03/admin-authz.xml

Wird der Benutzer user2 beispielsweise der Rolle operator hinzugefügt, ist der folgende Abschnitt der Datei admin-authz.xml in der before-Version betroffen:

<authorizations xmi:id="RoleAssignmentExt_2" role="SecurityRoleExt_2"/>

Die after-Version sieht wie folgt aus:

<authorizations xmi:id="RoleAssignmentExt_2" role="SecurityRoleExt_2">
  <users xmi:id="UserExt_1326649772453" name="user2"
    accessId="user:defaultWIMFileBasedRealm/uid=user2,o=defaultWIMFileBasedRealm"/>
</authorizations>
Durch Erstellen einer Sicherheitsdomäne werden Dateien in waspolicies-Unterverzeichnissen geändert
Zur Sicherheitsdomäne zugehörige Dateien werden in den waspolicies-Unterverzeichnissen gespeichert. Wird beispielsweise eine Sicherheitsdomäne mit dem Namen TestDomain hinzugefügt, werden im Verzeichnis waspolices/default/securitydomains/TestDomain viele Dateien erstellt:
before/waspolicies/default/securitydomains/TestDomain/domain-security-map.xml.ADDED
before/waspolicies/default/securitydomains/TestDomain/domain-security.xml.ADDED
before/waspolicies/default/securitydomains/TestDomain/wim/config/wimconfig.xml.ADDED
...
before/waspolicies/default/securitydomains/TestDomain/domain-security-map.xml
before/waspolicies/default/securitydomains/TestDomain/domain-security.xml
before/waspolicies/default/securitydomains/TestDomain/wim/config/wimconfig.xml
Durch Hinzufügen von SSL-Konfigurationen wird die Datei security.xml geändert
SSL-Konfigurationen werden in security.xml gespeichert. Daher ändert das Hinzufügen einer SSL-Konfiguration Dateien wie die folgenden:
before/cells/isthmusCell03/security.xml
after/cells/isthmusCell03/security.xml

Eine SSLConfig-Hinzufügung zur Datei security.xml sieht wie folgt aus:

<repertoire xmi:id="SSLConfig_1326650114281" alias="TestSSLConfig" type="JSSE"
  managementScope="ManagementScope_1">
    <setting xmi:id="SecureSocketLayer_1326650114296" clientAuthentication="false"
      securityLevel="HIGH" jsseProvider="IBMJSSE2" sslProtocol="SSL_TLS" keyStore="KeyStore_1"
      trustStore="KeyStore_1"/>
</repertoire>

Nächste Schritte

Die angegebenen Dateiänderungen wurden verwendet, um die Produktkonfiguration nach Bedarf zu prüfen.


Symbol, das den Typ des Artikels anzeigt. Taskartikel



Symbol für Zeitmarke Letzte Aktualisierung: 25.05.2016
http://www14.software.ibm.com/webapp/wsbroker/redirect?version=cord&product=was-nd-mp&topic=twve_checkpoint_changes
Dateiname:twve_checkpoint_changes.html