Der Service-Treiber für manuelle Aufgaben dient dazu, einen oder mehrere Benutzer darüber in Kenntnis zu setzen, dass ein Datenereignis aufgetreten und möglicherweise eine Aktion des Benutzers erforderlich ist. In einem Szenario, in dem es um die Bereitstellung für Mitarbeiter geht, kann das Datenereignis beispielsweise im Erstellen eines neuen Benutzerobjekts und die Aktion des Benutzers in der Zuteilung einer Büronummer durch eine entsprechende Dateneingabe in eDirectory oder in eine Anwendung bestehen. Denkbar sind auch Szenarios, in denen z. B. ein Administrator benachrichtigt wird, dass ein neues Benutzerobjekt erstellt wurde oder ein Benutzer Daten eines Objekts geändert hat usw.
Das Konfigurieren des Service-Treibers für manuelle Aufgaben besteht in der Regel aus dem Konfigurieren zweier separater, aber miteinander verwandter Subsysteme: die Richtlinien und Email-Schablonen des Abonnentenkanals einerseits und die Schablonen und Richtlinien des Webservers auf dem Herausgeberkanal andererseits.
Darüber hinaus müssen Treiberparameter wie z. B. der Name des SMTP-Servers, der Port des Webservers usw. konfiguriert werden.
Dieser Abschnitt umfasst:
Installation:Der Service-Treiber für manuelle Aufgaben wird bei der Installation der Option durch das Installationsprogramm von Identity Manager automatisch installiert.
Plattformen: Der Treiber läuft auf den von Identity Manager und dem Remote Loader unterstützten Plattformen.
Aktivierung: Der Treiber muss nicht separat aktiviert werden. Wenn Sie die Metaverzeichnis-Engine aktivieren, wird dieser Treiber ebenfalls aktiviert.
In diesem Abschnitt ist beschrieben, wie sich die verschiedenen Funktionen des Treibers nutzen lassen.
Es werden zwei primäre Betriebsarten unterstützt:
Direkte Datenanforderung: Ein Benutzer wird durch eine Email aufgefordert, Daten in eDirectory einzugeben (die eventuell von einer anderen Anwendung verarbeitet werden sollen). Der Email-Empfänger beantwortet die Email, indem er auf eine URL in der Nachricht klickt. Die URL verweist auf einen Webserver, der auf dem Herausgeberkanal des Service-Treibers für manuelle Aufgaben läuft. Der Benutzer interagiert dann mit den dynamischen Webseiten, die der Webserver zur Authentifizierung gegenüber eDirectory™ und zum Eingeben der angeforderten Daten erzeugt.
Ereignisbenachrichtigung:Eine Email wird an einen Benutzer gesendet, ohne dass der Herausgeberkanal daran beteiligt ist. Bei der Email kann es sich nur die Benachrichtigung handeln, dass in eDirectory ein Ereignis eingetreten ist, oder es könnte sich um eine Datenanforderung über eine Methode handeln, die nichts mit dem Webserver des Herausgeberkanals zu tun hat, z. B. Novell iManager, eine andere Anwendung oder eine benutzerdefinierte Schnittstelle.
Im Folgenden ist ein Beispielszenario für einen Bereitstellungsvorgang für einen neuen Mitarbeiter aufgeführt, in dem ihm vom Manager eine Raumnummer zugewiesen wird:
Im Folgenden ist ein Beispielszenario aufgeführt, in dem der Manager eines neuen Mitarbeiters dem Mitarbeiter einen Computer in einem Asset-Management-System zuweist:
Emails, HTML-Webseiten und XDS-Dokumente können alle als Dokumente angesehen werden. Der Service-Treiber für manuelle Aufgaben erstellt Dokumente dynamisch, die auf den an den Treiber übermittelten Informationen basieren.
Schablonen sind XML-Dokumente, die häufig verwendete oder feste Teile eines Dokuments enthalten. Zusätzlich enthalten sie Ersetzungs-Token, die angeben, wie die dynamischen oder zu ersetzenden Teile des endgültig zusammengestellten Dokuments angeordnet werden.
Sowohl der Abonnenten- als auch der Herausgeberkanal des Service-Treibers für manuelle Aufgaben erstellen Dokumente anhand von Schablonen. Der Abonnentenkanal erstellt Emails und der Herausgeberkanal erstellt Webseiten und XDS-Dokumente.
Der dynamische Teil eines Dokuments wird über Ersetzungsdaten zur Verfügung gestellt. Ersetzungsdaten auf dem Abonnentenkanal werden von den Abonnentenkanalrichtlinien (z. B. von der Befehlstransformationsrichtlinie) zur Verfügung gestellt. Ersetzungsdaten auf dem Herausgeberkanal werden dem Webserver in Form von HTTP-Daten zur Verfügung gestellt (URL-Daten und HTTP POST-Daten). Der Service-Treiber für manuelle Aufgaben kann automatisch bestimmte, dem Service-Treiber für manuelle Aufgaben bekannte Daten (z. B. die Adresse des Webservers) zur Verfügung stellen.
Die Schablonen werden von XSLT-Formatvorlagen verarbeitet. Diese Formatvorlagen sind nicht zu verwechseln mit Formatvorlagen, die in den Abonnenten- oder Herausgeberkanälen als DirXML-Richtlinien verwendet werden.
Die Ersetzungsdaten werden der XSLT-Formatvorlage als Parameter zur Verfügung gestellt. Nach der Verarbeitung der Formatvorlage wird ein XML-, HTML- oder Textdokument ausgegeben, das als Text einer Email, einer Webseite oder einer Übertragung an DirXML auf dem Herausgeberkanal verwendet wird.
Ersetzungsdaten werden anhand einer URL in einer Email vom Abonnentenkanal an den Herausgeberkanal übergeben. Die URL enthält einen Abfrageteil, in dem die Ersetzungsdatenelemente enthalten sind.
Der Service-Treiber für manuelle Aufgaben enthält im Lieferumfang vordefinierte Formatvorlagen, mit denen Schablonen verarbeitet werden können, um Email-, HTML- und XDS-Dokumente zu erstellen. Wenn zusätzliche Verarbeitungsoptionen gewünscht werden, können weitere benutzerdefinierte Formatvorlagen geschrieben werden.
Es ist auch eine erweiterte Methode für die Erstellung von Dokumenten verfügbar, bei der nur eine XSLT-Formatvorlage und Ersetzungsdaten verwendet werden. Bei dieser Methode werden keine Schablonen einbezogen. In diesem Handbuch wird jedoch angenommen, dass die Methode verwendet wird, bei der Schablonen einbezogen werden, da sie einfacher zu konfigurieren ist und ohne XSLT-Programmierkenntnisse verwaltet werden kann.
In diesem Abschnitt werden Schablonen für die Erstellung von Dokumenten beschrieben, wie sie im Service-Treiber für manuelle Aufgaben verwendet werden.
Schablonen sind XML-Dokumente, die von einer Formatvorlage verarbeitet werden, um ein Ausgabedokument zu erzeugen. Das Ausgabedokument kann in den Formaten XML, HTML oder einfacher Text erzeugt werden (bzw. in jedem anderen Format, das mit XSLT erzeugt werden kann).
Mit Schablonen können auf dem Abonnentenkanal Text für Emails und auf dem Herausgeberkanal dynamische Webseiten und XDS-Dokumente erzeugt werden.
Schablonen enthalten Text, Elemente und Ersetzungs-Token. Ersetzungs-Token werden im Ausgabedokument durch die Daten ersetzt, die der Formatvorlage bei der Verarbeitung der Schablone zur Verfügung gestellt werden.
Im Folgenden werden einige Beispiele für Schablonen aufgeführt, die verschiedenen Zwecken dienen. In den Beispielen sind die Ersetzungs-Token die fett gedruckten Strings zwischen zwei $-Zeichen.
Schablonen können auch Aktionselemente enthalten. Aktionselemente sind Steuerelemente, die von der Formatvorlage, die die Schablone verarbeitet, interpretiert werden. Aktionselemente werden in Schnitt F.0, Service-Treiber für manuelle Aufgaben: Aktionselemente der Schablone beschrieben. In den folgenden Beispielen werden auch die Aktionselemente fett gedruckt dargestellt.
Die folgende Beispielschablone wird zur Erzeugung eines HTML-Texts für eine Email verwendet:
<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>
Die folgende Beispielschablone wird zur Erzeugung eines einfachen Texts für eine Email verwendet:
<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>
Das Element <form:text> ist erforderlich, da Schablonen XML-Dokumente sein müssen. Das Element <form:text> wird bei der Schablonenverarbeitung entfernt.
Die folgende Schablone wird zur Erzeugung eines HTML-Formulars verwendet, das als Webseite zur Dateneingabe verwendet wird.
<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>
Die folgende Schablone wird für die Erzeugung eines XDS-Dokuments verwendet:
<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>
Bei den von $-Zeichen umschlossenen Elementen in den Beispielen handelt es sich um Ersetzungs-Token. Beispielsweise wird das Token $manager$ durch den Namen des Managers ersetzt.
Ersetzungs-Token können entweder in Text- oder in XML-Attributwerten angezeigt werden (siehe im ersten Beispiel den href-Wert innerhalb des Elements <a>).
Ersetzungsdaten bestehen aus Strings, die anstelle der Ersetzungs-Token im Ausgabedokument, das aus einer Schablone erzeugt wird, angezeigt werden. Ersetzungsdaten werden entweder von Daten des Abonnentenkanals, HTTP-Daten des Herausgeberkanals oder automatisch vom Treiber zur Verfügung gestellt. Ein zusätzlicher Ersetzungsdatentyp wird von eDirectory über den Identity Manager abgerufen (Abfragedaten). Ersetzungsdaten werden in Schnitt D.0, Service-Treiber für manuelle Aufgaben: Ersetzungsdaten genauer beschrieben.
Abonnentenkanaldaten:Es gibt zwei Typen von Ersetzungsdaten für den Abonnentenkanal. Der erste Typ besteht aus den Ersetzungswerten, die in Schablonen zur Email-Erstellung für die Ersetzungs-Token eingesetzt werden. Der zweite Typ wird im Abfrageteil einer URL verwendet, sodass die Daten auf dem Herausgeberkanal verwendet werden können, wenn die URL an den Webserver des Herausgeberkanals übertragen wird.
HTTP-Daten: Ersetzungsdaten werden dem Webserver des Herausgeberkanals in Form von URL-Query-Zeichenkettendaten, HTTP POST-Daten oder beidem zur Verfügung gestellt.
Automatische Daten: Der Service-Treiber für manuelle Aufgaben stellt automatische Daten zur Verfügung. Automatische Datenelemente werden in Schnitt E.0, Service-Treiber für manuelle Aufgaben: Automatische Ersetzungsdatenelemente beschrieben.
Abfragedaten:Ersetzungs-Token, die mit „query:“ beginnen, werden als Anforderung aktueller Daten von eDirectory angesehen. Der Teil des Tokens nach „query:“ ist der Name eines eDirectory-Objektattributs. Das abzufragende Objekt wird durch einen der Ersetzungsdatenelemente association, src-dn oder src-entry-id festgelegt. Die Elemente werden in genau dieser Reihenfolge berücksichtigt.
Aktionselemente sind Namespace-qualifizierte Elemente in der Schablone, die zur einfachen Logiksteuerung oder zur Erstellung von HTML-Elementen für HTML-Formulare verwendet werden. Der zur Qualifizierung der Elemente verwendete Namespace ist http://www.novell.com/dirxml/manualtask/form. In diesem Dokument und in den im Lieferumfang des Service-Treibers für manuelle Aufgaben enthaltenen Beispielschablonen wird das Präfix „form“ verwendet.
Die fett gedruckten Elemente in den Beispielen oben sind Aktionselemente.
Aktionselemente werden ausführlich in Schnitt F.0, Service-Treiber für manuelle Aufgaben: Aktionselemente der Schablone beschrieben.
Der Abonnentenkanal des Service-Treibers für manuelle Aufgaben ermöglicht den Versand von Emails. Hierzu unterstützt der Treiber ein benutzerdefiniertes XML-Element namens <mail>. Richtlinien auf dem Abonnentenkanal erstellen als Reaktion auf einige eDirectory-Ereignisse (z. B. bei der Erstellung eines Benutzers) ein <mail>-Element. Beispiel für ein <mail>-Element:
<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>
Der Abonnentenkanal des Service-Treibers für manuelle Aufgaben verwendet die im <mail>-Element enthaltenen Informationen für die Erstellung einer SMTP-Email. Eine URL kann erstellt und in die Email eingefügt werden, über die der Empfänger die Email beantworten kann. Die URL kann auf den Webserver des Herausgeberkanals oder auf einen beliebigen anderen Webserver verweisen.
Das <mail>-Element und dessen Inhalt werden ausführlich in Schnitt G.0, Service-Treiber für manuelle Aufgaben: <mail>-Element beschrieben.
Auf dem Herausgeberkanal des Service-Treibers für manuelle Aufgaben wird ein Webserver ausgeführt, der so konfiguriert ist, dass Benutzer über ihn Daten in eDirectory eingeben können. Der Webserver ist darauf ausgerichtet, mit Emails zu arbeiten, die vom Abonnentenkanal des Service-Treibers für manuelle Aufgaben gesendet werden.
Der Webserver des Herausgeberkanals kann statische Dateien und dynamischen Inhalt verarbeiten. Beispiele für statische Dateien sind u. a. Formatvorlagen und Bilder im .css-Format. Beispiel für dynamischen Inhalt sind Webseiten, die sich basierend auf den in der URL oder HHTP POST-Daten enthaltenen Ersetzungsdaten ändern.
Der Webserver des Herausgeberkanals ist in der Regel so konfiguriert, dass ein Benutzer als Antwort auf eine Email, die vom Abonnentenkanal gesendet wurde, Daten in eDirectory eingeben kann. Eine typische Benutzerinteraktion mit dem Webserver läuft wie folgt ab:
In diesem Abschnitt wird die Konfiguration der Parameter und Schablonen des Service-Treibers für manuelle Aufgaben beschrieben.
In diesem Abschnitt werden die Parameter beschrieben, die im Abschnitt „Treibereinstellungen“ in der Benutzeroberfläche des Treiberobjekts angezeigt werden.
Viele dieser Parameter betreffen eigentlich den Webserver des Herausgeberkanals. Sie werden im Bereich für die Treibereinstellungen angezeigt, weil auch der Abonnentenkanal des Service-Treibers für manuelle Aufgaben Zugriff auf sie benötigt.
Dieser Parameter ist ein eDirectory-DN eines Containerobjekts. Der Service-Treiber für manuelle Aufgaben kann XML-Dokumente (einschließlich XSLT-Formatvorlagen) sowohl von eDirectory als auch von der Festplatte laden. Wenn XML-Dokumente von eDirectory geladen werden sollen, gibt dieser Parameter den Stammcontainer an, aus dem die Dokumente geladen werden.
Von eDirectory geladene Dokumente befinden sich im Attributwert eines eDirectory-Objekts. Wenn nicht explizit angegeben, ist dieses Attribut „XmlData“. Das Attribut kann angegeben werden, indem ein #-Zeichen gefolgt vom Attributnamen an den Namen des Objekts angefügt wird, das das Dokument enthält.
Angenommen, der DN der Dokumentenbasis lautet „novell\Manuelle Aufgaben“ und unter „Manuelle Aufgaben“ befindet sich ein Container namens „Schablonen“.
Wenn sich im Verzeichnis „Schablonen“ ein DirXML-Formatvorlagenobjekt namens „Email_Schablone“ befindet, können folgende Ressourcenkennungen verwendet werden, um auf das XML-Dokument zu verweisen: „Schablonen/Email_Schablone“ oder „Schablonen/Email_Schablone#XmlData“.
Die Ressourcenkennungen können als Ersetzungsdaten, URL-Daten oder HTTP POST-Daten zur Verfügung gestellt werden. Möglicherweise erscheint folgendes Element unterhalb eines Elements vom Typ <message> auf dem Abonnentenkanal:
<template>templates/e-mail _template#XmlData</template>
Dieser Parameter identifiziert ein Dateisystemverzeichnis, das als Basisverzeichnis für die Auffindung von Ressourcen wie Schablonen, XSLT-Formatvorlagen und anderen Dateiressourcen verwendet wird, die vom Webserver des Herausgeberkanals verarbeitet werden. Beispielwerte:
Dieser Parameter gibt an, ob auf dem Herausgeberkanal ein Webserver ausgeführt werden soll oder nicht. Setzen Sie den Parameter auf „wahr“, wenn der Webserver ausgeführt werden soll, oder auf „falsch“, wenn der Webserver nicht ausgeführt werden soll.
Wenn der Service-Treiber für manuelle Aufgaben nur für das Versenden von Emails ohne Antwort-URL oder mit einer URL verwendet wird, die auf eine andere Anwendung verweist, sollte der HTTP-Server nicht ausgeführt werden, um Systemressourcen zu sparen.
Mithilfe dieses Parameters können Sie angeben, welche der lokalen IP-Adressen der Webserver des Herausgeberkanals für die Überwachung von HTTP-Anforderungen verwenden soll.
Wird der Parameter „HTTP-IP-Adresse oder -Hostname“ leer gelassen, überwacht der Webserver des Herausgeberkanals die Standard-IP-Adresse. Dies ist ausreichend für Server mit einer einzelnen IP-Adresse. Bei der Angabe einer IP-Adresse in Punktnotation als Wert für den Parameter überwacht der Webserver des Herausgeberkanals die angegebene Adresse auf HTTP-Anforderungen.
Beachten Sie, dass der für den Parameter „HTTP-IP-Adresse oder -Hostname“ angegebene Wert von der Email-Behandlungsroutine des Abonnentenkanals für die Erstellung von URLs verwendet wird, wenn der Hostname oder die Adresse nicht im Mail-Befehlselement angegeben ist. Wenn der Parameter „HTTP-Server verwenden (wahr|falsch)“ auf „falsch“ gesetzt ist, kann der Parameter „HTTP-IP-Adresse oder -Hostname“ für die Angabe der Adresse oder des Namens eines Webservers verwendet werden, der bei der Erstellung von URLs für Emails verwendet wird.
Dieser Parameter ist ein Ganzzahlwert, der angibt, welchen TCP-Port der Webserver des Herausgeberkanals auf eingehende Anforderungen überwachen soll. Wenn für diesen Parameter kein Wert angegeben ist, wird standardmäßig die Portnummer 80 oder 443 überwacht. Dies hängt davon ab, ob SSL für die Webserver-Verbindungen verwendet wird oder nicht.
Wenn der Service-Treiber für manuelle Aufgaben auf dem Identity Manager-Server ausgeführt wird (d. h., er wird nicht unter dem Remote Loader auf einem Remote-Computer ausgeführt), sollte der HTTP-Port nicht auf 80 oder 443 eingestellt werden, da in der Regel iMonitor oder ein anderer Prozess die Ports 80 und 443 verwendet.
Wenn dieser Parameter nicht leer ist, enthält er den Namen eines eDirectory-Schlüsselmaterialobjekts (Key Material Object, KMO), das das Serverzertifikat und den Schlüssel enthält, die vom Webserver des Herausgeberkanals für SSL verwendet werden.
Wenn dieser Parameter angegeben wird, verwendet der Webserver des Herausgeberkanals SSL für die Verarbeitung von HTTP-Anforderungen.
Dieser Parameter hat Vorrang vor anderen Java*-Keystore-Parametern (siehe unten).
Aus Sicherheitsgründen wird die Verwendung von SSL empfohlen, weil eDirectory-Passwörter bei Verwendung des Webservers des Herausgeberkanals in HTTP POST-Daten übergeben werden.
Dieser Parameter wird zusammen mit „Keystore-Passwort“, „Name des Zertifikats (Schlüsselalias)“ und „Zertifikatspasswort (Schlüsselpasswort)“ für die Angabe einer Java-Keystore-Datei verwendet, die ein Zertifikat und einen Schlüssel enthält, die vom Webserver des Herausgeberkanals für SSL verwendet werden.
Wenn dieser Parameter angegeben wird, verwendet der Webserver des Herausgeberkanals SSL für die Verarbeitung von HTTP-Anforderungen.
Wenn der Parameter „Name des KMO“ einen Wert enthält, werden dieser und ihm zugeordnete Parameter ignoriert.
Aus Sicherheitsgründen wird die Verwendung von SSL empfohlen, weil eDirectory-Passwörter bei Verwendung des Webservers des Herausgeberkanals in HTTP POST-Daten übergeben werden.
Mit diesem Parameter wird das Passwort für die Java-Keystore-Datei festgelegt, die durch den Parameter „Name der Keystore-Datei“ festgelegt ist.
Mit diesem Parameter wird der Name des Zertifikats festgelegt, das in der Java-Keystore-Datei verwendet werden soll, die durch den Parameter „Name der Keystore-Datei“ festgelegt ist.
Mit diesem Parameter wird das Passwort für das Zertifikat festgelegt, das durch den Parameter „Name des Zertifikats (Schlüsselalias)“ festgelegt ist.
In diesem Abschnitt werden die Einstellungen für den Abonnentenkanal beschrieben.
Mit diesem Parameter wird der Name des SMTP-Servers festgelegt, den der Abonnentenkanal zum Versenden von Emails verwendet.
Wenn für den durch die SMTP-Server-Parameter festgelegten SMTP-Server eine Authentifizierung erforderlich ist, gibt dieser Parameter den für die Authentifizierung zu verwendenden Kontonamen an. Das verwendete Passwort ist das Anwendungspasswort, das den Parametern der Treiberauthentifizierung zugeordnet ist.
Wenn dieser Parameter angegeben wird, besteht er aus der Email-Adresse, die vom Abonnentenkanal als SMTP-Absenderadresse verwendet wird. Wenn dieser Parameter nicht angegeben wird, müssen die <mail>-Elemente, die an den Abonnentenkanal gesendet werden, ein <from>-Element enthalten.
Ein <from>-Element, das unter <mail>-Elementen an den Abonnentenkanal gesendet wird, hat Vorrang vor diesem Parameter.
Wenn dieser Parameter angegeben wird, besteht er aus einer durch Whitespaces getrennten Liste mit Java-Klassennamen. Jeder Klassenname ist eine benutzerdefinierte Klasse, die die Schnittstelle „com.novell.nds.dirxml.driver.manualtask.CommandHandler“ implementiert und ein benutzerdefiniertes XDS-Element verarbeitet. (Bei der Behandlungsroutine für <mail> handelt es sich um eine integrierte Behandlungsroutine).
Weitere Informationen zu benutzerdefinierten Behandlungsroutinen finden Sie in Schnitt I.0, Service-Treiber für manuelle Aufgaben: Benutzerdefinierte Element-Behandlungsroutinen auf dem Abonnentenkanal.
In diesem Abschnitt werden die Einstellungen für den Herausgeberkanal beschrieben.
Wenn dieser Parameter angegeben wird, besteht er aus einer durch Whitespaces getrennten Liste mit Java-Klassennamen. Jeder Klassenname ist eine benutzerdefinierte Klasse, die „javax.servlet.http.HttpServer“ erweitert. Benutzerdefinierte Servlets können zur Erweiterung der Funktionalität des Webservers des Herausgeberkanals verwendet werden.
Weitere Informationen zu benutzerdefinierten Servlets finden Sie in Schnitt J.0, Service-Treiber für manuelle Aufgaben: Benutzerdefinierte Servlets für den Herausgeberkanal.
Die Konfiguration der Abonnentenkanalrichtlinien hängt davon ab, welchen Zweck eine bestimmte Installation mit dem Service-Treiber für manuelle Aufgaben erfüllen möchte. Es gibt jedoch bestimmte Richtlinien, die von Nutzen sein können.
In der Regel ist die Befehlstransformationsrichtlinie der beste Ort zum Erstellen eines <mail>-Elements, das an den Abonnentenkanal gesendet wird. Die Ursache hierfür ist, dass der Hauptteil der DirXML-Engine-Verarbeitung bereits abgeschlossen ist, wenn Befehle die Befehlstransformationsrichtlinie erreichen. Dies bedeutet, dass die Erstellungsrichtlinien für Add-Ereignisse verarbeitet wurden (wodurch das Einlegen von Vetos für Add-Ereignisse von Objekten ermöglicht wird, die z. B. nicht über alle für die Erstellung einer Email erforderlichen Attribute verfügen). Dies bedeutet auch, dass Modify-Ereignisse für Objekte ohne Verknüpfungen bereits in Add-Ereignisse konvertiert wurden.
Die XSLT-Formatvorlage, die die Email erstellt, fragt eDirectory möglicherweise nach weiteren Informationen ab.
Wenn es sich bei der Email beispielsweise um eine einfache Begrüßungsnachricht an einen neuen Mitarbeiter handelt, enthält der Add-Befehl möglicherweise alle erforderlichen Informationen: Vorname, Nachname und die Internet-Email-Adresse. Dies ist dann der Fall, wenn in der Erstellungsrichtlinie angegeben ist, dass Vorname, Nachname und Internet-Email-Adresse zu den obligatorischen Attributen gehören. Dadurch wird sichergestellt, dass nur Add-Befehle mit den erforderlichen Informationen die Befehlstransformation erreichen können.
Handelt es sich bei der Email jedoch um eine Nachricht an den Manager eines Mitarbeiters, muss die Formatvorlage eDirectory abfragen. Der DN des Managers kann vom Add-Ereignis des Benutzerobjekts des Mitarbeiters zur Verfügung gestellt werden. Die Email-Adresse des Managers muss jedoch abgefragt werden, da diese Information ein Attribut des Benutzerobjekts des Managers ist.
Falls als Ergebnis von Modify-Befehlen für dem Treiber zugeordnete Objekte Email-Benachrichtigungen erzeugt werden, müssen Abfragen für Optionen erstellt werden, die nicht im Modify-Befehl enthalten sind.
Wenn Emails von anderen Ereignissen als Add-Ereignissen erzeugt werden sollen, muss zugelassen werden, dass Add-Ereignisse für diese zu überwachenden Objekte den Abonnentenkanal erreichen können. Wenn zugelassen wird, dass Add-Ereignisse den Abonnentenkanal erreichen, hat dies die Erzeugung eines Verknüpfungswerts zur Folge, der vom Abonnentenkanal an Identity Manager zurückgegeben wird.
Es ist wichtig, dass für eDirectory-Objekte, die von den Richtlinien des Service-Treibers für manuelle Aufgaben überwacht werden sollen, eine Verknüpfung zum Service-Treiber für manuelle Aufgaben besteht. Nur für Objekte mit einer definierten Verknüpfung werden Ereignisse zum Löschen, Umbenennen und Verschieben an den Treiber weitergeleitet. Darüber hinaus werden Modify-Ereignisse für Objekte ohne eine Verknüpfung nach der Ereignistransformation des Abonnentenkanals in Add-Ereignisse konvertiert.
Alle anderen Befehle (zum Ändern, Verschieben, Umbenennen und Löschen) sollten von der Befehlstransformationsrichtlinie blockiert werden, um zu verhindern, dass sie den Abonnentenkanal erreichen. Der Abonnentenkanal verarbeitet nur <Add>- und <mail>-Befehle. Bei anderen Befehlen gibt der Abonnentenkanal eine Fehlermeldung zurück.
Emails werden vom Abonnentenkanal als Antwort auf den Erhalt eines <mail>-Elements gesendet, das die zu sendende Email beschreibt. In Schnitt G.0, Service-Treiber für manuelle Aufgaben: <mail>-Element finden Sie eine Beschreibung des <mail>-Elements und dessen Inhalts.
Emails können als Antwort auf ein beliebiges Identity Manager-Ereignis (Hinzufügen, Bearbeiten, Umbenennen, Verschieben, Löschen) erzeugt werden.
Die Ersetzungsdaten, die mit den einem <mail>-Element untergeordneten <message>-Elementen zur Verfügung gestellt werden, hängen von zwei Hauptfaktoren ab:
Wenn die Email eine URL enthalten soll, die auf den Webserver des Herausgeberkanals verweist und zum Einholen von Informationen von einem Benutzer verwendet wird, müssen die Ersetzungsdaten mindestens ein responder-dn-Element enthalten. Die Werte der responder-dn-Elemente müssen die DNs der Benutzerobjekte der Benutzer sein, an die die Nachricht gesendet wird.
Wenn ein Abfrage-Ersetzungs-Token (siehe Ersetzungsdaten) in der Schablone verwendet wird, müssen die Ersetzungsdaten für das <message>-Element ein Element namens „src-dn“ oder „src-entry-id“ oder eine Verknüpfung zum entsprechenden Wert enthalten. Ein Verknüpfungselement kann nur verwendet werden, wenn das abzufragende eDirectory-Objekt bereits über eine Verknüpfung zum Service-Treiber für manuelle Aufgaben verfügt. Die vom Abonnentenkanal für nicht verknüpfte Objekte erzeugte Verknüpfung kann nicht verwendet werden, weil sie zum Zeitpunkt der Abfrage noch nicht in das eDirectory-Objekt geschrieben wurde.
Das <message>-Element kann den MIME-Typ des Nachrichtentexts angeben. Wenn zwar der MIME-Typ, aber keine Formatvorlage angegeben ist (d. h., es ist kein untergeordnetes <stylesheet>-Element von <message> vorhanden), wird einer der zwei Standard-Formatvorlagennamen verwendet. Wenn der MIME-Typ einfacher Text ist, lautet der Standardname der Formatvorlage „process_text_template.xsl“. Bei einem anderen MIME-Typ lautet der Standardname der Formatvorlage „process_template.xsl“.
Email-Schablonen sind XML-Dokumente, die häufig verwendeten Text und Ersetzungs-Token enthalten. Email-Schablonen werden zur Erzeugung des Texts einer Email verwendet. Allgemeine Informationen zu Schablonen finden Sie in Schablonen.
Die in einer Email-Schablone verwendeten Ersetzungs-Token geben die <item>-Elemente vor, die als untergeordnete Elemente des <replacement-data>-Elements zur Verfügung gestellt werden müssen, das von der Abonnentenkanalrichtlinie erstellt wurde, die das <mail>-Element erstellt. Wenn z. B. die Email-Schablone über das Ersetzungs-Token $employee-name$ verfügt, muss ein <item name=“employee-name”>-Element in den Ersetzungsdaten für das <message>-Element vorhanden sein. Wenn das Element mit dem Mitarbeiternamen nicht vorhanden ist, enthält der Nachrichtentext der Email an der Stelle, die das Ersetzungs-Token in der Schablone einnimmt, keinen Text.
Email-Schablonen können zur Generierung von Nachrichtentexten im Format „einfacher Text“, HTML oder XML verwendet werden.
Wenn eine Email-Schablone eine Nachricht mit einfachem, unformatiertem Text generiert, muss diese von einer Formatvorlage verarbeitet werden, in der als Ausgabetyp „einfacher Text“ angegeben ist. Wenn in der Formatvorlage nicht einfacher Text als Ausgabetyp angegeben ist, tritt unerwünschtes XML-Escaping auf. Die Standard-Formatvorlage des Service-Treibers für manuelle Aufgaben, process_text_template.xsl, wird in der Regel zum Verarbeiten von Schablonen verwendet, die ein Ergebnis in einfachem Text ergeben.
Bei den meisten Implementierungen des Service-Treibers für manuelle Aufgaben sind keine Herausgeberkanalrichtlinien erforderlich. Dies liegt daran, dass die Webseite und die XDS-Schablonen so erstellt werden können, dass sie genau die erforderliche XDS ergeben und nicht mehr anhand der Richtlinien weiterverarbeitet werden müssen.
Wenn Richtlinien erforderlich sind, sind diese sehr genau auf eine Installation zugeschnitten.
Webseitenschablonen sind XML-Dokumente, die häufig verwendeten Text und Ersetzungs-Token enthalten. Webseitenschablonen werden zur Generierung von Webseitendokumenten verwendet (in der Regel HTML-Dokumente). Allgemeine Informationen zu Schablonen finden Sie in Schablonen.
Ersetzungs-Token in Webseitenschablonen geben vor, welche Ersetzungsdaten als URL-Abfragedaten auf dem Abonnentenkanal zur Verfügung gestellt werden. Ersetzungsdaten auf dem Herausgeberkanal werden für HTTP GET-Anforderungen von der URL-Query-Zeichenkette und für HTTP POST-Anforderungen von der URL-Query-Zeichenkette und den POST-Daten zur Verfügung gestellt.
Folgendes Szenario ist ein Beispiel für den Fluss der Ersetzungsdaten vom Abonnentenkanal zur Email und anschließend zum Herausgeberkanal.
Der Service-Treiber für manuelle Aufgaben ist so konfiguriert, dass der Manager eines neuen Mitarbeiters aufgefordert wird, dem neuen Mitarbeiter eine Raumnummer zuzuweisen. Der Auslöser für die Email an den Manager ist der <add>-Befehl für ein neues Benutzerobjekt, der von der Befehlstransformationsrichtlinie des Abonnentenkanals verarbeitet wird.
Wenn der Manager in der Email auf die URL klickt, wird eine Webseite im Webbrowser des Managers angezeigt. Die Webseite muss anzeigen, wem der Manager eine Raumnummer zuweist.
Diese Anforderung wird durch das <url-query>-Element auf dem Abonnentenkanal erfüllt, das ein Ersetzungsdatenelement mit dem Namen des neuen Benutzers enthält:
<item name=”subject-name”>Joe the Intern</item>
Dadurch enthält die URL-Query-Zeichenkette (neben anderen Angaben) “subject-name=Daniel%20ein%20Praktikant”. (Das Zeichen “%20” ist ein URL-kodiertes Leerzeichen).
Wenn der Manager auf die URL in der Email klickt, sendet der Webbrowser des Managers die URL an den Webserver des Herausgeberkanals. Der Webserver erstellt ein Ersetzungsdatenelement namens „subject-name“ mit dem Wert „Daniel ein Praktikant“.
Die ebenfalls durch die URL angegebene Webseitenschablone enthält ein Ersetzungs-Token namens $subject-name$. Wenn die Webseitenschablone von der Formatvorlage verarbeitet wird, um die Webseite zu erstellen, wird das Ersetzungs-Token durch „Daniel ein Praktikant“ ersetzt. Auf diese Weise wird die Webseite an den Mitarbeiter angepasst, dessen Erstellung des Benutzerobjekts das Versenden der Email ausgelöst hat.
Weitere Informationen zu einer ausführlichen Transaktion vom Abonnentenkanal zum Herausgeberkanal finden Sie in Schnitt H.0, Service-Treiber für manuelle Aufgaben: Datenfluss-Szenario bei Einstellung eines neuen Mitarbeiters.
XDS-Schablonen sind XML-Dokumente, die häufig verwendeten Text und Ersetzungs-Token enthalten. XDS-Schablonen werden zur Generierung von XDS-Dokumenten verwendet, die auf dem Herausgeberkanal des Service-Treibers für manuelle Aufgaben an Identity Manager gesendet werden. Allgemeine Informationen zu Schablonen finden Sie im Abschnitt „Überblick“.
Ersetzungs-Token in XDS-Schablonen geben einige Ersetzungsdaten vor, die dem Webserver in Form von Daten in einer HTTP POST-Anforderung zur Verfügung gestellt werden.
Im Folgenden finden Sie ein Beispiel für eine XDS-Schablone:
<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>
Die Ersetzungs-Token in der Schablone schreiben vor, dass die HTTP POST-Daten einen Wert für „association“ und „room-number“ zur Verfügung stellen müssen.
In der Regel hat der Wert „association“ seinen Ursprung im Abonnentenkanal. Die Email des Abonnentenkanals würde „association=beliebiger Wert“ in die Query-Zeichenkette der URL platzieren, die in der Email enthalten ist. Die Webseitenschablone, die zur Erzeugung der Webseite verwendet wird, wenn die URL an den Webserver gesendet wird, platziert den Wert „association“ in der Regel in einem versteckten INPUT-Element:
<INPUT TYPE="hidden" NAME="association" VALUE="$association$"/>
Durch die Platzierung des Werts „association“ als verstecktes INPUT-Element wird das Paar “association=beliebiger Wert” als Teil der HTTP POST-Daten gesendet.
Der Wert „room-number“ wird mithilfe eines INPUT-Elements in die Webseite eingefügt. Dieses Element ist ähnlich wie im folgenden Beispiel:
<input TYPE="text" NAME="room-number" SIZE="20" MAXLENGTH="20"/>
Wenn der Manager „1234“ eingibt und auf „Senden“ klickt, sendet der Webbrowser „room-number=1234“ als Teil der HTTP POST-Daten.
Anschließend generiert der Webserver ein <item name=“association”>- und ein <item name=“room-number”>-Ersetzungsdatenelement, die bei der Verarbeitung der XDS-Schablone verwendet werden.
Das XDS-Dokument wird durch die Verarbeitung der in den POST-Daten angegebenen XDS-Schablone generiert. Anschließend wird das XDS-Dokument über den Herausgeberkanal des Service-Treibers für manuelle Aufgaben an Identity Manager gesendet.
Der Service-Treiber für manuelle Aufgaben gibt Meldungen mit verschiedenen Trace-Stufen aus:
Weitere Informationen zu Einstellungen für den Service-Treiber für manuelle Aufgaben finden Sie in: