Konfiguration von Web Services zur Ausführung von Jobs

Transkript

1 Web Services Konfiguration von Web Services zur Ausführung von Jobs JOB SCHEDULER Tutorial März 2006 Software- und Organisations-Service GmbH Giesebrechtstr. 15 D Berlin Telefon (030) Telefax (030)

2 Konfiguration von Web Services zur Ausführung von Jobs 2 Impressum Software- und Organisations-Service GmbH Giesebrechtstr. 15 D Berlin Telefon (030) Telefax (030) Mail info@sos-berlin.com Web Letzte Aktualisierung: 11. März 2006

3 Konfiguration von Web Services zur Ausführung von Jobs 3 Inhaltsverzeichnis 1 Einleitung Einsatz des Job Schedulers für Web Services Web Service Fähigkeit für eigene Programme und Skripte Orchestrierung von Jobs mit Web Services Routing von Web Service Requests Ablauf eines asynchronen Web Service Ablauf eines synchronen Web Service Einfache Web Service Steuerung Starten eines Jobs Erzeugen eines Auftrags Konfiguration eines asynchronen Web Service Bereitstellen einer Job-Kette als asynchronen Web Service Das request_xslt_stylesheet Das response_xslt_stylesheet Das forward_xslt_stylesheet Konfiguration eines synchronen Web Service Erstellen von Jobs für synchrone Web Services Anhang A: execute_file_request.xslt Anhang B: execute_file_response.xslt Anhang C: execute_file_forward.xslt

4 Einleitung 4 1 Einleitung Der Job Scheduler bietet eine Schnitstelle um Jobs und Job-Ketten als Web Services zur Verfügung zu stellen. Hierbei wird zwischen zwei Verfahren unterschieden: Asynchrone Web Services: Mit Hilfe von XSLT-Stylesheets kann die Annahme von Web Service Anfragen, sowie deren Beantwortung konfiguriert werden. Der Job Scheduler ist oberhalb von HTTP auf kein spezielles Protokoll (z.b. SOAP) festgelegt. Die Implementierung dieses Protokolls ist nicht im Job Scheduler enthalten, sondern wird in den Stylesheets vorgenommen. Mit dieser Methode können vorhandene Job-Ketten zur Verwendung als Web Service angepasst werden. Das Ergebnis nach der Auftragsverarbeitung kann bei dieser Technik nur asynchron weitergeleitet werden. Es gibt zwar auch bei dieser Methode eine synchrone Antwort, diese dient aber nur der Quittierung, dass ein Auftrag angenommen wurde. Synchrone Web Services: Wird eine synchrone Antwort benötigt, in der das Ergebnis der Job-Verarbeitung enthalten ist, so müssen Jobs dazu entsprechende Schnittstellen implementieren. Die sychrone Antwort wird von einem Job mittels Job Scheduler API verschickt. Die Interpretation der Web Service Anfrage erfolgt im Job. Es werden keine Stylesheets verwendet, stattdessen wird konfiguriert, welche Job-Kette den Web Service beantworten soll. Für das Verständnis dieses Tutorials gelten folgende Voraussetzungen: Kentnisse über den Aufbau von SOAP Nachrichten Verständnis von Jobs und Job-Ketten im Job Scheduler Grundlegende Kenntnisse der XML-Kommandos des Job Schedulers Grundlegende XSLT Kenntnisse. (Für asynchrone Web Services) Kenntnisse der Job Scheduler Java API für die Job Implementierung. (Für synchrone Web Services)

5 Einsatz des Job Schedulers für Web Services 5 2 Einsatz des Job Schedulers für Web Services Mit dem Job Scheduler können Jobs automatisch als Web Services bereitgestellt werden. Nachstehend einige Beispiel für Einsatzgebiete dieser Schnittstelle. 2.1 Web Service Fähigkeit für eigene Programme und Skripte Beliebige ausführbare Programme und Shell Skripte werden automatisch als Web Services verfügbar. Ihre Applikationen steuern mittels Web Service Aufrufen beliebige Jobs, die ausführbare Programme, Shell Skripte oder Java-Klassen starten.

6 Einsatz des Job Schedulers für Web Services Orchestrierung von Jobs mit Web Services Eigene Programme und Skripte können mit dem Job Scheduler Web Service in das Business Process Management eingebunden werden. Der Job Scheduler liefert synchrone und asynchrone Antworten an Ihre BPM Engine.

