Fichier sdd.xml de niveau de composant

When you run the install-paa task, the Solution Installer examines each component to verify whether an sdd.xml file is included for that component. If an sdd.xml file is not found, one is generated with the information gathered from the directory parsing step.

Le type de données collectées dans la structure de répertoire de composants inclut des informations sur les différents types de ressources. Par exemple, la liste des ressources incluses dans chaque sous-répertoire et des tâches d'implémentation personnalisée de points d'extension. Il utilise également le nom du répertoire lorsqu'il génère le nom du composant. Après avoir regroupé les informations, il peut générer le fichier sdd.xml. Ce fichier contient les informations sur les points d'extension pour l'enregistrement sur Solution Installer ou ConfigEngine. Solution Installer peut ajouter des informations sur des points d'extension si des implémentations auto-générées ou personnalisées sont ajoutées au fichier sdd.xml. Il n'est plus nécessaire d'enregistrer manuellement des tâches personnalisées avec des éléments <SCU>.

La possibilité de générer automatiquement des dépendances entre les composants a été ajoutée. Vous devez inclure un fichier order.properties dans le répertoire /components du fichier Portal Application Archive (PAA). Pour plus d'informations, consultez la section Ordre d'installation des scripts et des artefacts.

Dans la plupart des cas, cette automatisation SDD est suffisante pour permettre aux fichiers PAA d'être déployés avec succès. Toutefois, il existe des situations dans lesquelles le développeur doit remplacer la fonction du fichier sdd.xml. Il peut s'agir par exemple du classement des composants où le fichier order.properties n'est pas conforme aux exigences du fichier PAA. Par exemple, un composant qui contient des points d'extension possédant des dépendances sur 2 ou plusieurs composants différents.

Cette information décrit les différents éléments du fichier sdd.xml de niveau composant en termes de leur utilisation. En outre, la procédure à suivre pour créer votre propre fichier sdd.xml personnalisé et l'emplacement où inclure des informations pertinentes sur le composant pour un déploiement réussi sont également traités.

Remarque : Si vous fournissez un fichier sdd.xml de niveau de composant, il n'est pas nécessaire de fournir des informations pour toutes les ressources incluses dans le fichier PAA. Indiquez des informations uniquement lorsque vous écrasez la fonction de Solution Installer.

Voici un exemple d'un fichier sdd.xml de niveau de composant :

<?xml version="1.0" encoding="UTF-8"?>

<iudd:iudd
	xmlns:iudd="http://www.ibm.com/xmlns/prod/autonomic/solutioninstall/IUDD"
	xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance"
	xmlns:OSRT="http://www.ibm.com/xmlns/prod/autonomic/resourcemodel/OS/resourcetypes"
	xmlns:OSAT="http://www.ibm.com/xmlns/prod/autonomic/resourcemodel/OS/artifacttypes"
	xmlns:J2EERT="http://www.ibm.com/xmlns/prod/autonomic/resourcemodel/J2EE/resourcetypes"
	xsi:schemaLocation="http://www.ibm.com/xmlns/prod/autonomic/solutioninstall/IUDD ../iudd/iudd.xsd"
	schemaVersion="2.0.0" buildID="112220" buildDate="2006-01-19T12:00:00">

	<packageIdentity contentType="Component">
		<name>components/componentN</name>
		<version>8.0.0.0</version>
		<displayName key="d0001" default="components/componentN" />
		<manufacturer>
			<displayName key="AC_01" default="IBM" />
		</manufacturer>
	</packageIdentity>

	<topology>
		<resource type="OSRT:OperatingSystem" id="OS" />
	</topology>

	<content xsi:type="iudd:RootIUContent">
		<rootIU id="components/componentN">
			<variables>
				<parameters>
					<parameter name="installLocation" defaultValue="/usr/dummy.offr.1" />
				</parameters>
			</variables>

			<SCU id="deploy-portlets-applySIFeaturePack" targetRef="OS">
				<identity>
					<name>Do Configuration Task</name>
					<version>8.0.0.0</version>
					<displayName key="keyInBundle"
						default="Executes Configuration for this component" />
					<description key="keyInBundle"
						default="This section runs configuration for this component" />
				</identity>
				<unit>ts-applySIFeaturePack" />
						</parameters>
					</configArtifact>
				</unit>
			</SCU>
			<SCU id="remove-portlets-applySIFeaturePack" targetRef="OS">
				<identity>
					<name>Do Configuration Task</name>
					<version>1.0.0.0</version>
					<displayName key="keyInBundle"
						default="Executes Configuration for this component" />
					<description key="keyInBundle"
						default="This section runs configuration for this component" />
				</identity>
				<unit>
					<configArtifact type="ConfigEngine">
						<parameters>
							<parameter name="targetName" value="remove-portlets-applySIFeaturePack" />
						</parameters>
					</configArtifact>
				</unit>
			</SCU>
		</rootIU>
	</content>

