Man kann bei einem benutzerdefinierten Auftrag die Aktion bestimmen, welche ausgeführt werden soll. Folgende Aktionen stehen dabei zur Verfügung:
In diesem Artikel wird die Variante URL aufrufen näher beleuchtet und dabei erklärt wie man URL-Parameter übergeben kann.
#result#
angezeigt.sso=TestUser|20081027095715|+01:00|6665F482DA1536FA66B8DED56E1F21C6
20050829145501 für den Zeitstempel 2005-08-29 14:55:01
7C072DE6355A81B976CE9AC32A
Man kann nach der Pfadangabe für die externe Anwendung Parameter übergeben. Diese gibt man durch ein Leerzeichen getrennt an. Die Parameter werden in der Reihenfolge übergeben, in der sie angegeben wurden.
Durch frei definierbare Parameter kann man, je nach Programmierung, die externe Anwendung steuern. So kann beispielsweise eine Anwendung für verschiedene Zwecke verwendet werden. Je nach Kontext kann die Anwendung dann mit unterschiedlichen Parametern angesprochen werden und somit unterschiedliche Aktionen ausführen.
Definierter Parameter %LOG%
Der Parameter %LOG% übergibt Pfad und Dateinamen der Konfigurationsdatei des jeweiligen Publizierungsauftrags, wenn der benutzerdefinierte Auftrag automatisch nach einer Publizierung gestartet wurde. Diese Einstellung nimmt man im SmartTree vor (Publizierung verwalten > Projekt > Benutzerdefinierten Auftrag starten). Die Konfigurationsdatei enthält wiederum den Pfad zu den Publizierungs-Log-Dateien. Diese können von der externen Anwendung beispielsweise verwendet werden, um die Log-Dateien auszulesen und so die Dateinamen der publizierten Dateien zu ermitteln.
Wenn man im Anschluß einer Publizierung einen Auftrag vom Typ URL starten, dann wird der Parameter %LOG% mit ausgewertet. Allerdings ist hier die Funktionalität anders als beim Aufruf einer externen Applikation, diese macht nur Sinn, wenn man auch die Option zum Mitsenden der Logfiles bei der Publizierung aktiviert. Diese Option gibt es bei lokalen und FTP-Publizierungszielen.
Der dort eingestellte Pfad zusammen mit dem Dateinamen der Logdatei wird dann der URL mitgegeben, als Post-Parameter. Die Pfade unterscheiden sich natürlich je nach Publizierungsziel, für lokale Ziele müssen auch lokale Pfade angegeben werden, für FTP-Ziele müssen Pfade angegeben werden, die der WebServer, der mit der URL angesprochen wird, auch verarbeiten kann.
Der oder die Logfiles (bei mehreren Varianten können das auch mehrere Logfiles sein), werden in Form eines XML-Schnipsels gesendet. Das sieht dann wie folgt aus:
<REQUESTPARAMETER> <![CDATA[<LOGFILES> <LOGFILE type="1=Publisher, 2=Transfer Job, 3=Delete Job" path="Path/FileName" publishingtarget="Guid of publication target"/> <LOGFILE type="1=Publisher, 2=Transfer Job, 3=Delete Job" path="Path/FileNaem" publishingtarget="Guid of publication target"/> <LOGFILE type="1=Publisher, 2=Transfer Job, 3=Delete Job" path="Path/FileNaem" publishingtarget="Guid of publication target"/> </LOGFILES>]]> </REQUESTPARAMETER>
Man bekommt dann bei der Publizierung per FTP zum Beispiel die _ftp.xml und _cleaner.xml Logdateien, beim lokalen Publizieren die regulären und die _cleaner.xml Logdateien.
Hinweis von R&D: Diese Funktionalität wurde vor langer Zeit für eine Erweiterung des Management Servers entwickelt, welches es aber nie zur Serienreife gebracht hat. Funktionieren sollte sie jedoch immer noch.
Man muß das Publizieren von Logfiles aktivieren und den Pfad auswählen. Und dann beim aufzurufenen Auftrag %LOG% mit angeben. Dies wird dann intern wieder aus der URL rausgenommen, jedoch die Logdateien werden dann per Post mitgeliefert.
Der Pfad oben sollte schon ein lokales Verzeichnis beschreiben, sowas wie C:\Temp\Logs oder ähnliches. Nur bei FTP-Zielen muß dann den Pfad ala logs/target1/ oder sowas in der Art angegeben werden. Die Logdateien werden dann auch in den angegebenen Pfad kopiert.
Hinweis von R&D: Was der Management Server (MS) genau macht, wenn man nicht logs angibt, bei einem lokalen Ziel, ist nicht bekannt. Im schlimmsten Fall versucht der MS die Files in ..\System32 oder ein anderes System-Verzeichnis zu kopieren. Im optimalen Fall packt er es unterhalb des Publizierungsziels.
... ist Senior Site Reliability Engineer bei der Vodafone GmbH in Düsseldorf. Seit dem Jahr 2007 betreut er zusammen mit seinen Kollegen die OpenText- (vormals RedDot-) Plattform Web Site Management für die deutsche Konzernzentrale.
Er entwickelt Erweiterungen in Form von Plug-Ins und PowerShell Skripten. Seit den Anfängen in 2001 (RedDot CMS 4.0) kennt er sich speziell mit der Arbeitweise und den Funktionen des Management Server aus.