Répertoire des composants

includes

Ce répertoire est l'emplacement dans lequel ConfigEngine recherche les tâches qui implémentent les points d'extension répertoriés dans le fichier sdd.xml de niveau composant. Le nom du fichier XML qui contient les tâches Ant n'est pas codé en dur, et ConfigEngine charge automatiquement tout fichier XML figurant dans ce répertoire. Il n'est pas nécessaire de stocker les tâches Ant dans un même fichier. Elles peuvent être réparties dans plusieurs fichiers qui sont tous sélectionnés par ConfigEngine.

templates

Ce répertoire contient les fichiers de script additionnels des tâches de configuration. Par exemple, si vous déployez un fichier WAR et voulez exécuter des tâches de configuration de portlet, vous pouvez placer les scripts XML dans ce répertoire. Copiez le fichier WAR dans le répertoire profile_dir/installableApps avec votre implémentation de tâches personnalisées et référencez cet emplacement dans votre script XMLAccess.

Remarque : Solution Installer n'exécute pas automatiquement les scripts stockés dans cet emplacement. A la place, les tâches personnalisées appellent ces scripts.

jcr

Ce répertoire contient des artefacts liés à JCR et une structure de répertoire de nœuds. Chaque entrée est un fichier ou un répertoire avec des métadonnées associées (titre, dernière modification, autorisations). Le contenu de ce répertoire doit être installé avec un code personnalisé. Solution Installer ne génère pas automatiquement toute tâche permettant de gérer les ressources qui se trouvent à cet emplacement.

jsp

Placez tout fichier JSP que vous voulez conditionner dans le cadre de votre application dans ce répertoire. Généralement le code personnalisé gère les ressources dans cet emplacement. Cependant, les fichiers JSP relatifs à Web Content Manager sont traités comme des cas spéciaux. Placez ces fichiers dans un sous-dossier appelé wcm sous le répertoire jsp, par exemple, jsp/wcm. Solution Installer copie tous les fichiers et dossiers dans l'emplacement approprié sur le serveur : ${WasUserHome}/installedApps/${NodeName}/WCM_EXTENSION.ear/wp.wcmextension.war/jsp/wcm/content.

Remarque : Solution Installer n'exécute aucune tâche par défaut pour gérer un autre contenu JSP, à l'exclusion des tâches qui se trouvent dans le répertoire jsp/wcm. Le développeur doit fournir une tâche personnalisée pour que ce contenu soit copié dans l'emplacement correct.

wcm

Ce répertoire contient les bibliothèques Web Content Manager. Chaque sous-répertoire du répertoire wcm représente une bibliothèque séparée. Ces bibliothèques sont une forme particulière des artefacts JCR. Les bibliothèques Web Content Manager se trouvent dans des répertoires séparés en raison du processus requis pour leur installation avec la fonction par défaut. Par exemple, si vous avez une bibliothèque appelée lib1, vous pouvez placer le contenu dans le répertoire content/wcm/lib1 ; par exemple, content/wcm/lib1/554ee7f5.

Plusieurs bibliothèques Web Content Manager contenues dans un sous-répertoire unique sont prises en charge. Cependant, cela limite la capacité de Solution Installer à supprimer et remplacer des bibliothèques. C'est-à-dire que la tâche sur laquelle Solution Installer s'appuie pour l'importation extrait tout le contenu d'un sous-répertorie fourni et tente d'effectuer l'importation sur le serveur. Par conséquent, pour pouvoir être remplacées, toutes les bibliothèques du répertoire doivent être marquées pour la suppression. Lorsque des bibliothèques sont allouées à leur propre sous-répertoire, elles peuvent être remplacées individuellement sur le système lorsqu'il n'y a pas de dépendances entre bibliothèques. Une autre bibliothèque existante n'a pas de dépendance sur des éléments de la bibliothèque sélectionnée pour être supprimée.

webdav

Ce répertoire et sa sous-structure contiennent les artefacts qui doivent être téléchargés dans le magasin de fichiers WebDAV. Il existe quatre sous-répertoires possibles. Chaque répertoire porte un nom qui reflète le type de fonction fournit dans les fichiers qu'il contient. les options suivantes sont disponibles :

iwidgets