</iudd:iudd>

Dans l'élément racine <iudd:iudd>, les sous-éléments importants suivants sont requis pour l'installation par Solution Installer :

L'élément <packageIdentity>

Le premier élément est l'élément <packageIdentity> ; par exemple :

<packageIdentity contentType="Component">
		<name>components/componentN</name>
		<version>8.5.0.0</version>
		<displayName key="d0001" default="components/componentN" />
		<manufacturer>
			<displayName key="AC_01" default="IBM" />
		</manufacturer>
	</packageIdentity>

L'élément <packageIdentity> informe le programme d'installation de solutions et la tâche ConfigEngine sur le type d'application à installer. Dans ce cas, l'attribut contentType correspond à "component". Un composant est le niveau de granularité le plus bas utilisé par la tâche ConfigEngine et donc par le programme d'installation de solutions pour regrouper les ressources de l'application. Un ou plusieurs composants sont regroupées dans un assemblage. Ce regroupement est le prochain niveau de granularité pour regrouper des ressources reconnues par la tâche ConfigEngine ou par Solution Installer. Chaque fichier PAA est considéré comme un assemblage par Solution Installer même s'il contient un seul composant. Avec le fichier PAA, un assemblage de niveau supérieur doit être associé à un composant. Consultez la section Fichier sdd.xml de niveau d'assemblage pour plus d'informations.

Si vous regardez l'élément <packageIdentity>, un certain nombre de sous-éléments fournissent des informations sur le contenu en cours d'installation. Les éléments <name> et <version> doivent être modifiés en fonction de l'application en cours d'installation. L'élément <displayName> peut également être modifié pour inclure le nom de composant, mais ce n'est pas obligatoire.

L'élément <name> doit correspondre au chemin du composant par rapport au fichier sdd.xml du niveau assemblage. For example, as the PAA file puts all components in the components directory, a component name needs to also include the components/. Par exemple, un composant appelé 'componentN' aurait le nom de composant 'components/componentN'.

L'élément <topology>

Le sous-élément suivant est l'élément <topology>. Cet élément ne requiert aucune altération. Par exemple:

<topology>
		<resource type="OSRT:OperatingSystem" id="OS" />
	</topology>

L'élément <content>

Le bloc d'éléments final est l'élément <content>. Cet élément fournit à Solution Installer et à la tâche ConfigEngine des informations sur ce qui est en cours d'installation et les serveurs sur lesquels le progiciel peut être installé. L'élément <rootIU> correspond à l'emplacement réel des informations. Affectez à l'attribut id de l'élément <rootIU> le nom du composant qui est utilisé dans l'élément <name> de l'élément <packageIdentity>. Par exemple:

<content xsi:type="iudd:RootIUContent">
		<rootIU id="components/componentN">
			<variables>
				<parameters>
					<parameter name="installLocation" defaultValue="/usr/dummy.offr.1" />
				</parameters>
			</variables>

			<SCU id="deploy-portlets-applySIFeaturePack" targetRef="OS">
				<identity>
					<name>Do Configuration Task</name>
					<version>1.0.0.0</version>
					<displayName key="keyInBundle"
						default="Executes Configuration for this component" />
					<description key="keyInBundle"
						default="This section runs configuration for this component" />
				</identity>
				<unit>
					<configArtifact type="ConfigEngine">
						<parameters>
							<parameter name="targetName" value="deploy-portlets-applySIFeaturePack" />
						</parameters>
					</configArtifact>
				</unit>
			</SCU>
		</rootIU>
	</content>

La tâche ConfigEngine nécessite l'élément <variables> pour le traitement du contenu. Il n'est pas nécessaire d'éditer cette section du code. Ajoutez-la au fichier sdd.xml de niveau de composant comme illustré dans l'exemple précédent.