7 Einsatz des Job Schedulers für Web Services Routing von Web Service Requests Der Job Scheduler kann Web Service Requests vom Internet in das Intranet routen. Die Requests werden empfangen, authentifiziert und validiert. Valide Requests werden zur Weiterverarbeitung an einen weiteren Job Scheduler im Intranet übertragen.

8 Ablauf eines asynchronen Web Service 8 3 Ablauf eines asynchronen Web Service A n a l o g z u m n a c h f o l g e n d e n B e i s p i e l s e i i m J o b S c h e d u l e r f ü r d i e U R L ein Web Service konfiguriert. Ein Client schickt per HTTP POST an den Job Scheduler (Host und TCP Port des Job Schedulers) einen Web Service Aufruf. Den ankommenden Aufruf kann der Job Scheduler so nicht verstehen. Er verwendet daher das für den Web Service konfigurierte request_xslt_stylesheet, um den unbekannten Aufruf in ein für ihn verständliches XML-Kommando zu transformieren. Das transformierte XML-Kommando führt der Job Scheduler aus. Die HTTP-Verbindung wird währenddessen offengehalten. Das Ausführen eines XML-Kommandos im Job Scheduler liefert eine XML-Antwort. Beispielsweise liefert der Job Scheduler auf einen erfolgreichen <kill_task> Befehl die XML-Antwort: <spooler> <answer> <ok/> </answer> </spooler> Der (SOAP-)Client am anderen Ende der offenen HTTP-Verbindung erwartet eine (synchrone) Antwort, würde jedoch die Antwort des Job Schedulers nicht verstehen, da sie noch keine SOAP-Nachricht ist. Deswegen transformiert der Job Scheduler mit Hilfe des response_xslt_stylesheet die XML-Antwort in eine Antwort, die vom Client verstanden wird. Diese Antwort schickt der Job Scheduler an den Client und schließt die HTTP-Verbindung. Diese synchronen Antworten beinhalten in der Regel nur sehr einfache Informationen, zum Beispiel, ob ein Auftrag erfolgreich übergeben wurde, und welche ID er erhalten hat. Möchte man jedoch einen Web Service bereitstellen, dessen Antwort das Ergebnis der Ausführung eines Auftrags beinhaltet, so erfordert dies eine asynchrone Antwort, falls die Ausführung des Auftrags längere Zeit in Anspruch nimmt. Dazu werden die (beim Durchlaufen der Job-Kette veränderten) Parameter des Auftrags mit dem forward_xslt_stylesheet transformiert. Das Ergebnis wird als asynchrone Antwort mit einer neuen HTTP Verbindung zurück an den (SOAP-)Client (oder an einen anderen Empfänger) geschickt.

9 Ablauf eines asynchronen Web Service 9

10 Ablauf eines synchronen Web Service 10 4 Ablauf eines synchronen Web Service Für die URL sei ein Web Service konfiguriert. Dieser verwendet eine Job-Kette, um Web Service Anfragen synchron zu beantworten. Ein Client schickt per HTTP POST an den Job Scheduler (Host und TCP Port des Job Schedulers) einen Web Service Aufruf. Der Job Scheduler versucht nicht, diese Anfrage zu verstehen, sondern erzeugt für die konfigurierte Job-Kette einen neuen Auftrag, der die Anfrage enthält. Jobs in dieser Job-Kette haben die Möglichkeit, diese Anfrage aus dem Auftrag zu lesen und zu beantworten. Ein Job in der Kette muss die Anfrage mit der Web_service_response.send() Methode beantworten.

11 Einfache Web Service Steuerung 11 5 Einfache Web Service Steuerung Die Job Scheduler Distribution enthält zwei Standard Stylesheets, um Grundlegende Funktionen des Job Schedulers per SOAP bereitzustellen. Per default ist dieser Standard Web Service jedoch abgeschaltet. Um ihn zu aktivieren, müssen in der Datei config/scheduler.xml die XML-Kommentare um das <web_services>... </web_services> Element entfernt werden. Nach einem Neustart des Job Schedulers steht dann ein Web Service unter der url bereit. 5.1 Starten eines Jobs Z u m S t a r t e n e i n e s J o b s w i r d d i e S O A P M e t h o d e s t a r t J o b i m N a m e s p a c e zur Verfügung gestellt. Diese kennt folgende Parameter, die als Kind Elemente von <startjob> gesendet werden müssen: job: Jobname name: Name für die Task (optional) after: Eine Anzahl Sekunden, nach deren Ablauf erst die Task gestartet werden soll (optional) at: Zeitpunkt, zu dem die Task gestartet werden soll (optional) Außderdem können beliebig viele <param> Elemente gesendet werden, um Job Parameter zu setzen. <param> hat die Kind-Elemente <name> und <value>. Beispiel: startjob für Job scheduler_check_sanity <?xml version="1.0" encoding="utf-8"?> <soapenv:envelope xmlns:soapenv=" <soapenv:body> <startjob xmlns=" <job>scheduler_check_sanity</job> <at> :05:00</at> </startjob> </soapenv:body> Als Antwort kommt ein SOAP Dokument zurück, das die vom Job Scheduler vergebene Task Id enhält. Beispiel: SOAP Antwort auf startjob <?xml version="1.0" encoding="utf-8"?> <soapenv:envelope xmlns:soapenv=" <soapenv:body> <sos:taskid xmlns:sos=" </soapenv:body>

12 Einfache Web Service Steuerung Erzeugen eines Auftrags Zum Erzeugen eines Auftrags wird die SOAP Methode addorder zur Verfügung gestellt. Diese kennt folgende Parameter, die als Kind Elemente von <addorder> gesendet werden müssen: jobchain: Jobkette des Auftrags id: ID des Auftrags (optional) title: Titel des Auftrags(optional) Außderdem können beliebig viele <param> Elemente gesendet werden, um Auftrags Parameter zu setzen. Beispiel: addorder für die Jobkette database_reports (aus dem Managed Jobs Paket) <?xml version="1.0" encoding="utf-8"?> <soapenv:envelope xmlns:soapenv=" <soapenv:body> <addorder xmlns=" <jobchain>database_reports</jobchain> <title>soaptest</title> <param> <name>command</name> <value>select * FROM SCHEDULER_MANAGED_ORDERS</value> </param> <param> <name>database_connection</name> <value>scheduler</value> </param> <param> <name>scheduler_order_report_mailto</name> <value> @myhost.com</value> </param> <param> <name>scheduler_order_report_asbody</name> <value>1</value> </param> <param> <name>scheduler_order_report_subject</name> <value>webservice_test 1</value> </param> </addorder> </soapenv:body> Als Antwort kommt ein SOAP Dokument zurück, das die vom Job Scheduler vergebene Order Id enhält. Beispiel: SOAP Antwort auf addorder <soapenv:envelope xmlns:soapenv=" <soapenv:body> <sos:orderid xmlns:sos=" </soapenv:body>

13 Konfiguration eines asynchronen Web Service 13 6 Konfiguration eines asynchronen Web Service Damit der Job Scheduler die im folgenden Kapitel erstellten Stylesheets für einen Web Service verwendet, muss dieser zunächst in der Konfigurationsdatei scheduler.xml konfiguriert werden. Wenn noch nicht vorhanden, muss nach dem Element </process_classes> ein neues Element <web_services> eingefügt werden. Innerhalb von <web_services> wird für jeden Web Service ein <web_service> Element erstellt. Für das hier vorgestellte Beispiel wird die Konfiguration des Web Service wie folgt vorausgesetzt: <web_service debug = "yes" request_xslt_stylesheet = "samples/config/execute_file_request.xslt" response_xslt_stylesheet = "samples/config/execute_file_response.xslt" forward_xslt_stylesheet = "samples/config/execute_file_forward.xslt" name = "execute_file" url_path = "/execute_file" /> Der Parameter debug="yes" bewirkt, dass die Ergebnisse der XSL Transformationen im Verzeichnis logs des Job Schedulers abgelegt werden. Dies ist hilfreich, um zu prüfen, ob die Transformationen wie erwartet durchgeführt werden, sollte aber im produktiven Betrieb abgeschaltet werden, da sonst sehr viele Dateien entstehen. Die Verzeichnisangaben sind an die Verzeichnisse anzupassen, in denen die Stylesheets abgelegt wurden. Nachdem die Datei scheduler.xml geändert wurde, muss der Job Scheduler neu gestartet werden.

14 Bereitstellen einer Job-Kette als asynchronen Web Service 14 7 Bereitstellen einer Job-Kette als asynchronen Web Service Das folgende Beispiel setzt eine Installation des Job Schedulers mit dem Paket Managed Jobs voraus. Im Paket Managed Jobs ist eine vorkonfigurierte Job-Kette executable_files vorhanden. Diese enthält den Job JobSchedulerManagedExecutableJob, der auf dem Host des Job Schedulers vorhandene ausführbare Dateien startet. Das Managed Jobs Paket ist keine Voraussetzung für Web Services im Job Scheduler, sondern nur für dieses Beispiel. Für diese Job-Kette, soll eine SOAP-Schnittstelle bereitgestellt werden, die es ermöglicht, Executables auf dem Host des Schedulers aufzurufen. Als Beispielaufruf wird ein Unix "ls"-kommando übergeben, welches den Inhalt des Arbeitsverzeichnisses in die Standardausgabe (stdout) schreibt. Optional soll eine asynchrone Antwort möglich sein, die diese Ausgaben des Executable Files enthält. Die kompletten Quelltexte für die Stylesheets befinden sich im Anhang. 7.1 Das request_xslt_stylesheet Für die Entwicklung des Stylesheets, das die SOAP-Anfrage entgegennimmt und in ein für den Job Scheduler verständliches XML-Kommando umwandelt, gehen wir zunächst von der SOAP-Anfrage aus. Die SOAP-Schnittstelle benötigt eine Methode executefile mit einem Parameter file, der den Aufruf angibt. Beispiel: SOAP Anfrage Methode executefile <?xml version="1.0" encoding="utf-8"?> <soapenv:envelope xmlns:soapenv=" <soapenv:header> <wsa:to xmlns:wsa=" </wsa:to> </soapenv:header> <soapenv:body> <executefile xmlns=" <file>ls</file> </executefile> </soapenv:body> Bevor der Job Scheduler den Aufruf transformiert, bettet er ihn in ein <service_request> Dokument ein, das weitere Meta-Informationen über die Anfrage transportiert.

15 Bereitstellen einer Job-Kette als asynchronen Web Service 15 Beispiel: service_request <?xml version="1.0" encoding="utf-8"?> <service_request url=" <web_service name="execute_file" url_path="/execute_file" request_xslt_stylesheet="samples/config/execute_file_request.xslt" response_xslt_stylesheet="samples/config/execute_file_response.xslt" debug="1"/> <content> <soapenv:envelope xmlns:soapenv=" </content> </service_request> Daher muss das Stylesheet von einer Wurzel <service_request> ausgehen: <xsl:template match="/service_request"> <xsl:apply-templates select="content/soapenv:envelope/soapenv:body"/> <xsl:template match="soapenv:body"> <xsl:apply-templates select="*" mode="soapbody"/> Das zweite Template selektiert noch nicht die erwartete Methode executefile, sondern alle Elemente im Mode "soapbody". Zum einen könnte es sein, dass man mit einem Stylesheet (und einem Web Service) unterschiedliche Methoden behandeln möchte. Dann würde man für jede Methode ein separates Template mit dem Mode "soapbody" schreiben. Zum anderen erlaubt es dieses select, für gültige SOAP Requests, die eine unbekannte Methode aufrufen, einen SOAP Fehler zurückzugeben. Dazu später mehr. In diesem Beispiel wird ein Template benötigt für <execute_file> Elemente. <xsl:template match="sos:executefile" mode="soapbody" priority="2"> <add_order job_chain="executable_files"> <xsl:attribute name="web_service"> <xsl:value-of </xsl:attribute> <params> <param name="command"> <xsl:attribute name="value"> <xsl:value-of select="sos:file"/> </xsl:attribute> </param> </params> </add_order> Das Template generiert einen <add_order> Befehl für die Job-Kette executable_files. Des weiteren erhält der <add_order> Befehl ein Attribut web_service, das den Namen (siehe Konfiguration) des aufgerufenen Web Service enthält: <?xml version="1.0" encoding="utf-8"?> <add_order job_chain="executable_files" web_service="execute_file"> <params> <param name="command" value="ls"/> </params> </add_order>

16 Bereitstellen einer Job-Kette als asynchronen Web Service 16 Die Übergabe des Web Service Namens an den Auftrag ist Voraussetzung, um später eventuell eine asynchrone Antwort oder Weiterleitung zu durchführen zu können. In <params> werden die Auftragsparameter gesetzt. Der Job JobSchedulerManagedExecutableJob kennt einen Parameter command, der den auszuführenden Befehl (in diesem Fall "ls") enthält. Für die Fehlerbehandlung gibt es ein weiteres Template. Dieses gilt für alle Methodenaufrufe, die nicht schon von einem anderen Template behandelt wurden. In diesem Fall also alle Methoden außer executefile. <xsl:template match="*" mode="soapbody" priority="0.5"> <!-- SOAP-Fehlermeldung an Web Service generieren --> <service_response> <content> <soapenv:envelope> <soapenv:body> <soapenv:fault> <faultcode>soap-env:client</faultcode> <faultstring>unknown command: <xsl:value-of select="name(.)"/> </faultstring> </soapenv:fault> </soapenv:body> </content> </service_response> Dieses Template erstellt das Scheduler Kommando <service_response>. Dieses schickt den Inhalt des Elements <content> als Antwort zurück. Damit wird für alle unbekannten Methodenaufrufe eine SOAP Fehlermeldung erzeugt. 7.2 Das response_xslt_stylesheet Nachdem der Job Scheduler den Auftrag angenommen hat, gibt er eine Antwort, die das Element <OK> und weitere Informationen über den neuen Auftrag enthält, oder das Element <ERROR> im Fehlerfall. Beispiel: Antwort vom Job Scheduler <?xml version="1.0" encoding="iso "?> <spooler> <answer time=" :19:46.342"> <ok> <order order="3823" id="3823" state="0" initial_state="0" job_chain="executable_files" job="scheduler_managed_executable_file" priority="0" created=" :19:46.342" web_service="execute_file"> <log level="debug9"/> </order> </ok> </answer> </spooler> Diese Antwort des Job Schedulers wird vom response_xslt_stylesheet umgewandelt, und als synchrone Antwort an den Client zurückgeschickt. Dafür muss ein <service_response> Kommando für den Job Scheduler generiert werden: <xsl:template match="/spooler/answer"> <service_response> <content>

17 Bereitstellen einer Job-Kette als asynchronen Web Service 17 <soapenv:envelope> <soapenv:body> <xsl:apply-templates select="error ok"/> </soapenv:body> </content> </service_response> Im Erfolgsfall kann dann z.b. die ID zurückgegeben werden, die an den neuen Auftrag vergeben wurde: <xsl:template match="ok[order]" priority="2"> <sos:orderid><xsl:value-of Es sind auch andere Rückgaben denkbar, wie zum Beispiel ein boolscher Wert, der über den Erfolg des Kommandos Auskunft gibt. 7.3 Das forward_xslt_stylesheet Nachdem ein Auftrag durchlaufen ist, ist es möglich mit einer weiteren XSLT-Transformation asynchron ein Ergebnis zu liefern beziehungsweise an einen anderen Emfänger weiterzuleiten. Transformiert wird in diesem Fall entweder ein <order> oder ein <task> Element, je nachdem, ob der Web Service ein add_order oder ein start_job ausgeführt hat. Das <order> Element enthält Informationen über den Auftrag inclusive der Auftragsparameter. Der Job JobSchedulerManagedExecutableJob setzt nach der Ausführung einen neuen Auftragsparameter std_out_output, der die Ausgaben des ausgeführten Kommandos (stdout) enthält. Diese Ausgaben soll das Stylesheet zu einer SOAP Antwort transformieren. <xsl:template match="order"> <service_request url=" <content> <soapenv:envelope> <soapenv:body> <xsl:apply-templates "/> </soapenv:body> </content> </service_request> Es wird zunächst ein <service_request> Element erstellt. Dieses benötigt einen Parameter url für die Antwortadresse, da für die asynchrone Antwort eine neue Verbindung aufgebaut werden muss. In diesem Beispiel ist die Antwort URL fest im Stylesheet eingetragen. Diese ist nur dann sinnvoll, wenn die Antwort tatsächlich immer an dieselbe Adresse weitergeleitet werden soll. In der Praxis kommt es jedoch oft vor, dass die Antwortadresse bereits in der Anfrage an den Web Service enthalten ist. In diesem Fall müsste das request_xslt_stylesheet die Antwortadresse in einen Auftragsparameter schreiben, aus dem sie dann vom forward_xslt_stylesheet wieder ausgelesen werden kann. Das Template selektiert den Paramter mit dem Namen "std_out_output" und schreibt den Inhalt in ein neues Element der Antwort:

18 Bereitstellen einer Job-Kette als asynchronen Web Service 18 <xsl:template <sos:stdout> <xsl:value-of </sos:stdout> Dadurch kann der Inhalt der Standard-Ausgabe (stdout) von einer Anwendung weiterverarbeitet werden, die diese Antwort empfängt. Diese muss beachten, dass die Newlines im <sos:stdout> Element tatsächlich als Newlines und nicht als Whitespace zu interpretieren sind. Beispiel: Asynchrone Antwort des Web Service <?xml version="1.0"?> <soapenv:envelope xmlns:soapenv=" <soapenv:body> <sos:stdout xmlns:sos=" config jobs lib logs mail web </sos:stdout> </soapenv:body>

19 Konfiguration eines synchronen Web Service 19 8 Konfiguration eines synchronen Web Service Damit der Job Scheduler den im folgenden Kapitel vorgestellten Job für einen Web Service verwendet, muss dieser zunächst in der Konfigurationsdatei scheduler.xml in einer Job-Kette konfiguriert werden. Wenn noch nicht vorhanden, muss nach dem Element </jobs> ein neues Element <job_chains> eingefügt werden. Innerhalb von <job_chains> wird für jede Job-Kette ein <job_chain> Element erstellt. Für das im nächsten Kapitel vorgestellte Beispiel wird die Job-Kette wie folgt vorausgesetzt: <job_chain name="web_service_test"> <job_chain_node state="1" job="web_service_test_job" next_state="100" error_state="999" /> <job_chain_node state="100"/> <job_chain_node state="999"/> </job_chain> Job-Ketten bestehen oft aus mehreren Jobs, diese Beispiel verwendet eine Job-Kette mit nur einem Job web_service_test_job, der im <jobs> Abschnitt wie folgt konfiguriert wird: <job name = "web_service_test_job" order = "yes"> <script language = "java" java_class = "sos.scheduler.service.webservicetestjob"/> </job> Damit diese Job-Kette als synchroner Web Service verwendet werden kann, wird im <web_services> Element (siehe Konfiguration asynchroner Web Services) ein neuer Web Service angelegt: <web_service name="test" job_chain="web_service_test" url_path="/test"/> Nachdem die Datei scheduler.xml geändert wurde, muss der Job Scheduler neu gestartet werden.