Placez les fichiers .zip contenant les iWidgets qui doivent être envoyés au magasin de fichiers WebDAV et enregistrés avec HCL. Solution Installer télécharge automatiquement tout fichier .zip trouvé dans ce répertoire vers le répertoire dav:fs-type1/iwidgets/. Des tâches supplémentaires sont nécessaires pour enregistrer les définitions iWidget dans HCL. Le programme d'installation doit connaître les fichiers de définition de widget pour l'enregistrement avec WebSphere. Le fichier de propriétés iwidgets.properties doit être inclus dans le répertoire iwidgets dans le PAA. Les propriétés sont générées en utilisant le nom de fichier .zip contenant le fichier de définition comme nom de propriété. Il fournit également la liste des fichiers de définition séparés par une virgule contenus dans ce fichier en tant que valeur.

layout-templates

Placez les fichiers .zip contenant les modèles de présentation dans ce répertoire. Une fois ces fichiers détectés par le programme d'installation, le code est généré pour envoyer automatiquement ce contenu au répertoire dav:fs-type1/layout-templates/ dans le magasin de fichiers WebDAV.

skins

Placez dans ce répertorie tout fichier .zip contenant des habillages non propres à un thème. Le contenu est envoyé automatiquement au répertoire dav:fs-type1/skins/ dans le magasin de fichiers WebDAV.

themes

Placez dans ce répertoire les fichiers .zip renfermant un contenu de thème statique. Ils sont envoyés automatiquement au répertoire dav:fs-type1/themes/ dans le magasin de fichiers WebDAV.

Remarque : Si le thème contient du contenu dynamique, incluez-le dans un fichier WAR déployé lors de l'exécution.

Solution Installer télécharge du contenu WebDAV avec le point d'entrée dav:fs-type1/*.* WebDAV. Les thèmes et les habillages ne sont pas disponibles systématiquement via les points d'entrée themelist ou skinlist. Pour que les thèmes et les habillages soient disponibles via les pages d'administration, il est nécessaire de créer un script XMLAccess pour enregistrer les ressources dans HCL. La racine de contexte dans laquelle le contenu de chacun des fichiers .zip est installé est définie de la manière suivante :

• Le répertoire racine se trouve dans le fichier .zip. Par exemple, tout le contenu est inclus dans un répertoire. Il est ensuite annexé à l'TargetURI. Par exemple, un fichier .zip dans le répertoire componentName/content/webdav/themes avec un répertoire racine d'exemple donnerait TargetURI dav:fs-type1/themes/sample/.
• Aucun répertoire racine ne se trouve dans le fichier .zip. Tous les élément sont au niveau parent. Le nom du fichier .zip est utilisé, moins le suffixe ‘.zip'. Par exemple, un fichier .zip avec le nom sample1.zip donnerait TargetURI ‘dav:fs-type1/themes/sample1/’. La tâche de téléchargement des fichiers .zip vers le système de fichiers WebDAV est définie pour remplacer le répertoire courant avec le nouveau contenu. Toutefois, Solution Installer modifie cette fonction pour fusionner le contenu par défaut à la place. Lorsque le paramètre UpdateMode a pour valeur replace (par défaut), le téléchargement remplace la totalité du contenu sous TargetURI. Par exemple, si vous téléchargez un fichier .zip vers dav:fs-type1/themes/, il ne remplace pas le contenu équivalent enregistré dans le répertoire. Il remplace tout le contenu du répertoire. Par conséquent, il a été décidé qu'il est préférable de définir le contenu pour le fusionner avec le contenu existant comme comportement par défaut. Si vous voulez que UpdateMode ait pour valeur replace, vous devez ajouter un fichier de propriétés au répertoire. Par exemple, si vous voulez remplacer tous les thèmes, placez le fichier webdav.properties dans le répertoire componentName/content/webdav/themes. Il n'y a qu'une propriété dans ce fichier : webdav.replace=list of .zip files. La valeur de la propriété webdav.replace est une liste de fichiers séparés par une virgule qui indique à Solution Installer les fichiers à télécharger.

xmlaccess

