Le pilote de services de tâches manuelles a été conçu pour notifier à un ou plusieurs utilisateurs la survenue d'un événement au niveau des données et, le cas échéant, la nécessité d'une opération de leur part. Par exemple, dans un scénario de provisioning d'employé, il peut s'agir de la création d'un nouvel objet Utilisateur et l'opération de l'utilisateur peut consister à assigner un numéro de bureau en saisissant des données dans eDirectory ou dans une application. D'autres scénarios incluent l'envoi d'une notification à l'administrateur pour lui signaler la création d'un objet Utilisateur, la modification des données d'un objet par un utilisateur, etc.
Pour configurer le pilote de service de tâches manuelles, vous devez en général configurer deux sous-systèmes séparés mais liés : les modèles de courrier électronique et les stratégies de canal Abonné, ainsi que les modèles du serveur Web du canal Éditeur et ses stratégies.
En outre, les paramètres de pilote comme le nom du serveur SMTP, le numéro de port du serveur Web, etc., doivent être définis.
Dans cette section :
Installation :le pilote de services de tâches manuelles est automatiquement installé lorsque vous installez l'option depuis le programme d'installation de Identity Manager.
Plates-formes : le pilote s'exécute sur les plates-formes prises en charge par Identity Manager et le chargeur distant.
Activation : le pilote n'a pas besoin d'être activé séparément. Il est activé en même temps que le moteur méta-annuaire.
Vous trouverez dans cette section des informations sur le fonctionnement des différentes fonctionnalités du pilote.
Deux principaux modes de fonctionnement sont pris en charge :
Demande directe de données : un message électronique est envoyé pour demander à l'utilisateur de saisir des données dans eDirectory (ces données pourront être éventuellement utilisées par une autre application). Le destinataire répond en cliquant sur l'URL fournie dans le message. L'URL désigne le serveur Web fonctionnant sur le canal Éditeur du pilote de service de tâches manuelles. L'utilisateur interagit avec les pages Web dynamiques générées par le serveur Web pour s'authentifier auprès de eDirectory™ et pour entrer les données demandées.
Notification d'événement :un message électronique est envoyé à l'utilisateur sans utiliser le canal Éditeur. Il peut simplement s'agir de la notification d'une opération effectuée dans eDirectory ou d'une requête de données par un moyen autre que le serveur Web du canal Éditeur, par exemple Novell iManager, une autre application ou une interface personnalisée.
Voici un scénario d'exemple de provisioning d'employé dans lequel le responsable d'un nouvel employé affecte à celui-ci un numéro de bureau :
Voici un exemple de scénario dans lequel le responsable d'un nouvel employé assigne à celui-ci un ordinateur dans un système de gestion des ressources :
Les messages électroniques, les pages Web au format HTML et les documents XDS peuvent tous être considérés comme des documents. Le pilote de service de tâches manuelles crée des documents de manière dynamique, en fonction des informations fournies au pilote.
Les modèles sont des documents XML qui contiennent les textes standard ou parties fixes d'un document, ainsi que des jetons de remplacement qui indiquent l'emplacement des parties dynamiques (de remplacement) du document final construit.
Le canal Abonné et le canal Éditeur du pilote de service de tâches manuelles utilisent des modèles pour créer des documents. Le canal Abonné crée des messages électroniques et le canal Éditeur, des pages Web et des documents XDS.
La partie dynamique d'un document est fournie via des données de remplacement. Les données de remplacement sur le canal Abonné sont fournies par les stratégies de canal Abonné (par exemple la stratégie de transformation de la commande). Celles du canal Éditeur proviennent des données HTTP (données d'URL et données HTTP POST) envoyées au serveur Web. Le pilote de service de tâches manuelles peut automatiquement fournir certaines données qu'il connaît (par exemple, l'adresse du serveur Web).
Les modèles sont traités par des feuilles de style XSLT. Ces feuilles de style de traitement des modèles sont séparées des feuilles de style utilisées comme stratégies DirXML dans le canal Abonné ou le canal Éditeur.
Les données de remplacement sont fournies à la feuille de style XSLT sous forme de paramètre. Le résultat du traitement de la feuille de style est un document XML, HTML ou texte. Il sera utilisé comme corps d'un message électronique, comme page Web ou sera envoyé à DirXML sur le canal Éditeur.
Les données de remplacement sont acheminées du canal Abonné vers le canal Éditeur via l'URL qui figure dans le message électronique. L'URL comprend une section requête qui contient les éléments de données de remplacement.
Le pilote de service de tâches manuelles est fourni avec suffisamment de feuilles de style prédéfinies pour traiter les modèles et créer des documents électroniques, des documents HTML et des documents XDS. D'autres feuilles de style personnalisées peuvent être créées afin de fournir, au besoin, d'autres options de traitement.
Une méthode avancée de création de documents est également disponible, qui utilise uniquement une feuille de style XSLT et des données de remplacement. Aucun modèle n'intervient dans la procédure. Toutefois, ce guide suppose l'utilisation de la méthode modèle parce que la méthode modèle est plus facile à configurer et à maintenir sans connaissance de la programmation XSLT.
Cette section décrit les modèles de création de documents utilisés dans le pilote de service de tâches manuelles.
Les modèles sont des documents XML qui sont traités par une feuille de style afin de générer un document final. Le document final peut être un document XML, HTML ou du texte ordinaire (ou tout autre document qui peut être généré en utilisant XSLT).
Les modèles permettent de générer le texte de messages électroniques sur le canal Abonné, ainsi que des pages Web dynamiques et des documents XDS sur le canal Éditeur.
Les modèles contiennent du texte, des éléments et des jetons de remplacement. Les jetons de remplacement sont remplacés dans le document final par les données fournies à la feuille de style qui traite le modèle.
Plusieurs exemples de modèles (qui ont des fonctions diverses) sont présentés ci-dessous. Dans ces exemples, les jetons de remplacement correspondent aux chaînes de caractères comprises entre les deux signes $ et apparaissant en gras.
Les modèles peuvent aussi contenir des éléments d'opération. Ce sont des éléments de commande interprétés par la feuille de style de traitement des modèles. Les éléments d'opération sont décrits dans l'Section F.0, Pilote de services de tâches manuelles : référence de modèles d'éléments d'opération. Dans les exemples suivants, les éléments d'opération apparaissent également en gras.
Le modèle de l'exemple suivant permet de produire le corps d'un message électronique au format HTML :
<html xmlns:form="http://www.novell.com/dirxml/manualtask/form"> <head></head> <body> Dear $manager$,<p/> <p> This message is to inform you that your new employee <b>$given-name$ $surname$</b> has been hired. <p> You need to assign a room number for this individual. Click <a href="$url$">Here</a> to do this. </p> <p> Thank you,<br/> HR Department </p> </body> </html>
Le modèle de l'exemple suivant permet de produire le corps d'un message électronique au format texte ordinaire :
<form:text xmlns:form="http://www.novell.com/dirxml/manualtask/form"> Dear $manager$, This message is to inform you that your new employee $given-name$ $surname$ has been hired. You need to assign a room number for this individual. Use the following link to do this: $url$ Thank you, The HR Department </form:text>
L'élément <form:text> est requis parce que les modèles doivent être des documents XML. L'élément <form:text> est supprimé lors du traitement du modèle.
Le modèle suivant permet de produire un formulaire HTML utilisé comme page Web pour l'entrée de données :
<html xmlns:form="http://www.novell.com/dirxml/manualtask/form">
<head>
<title>Enter room number for $subject-name$</title>
</head>
<body>
<link href="novdocmain.css" rel="style sheet" type="text/css"/>
<br/><br/><br/><br/>
<form class="myform" METHOD="POST" ACTION="$url-base$/process_template.xsl">
<table cellpadding="5" cellspacing="10" border="1" align="center">
<tr><td>
<input TYPE="hidden" name="template" value="post_form.xml"/>
<input TYPE="hidden" name="subject-name" value="$subject-name$"/>
<input TYPE="hidden" name="association" value="$association$"/>
<input TYPE="hidden" name="response-style sheet" value="process_template.xsl"/>
<input TYPE="hidden" name="response-template" value="post_response.xml"/>
<input TYPE="hidden" name="auth-style sheet" value="process_template.xsl"/>
<input TYPE="hidden" name="auth-template" value="auth_response.xml"/>
<input TYPE="hidden" name="protected-data" value="$protected-data$"/>
You are:<br/>
<form:if-single-item name="responder-dn">
<input TYPE="hidden" name="responder-dn" value="$responder-dn$"/>
$responder-dn$
</form:if-single-item> <form:if-multiple-items name="responder-dn"> <form:menu name="responder-dn"/> </form:if-multiple-items>
</td></tr>
<tr><td>
Enter your password: <br/>
<input name="password" TYPE="password" SIZE="20" MAXLENGTH="40"/>
</td></tr>
<tr><td>
Enter room number for $subject-name$:<br/>
<input TYPE="text" NAME="room-number" SIZE="20" MAXLENGTH="20" value="$query:roomNumber$"/>
</td></tr>
<tr><td>
<input TYPE="submit" value="Submit"/> <input TYPE="reset" value="Clear"/>
</td></tr>
</table>
</form>
</body>
</html>
Le modèle suivant permet de produire un document XDS :
<nds>
<input>
<modify class-name="User" src-dn="not-applicable">
<association>$association$</association>
<modify-attr attr-name="roomNumber">
<remove-all-values/>
<add-value>
<value>$room-number$</value>
</add-value>
</modify-attr>
</modify>
</input>
</nds>
Les éléments délimités par des signes $ dans les exemples de modèles ci-dessus sont des jetons de remplacement. Par exemple, $manager$ est remplacé par le nom réel du responsable.
Les jetons de remplacement peuvent apparaître dans les valeurs d'attribut texte ou XML (notez la valeur href sur l'élément <a> dans le premier exemple ci-dessus).
Les données de remplacement sont des chaînes qui vont prendre la place des jetons de remplacement dans le document final généré à partir d'un modèle. Ces chaînes proviennent soit de données du canal Abonné, soit de données HTTP du canal Éditeur ou sont automatiquement fournies par le pilote. Un type supplémentaire de données de remplacement sont les données récupérées de eDirectory via Identity Manager (données de requête). Les données de remplacement sont décrites plus en détail dans l'Section D.0, Pilote de services de tâches manuelles : données de remplacement.
Données du canal Abonné :les données de remplacement qui proviennent du canal Abonné sont de deux types. Le premier fournit les valeurs des jetons de remplacement contenus dans les modèles utilisés pour créer des messages électroniques. Le second est placé dans la partie requête d'une URL pour que les données puissent être utilisées sur le canal Éditeur lorsque l'URL est soumise au serveur Web du canal Éditeur.
Données HTTP : les données de remplacement sont fournies au serveur Web du canal Éditeur sous la forme de données de chaîne de requête d'URL, données HTTP POST ou les deux.
Données automatiques : le pilote de service de tâches manuelles fournit des données automatiques. Les données automatiques sont décrites dans l'Section E.0, Pilote de services de tâches manuelles : éléments de données de remplacement automatiques.
Données de requête :les jetons de remplacement qui commencent par query: sont considérés comme des demandes de données actuelles auprès de eDirectory. La partie du jeton qui suit query: est le nom d'un attribut d'objet eDirectory. L'objet à interroger est spécifié par l'une des données de remplacement association, src-dn ou src-entry-id. Les éléments sont considérés dans l'ordre présenté dans la phrase précédente.
Les éléments d'opération sont des éléments qualifiés par un espace de nom. Ils figurent dans le modèle et sont utilisé pour une commande simple ou pour créer des éléments HTML pour des formulaires HTML. L'espace de nom utilisé pour qualifier les éléments est http://www.novell.com/dirxml/manualtask/form. Dans ce document et dans les exemples de modèles fournis avec le pilote de service de tâches manuelles, le préfixe utilisé est form.
Les éléments qui apparaissent en gras dans les exemples ci-dessus sont des éléments d'opération.
Les éléments d'opération sont décrits en détail dans l'Section F.0, Pilote de services de tâches manuelles : référence de modèles d'éléments d'opération.
Le canal Abonné du pilote de service de tâches manuelles est conçu pour envoyer des messages électroniques. Pour ce faire, le pilote prend en charge un élément XML personnalisé nommé <mail>. Les stratégies sur le canal Abonné construisent un élément <mail> en réponse à un événement eDirectory (par exemple, la création d'un utilisateur). Un exemple d'élément <mail> est fourni ci-dessous :
<mail src-dn="\PERIN-TAO\novell\Provo\Joe">
<to>JStanley@novell.com</to>
<cc>carol@novell.com</cc>
<reply-to>HR@novell.com</reply-to>
<subject>Room Assignment Needed for: Joe the Intern</subject>
<message mime-type="text/html">
<stylesheet>process_template.xsl</stylesheet>
<template>html_msg_template.xml</template>
<replacement-data>
<item name="manager">JStanley</item>
<item name="given-name">Joe</item>
<item name="surname">The Intern</item>
<url-data>
<item name="file">process_template.xsl</item>
<url-query>
<item name="template">form_template.xml</item>
<item name="responder-dn" protect="yes">\PERIN-TAO\big-org\phb</item>
<item name="responder-dn" protect="yes">\PERIN-TAO\big-org\carol</item>
<item name="subject-name">Joe The Intern</item>
</url-query>
</url-data>
</replacement-data>
<resource cid="css-1">novdocmain.css</resource>
</message>
<message mime-type="text/plain">
<stylesheet>process_text_template.xsl</stylesheet>
<template>txt_msg_template.xml</template>
<replacement-data>
<item name="manager">JStanley</item>
<item name="given-name">Joe</item>
<item name="surname">The Intern</item>
<url-data>
<item name="file">process_template.xsl</item>
<url-query>
<item name="template">form_template.xml</item>
<item name="responder-dn" protect="yes">\PERIN-TAO\big-org\phb</item>
<item name="responder-dn" protect="yes">\PERIN-TAO\big-org\carol</item>
<item name="subject-name">Joe The Intern</item>
</url-query>
</url-data>
</replacement-data>
</message>
<attachment>HR.gif</attachment>
</mail>
Le canal Abonné du pilote de services de tâches manuelles utilise les informations contenues dans l'élément <mail> pour construire un message électronique SMTP. Une URL peut être construite et insérée dans le message électronique via laquelle le destinataire du message peut répondre au message. L'URL peut pointer vers le serveur Web du canal Éditeur ou pointer vers un autre serveur Web.
L'élément <mail> et son contenu sont décrits en détail dans l'Section G.0, Pilote de services de tâches manuelles : référence à l'élément <mail>.
Le canal Éditeur du pilote de service de tâches manuelles exécute un serveur Web configuré de telle sorte que les utilisateurs puissent entrer des données dans eDirectory via un navigateur Web. Le serveur Web est conçu pour fonctionner en association avec les messages électroniques envoyés du canal Abonné du pilote de service de tâches manuelles.
Le serveur Web du canal Éditeur peut fournir des fichiers statiques et des contenus dynamiques. Les fichiers statiques comprennent par exemple les feuilles de style .css, les images, etc. Les contenus dynamiques sont par exemple les pages Web qui changent selon les données de remplacement contenues dans les données d'URL ou HTTP POST.
Le serveur Web du canal Éditeur est normalement configuré pour permettre à un utilisateur d'entrer des données dans eDirectory en réponse à un message électronique envoyé par le canal Abonné. Une interaction typique de l'utilisateur avec le serveur Web se ferait comme suit :
Cette section décrit la configuration des paramètres et des modèles du pilote de services de tâches manuelles.
Cette section décrit les paramètres qui apparaissent dans la section “Configuration du pilote” de l'interface utilisateur de l'objet pilote.
Plusieurs de ces paramètres concernent en fait le serveur Web du canal Éditeur. Ils apparaissent dans la zone Configuration du pilote parce que l'Abonné du pilote de service de tâches manuelles a également besoin d'y accéder.
Ce paramètre est le DN eDirectory d'un objet Conteneur. Le pilote de service de tâches manuelles peut charger des documents XML (y compris des feuilles de style XSLT) à partir de eDirectory et à partir du disque. Si vous devez charger des documents XML à partir de eDirectory, ce paramètre identifie le conteneur racine à partir duquel les documents seront chargés.
Les documents chargés à partir de eDirectory résident dans la valeur d'attribut d'un objet eDirectory. Si aucun attribut n'est pas précisé, XmlData est utilisé par défaut. Vous pouvez spécifier l'attribut en ajoutant le symbole # suivi du nom d'attribut au nom de l'objet contenant le document.
Par exemple, supposons que le DN de base de documents est spécifié comme « novell\Manual Task Documents » et qu'il y a dans « Documents Manual Task » un conteneur nommé « templates ».
Si un objet Feuille de style DirXML nommé « e-mail _template » réside sous le répertoire « templates », les identificateurs de ressources suivants peuvent être utilisés pour faire référence au document XML : “templates/e-mail _template” ou “templates/e-mail _template#XmlData”.
Les identificateurs de ressource peuvent être fournis sous la forme de données de remplacement, données d'URL ou données HTTP POST. Par exemple, l'élément suivant peut apparaître sous un élément <message> dans le canal Abonné :
<template>templates/e-mail _template#XmlData</template>
Ce paramètre identifie un répertoire de système de fichiers qui sert de répertoire de base pour la localisation des ressources telles que les modèles, les feuilles de style XSLT et d'autres ressources fichier fournies par le serveur Web du canal Éditeur. Exemples de valeurs :
Ce paramètre indique si le canal Éditeur doit exécuter ou non un serveur Web. Réglez le paramètre sur vrai si le serveur Web doit être exécuté ou faux si le serveur Web ne doit pas être exécuté.
Si le pilote de service de tâches manuelles n'est utilisé que pour envoyer un message électronique sans URL de réponse ou avec une URL qui pointe vers une autre application, le serveur HTTP ne doit pas être exécuté, pour enregistrer les ressources système.
Ce paramètre permet de spécifier à quelle adresse, parmi les multiples adresses IP locales, le serveur Web du canal Éditeur écoutera les requêtes HTTP.
Si vous laissez la valeur du paramètre nom d'hôte ou adresse HTTP IP vide, le serveur Web du canal Éditeur écoutera sur l'adresse IP par défaut. Pour les serveurs avec une seule adresse IP, cela est suffisant. Si vous placez une adresse IP à points comme valeur de paramètre, le serveur Web du canal Éditeur écoutera les requêtes HTTP sur l'adresse spécifiée.
Notez que la valeur spécifiée pour l'adresse IP HTTP ou le nom d'hôte est utilisée par le gestionnaire de messagerie du canal Abonné pour construire les URL si aucun nom d'hôte ni adresse n'est précisé dans l'élément de commande de courrier. Si le paramètre Use HTTP server (true|false) est réglé sur faux, l'adresse HTTP IP ou le nom d'hôte peut servir à spécifier l'adresse ou le nom d'un serveur Web à utiliser dans la construction des URL pour les messages de courrier électronique.
Ce paramètre est un nombre entier qui indique le port TCP sur lequel le serveur Web du canal Éditeur doit écouter les requêtes entrantes. Si cette valeur n'est pas spécifiée, le numéro de port prend par défaut la valeur 80 ou 443, selon que le SSL est utilisé ou non pour les connexions du serveur Web.
Si le pilote de services de tâches manuelles fonctionne sur le serveur Identity Manager (c'est-à-dire, s'il n'est pas exécuté sous le chargeur distant sur une machine distante), le port HTTP doit être défini sur une valeur différente de 80 ou 443. En effet, les ports 80 et 443 sont généralement utilisés par iMonitor ou d'autres processus.
Ce paramètre, lorsqu'il est renseigné, indique le nom de l'objet Matériel clé (KMO) eDirectory qui contient le certificat et la clé de serveur utilisés pour SSL par le serveur Web du canal Éditeur.
La définition de ce paramètre oblige le serveur Web du canal Éditeur à utiliser SSL pour traiter les requêtes HTTP.
Il a la priorité sur tous les paramètres Keystore Java* (reportez-vous ci-dessous).
L'utilisation de SSL est recommandée pour des raisons de sécurité parce que les mots de passe eDirectory sont transmis dans les données HTTP POST lors de l'utilisation du serveur Web du canal Éditeur
Ce paramètre, ainsi que le mot de passe Keystore, le nom du certificat (alias de la clé) et le mot de passe du certificat (mot de passe clé) sert à spécifier un fichier keystore Java qui contient un certificat et une clé utilisés pour SSL par le serveur Web du canal Éditeur.
La définition de ce paramètre oblige le serveur Web du canal Éditeur à utiliser SSL pour traiter les requêtes HTTP.
Si le nom du paramètre KMO est défini, ce paramètre et ses paramètres associés sont ignorés.
L'utilisation de SSL est recommandée pour des raisons de sécurité à condition que les mots de passe eDirectory soient transmis sous la forme de données HTTP POST lors de l'utilisation du serveur Web du canal Éditeur.
Ce paramètre spécifie le mot de passe pour le fichier keystore Java spécifié avec le paramètre Nom du fichier keystore.
Ce paramètre spécifie le nom du certificat à utiliser dans le fichier keystore Java spécifié avec le paramètre Nom du fichier keystore.
Ce paramètre spécifie le mot de passe pour le certificat spécifié en utilisant le paramètre Nom du certificat (alias de la clé).
Cette section décrit les paramètres du canal Abonné.
Ce paramètre précise le nom du serveur SMTP utilisé par le canal Abonné pour l'envoi des messages électroniques.
Si le serveur SMTP spécifié en utilisant le paramètre du serveur SMTP nécessite une authentification, ce paramètre spécifie le nom de compte à utiliser pour l'authentification. Le mot de passe utilisé est le mot de passe Application associé aux paramètres Authentification du pilote.
Lorsqu'elle est précisée, cette adresse électronique est celle utilisée dans le champ SMTP « De » pour les messages électroniques envoyés par le canal Abonné. Lorsque cette adresse n'est pas indiquée, les éléments <mail> envoyés au canal Abonné doivent contenir un élément <from>.
Tout élément <from> contenu dans des éléments <mail> envoyés au canal Abonné a priorité sur ce paramètre.
Lorsqu'il est précisé, ce paramètre correspond à une liste de noms de classes Java séparés par des blancs. Chaque nom de classe est une classe personnalisée qui implémente l'interface com.novell.nds.dirxml.driver.manualtask.CommandHandler et gère un élément XDS personnalisé. Le gestionnaire qui traite l'élément <mail> est un gestionnaire intégré.
Des informations supplémentaires sur les gestionnaires personnalisés sont disponibles dans l'Section I.0, Pilote de service de tâches manuelles : gestionnaires des éléments personnalisés pour le canal Abonné.
Cette section décrit les paramètres du canal Éditeur.
Lorsque ce paramètre est précisé, il correspond à une liste de noms de classes Java séparés par des blancs. Chaque nom de classe est une classe personnalisée qui étend javax.servlet.http.HttpServer. Les servlets personnalisées peuvent servir à étendre la fonctionnalité du serveur Web du canal Éditeur.
Des informations supplémentaires sur les servlets personnalisées sont disponibles dans l'Section J.0, Pilote de service de tâches manuelles : servlets personnalisés pour le canal Éditeur.
La configuration des stratégies de canal Abonné dépend de ce qu'une installation particulière accomplira avec le pilote de service de tâches manuelles. Toutefois, certaines instructions peuvent vous aider.
En général, le meilleur endroit pour construire un élément <mail> à envoyer à l'Abonné est la stratégie de transformation de la commande. En effet, la plus grande partie du traitement du moteur DirXML a été effectuée lorsque les commandes atteignent la stratégie de transformation de la commande. Cela signifie que les stratégies de création ont été traitées pour les événements d'ajout (ce qui permet par exemple d'opposer un veto sur les événements d'ajout d'objets qui ne possèdent pas tous les attributs nécessaires à la construction du message électronique). Cela signifie également que les événements de modification d'objets sans association ont déjà été convertis en événements d'ajout.
La feuille de style XSLT qui construit le message électronique peut ou non avoir besoin d'interroger eDirectory pour des informations supplémentaires.
Par exemple, si le message électronique est simplement un message de bienvenue destiné à un employé nouvellement embauché, la commande d'ajout peut contenir toutes les informations nécessaires : prénom, nom et adresse de messagerie Internet. Il faut spécifier dans la stratégie de création que le prénom, le nom et l'adresse de messagerie Internet sont des attributs requis. Ainsi, seules les commandes d'ajout qui contiennent les informations nécessaires peuvent parvenir à la transformation de la commande.
Toutefois, si le message électronique est un message au responsable d'un employé, la feuille de style doit interroger eDirectory. Le DN du responsable s'obtient auprès de l'événement d'ajout de l'objet Utilisateur de l'employé, mais une requête doit être envoyée afin d'obtenir son adresse électronique car ces informations sont un attribut de l'objet Utilisateur du responsable.
En outre, si des notifications par courrier électronique sont générées suite au résultat des commandes de modification d'objets associés au pilote, des requêtes doivent être envoyées afin d'obtenir les informations non contenues dans la commande de modification.
Si des messages électroniques doivent être générés à partir d'événements différents des événements d'ajout, les événements d'ajout doivent être autorisés à atteindre le canal Abonné associé aux objets à surveiller. L'autorisation d'envoi des événements d'ajout à l'Abonné donne une valeur d'association générée qui est renvoyée par l'Abonné à Identity Manager.
Il est important que les objets eDirectory qui doivent être surveillés par les stratégies du pilote de service de tâches manuelles aient une association pour le pilote de service de tâches manuelles. Seuls les objets dotés d'une association verront les événements de suppression, de réassignation de nom et de déplacement signalés au pilote. En outre, les événements de modification sur des objets sans association sont convertis en événements d'ajout après la transformation de l'événement sur le canal Abonné.
Toutes les autres commandes (modifier, déplacer, renommer et supprimer) doivent être bloquées par la stratégie de transformation de la commande et ne pourront pas atteindre l'Abonné. L'Abonné gère uniquement les commandes <add> et les commandes <mail>. Les autres commandes donnent une erreur renvoyée par l'Abonné.
Des messages électroniques sont envoyés par le canal Abonné en réponse à la réception d'un élément <mail> qui décrit le message électronique à envoyer. Reportez-vous à l'Section G.0, Pilote de services de tâches manuelles : référence à l'élément <mail> pour voir la description de l'élément <mail> et de son contenu.
Des messages électroniques peuvent être générés en réponse à tout événement Identity Manager (ajout, modification, réassignation de nom, déplacement, suppression).
Les données de remplacement qui sont fournies avec les éléments <message> enfants d'un élément <mail> dépendent de deux facteurs principaux :
Si le message électronique doit contenir une URL qui pointe sur le serveur Web du canal Éditeur et est utilisée pour solliciter des informations auprès d'un utilisateur, les données de remplacement doivent contenir au moins un élément responder-dn. Les valeurs des éléments « responder-dn » doivent correspondre aux DN des objets Utilisateur des utilisateurs auxquels le message est envoyé.
Si un jeton de remplacement de requête (reportez-vous à la Données de remplacement) est utilisé dans le modèle, les données de remplacement pour l'élément <message> doivent contenir un élément nommé src-dn, src-entry-id ou une association à la valeur appropriée. Un élément d'association ne peut être utilisé que si l'objet eDirectory sur lequel porte la requête est déjà doté d'une association pour le pilote de service de tâches manuelles. L'association générée par l'Abonné pour les objets non associés ne peut pas être utilisée parce qu'elle n'a pas été écrite sur l'objet eDirectory lorsque la requête a eu lieu.
L'élément <message> peut spécifier le type MIME du corps du message. Si le type MIME est spécifié mais qu'aucune feuille de style ne l'est (autrement dit, il n'y a pas d'élément <stylesheet> enfant de <message>), une des deux feuilles de style par défaut est utilisée. Si le type MIME a pour valeur text/plain, le nom de la feuille de style par défaut est process_text_template.xsl. Si le type MIME a une valeur autre que text/plain, le nom de la feuille de style par défaut est process_template.xsl.
Les modèles de messages électroniques sont des documents XML qui contiennent du texte standard et des jetons de remplacement. Ils permettent de générer le texte du corps d'un message. Reportez-vous à la Modèles afin d'obtenir des informations générales sur les modèles.
Les jetons de remplacement utilisés dans un modèle de message électronique déterminent les éléments <item> qui doivent être fournis comme enfants de l'élément <replacement-data> construit par la stratégie du canal Abonné qui construit l'élément <mail>. Par exemple, si le modèle de message électronique comporte le jeton de remplacement $employee-name$, il doit y avoir un élément <item name=“employee-name”> dans les données de remplacement pour l'élément <message>. Si l'élément du nom employé est absent, le corps du message électronique résultant ne comporte pas de texte dans l'emplacement occupé par le jeton de remplacement dans le modèle.
Les modèles de messages électroniques peuvent être utilisés pour générer des corps de messages au format texte ordinaire, HTML ou XML.
Si un modèle de message électronique génère un message au format texte ordinaire, il doit être traité par une feuille de style qui précise « texte ordinaire » comme type de sortie. Si la feuille de style ne précise pas qu'il s'agit de texte ordinaire, des caractères d'échappement XML indésirables seront générés. La feuille de style par défaut du pilote de services de tâches manuelles, process_text_template.xsl, est normalement utilisée pour traiter les modèles qui produisent des documents au format texte ordinaire.
Dans la plupart des implémentations du pilote de service de tâches manuelles, aucune stratégie de canal Éditeur n'est nécessaire. En effet, il est possible de construire la page Web et les modèles XDS pour qu'ils donnent exactement le XDS requis et le XDS n'aura plus besoin ensuite d'être traité par les stratégies.
Si des stratégies sont requises, elles seront très spécifiques à une installation.
Les modèles de pages Web sont des documents XML qui contiennent du texte standard et des jetons de remplacement. Ils permettent de générer des documents de pages Web (généralement des documents HTML). Reportez-vous à la Modèles afin d'obtenir des informations générales sur les modèles.
Les jetons de remplacement dans les modèles de page Web déterminent quelles données de remplacement sont fournies sous la forme de données de requête d'URL sur le canal Abonné. Sur le canal Éditeur, les données de remplacement sont obtenues à partir de la chaîne de requête d'URL correspondant aux requêtes HTTP GET, et à partir de la chaîne de requête d'URL et des données POST correspondant aux requêtes HTTP POST.
Considérez par exemple le flux de données de remplacement du canal Abonné vers le message électronique puis vers le serveur Web du canal Éditeur :
Le pilote de services de tâches manuelles est configuré de telle sorte que le responsable d'un nouvel employé doit assigner à ce dernier un numéro de bureau. L'envoi du message électronique au responsable est déclenché par la commande d'ajout <add> d'un nouvel objet Utilisateur traité par la stratégie de transformation de commande du canal Abonné.
Lorsque le responsable clique sur l'URL qui figure dans le message, une page Web s'affiche dans son navigateur Web. Cette page doit indiquer pour qui le responsable doit entrer un numéro de bureau.
Pour ce faire, l'élément <url-query> du canal Abonné contient un élément de données de remplacement qui identifie le nouvel utilisateur par son nom :
<item name=”subject-name”>Joe the Intern</item>
La chaîne de requête d'URL contient donc (entre autres) “subject-name=Joe%20the%20Intern” (le “%20” représente un espace codé URL).
Le navigateur Web du responsable soumet l'URL au serveur Web du canal Éditeur dès que le responsable clique sur l'URL dans le message. Le serveur Web construit l'élément de données de remplacement « subject-name » associé à la valeur « Joe le stagiaire ».
Le modèle de page Web également spécifié par l'URL contient le jeton de remplacement $subject-name$. Lorsque le modèle de page Web est traité par la feuille de style pour construire la page Web, le jeton de remplacement est remplacé par « Joe le stagiaire », qui personnalise la page Web correspondant à l'employé dont la création de l'objet Utilisateur a causé l'envoi du message électronique.
Pour obtenir des informations supplémentaires sur une transaction complète canal Abonné à canal Éditeur, reportez-vous à l'Section H.0, Pilote de services de tâches manuelles : scénario de flux de données pour le nouvel employé.
Les modèles XDS sont des documents XML qui contiennent du texte standard et des jetons de remplacement. Les modèles XDS servent à générer des documents XDS qui sont soumis à Identity Manager sur le canal Éditeur du pilote de services de tâches manuelles. Afin d'obtenir des informations générales sur les modèles, reportez-vous à la section Modèles de la section Présentation.
Les jetons de remplacement utilisés dans les modèles XDS déterminent certaines données de remplacement qui sont fournies au serveur Web sous la forme de données de requête HTTP POST.
Considérez par exemple le modèle XDS suivant :
<nds>
<input>
<modify class-name="User" src-dn="not-applicable">
<association>$association$</association>
<modify-attr attr-name="roomNumber">
<remove-all-values/>
<add-value>
<value>$room-number$</value>
</add-value>
</modify-attr>
</modify>
</input>
</nds>
Les jetons de remplacement utilisés dans le modèle indiquent que les données HTTP POST doivent fournir une valeur d'association et une valeur de numéro de bureau.
Normalement, la valeur d'association provient du canal Abonné. Le message électronique du canal Abonné place « association=une certaine valeur » dans la chaîne de requête de l'URL insérée dans le message. Le modèle de page Web utilisé pour générer la page Web lors de la soumission de l'URL au serveur Web place généralement la valeur d'association dans un élément INPUT masqué :
<INPUT TYPE="hidden" NAME="association" VALUE="$association$"/>
Si on place la valeur d'association comme élément INPUT masqué, la paire « association“une certaine valeur » doit être soumise avec les données HTTP POST.
La valeur de numéro de bureau est entrée dans la page Web à l'aide d'un élément INPUT similaire au suivant :
<input TYPE="text" NAME="room-number" SIZE="20" MAXLENGTH="20"/>
Si le responsable saisit 1234 et clique sur Soumettre, le navigateur Web envoie « room-number=1234 » parmi les données HTTP POST.
Le serveur Web génère ensuite un élément de données de remplacement <item name=“association”> et un élément de données de remplacement <item name=“room-number”> qui sont utilisés lors du traitement du modèle XDS.
Le document XDS est généré en traitant le modèle XDS à l'aide de la feuille de style spécifiée dans les données POST. Ensuite, le document XDS est soumis à Identity Manager sur le canal Éditeur du pilote de services de tâches manuelles.
Le pilote de service de tâches manuelles émet des messages avec différents niveaux de suivi :
Pour plus d'informations sur les paramètres du pilotes de services de tâches manuelles, reportez-vous aux annexes suivantes :