20 Erstellen von Jobs für synchrone Web Services 20 9 Erstellen von Jobs für synchrone Web Services In diesem Kapitel wird gezeigt, wie neue Jobs implementiert werden können, die eine Web Service Anfrage auslesen und eine synchrone Antwort zurückschicken. Die Interpretation möglicher Protokolle (z.b. SOAP) ist Aufgabe des Jobs. Dieser erhält den Inhalt des Requests als String oder binär. Damit das Beispiel einfach bleibt, wird hier kein XML interpretiert, da dadurch der Code länger und komplizierter ausfallen würde. Die Verwendung von DOM ist nicht Gegenstand dieses Tutorials. Der folgende Job gibt daher nur den Inhalt des Requests im Protokoll aus und sendet einen String zurück, der seine Task ID enthält. Beispiel: WebServiceTestJob.java package sos.scheduler.service; import sos.spooler.job_impl; import sos.spooler.order; import sos.spooler.web_service_operation; import sos.spooler.web_service_request; import sos.spooler.web_service_response; public class WebServiceTestJob extends Job_impl { public boolean spooler_process() throws Exception { Order order = spooler_task.order(); Web_service_operation operation; try { operation = order.web_service_operation(); } catch (Exception e){ spooler_log.info("there is no Web Service operation attached to this order"); return true; } // read request Web_service_request request = operation.request(); spooler_log.info("content of Web Service Request:\n"+request.string_content()); // send reply Web_service_response response = operation.response(); } response.set_string_content("task ID: "+spooler_task.id()); response.send(); return true; } Zu Beginn der Job-Implementierung fällt auf, dass der Aufruf web_service_operation() in einem try-catch-block steht. Es kann sein, dass ein Job einen Auftrag zu verarbeiten hat, der in einem vorherigen Lauf des Job Schedulers angelegt aber noch nicht verarbeitet wurde. In diesem Fall würde der Job Scheduler beim Neustart den Auftrag aus der Datenbank laden, nur die HTTP Verbindung des Clients wäre inzwischen beendet. Dadurch gäbe es kein Web_service_operation Objekt mehr. Der Job sollte diesen Fehler abfangen und entscheiden, wie er den Auftrag behandelt. Aus dem Web_service_request Objekt wird der Inhalt der Anfrage gelesen und ins Protokoll geschrieben. Am Web_service_response Objekt wird die Antwort gesetzt und mit send() synchron an den Client zurückgegeben.

21 Erstellen von Jobs für synchrone Web Services 21 In der Praxis muss es nicht der gleiche Job sein, der das Web_service_request liest und die Web_service_response setzt. Es ist z.b. möglich eine Job-Kette zu erstellen, in der der erste Job das Web_service_request Objekt liest, auswertet und einige Parameter aus dem Request in die Payload des Auftrags schreibt. Die folgenden Jobs verarbeiten die Payload des Auftrags und nur der letzte Job schreibt in das Web_service_response Objekt und ruft die send() Methode auf. Im Samples Paket der Job Scheduler Distribution ist dieser Job auch in Javascript, VBScript und Perlscript Versionen im Verzeichnis samples/jobs enthalten unter unter den Dateinamen: web_service_test_job.js web_service_test_job.vbs web_service_test_job.pl In den Beispielkonfigurationsdateien des Samples Pakets werden dazu auch Jobketten und Web Services angelegt.

22 execute_file_request.xslt 22 Anhang A: execute_file_request.xslt <?xml version="1.0" encoding="iso "?> <xsl:stylesheet xmlns:xsl=" xmlns:soapenv=" xmlns:sos=" exclude-result-prefixes="soapenv sos" version="1.0"> <xsl:output method="xml" indent="yes"/> <xsl:template match="/service_request"> <xsl:apply-templates select="content/soapenv:envelope/soapenv:body"/> <xsl:template match="soapenv:body"> <xsl:apply-templates select="*" mode="soapbody"/> <xsl:template match="*" mode="soapbody" priority="0.5"> <!-- SOAP-Fehlermeldung an Web Service generieren --> <service_response> <content> <soapenv:envelope> <soapenv:body> <soapenv:fault> <faultcode>soap-env:client</faultcode> <faultstring>unknown command: <xsl:value-of select="name(.)"/> </faultstring> </soapenv:fault> </soapenv:body> </content> </service_response> <xsl:template match="sos:executefile" mode="soapbody" priority="2"> <add_order job_chain="executable_files"> <xsl:attribute name="web_service"> <xsl:value-of </xsl:attribute> <params> <param name="command"> <xsl:attribute name="value"> <xsl:value-of select="sos:file"/> </xsl:attribute> </param> </params> </add_order> </xsl:stylesheet>

23 execute_file_response.xslt 23 Anhang B: execute_file_response.xslt <?xml version="1.0" encoding="iso "?> <xsl:stylesheet xmlns:xsl=" xmlns:soapenv=" xmlns:sos=" exclude-result-prefixes="soapenv sos" version="1.0"> <xsl:output method="xml" indent="yes"/> <xsl:template match="/spooler/answer"> <service_response> <content> <soapenv:envelope> <soapenv:body> <xsl:apply-templates select="error ok"/> </soapenv:body> </content> </service_response> <xsl:template match="error"> <soapenv:fault> <faultcode>soap-env:client</faultcode> <faultstring><xsl:value-of </soapenv:fault> <xsl:template match="ok[order]" priority="2"> <sos:orderid><xsl:value-of </xsl:stylesheet>

24 execute_file_forward.xslt 24 Anhang C: execute_file_forward.xslt <?xml version="1.0" encoding="iso "?> <xsl:stylesheet xmlns:xsl=" xmlns:soapenv=" xmlns:sos=" exclude-result-prefixes="soapenv sos" version="1.0"> <xsl:output method="xml" indent="yes"/> <xsl:template match="order"> <service_request url=" <content> <soapenv:envelope> <soapenv:body> <xsl:apply-templates ]"/> </soapenv:body> </content> </service_request> <xsl:template <sos:stdout> <xsl:value-of </sos:stdout> </xsl:stylesheet>