Enregistre tous les scripts d'accès XML de niveau composant. Ce répertoire est différent du répertoire component/config/templates qui stocke les scripts à appeler par les tâches Ant personnalisées. Tous les scripts qui doivent être exécutés par défaut sont placés dans le répertoire content/xmlaccess. Ce répertoire a deux sous-répertoires pour faciliter la distinction entre les scripts d'installation et de désinstallation. Les scripts nécessaires à l'installation résident dans le répertoire /content/xmlaccess/install et les scripts de désinstallation, dans le répertoire /content/xmlaccess/uninstall. Le répertoire component/content/xmlaccess contient différents types de scripts permettant d'enregistrer un thème ou de créer des pages et d'affecter des portlets. Les scripts de création d'un groupe d'utilisateurs et de groupes ou d'un emplacement de données d'identification dans le coffre des informations d'identification HCL constituent d'autres exemples. Tous les scripts trouvés par Solution Installer dans ces répertoires sont automatiquement exécutés.

database

Ce répertoire contient des scripts de base de données afin de créer des tables et de pré-remplir des tables avec les données appropriées. Solution Installer peut générer des tâches Ant pour créer les paramètres de configuration appropriés sur le serveur d'applications WebSphere® Application Server sous-jacents. Pour plus de détails concernant les propriétés requises, consultez la section Propriétés de la base de données de Solution Installer.

Il existe deux répertoires dans le répertoire databasedu fichier PAA : install et uninstall. Le développeur de fichier PAA doit placer les scripts suivants dans ces répertoires :

• Les scripts .ddl et .sql pour créer et remplir des tables dans le répertoire install
• Les scripts .ddl et .sql pour placer des tables dans le répertoire uninstall

Si plusieurs scripts sont requis, incluez un fichier order.properties dans le répertoire approprié pour spécifier l'ordre correct pour l'installation.

Si vous fournissez des scripts de configuration pour différents types de base de données dans un fichier PAA unique, il existe une étape supplémentaire. Exécutez cette étape lors de la phase de création de PAA. Pour chaque type de base de données, un fichier de propriétés doit être ajouté au répertoire components/componentName/content/database/install.

• Pour les scripts Derby, appelez le fichier scripts.derby.properties.
• Pour les scripts DB2®, appelez le fichier scripts.db2.properties.
• Pour les scripts Oracle, appelez le fichier scripts.oracle.properties.
• Pour les scripts SQL Server, appelez le fichier scripts.sql.properties.

Ajoutez une liste de scripts séparés par des virgules au fichier de propriétés afin qu'ils s'exécutent pour un type de base de données propre. Solution Installer détermine au moment de l'exécution l'ensemble de scripts à exécuter pour le type de base de données demandé.

pzn

Les artefacts associés à PZN, tels que les fichiers JAR contenant des règles métier et des fichiers .nodes se trouvent dans ce répertoire. Solution Installer copie automatiquement les fichiers JAR contenant les classes Java personnalisées à l'emplacement approprié sous le répertoire profile et télécharge tout fichier .nodes sur le serveur.

ear

Contient les fichiers EAR à déployer sur le serveur d'applications. Placez dans un fichier EAR les fichiers .war qui ne contiennent pas de portlets et doivent être installés sur le serveur d'applications. Cela s'explique par le fait que les scripts par défaut utilisés pour déployer les artefacts nécessitent des informations spécifiques pour exécuter l'installation. Par exemple, le nom d'affichage et la racine de contexte pour l'application. Ces informations se trouvent dans le fichier application.xml d'un fichier EAR. Les informations de racine de contexte ne seront pas disponibles avec simplement un fichier WAR. Par exemple, un fichier WAR theme.war doit être encapsulé de cette manière. Si vous fournissez un script de déploiement Ant personnalisé, ce n'est pas nécessaire, car vous pouvez fournir les informations appropriées dans le script ou un fichier de propriétés.

Les fichiers EAR sont déployés automatiquement sur le serveur. Toutefois, si un fichier WAR contenant un portlet est placé dans un fichier EAR, le développeur doit fournir un script supplémentaire pour enregistrer les portlets auprès de HCL. Le développeur doit vérifier que les portlets sont enregistrés correctement.

portlets

