4 Personnalisation du pilote. Novell 4.0 pour PeopleSoft
Novell Confidential Manual (FRA) 28 October 2003
4
Personnalisation du pilote
Cette section traite de la personnalisation du pilote par le déclenchement de transactions grâce au programme PSA via PeopleCode.
Personnalisation de l’agent PSA par le déclenchement de transactions
Les transactions sont déclenchées à l’aide de données PeopleCode dans PeopleSoft et sont écrites dans des tables de transaction. Pour permettre le traitement par plusieurs pilotes, vous pouvez classer le traitement des transactions en utilisant une valeur de sous-type de pilote différente.
L’administrateur ou le consultant PeopleSoft peut déclencher des transactions dans n’importe quelle circonstance liée à un processus PeopleSoft prédéfini ou créer des transactions à l’aide d’un mécanisme par lots.
Vous pouvez utiliser les informations suivantes pour créer vos propres déclencheurs de transaction
également nommés appels de fonction PeopleCode.
Un appel de fonction PeopleCode se présente ainsi :
DirXML_Trans(Table de transaction,
Sous-type de transaction,
Schéma de transaction,
Événement de transaction,
ID d'association de transaction,
Date et heure de la transaction,
Valeur de la transaction,
Nom du champ Row Delete (Supprimer la ligne),
Clé du champ Row Delete (Supprimer la ligne);
En utilisant le format et l’exemple de données plus haut, un appel de fonction réel se présente ainsi :
DirXML_Trans("DIRXML_TRANS01",
"NPSDriver1",
DIRXML_SCHEMA01,
"A",
DIRXML_PERS_VW.EMPLID,
%Datetime,
"",
"",
"");
Personnalisation du pilote
31
Novell Confidential Manual (FRA) 28 October 2003
Définitions des paramètres d’appel de fonction
Paramètre
Table de transaction
Description
Le nom de la table dans laquelle les transactions sont écrites. Cette table est créée dans PeopleTools et les éléments de champ doivent correspondre à ceux de la table DIRXML_TRANS01 fournie.
Valeur par défaut
DIRXML_TRANS01
Sous-type de transaction Le nom utilisé pour identifier le type de transaction. Le pilote utilise ce paramètre pour traiter les types de transactions spécifiés.
Schéma de transaction
Événement de transaction
ID d’association de transaction
NPSDriver1
Le nom de l’objet CI de schéma auquel la transaction est connectée. Le pilote utilise le nom de cet objet pour lancer une requête dans les données connectées au type de transaction.
DIRXML_SCHEMA01
Le type d’événement XML écrit dans la table de transaction. Il peut s’agir d’une des 4 valeurs listées.
A=ADD
M=MODIFY
D=DELETE
R=ROW DELETE
L’identificateur utilisé pour associer un enregistrement particulier de PeopleSoft à un objet eDirectory. Il peut s’agir de la valeur
EMPLID pour les employés, de la valeur
STUDENTID pour les étudiants, de la valeur
DEPTID pour les services, de la valeur
ACCTID pour les codes de compte, etc. Les
éléments clés doivent être identifiés pour le schéma de transaction.
DIRXML_ASSOC_ID
Date et heure de la transaction
L’élément date/heure utilisé pour déterminer le moment auquel la transaction a été traitée.
%Datetime
Valeur de la transaction Le paramètre contient 1...n valeurs que le développeur souhaite envoyer au pilote lors du traitement. Cette valeur peut ne pas être disponible via l’objet Schéma lorsqu’une transaction est traitée par le pilote.
DIRXML_S_ID | "|" |
DIRXML_S_LN
Nom du champ Row
Delete (Supprimer la ligne)
Le nom du champ de l’attribut du niveau de défilement.
PHONES
Clé du champ Row
Delete (Supprimer la ligne)
Le type de données de l’attribut.
BUSN
32
Guide d’implémentation du pilote DirXML pour PeopleSoft
Novell Confidential Manual (FRA) 28 October 2003
Personnalisation du pilote grâce aux modifications des règles du pilote
Cette section contient des informations pour vous aider à comprendre comment les règles du pilote sont implémentées et comment vous pouvez modifier ces objets. Les rubriques sont les suivantes :
« Modification de la règle d’assignation du pilote », page 33
« Présentation du filtre du canal Éditeur », page 34
« Règles de l’objet Éditeur », page 36
« Objets du canal Abonné », page 41
« Règles de l’objet Abonné », page 43
Modification de la règle d’assignation du pilote
La règle d’assignation représente un objet Novell
®
eDirectory
TM
qui détermine la relation entre des champs de données définis dans l’application PeopleSoft et des attributs eDirectory. La règle d’assignation est située dans le conteneur de l’objet Pilote ; elle est utilisée par le canal Éditeur et par le canal Abonné du pilote.
Une règle d’assignation par défaut préconfigurée est fournie avec le produit du pilote. Les assignations définies dans cette règle ont été créées en coordination avec l’interface de composant
(CI) préconfigurée de l’application PeopleSoft, qui est également fournie avec le produit du pilote.
Le CI par défaut est appelé DIRXML_SCHEMA01 et représente un ensemble de données relatives
à des employés. Les champs de données de ce CI sont assignés à des attributs similaires de l’objet
Utilisateur eDirectory.
L’exemple suivant illustre la règle d’assignation fournie. nds-name représente le nom de la classe ou de l’attribut dans eDirectory et app-name représente la classe ou l’attribut du CI PeopleSoft.
<?xml version="1.0" encoding="UTF-8"?> <attr-name-map>
<class-name>
<nds-name>Utilisateur</nds-name>
<app-name>DIRXML_SCHEMA01</app-name>
</class-name>
<attr-name classname="User">
<nds-name>Given Name</nds-name>
<app-name>First Name</app-name>
</attr-name>
...
</attr-name-map >
Lorsque vous modifiez ou créez une règle d’assignation, vérifiez que les noms de champ
PeopleSoft sont identiques (orthographe et utilisation des majuscules) dans la règle d’assignation et dans la définition de message PeopleSoft. L’utilisation de l’éditeur de règle d’assignation
Identity Manager garantit le bon comportement de l’assignation. Il est également important de noter que si de nouveaux attributs sont inclus ou supprimés de la règle d’assignation, le nouvel attribut défini doit être reflété dans les filtres des canaux Éditeur et Abonné respectifs. S’ils ne sont pas inclus dans les filtres, les attributs assignés ne peuvent pas être synchronisés.
Personnalisation du pilote
33
Novell Confidential Manual (FRA) 28 October 2003
Utilisation de l’interrogation de schéma pour rafraîchir le CI de schéma PeopleSoft
Le schéma que le pilote lit à partir de PeopleSoft se compose des champs de données définis sur le CI DIRXML_SCHEMA01. Si les éléments de données sont modifiés ou si le CI est renommé, il est nécessaire de rafraîchir la définition du schéma de l’application PeopleSoft.
Objets du canal Éditeur
L’objet Éditeur contient un filtre et un ensemble de règles. Les règles sont nécessaires pour convertir les données du CI de PeopleSoft au format XDS. Le pilote envoie ensuite les données au moteur DirXML. Avant d’envoyer les données à eDirectory, le moteur leur applique le filtre du canal Éditeur puis la logique d’entreprise définie par les règles de l’objet Éditeur.
Présentation du filtre du canal Éditeur
Le filtre du canal Éditeur spécifie les classes d’objet et les attributs associés qui sont transmis du
CI PeopleSoft à eDirectory. Le filtre est défini à l’aide de l’assignation de nom eDirectory ; il est donc appliqué une fois l’assignation de schéma terminée.
Par exemple, si la classe Utilisateur est spécifiée dans le filtre du canal Éditeur uniquement avec les attributs Surname et Given Name, le moteur DirXML permet uniquement de modifier ces attributs pour les transmettre aux règles de l’objet Éditeur à partir du pilote PeopleSoft. Si un attribut Telephone Number est modifié, le filtre du canal Éditeur supprime ces données car cet attribut ne figure pas dans le filtre. D’autres valeurs d’attribut peuvent être créées par les règles de l’objet Éditeur selon le scénario d’intégration.
Vous pouvez configurer le filtre du canal Éditeur pour inclure des attributs nécessaires à votre environnement et autorisés par les contrôles d’accès eDirectory. Il doit inclure les éléments suivants :
Les classes d’objet que vous souhaitez synchroniser.
Les attributs des objets que vous souhaitez synchroniser.
Les attributs nécessaires à vos règles d’objet Éditeur. Ces attributs ne sont pas synchronisés mais ils sont nécessaires pour mettre en uvre une logique d’entreprise définie qui sera appliquée aux données synchronisées.
Le filtre du canal Éditeur spécifie un ensemble de données considéré comme expert par la base de données PeopleSoft. En fonction de la logique d’entreprise, il peut exister plusieurs sources expertes de données spécifiques (tel un autre pilote DirXML ou eDirectory lui-même). La configuration des filtres de votre environnement détermine la propriété et le caractère expert des données.
Attributs du filtre du canal Éditeur
Par défaut, les applications PeopleSoft sont considérées comme hautement expertes. Par conséquent, la plupart des noms de champ de l’interface de composant par défaut
DIRXML_SCHEMA01 est envoyée vers le filtre du canal Éditeur. Comme mentionné auparavant, les noms des attributs du filtre représentent des noms d’attribut eDirectory qui ont été assignés à l’aide de la règle d’assignation.
34
Guide d’implémentation du pilote DirXML pour PeopleSoft
Novell Confidential Manual (FRA) 28 October 2003
Le CI DIRXML_SCHEMA01 définit également un élément de niveau de défilement 1 intitulé
PHONES. Le défilement PHONES contient plusieurs éléments comprenant chacun deux champs qui identifient des numéros de téléphone et le type du numéro. Étant donné que ces éléments ne peuvent pas être directement assignés aux attributs eDirectory, ils ne peuvent pas figurer dans la règle d’assignation. Cependant, Identity Manager permet de créer une règle qui peut convertir les
éléments PHONES en attributs eDirectory à valeur unique. Les attributs eDirectory peuvent être listés dans le filtre de pouvoir être envoyés vers eDirectory. La règle de transformation de l’entrée du canal Éditeur effectue cette opération.
Les attributs listés ci-après sont inclus dans le filtre du canal Éditeur par défaut :
Attributs
employeeStatus
Full Name
Given Name homePhone initials isManager mailstop managerWorkforceID mobile
OU
Attributs
pager
Physical Delivery Office Name
Postal Code
S
SA
Surname
Telephone Number
Title workforceID
Les attributs homePhone, mobile et pager figurent également dans le filtre du canal Abonné. Cela signifie que ces attributs sont doublement experts ou qu’ils sont liés par une relation homologue à homologue entre eDirectory et PeopleSoft.
Sécurisation des données
Les applications PeopleSoft, comme de nombreuses autres applications, contiennent des données sensibles qui doivent être hautement sécurisées par les entreprises. Il existe deux façons de vérifier que les données sécurisées ne sont pas publiées via le canal Éditeur à partir de l’application
PeopleSoft :
En les supprimant de la définition CI des données synchronisées.
En les supprimant du filtre du canal Éditeur.
La première méthode garantit que les données ne quitteront pas l’application PeopleSoft.
La seconde méthode garantit que les données ne seront pas synchronisées dans eDirectory via le pilote.
Personnalisation du pilote
35
Novell Confidential Manual (FRA) 28 October 2003
Règles de l’objet Éditeur
Par défaut, l’objet Éditeur contient ou utilise les règles suivantes :
Règle de transformation de l’entrée (page 36)
Règle de concordance (page 37)
Règle de transformation de la commande (page 38)
Les règles contiennent des modèles qui effectuent certaines opérations spécifiques permettant de manipuler des données, d’interroger eDirectory ou PeopleSoft pour obtenir des données supplémentaires nécessaires au traitement, de créer de nouveaux attributs en fonction des valeurs d’autres attributs, voire de rejeter des événements de données complets. La section suivante explique chaque règle et décrit le fonctionnement de chaque règle ou modèle. Puisque XML et
XSLT permettent une plus grande souplesse, toutes les règles peuvent être modifiées pour répondre aux besoins de votre entreprise. La règle d’assignation a été décrite précédemment et ne
Règle de transformation de l’entrée
La règle de transformation de l’entrée est implémentée comme règle par défaut pour le pilote
PeopleSoft. Bien que la règle de transformation de l’entrée ne soit pas exclusivement utilisée par le canal Éditeur, elle participe à la publication des données via le canal Éditeur ; en effet, elle sert
à transformer le format des données de n’importe quel document XDS reçu du module d’interface du pilote PeopleSoft, quel que soit le canal à l’origine de l’envoi du document. Cela signifie que le canal Abonné peut émettre des requêtes d’objet vers le module d’interface du pilote. Toutes les données envoyées en réponse sont traitées à l’aide de la règle de transformation de l’entrée.
Un exemple de transformation de données contenue dans cette règle est la transformation d’attributs structurés à valeurs multiples dans PeopleSoft, qui sont convertis en attributs de chaîne dans eDirectory.
Les modèles suivants sont proposés dans la règle de transformation de l’entrée par défaut. Outre les modèles listés, toutes les règles Identity Manager contiennent des modèles de transformation d’identité qui permettent de copier des attributs et des éléments XML envoyés sans être modifiés.
Plusieurs instances de chaque modèle listé existent pour chaque type de document qui peut être reçu par la règle (query response, add et modify) :
Modèle de transformation des données Manager Flag
Ce modèle convertit les valeurs de données Y ou N de l’attribut Manager de PeopleSoft en valeurs booléennes True ou False, afin de refléter le format des données de l’attribut isManager de eDirectory.
Modèles de transaction des données Phone Number
Ces modèles convertissent les valeurs de format structurées des éléments de données de défilement
PHONES de PeopleSoft en attributs et formats de chaîne correspondants dans eDirectory. En fonction du composant Phone Type de PHONES, le composant Phone Number est écrit dans un attribut de chaîne eDirectory correctement formaté.
36
Guide d’implémentation du pilote DirXML pour PeopleSoft
Novell Confidential Manual (FRA) 28 October 2003
Les assignations suivantes sont proposées :
Type de téléphone
BUSN
HOME
CELL
PGR
Attribut eDirectory
Telephone Number homePhone mobile pager
Règle de concordance
La règle de concordance est utilisée par le moteur DirXML pour appliquer des critères afin de déterminer si un objet de données concordant existe déjà dans eDirectory. La règle de concordance est appliquée à tous les documents d’ajout reçus du module d’interface du pilote PeopleSoft.
Si cette règle trouve une concordance, le moteur DirXML convertit automatiquement l’événement d’ajout en événement de modification. Si aucun objet concordant dans eDirectory n’est actuellement associé à l’application PeopleSoft, une association est créée.
La règle de concordance doit fournir les critères qui permettent de garantir une concordance de 0 ou 1. Plusieurs règles peuvent exister et le moteur DirXML les applique dans l’ordre de leur définition. Toute règle qui génère une valeur de concordance de 0 ou supérieure à 1 est ignorée et la règle suivante est appliquée. L’opération se termine lorsqu’une concordance est trouvée ou après le traitement de la dernière règle.
La règle de concordance du canal Abonné par défaut est une règle XML qui tente d’établir une concordance avec des objets Utilisateur eDirectory qui contiennent la même valeur d’attribut workforceID (assignée depuis l’attribut DIRXML_SCHEMA01 DIRXML_ASSOC_ID).
Règle de création
La règle de création est utilisée pour spécifier les critères de création d’un nouvel objet si la règle de concordance n’a pas réussi à trouver de correspondance. Cette règle effectue différents tests et transformations en fonction des conditions de création d’objet requises dans eDirectory et de la logique d’entreprise utilisée.
La règle de création PeopleSoft par défaut est une règle XML qui affirme que le document <add> est destiné à un objet Utilisateur et qu’il doit contenir des attributs Surname et Given Name. En effet, l’attribut Surname est obligatoire dans eDirectory et la logique d’entreprise utilisée pour nommer l’objet nécessite l’existence de l’attribut Given Name.
Personnalisation du pilote
37
Novell Confidential Manual (FRA) 28 October 2003
Règle de placement
La règle de placement définit l’endroit dans lequel un objet est placé dans l’arborescence eDirectory au moment de sa création. Ce placement peut être déterminé par la présence (ou l’absence) d’attributs, de valeurs d’attribut particulières, etc. Il peut également varier selon la règle de création et être transmis à la règle de placement.
Dans un environnement de gestion des ressources humaines PeopleSoft, un employé est embauché, une notification est envoyée au service informatique et un administrateur système détermine l’emplacement du nouvel objet Utilisateur dans l’arborescence eDirectory. Avant de définir les règles d’emplacement, analysez le processus utilisé actuellement par votre entreprise.
La règle de placement PeopleSoft par défaut représente un ensemble de règles XML qui place des objets Utilisateur en fonction de l’attribut employeeStatus. Elle utilise l’ordre de traitement suivant : Si la valeur de l’attribut employeeStatus est A, l’employé est placé dans l’unité organisationnelle (Nom_Org)\Users\Active. Si la valeur de l’attribut employeeStatus est I, l’employé est placé dans l’unité organisationnelle (Nom_Org)\Users\InActive. Si la valeur de l’attribut employeeStatus est absente, l’employé est placé dans l’unité organisationnelle
(Nom_Org)\Users\InActive.
Règle de transformation de la commande
La règle de transformation de la commande représente la règle de transformation finale à traiter avant de soumettre un document de l’objet Éditeur à eDirectory. Pour illustrer ces fonctions, la configuration par défaut du pilote PeopleSoft met en uvre un exemple inhabituel de logique d’entreprise qui démontre la souplesse et la puissance de Identity Manager.
Le scénario de logique d’entreprise est requis pour gérer l’attribut CN de l’objet et le nom distinctif
(DN) complet de chaque utilisateur dans l’application PeopleSoft. L’attribut CN est généré au niveau des nouveaux objets lorsqu’ils sont créés dans eDirectory. Le DN n’est pas un véritable attribut mais une concaténation du chemin de répertoire et du CN d’un utilisateur. Le DN varie selon l’attribut employeeStatus d’un objet ; il est donc défini selon les événements d’ajout et de suppression d’utilisateurs transformés en événements de déplacement.
Ces données étant connues lors du traitement de la règle de transformation de la commande, les données CN et DN sont placées dans l’attribut event-id du document qui ajoute ou déplace l’objet.
Lorsque Identity Manager a appliqué les données à eDirectory, un document d’état est renvoyé.
La règle de transformation de la sortie (décrite dans le canal Abonné) surveille les documents d’état renvoyés et transforme les documents traités à l’aide des données CN et DN incorporées en documents de modification qui sont appliqués à l’application PeopleSoft. Il s’agit de la fonction
d’écriture différée.
En tant que règle de transformation finale, la règle de transformation de la commande fournit un excellent emplacement pour définir des opérations qui doivent être appliquées sans risquer de provoquer une transformation de l’événement supplémentaire, ce qui permet de programmer le traitement de règles complexes dans un emplacement unique. Comme nous le verrons, la plupart des transformations de logique d’entreprise du canal Éditeur est implémentée dans cette règle.
Les modèles suivants sont proposés dans la règle de transformation de la commande par défaut.
Outre les modèles listés, toutes les règles Identity Manager contiennent des modèles de transformation d’identité qui permettent de copier des attributs et des éléments XML qui sont envoyés sans être modifiés. La configuration par défaut gère uniquement les documents associés
à des objets Utilisateur.
38
Guide d’implémentation du pilote DirXML pour PeopleSoft
Novell Confidential Manual (FRA) 28 October 2003
correspond à l’élément <add>
Ce processus exécute les opérations suivantes :
Tente de rechercher le responsable de l’utilisateur. Si le responsable de l’utilisateur est identifié et si l’attribut employeeStatus du responsable est défini sur A, le modèle définit le responsable et l’attribut managerWorkforceID au niveau de l’utilisateur.
Définit l’attribut Login Disabled en fonction de l’attribut employeeStatus. Si l’état affiche la lettre A, l’attribut Login Disabled est défini sur False. Si l’état affiche la lettre I, l’attribut
Login Disabled est défini sur True.
Ajoute ou supprime la valeur Group Membership en fonction de la valeur de l’attribut employeeStatus. Tous les employés actifs dont l’attribut isManager est défini sur False sont placés dans un groupe Employee (Employé). Tous les employés actifs dont l’attribut isManager est défini sur True sont placés dans un groupe Manager (Responsable). L’attribut
Group Membership et les liens associés au niveau des objets de groupe sont effacés si l’attribut employeeStatus est défini sur I.
Détermine le placement d’un objet en fonction de la valeur de l’attribut employeeStatus.
Les objets Utilisateur actifs sont placés dans une unité organisationnelle active. Les objets
Utilisateur inactifs sont placés dans une unité organisationnelle inactive.
Ajoute l’attribut manager à tout objet Utilisateur actif de l’annuaire dont l’attribut managerWorkforceID spécifie ce nouvel utilisateur.
Ajoute la valeur de l’attribut directReports à tout objet Utilisateur actif de l’annuaire spécifié par l’attribut managerWorkforceID de cet utilisateur.
Génère un attribut event-id d’écriture différée pour faciliter l’ajout des attributs CN et DN dans PeopleSoft.
correspond à l’élément <modify>
Ce processus exécute les opérations suivantes :
Tente de rechercher le responsable de l’utilisateur. Si le responsable de l’utilisateur est identifié et si l’attribut employeeStatus du responsable est défini sur A, le modèle définit le responsable et l’attribut managerWorkforceID au niveau de l’utilisateur.
Définit l’attribut Login Disabled en fonction de l’attribut employeeStatus. Si l’état affiche la lettre A, l’attribut Login Disabled est défini sur False. Si l’état affiche la lettre I, l’attribut
Login Disabled est défini sur True.
Ajoute ou supprime l’attribut Group Membership en fonction de l’attribut employeeStatus.
Tous les employés actifs dont l’attribut isManager est défini sur False sont placés dans un groupe d’employés par défaut. Tous les employés actifs avec l’attribut isManager et des liens associés au niveau des objets de groupe sont effacés si l’attribut employeeStatus est défini sur
I. Si l’attribut isManager est modifié dans le document de modification, le nom de l’utilisateur est effacé de l’attribut Member dans son groupe précédent.
Ajoute l’attribut manager à tout objet Utilisateur actif de l’annuaire dont l’attribut managerWorkforceID spécifie ce nouvel utilisateur.
Ajoute la valeur de l’attribut directReports à tout objet Utilisateur actif de l’annuaire spécifié par l’attribut managerWorkforceID de cet utilisateur.
Si la valeur de l’attribut employeeStatus passe de I à A, génère un événement de déplacement avec un event-id d’écriture différée afin de faciliter la modification de l’attribut DN dans
PeopleSoft. Cet événement déplacera l’objet Utilisateur de l’unité organisationnelle InActive vers l’unité organisationnelle Active.
Personnalisation du pilote
39
Novell Confidential Manual (FRA) 28 October 2003
correspond à l’élément <delete>
Ce processus exécute les opérations suivantes :
Transforme le <delete> en un document <modify>.
Définit l’attribut Login Disabled sur True.
Supprime l’attribut Group Membership de l’objet Utilisateur. Il supprime également le nom d’utilisateur de l’attribut Member du groupe actuel.
Supprime l’attribut manager de l’utilisateur.
Supprime l’attribut directReports de l’utilisateur.
Supprime l’attribut manager de tous les utilisateurs qui figuraient dans la liste directReports.
Supprime le nom d’utilisateur de l’attribut directReports de son/sa responsable.
Crée un événement de déplacement avec un event-id d’écriture différée afin de faciliter la modification de l’attribut DN dans PeopleSoft. Cet événement déplacera l’objet Utilisateur de l’unité organisationnelle inactive vers l’unité organisationnelle active.
buildAddEventID et buildDeleteEventID
Ces modèles font partie de l’implémentation d’écriture différée CN et DN. Ils gèrent l’incorporation des attributs CN et DN de l’objet Utilisateur dans l’attribut event-id du document.
get-empl-status
Ce modèle demande la valeur de l’attribut employeeStatus à partir d’un objet Utilisateur spécifié dans eDirectory.
get-empl-isManager
Ce modèle demande la valeur de l’attribut isManager à partir d’un objet Utilisateur spécifié dans eDirectory.
get-empl-CN
Ce modèle demande la valeur de l’attribut CN à partir d’un objet Utilisateur spécifié dans eDirectory.
get-empl-managerWorkforceID
Ce modèle demande la valeur de l’attribut managerWorkforceID à partir d’un objet Utilisateur spécifié dans eDirectory.
get-empl-ID
Ce modèle demande la valeur de l’attribut d’association Identity Manager à partir d’un objet
Utilisateur spécifié dans eDirectory. La valeur d’association représente l’ID unique de l’objet dans l’application PeopleSoft.
set-manager-on-user
Ce modèle interroge eDirectory pour déterminer si le paramètre managerWorkforceID transmis correspond à un objet Utilisateur actif dans eDirectory. Le nom de l’objet manager-User est défini dans l’attribut manager de l’utilisateur si le responsable est actif.
40
Guide d’implémentation du pilote DirXML pour PeopleSoft
Novell Confidential Manual (FRA) 28 October 2003
set-manager-on-direct-reports
Ce modèle reçoit un paramètre ID d’objet manager-User. Une requête est envoyée à eDirectory pour demander une liste de tous les utilisateurs actifs dont l’ID d’objet manager-User est spécifié dans l’attribut managerWorkforceID. L’attribut manager de tous les utilisateurs de la liste est défini selon le nom de l’attribut manager-User.
clear-manager-on-direct-reports
Ce modèle reçoit un paramètre ID d’objet manager-User. Une requête est envoyée à eDirectory pour demander une liste de tous les utilisateurs actifs dont l’ID d’objet manager-User est spécifié dans l’attribut managerWorkforceID. L’attribut manager de tous les utilisateurs de la liste est supprimé.
set-directReports-on-manager
Ce modèle reçoit un paramètre ID d’objet manager-User. Une requête est envoyée à eDirectory pour rechercher un utilisateur actif dont l’ID d’objet manager-User est spécifié dans l’attribut workforceID. L’attribut directReports de l’objet manager-User est modifié pour inclure le DN de l’objet Utilisateur spécifié dans le document source.
clear-directReports-on-manager
Ce modèle reçoit un paramètre ID d’objet manager-User. Une requête est envoyée à eDirectory pour rechercher un utilisateur actif dont l’ID d’objet manager-User est spécifié dans l’attribut workforceID. L’attribut directReports de l’objet manager-User est modifié pour supprimer le DN de l’objet Utilisateur spécifié dans le document source.
set-directReports-on-user
Ce modèle reçoit un paramètre ID d’objet Utilisateur. Une requête est envoyée à eDirectory pour trouver une liste de tous les utilisateurs actifs dont l’ID d’objet Utilisateur est spécifié dans l’attribut managerWorkforceID. L’attribut directReports de l’objet Utilisateur est modifié pour inclure le DN de tous les objets Utilisateur de la liste.
Objets du canal Abonné
L’objet Abonné contient un filtre et un ensemble de règles. Ces règles sont nécessaires à la conversion des données de eDirectory vers le pilote PeopleSoft.
eDirectory envoie les événements de modification des données filtrées vers PeopleSoft à l’aide du moteur DirXML. Le moteur applique la logique d’entreprise définie par les règles de l’objet
Abonné avant d’envoyer les données au pilote PeopleSoft qui convertit ces données du format
XDS Identity Manager au format d’interface de composant PeopleSoft. Le pilote PeopleSoft envoie ensuite les données à l’application PeopleSoft et met à jour la table intermédiaire.
Personnalisation du pilote
41
Novell Confidential Manual (FRA) 28 October 2003
Présentation du filtre du canal Abonné
Le filtre du canal Abonné spécifie les classes d’objet et les attributs associés transmis de eDirectory vers l’interface de composant PeopleSoft. Le filtre est défini à l’aide de l’assignation de nom eDirectory ; il est donc appliqué avant l’assignation de schéma.
Par exemple, si la classe Utilisateur est spécifiée dans le filtre du canal Abonné uniquement avec les attributs mobile et pager, le filtre permet uniquement de modifier ces attributs pour les transmettre au moteur DirXML. Si un attribut Telephone Number est modifié, le filtre du canal
Abonné supprime ces données car cet attribut ne figure pas dans le filtre. D’autres valeurs d’attribut peuvent être créées par les règles de l’objet Abonné selon le scénario d’intégration.
Vous pouvez configurer le filtre du canal Abonné pour inclure des attributs nécessaires à votre environnement et autorisés par les contrôles d’accès eDirectory. Il doit inclure les éléments suivants :
Les classes d’objet que vous souhaitez synchroniser.
Les attributs des objets que vous souhaitez synchroniser.
Les attributs nécessaires à vos règles d’objet Abonné. Ces attributs ne peuvent pas être synchronisés mais ils sont nécessaires pour mettre en uvre une logique d’entreprise définie qui sera appliquée aux données synchronisées.
Le filtre du canal Abonné spécifie un ensemble de données qui sera considéré comme expert pour eDirectory ou toute autre application experte capable d’écrire les données dans eDirectory. En fonction de la logique d’entreprise, il peut exister plusieurs sources expertes de données spécifiques (tel un autre pilote DirXML ou eDirectory lui-même). La configuration des filtres de votre environnement détermine la propriété et le caractère expert des données.
Attributs du filtre du canal Abonné
Par défaut, les applications PeopleSoft sont considérées comme hautement expertes.
Par conséquent, la plupart des noms de champ du filtre du canal Abonné sont des éléments de données qui, généralement, ne sont pas assignés par une application PeopleSoft. Les noms des attributs du filtre représentent des noms d’attribut eDirectory assignés à l’aide de la règle d’assignation. L’application PeopleSoft par défaut, DIRXML_SCHEMA01, définit également un
élément de niveau de défilement 1 intitulé PHONES. PHONES contient plusieurs éléments, chacun comportant deux champs qui identifient le numéro de téléphone et le type du numéro.
Étant donné que ces éléments ne peuvent pas être directement assignés aux attributs eDirectory, ils ne peuvent pas figurer dans la règle d’assignation. Cependant, Identity Manager vous permet de créer une règle qui peut convertir les attributs eDirectory à valeur unique en instances uniques de l’élément de défilement PHONES. Les attributs eDirectory peuvent être listés dans le filtre pour
être envoyés au moteur DirXML. La règle de transformation de la sortie du canal Abonné effectue les transformations de données qui conviennent.
Les attributs listés ci-après sont inclus dans le filtre du canal Abonné par défaut.
CN
Description
homePhone
Internet EMail Address
mobile
pager
workforceID
42
Guide d’implémentation du pilote DirXML pour PeopleSoft
Novell Confidential Manual (FRA) 28 October 2003
Les attributs CN, Description et Internet EMail Address sont propres au filtre du canal Abonné.
Les attributs homePhone, mobile et pager figurent également dans le filtre du canal Éditeur.
Cela signifie que ces attributs sont doublement experts ou qu’ils sont liés par une relation homologue à homologue entre eDirectory et PeopleSoft. L’attribut workforceID figure dans le filtre pour le traitement des règles et il n’est pas synchronisé dans PeopleSoft.
Sécurisation des données
Pour ne pas partager des données sensibles avec l’application PeopleSoft, il suffit de supprimer ces données du filtre du canal Abonné.
Modification du filtre
Un filtre du canal Abonné correctement configuré permet de sécuriser l’environnement et le partage des données entre eDirectory et PeopleSoft. Exécutez la procédure décrite dans
« Modification du filtre », page 43
pour configurer le filtre comme vous le souhaitez. Vérifiez que les attributs nécessaires au traitement des règles de l’objet Abonné (comme workforceID) sont présents dans le filtre même s’ils ne seront pas synchronisés dans l’application PeopleSoft.
Règles de l’objet Abonné
Par défaut, l’objet Abonné contient ou utilise les règles suivantes :
« Règle de concordance », page 43
« Règle de transformation de la commande », page 44
« Règle de transformation de la sortie », page 45
Les règles contiennent des modèles qui effectuent certaines opérations spécifiques permettant de manipuler des données, d’interroger eDirectory ou PeopleSoft pour obtenir des données supplémentaires nécessaires au traitement, de créer de nouveaux attributs en fonction des valeurs d’autres attributs, voire de rejeter des événements de données complets. La section suivante explique chaque règle et fournit une description des opérations réalisées par chaque règle. Puisque
XML et XSLT permettent une plus grande souplesse, toutes les règles peuvent être modifiées pour répondre aux besoins de votre entreprise. La règle d’assignation de schéma a été décrite précédemment et n’est pas abordée dans cette section. Pour plus d’informations sur la règle d’assignation de schéma, reportez-vous à
« Modification de la règle d’assignation du pilote », page 33 .
Règle de concordance
La règle de concordance est utilisée par le moteur DirXML pour appliquer des critères afin de déterminer si un objet de données concordant existe déjà dans l’application PeopleSoft. La règle de concordance est appliquée à tous les documents reçus de eDirectory et contenant des objets
Utilisateur qui ne sont pas actuellement associés à des objets PeopleSoft. Si cette règle trouve une concordance, l’événement d’ajout est converti en opération de fusion d’objets. Cette fusion recherche tous les attributs du filtre du canal Éditeur dans PeopleSoft pour les appliquer à eDirectory, et recherche tous les attributs du filtre du canal Abonné dans eDirectory pour les appliquer à PeopleSoft. Le processus est terminé lorsqu’une valeur d’association est écrite dans l’objet Utilisateur eDirectory. Le canal Abonné ne contenant pas de règle de création, l’événement d’ajout est rejeté si aucune concordance n’est trouvée.
Personnalisation du pilote
43
Novell Confidential Manual (FRA) 28 October 2003
La règle de concordance doit fournir les critères qui permettent de garantir une concordance de 0 ou 1. Plusieurs règles peuvent exister et le moteur DirXML les applique dans l’ordre de leur définition. Toute règle qui génère une valeur de concordance de 0 ou supérieure à 1 est ignorée et la règle suivante est appliquée. L’opération se termine lorsqu’une concordance est trouvée ou après le traitement de la dernière règle.
La règle de concordance de l’objet Abonné par défaut représente une règle XML qui tente de trouver un objet PeopleSoft DIRXML_SCHEMA01 contenant un attribut DIRXML_ASSOC_ID correspondant à l’attribut workforceID de l’objet Utilisateur eDirectory. La règle est définie dans la classe et dans les noms d’attribut eDirectory ; en effet, l’assignation de schéma n’a pas encore
été appliquée.
Règle de transformation de la commande
La règle de transformation de la commande fournit un excellent emplacement pour définir des opérations qui doivent être appliquées sans risquer de provoquer une transformation de l’événement supplémentaire, ce qui permet de programmer le traitement de règles complexes dans un emplacement unique. La plupart des transformations de logique d’entreprise du canal Abonné sont implémentées dans cette règle.
Les modèles suivants sont proposés dans la règle de transformation de la commande par défaut.
Outre les modèles listés, toutes les règles Identity Manager contiennent des modèles de transformation d’identité qui permettent de copier des attributs et des éléments XML qui sont envoyés sans être modifiés. La configuration par défaut gère uniquement les documents associés
à des objets Utilisateur.
correspond à l’élément <modify>
Ce modèle recherche une valeur d’association dans tous les éléments de modification Utilisateur.
Les documents de modification pour des objets Utilisateur non associés sont rejetés.
correspond à l’élément <rename>
Ce modèle convertit les événements de réassignation de nom eDirectory sur des objets Utilisateur associés en documents de modification contenant les nouveaux attributs CN et DN Utilisateur.
correspond à l’élément <move>
Ce modèle convertit les événements Rename eDirectory d’objets Utilisateur associés en documents de modification contenant les nouveaux attributs Utilisateur CN et DN.
correspond à l’élément <delete>
Ce modèle convertit des événements de suppression eDirectory sur des objets Utilisateur associés en documents de modification qui suppriment les valeurs des attributs CN et DN. Les valeurs de tous les attributs identifiés comme étant propres au filtre du canal Abonné, Description et Internet
EMail Address, sont également supprimés.
Ce modèle demande la valeur de l’attribut isManager à partir d’un objet Utilisateur spécifié dans eDirectory.
44
Guide d’implémentation du pilote DirXML pour PeopleSoft
Novell Confidential Manual (FRA) 28 October 2003
Règle de transformation de la sortie
La règle de transformation de la sortie est implémentée comme règle par défaut pour le pilote
PeopleSoft. Bien que la règle de transformation de la sortie ne soit pas exclusivement utilisée par le canal Abonné, elle participe à la publication des données via le canal Abonné ; en effet, elle permet de transformer le format des données de n’importe quel document XDS reçu de eDirectory, quel que soit le canal à l’origine de l’envoi du document. Un exemple de transformation de données contenu dans cette règle est la transformation d’attributs eDirectory à valeur unique en
éléments de défilement structurés à valeurs multiples dans PeopleSoft.
Les modèles suivants sont proposés dans la règle de transformation de la sortie par défaut.
Outre les modèles listés, toutes les règles Identity Manager contiennent des modèles de transformation d’identité qui permettent de copier des attributs et des éléments XML qui sont envoyés sans être modifiés. Il existe plusieurs instances de chaque modèle listé pour chaque type de document ou élément de données pouvant être reçu pat la règle :
écriture différée
Comme décrit dans la règle de transformation de la commande du canal Éditeur, ce modèle surveille toutes les réponses de document d’état provenant de eDirectory. Si un document d’état avec une valeur Success est reçu et contient un attribut event-id avec une valeur CN et DN incorporée, le modèle stocke le document d’état et émet un document de modification avec les valeurs CN et DN vers l’application PeopleSoft. Une fois la commande d’écriture différée terminée, le document d’état original est renvoyé vers le canal Éditeur.
Transformation des données Phone number
Ce modèle convertit les attributs telephone number à valeur unique en valeurs de format structurées des éléments de données de défilement PHONES PeopleSoft. En fonction de l’attribut eDirectory, un autre composant Phone Type d’élément PHONES et le composant Phone Number sont écrits dans l’application PeopleSoft. Les assignations suivantes sont proposées :
Type de téléphone
BUSN
HOME
CELL
PGR
Attribut eDirectory
Telephone Number homePhone mobile pager
Modèles de transformation d’interrogation Phone number
Ce modèle convertit la requête de n’importe quelle valeur d’attribut telephone number eDirectory en requête de tous les éléments de défilement PHONES. Le moteur DirXML filtre toutes les données qui n’ont pas été demandées.
Personnalisation du pilote
45
Novell Confidential Manual (FRA) 28 October 2003
46
Guide d’implémentation du pilote DirXML pour PeopleSoft
Download
Public link updated
The public link to your chat has been updated. You may view and manage your chat links after registration here.