Invalidation du cache dans l'infrastructure de commandes BOD

Contrairement aux services Get qui ne modifient pas les objets métier, les services Change, Process et Sync viennent modifier les objets métier dans le système et peuvent avoir à invalider des représentations existantes en cache des objets métier sur lesquels ils opèrent. Par exemple, lorsqu'un élément CatalogEntry donné est modifié, chaque page JSP ou service en cache référençant cet objet doit être invalidé. Lorsque vous utilisez l'infrastructure de commandes BOD avec un outil, par exemple le Centre de gestion, ou l'intégrez à des systèmes externes, vous devez appliquer des stratégies d'invalidation de nom et des éléments associés. Lorsque vous utilisez l'infrastructure de commandes BOD avec une vitrine de magasin, vous devez instaurer des stratégies d'invalidation de commandes de service afin d'invalider les vues dans la vitrine.

Invalidation du nom

Dans le cadre des commandes de contrôleur Change, Sync et Process, vous pouvez définir un attribut nommé uniqueIDXPath. Cet attribut est rattaché à une propriété pouvant être définie sur la commande afin d'indiquer le chemin où rechercher l'ID unique (UniqueID) des noms modifiés suite à la requête. Cet attribut de commande est utilisé pour les besoins de mise en cache afin de résoudre l'identificateur des objets impliqués dans la requête.

L'attribut uniqueIDXPath est utilisé lorsque la méthode getUniqueID() est appelée. L'objectif de la méthode getUniqueID() est de renvoyer une collection des identificateurs internes de l'objet impliqué dans la requête de service. Dans le cas de Change, Process et Sync, il s'agit des objets ayant été modifiés et nécessitant une validation.

Le contrôleur du service BOD peut également étendre la méthode getUniqueID() et l'implémenter pour renvoyer une collection d'ID uniques représentant les noms modifiés suite à la requête en cours. Cette approche nécessite des modifications du code et ne tire pas partie de la configuration des propriétés pouvant être définies sur un commande.

Définition de l'attribut XPath UniqueID

L'enregistrement des commandes des contrôleurs de service BOD est situé dans la table CMDREG. Cet enregistrement de base de données contient l'implémentation à laquelle est associée l'interface. Conjointement à cette association, la colonne PROPERTIES peut être utilisée afin de définir sur la commande des propriétés par défaut lorsqu'elle est instanciée. Pour les besoins d'invalidation du cache, cette propriété peut être définie pour toute commande de contrôleur de service BOD constituant une extension des commandes du service Abstract BOD afin d'émettre des requêtes d'invalidation lorsque des modifications sont apportés à des noms spécifiques.

L'instruction SQL suivante peut être utilisée afin de mettre à jour les propriétés de commande pour spécifier la valeur XPath où rechercher l'ID unique (UniqueID) des noms dans la requête.

update CMDREG set properties = properties || '&uniqueIDXPath;=NounIdentifier/UniqueID' 
where interfacename = 'bod service command controller interface'

Création de la stratégie d'invalidation de nom

Une fois que la commande renvoie une collection des ID uniques des noms modifiés suite à la requête, le fichier cachespec.xml qui définit la mise en cache et son invalidation doit être configuré afin de créer la stratégie d'invalidation. Bien que non obligatoire, il est recommandé de placer le fichier cachespec.xml de chaque module de service dans le module Web HTTPInterface de ce module de service.

De manière semblable à la définition d'une stratégie de mise en cache pour une commande de service Get, l'identificateur de validation comprend le nom et l'ID unique qui sont invalidés. Cette stratégie d'invalidation est configurée comme toute autre entrée de mise en cache de commande, avec les directives suivantes en sus :

La propriété delay-invalidations est définie à 'true'. Ceci vise à garantir que l'invalidation intervienne après l'exécution de la commande de sorte à ce que les ID uniques aient été résolus.
La méthode à appeler est getUniqueID, et l'attribut multipleIDs est défini à 'true'. Comme getUniqueID renvoie une collection d'ID uniques, cet attribut crée une clé d'invalidation pour chaque élément de la collection renvoyée.

Le code XML fournit un exemple de stratégie d'invalidation créée pour ChangeCatalogEntryCmdImpl :