Placez les fichiers WAR contenant des portlets JSR dans le répertoire portlets. Les portlets existants ne sont pas gérés automatiquement par le programme d'installation. Ils nécessitent un code personnalisé pour l'installation et ne doivent pas être placés dans ce répertoire. La séparation de ces fichiers WAR des autres fichiers qui contiennent des servlets ou d'autres types d'applications s'explique par la méthode d'installation nécessaire. Ces fichiers contenant des portlets JSR sont généralement installés et déployés avec un script d'accès XML. Ces fichiers qui doivent être installés directement sur le serveur d'applications sont déployés à l'aide d'une tâche Ant ConfigEngine ou d'un script wsadmin. Solution Installer peut lire le répertoire de portlets et installer les fichiers WAR automatiquement sans que la détection d'un fichier WAR ne correspondant pas à un portlet pose problème. Cependant, si une configuration supplémentaire est requise pour un portlet, remplacez la tâche d'installation par défaut à l'aide d'une tâche Ant avec un script XMLAccess personnalisé pour effectuer l'installation. Ajoutez un élément <SCU> au fichier sdd.xml pour le point d'extension deploy-portlets-applySIFeaturePack et ajoutez une tâche Ant qui implémente ce point d'extension dans le répertoire config/includes. Cette tâche Ant doit appeler la tâche XMLAccess afin d'exécuter un script XMLAccess pour le serveur de portail.

L'installation automatique utilise l'ID unique de l'élément <portlet-app> qui se trouve dans le fichier warfile/WEB-INF/portlet.xml et l'emplacement du fichier WAR lui-même pour activer le déploiement. Si l'ID unique n'est pas disponible, le nom du fichier WAR est utilisé. Le fichier WAR est copié automatiquement dans le répertoire wp_profile_root/installableApps. Voici un exemple de script XMLAccess montrant comment les informations sont utilisées pour piloter l'installation.

<?xml version="1.0" encoding="UTF-8"?>
<request xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance"
		xsi:noNamespaceSchemaLocation="PortalConfig_8.5.0.0.xsd" type="update"
		create-oids="true">
		<portal action="locate">
			<web-app action="update" active="true"
				uid="portletXmlUniqueId.webmod">
				<url>file:///$profile_dir$/installableApps/warfile.war</url>
			</web-app>
		</portal>
</request>

Les fichiers WAR placés dans cet emplacement portent également des noms uniques générés automatiquement pour les portlets individuels au cours de l'installation. La génération de noms uniques repose sur le schéma componentName.portletName Voici une exemple de script XMLAccess montrant comment les valeurs de nom unique sont indiquées :

<?xml version="1.0" encoding="UTF-8"?>
<request xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance"
xsi:noNamespaceSchemaLocation="PortalConfig_8.5.0.0.xsd" type="update" create-oids="true">
		<portal action="locate">
			<web-app action="locate" domain="rel" objectid="WebAppID.webmod"
uid="WebAppId.webmod">
			<portlet-app action="update" domain="rel" name="PortletAppId"
uid="PortletAppId">
			<portlet action="update" domain="rel" name="PortletName"
uniquename="componentName.PortletName"/>
			</portlet-app>
		</web-app>
	</portal>
</request>

Ajoutez le nom de composant comme préfixe du nom de fichier WAR suivant le schéma componentName.WARname.war. Bien que ce ne soit pas essentiel, cela permet à l'utilisateur de suivre efficacement les fichiers WAR installés à l'aide de Solution Installer.

war

Ce répertoire contient tout fichier WAR que le développeur ne veut pas installer automatiquement. Le développeur étend le point d'extension avec une tâche Ant personnalisée pour installer les artefacts. Un exemple est lorsque le fichier WAR contient des portlets existants. Eventuellement, le fichier WAR ne contient pas de portlets et le développeur ne veut pas le placer dans un fichier EAR. En outre, des étapes de personnalisation supplémentaires peuvent être nécessaires pour la configuration des artefacts déployés. Par conséquent, un script personnalisé est nécessaire. Le programme d'installation ignore généralement ce répertoire, sauf pour copier les fichiers dans le répertoire wp_profile_root/installableApps et lancer tout code personnalisé fourni pour gérer ces artefacts.

zip

Ce répertoire renferme tout contenu de fichier .zip à inclure pour un composant. Par exemple, vous pouvez disposer d'artefacts qui doivent être copiés et installés vers un serveur qui ne prend pas en charge Solution Installer. Solution Installer ne traite pas automatiquement le contenu de ce répertoire, Les fichiers individuels restent compressés après que le fichier PAA ait été extrait. En fait, le traitement de ces fichiers est effectué par les tâches Ant personnalisées fournies par le développeur ou il est effectué manuellement.