L'élément <SCU> est l'élément du fichier qui est le plus pertinent pour l'ajout de code personnalisé à votre fichier PAA. Chaque élément <SCU> représente un point d'extension ConfigEngine. Ces points d'extension déterminent comment et quand les ressources sont installés ou désinstallés sur le serveur au cours de la tâche deploy-paa. Chaque point d'extension possède une tâche de mise en oeuvre équivalente qui doit être ajoutée à un fichier XML dans le répertoire components/componentN/config/includes. Reportez-vous à la section Points d'extension ConfigEngine pour Solution Installer pour consulter la liste des extensions exportées et savoir comment elles sont mappées sur les répertoires. Pour plus d'informations sur les points d'extension et sur leur utilisation, voir la section Présentation du fichier sdd.xml de niveau de composant.

Solution Installer ajoute automatiquement l'élément <SCU> correct au fichier sdd.xml après la détection d'une tâche d'implémentation de point d'extension. Solution Installer examine d'abord le répertoire components/componentName/config/includes et recherche les fichiers XML qui contiennent des tâches Ant personnalisées. Toutes les tâches qui répondent aux critères d'implémentation de point d'extension sont alors enregistrées dans le fichier sdd.xml où un élément <SCU> existant pour le point d'extension n'existe pas. Toutefois, vous pouvez enregistrer manuellement les éléments <SCU>, en particulier si vous souhaitez définir des dépendances entre plusieurs composants sur différents plusieurs points d'extension.

Dans l'exemple précédent, il existe deux endroits où vous devez apporter des modifications. Le premier emplacement est l'attribut id de l'élément <SCU>. Affectez à l'ID le nom du point d'extension requis en y ajoutant applySIFeaturePack à la fin. Par exemple: deploy-apps-applySIFeaturePack. Le second élément à modifier est l'élément <parameter> imbriqué. Définissez l'attribut de valeur de cet élément sur la chaîne de point d'extension. Par exemple, définissez-le sur deploy-apps-applySIFeaturePack.

Pour chaque point d'extension, un élément <SCU> distinct est requis par Solution Installer ou ConfigEngine. Par conséquent, un autre élément <SCU> est requis pour fournir une extension remove-apps-removeSIFeaturePack équivalente.

Une second rôle relativement important est affecté à l'élément <SCU>. Ces éléments influencent également l'ordre dans lequel les composants sont installés. Il se peut que vous ayez un fichier PAA avec deux composants, où le second composant est installé avant le premier. Un mécanisme est nécessaire pour garantir que le bon ordre est imposé sur le déploiement. Cette action peut être réalisée en ajoutant un élément <requirements> à l'élément <SCU> comme illustré dans l'exemple suivant :

<SCU id="deploy-portlets-applySIFeaturePack" targetRef="OS">
  <identity>
    <name>Do Configuration Task</name>
    <version>1.0.0.0</version>
    <displayName key="keyInBundle" default="Executes Configuration for this component" />
    <description key="keyInBundle" default="This section runs configuration for this component" />
  </identity>
  <unit>
    <configArtifact type="ConfigEngine">
      <parameters>
        <parameter name="targetName" value="deploy-portlets-applySIFeaturePack" />
      </parameters>
    </configArtifact>
  </unit>
<!—register a dependency on a previous component-->
<requirements>
<requirement name=" deploy-portlets-applySIFeaturePack">
<alternative name="dependentComponent"/>
</requirement>
</requirements>
</SCU>

L'élément <requirements> peut contenir un ou plusieurs éléments <requirement>, chacun représentant un composant sur lequel dépend le composant en cours précédemment installé. L'attribut name de l'élément <requirement> peut être défini sur la valeur que le développeur choisit. L'attribut name de l'élément <alternative> doit correspondre au nom complet du composant sur lequel le point d'extension en cours dépend. Le lien de dépendance est entre les points d'extension. Si vous ajoutez l'élément <requirements> à l'élément <SCU> pour le point d'extension deploy-apps-applySIFeaturePack, enregistrez un point d'extension deploy-apps-applySIFeaturePack équivalent pour le composant dépendant.

Certains points d'extension ne permettent pas de définir la dépendance d'un composant. Les points d'extension qui sont appelés dans le cadre de deploy-apps-applySIFeaturePack, comme install-content-xmlaccess, appliquent l'élément <requirements> au point d'extension deploy-apps-applySIFeaturePack. Consultez Points d'extension ConfigEngine pour Solution Installer pour connaître la liste complète des points d'extension pris en charge par Solution Installer et savoir s'ils peuvent gérer les dépendances de composants.