<cache-entry>
	<class>command</class>
	<name>com.ibm.commerce.catalog.facade.server.commands.ChangeCatalogEntryCmdImpl</name>
	<name>com.ibm.commerce.catalog.facade.server.commands.ProcessCatalogEntryCmdImpl</name>
	<property name="delay-invalidations">true</property>
	<invalidation>CatalogEntry
		<component id="getUniqueID" type="method" multipleIDs="true">
			<required>true</required>		
		</component>
	</invalidation>
</cache-entry>

Invalidation de noms associés

Lorsque vous modifiez un nom, l'action effectuée peut également affecter les noms qui lui sont associés. Par exemple, lors du transfert d'un nom CatalogEntry d'un groupe CatalogGroup à un autre, non seulement le nom CatalogEntry doit-il être invalidé mais mais aussi l'ancien et le nouveau nom CatalogGroup parent.

Toutes les actions sont représentées en tant que commandes d'action réalisant une action spécifique sur le nom (dans le cas d'une action Process) ou sur la partie de nom (dans le cas d'actions Change et Sync). Ces commandes d'action sont très spécifiques et interviennent généralement là où des modifications des noms associés sont exécutées. Dans notre exemple, l'implémentation de la commande responsable de l'invalidation de CatalogGroup serait celle associée à l'interface com.ibm.commerce.catalog.facade.server.commands.ChangeCatalogEntryPartCmd et à l'expression XPath /CatalogEntry[]/ParentCatalogGroupIdentifier.

Pour les besoins de l'invalidation, elle conserverait, dans le cadre de l'implémentation de commande, un objet Collection enregistrant tous les noms associés ayant été modifiés. La collection est renvoyée par une méthode appliquée à la commande, par exemple getModifiedCatalogGroups(), qui peut être utilisée par la stratégie d'invalidation du cache. La convention de dénomination suggérée pour déclarer explicitement les différents noms associés affectés suite à cette commande d'action pour ces méthodes get est getModifiedNounNames.

Création de la stratégie d'invalidation de nom associé

Après que la commande renvoie une collection d'ID uniques de noms associés susceptibles d'être modifiés, l'étape suivante consiste à mettre à jour le fichier cachespec.xml de ce module de service avec la commande d'invalidation. Le fichier cachespec.xml est le même que celui utilisé pour enregistrer la stratégie d'invalidation des commandes du contrôleur BOD.

La stratégie d'invalidation est fort similaire à celle définie pour les commandes de contrôleur Change, Process ou Sync. Définissez la propriété delay-invalidation à 'true', suite à quoi la méthode renverra une collection d'ID uniques à invalider, au lieu d'une seule. La différence est que la méthode getModifiedNounNames() personnalisée est appelée au lieu de la méthode générique getUniqueID.

Ci-après figure un exemple XML de stratégie d'invalidation personnalisée pour une commande d'action modifiant la relation Groupe de catalogue d'une entrée de catalogue :

<cache-entry>
	<class>command</class>
	<name>com.ibm.commerce.catalog.facade.server.commands.ChangeCatalogEntryParentCmdImpl</name>	
	<property name="delay-invalidations">true</property>
	<invalidation>categoryId
		<component id="getModifiedCatalogGroups" type="method" multipleIDs="true">
			<required>true</required>		
		</component>
	</invalidation>
</cache-entry>

Où une méthode personnalisée, getModifiedCatalogGroup, est utilisée pour invalider les groupes de catalogues associés.

Règles d'invalidation de commandes SOA de catalogue pour tous les magasins

L'exemple suivant illustre comment définir les règles d'invalidation des nouvelles commandes de catalogue pour tous les magasins. Pour pouvoir utiliser ces règles, les entrées de cache définies dans ce fichier doivent être fusionnées dans le fichier cachespec.xml pour mise en cache des pages et fragments JSP.

Remarque : Le snippet suivant est contenu dans le fichier WCDE_installdir\samples\dynacache\invalidation\catalog\cachespec.xml. Cependant, ce fichier ne peut pas être utilisé directement vu qu'il ne comporte pas l'élément cache.


<!-- This list of unique IDs is to indicate which Catalog nouns have been involved with the change/process -->
<!-- request and requires to be invalidated.                                                               -->

<cache-entry>
       <class>command</class>
       <name>com.ibm.commerce.catalog.facade.server.commands.ChangeCatalogCmdImpl</name>
  <name>com.ibm.commerce.catalog.facade.server.commands.ProcessCatalogCmdImpl</name>
       <property name="delay-invalidations">true</property>
       <invalidation>catalogId
              <component id="getUniqueID" type="method" multipleIDs="true">
                     <required>true</required>              
              </component>
       </invalidation>
</cache-entry>

<!-- This list of unique IDs is to indicate which CatalogGroup nouns have been involved with the change/process                        -->
<!-- request and requires to be invalidated.                                                                                           -->
<!-- The catalog id can be used to invalidate related pages when a catalog group is updated.                                           -->
<!-- For example, when the name of a category is renamed (categoryId=50400000003), the CategoryDisplay page for this category needs to -->
<!-- invalidate:                                                                                                                       -->
<!-- CategoryDisplay?catalogId=504&categoryId=50400000003                                                                              -->
<!-- Since the CategoryDisplay pages for its parent category (categoryId=50400000013) and sibling categories (categoryId=50400000014)  -->
<!-- also display the name of the category, they also need to invalidate.                                                              -->
<!-- CategoryDisplay?catalogId=504&categoryId=50400000013                                                                              -->
<!-- CategoryDisplay?catalogId=504&categoryId=50400000014                                                                              -->

<cache-entry>
       <class>command</class>
       <name>com.ibm.commerce.catalog.facade.server.commands.ChangeCatalogGroupCmdImpl</name>
  <name>com.ibm.commerce.catalog.facade.server.commands.ProcessCatalogGroupCmdImpl</name>
       <property name="delay-invalidations">true</property>
       <invalidation>categoryId
              <component id="getUniqueID" type="method" multipleIDs="true">
                     <required>true</required>              
              </component>
       </invalidation>
       <invalidation>catalogId
                     <component id="getCatalogId" type="method">
                            <required>true</required>
                     </component>
       </invalidation>
</cache-entry>

<!-- This list of unique IDs is to indicate which CatalogEntry nouns have been involved with the change/process -->
<!-- request and requires to be invalidated.                                                                    -->
       
<cache-entry>
       <class>command</class>
       <name>com.ibm.commerce.catalog.facade.server.commands.ChangeCatalogEntryCmdImpl</name>
  <name>com.ibm.commerce.catalog.facade.server.commands.ProcessCatalogEntryCmdImpl</name>
       <property name="delay-invalidations">true</property>
       <invalidation>productId
              <component id="getUniqueID" type="method" multipleIDs="true">
                     <required>true</required>              
              </component>
       </invalidation>
</cache-entry>

Exemple d'invalidation de catalogue

Copiez le contenu du fichier WCDE_installdir\samples\dynacache\invalidation\catalog\cachespec.xml à la fin du fichier WAS_installdir\profiles\instance_name\installedApps\cell_name\WCServer_enterprise_archive\Stores.war\WEB-INF\cachespec.xml précédant immédiatement l'élément </cache>.

Les magasins type ne montrent pas comment invalider des noms associés. Par exemple, si un nom de produit est modifié, la page de détails du produit est invalidée mais la page de catégorie contenant le nom du produit ne l'est pas. Vous pouvez invalider des objets associés en cache à l'aide des approches suivantes :

Invalidation périodique
Cette approche est simple à mettre en oeuvre mais peut périmer des entrées pendant un laps de temps. Pour consulter un exemple, voir l'entrée MiniShopCarDisplay.jsp dans le fichier cachespec.xml du magasin type Madisons. Pour obtenir des informations, voir Invalidation périodique dans la rubrique Invalidation des données en mémoire cache.
Déclencheurs de base de données sur la table CACHEIVL.
Pour obtenir des informations, voir API Dynacache et invalidation de la table CACHEIVL dans la rubrique Invalidation des données en mémoire cache.
Code Java personnalisé pour émettre des messages d'invalidation à l'aide des API Dynacache.
Cette approche requiert une bonne compréhension des API Dynacache. Pour obtenir des informations, voir IBM WebSphere Application ServerTM, Release 7 API Specification: Dynacache API et Mastering DynaCache in HCL Commerce.