Pour les fichiers JAR disponibles globalement, placez les fichiers JAR dans le répertoire component/shared/app ou component/shared/ext. Ces fichiers ne sont pas copiés vers les répertoires équivalents sous le répertoire PortalServer_root. En fait, une tâche est exécutée pour enregistrer tous les fichiers JAR qui se trouvent dans les répertoires shared/app et shared/ext des composants. Lorsque des objets se trouvent dans ces répertoires, ils sont enregistrés directement avec un groupe de bibliothèques partagées, spécifiques de Solution Installer, qui résident dans le profil, ce qui rend le profil de bibliothèques spécifique. Par conséquent, des versions différentes des mêmes fichiers peuvent être installées dans différents profils.

Les fichiers JAR présents dans le répertoire component/shared/app sont enregistrés dans le fichier shared.app.jar propre à Solution Installer. De même, les fichiers .jar dans le répertoire componentName/shared/ext sont enregistrés avec un fichier shared.ext.jar spécifique de profil. Ces fichiers se trouvent dans la sous-arborescence du répertoire wp_profile_root/PortalServer/solutionInstaller. La bibliothèque 'sisharedlib' spécifique est enregistrée au niveau de la cellule ou du nœud du profil. Une référence est ensuite ajoutée au chemin d'accès aux classes du serveur d'applications pour que les fichiers soient disponibles lors de l'exécution. Seul le fichier shared.app.jar est chargé automatiquement par la bibliothèque SiSharedLib. Une fois l'enregistrement de ces fichiers terminé, il est nécessaire de redémarrer le serveur pour recharger les bibliothèques et rendre les classes disponibles dans le chemin d'accès aux classes. Une fois cette opération terminée, les classes spécifiques de la bibliothèque sont maintenant disponibles globalement pour le serveur pour permettre à une application d'y accéder.

# set whether the library should be at the server scope or application scope
# Can have the following values:
# cell, cluster, node, server
library-scope=server
# specify whether the library should be added to the server class path
# or associated with a specific application.
Library-ref=application
# Set the name of the application(s) to which the library is to be associated.
# name of application(s) found in the integrated administration
# console/applications/enterprise applications.
applicationName=# your application name
# Set class loading preference, options are either
# 'PARENT_FIRST' or 'PARENT_LAST'.
classLoadingMode=PARENT_FIRST

Si plusieurs applications sont associées à la bibliothèque, définissez une liste des noms d'application séparés par une virgule comme suit : applicationName=AppName1,AppName2,AppName3, où AppName1,AppName2,AppName3 représentent les applications auxquelles la bibliothèque doit être associée.

Le contenu du répertoire par défaut et des répertoires de modèle suivants est réparti dans deux autres sous-répertoire pour faciliter la distinction entre des scripts d'installation et de désinstallation. Les scripts d'installation se trouvent dans le répertoire /component/template/template_Name/install et les scripts de désinstallation sont placés dans le répertoire /component/template/template_Name/uninstall. Les scripts qui se trouvent dans le répertoire par défaut sont toujours exécutés. Par conséquent, si vous offrez plusieurs modèles et que vous ne voulez pas installer l'un d'entre eux par défaut, laissez cette structure de répertoires vide. En général, le contenu des répertoires par défaut ou de modèles inclut des scripts XMLAccess permettant de créer des pages, de placer des portlets dans les pages et de créer des utilisateurs. C'est-à-dire, toute tâche associée au site n'est pas couverte par les autres répertoires ou composants. Par exemple, ne placez pas un script XMLAccess pour installer un fichier WAR ici. A la place, si ce fichier est requis, placez-le dans le répertoire component/config/templates si une tâche Ant personnalisée est nécessaire, ou sinon dans le répertoire component/content/xmlaccess/install.

Pour utiliser un modèle autre que celui par défaut, définissez la propriété templateName dans le fichier componentName.properties. La valeur de la propriété templateName doit refléter le nom du modèle à utiliser. Par exemple: templateName=template2.

<?xml version="1.0" encoding="UTF-8"?>
<!DOCTYPE component PUBLIC "componentId" "component.dtd">
<component build-date="6/10/14" build-version="20140610-1200" name="components/sample1" spec-version="5.0"/>