Streaming verwenden

HTTP-Requests, die an das Streaming-Interface einer der CMS-Applikationen gerichtet sind, müssen eine der HTTP-Methoden POST und GET verwenden. Ein Request, der mit einer anderen als diesen beiden Methoden ausgeführt wird, wird mit einer HTTP-Response quittiert, die den HTTP-Fehler-Code 405 (Method not allowed) enthält.

Uploads

Daten werden mit einem POST-Request zur URL /stream zu einer CMS-Applikation übertragen. Beim Upload muss der Body des HTTP-POST-Requests die zu übertragenden Daten enthalten. Keep-Alive wird unterstützt.

Die Applikation legt die erhaltenen Daten im Dateisystem ab und erzeugt ein Ticket, dessen ID er an den Client zurückgibt. Die HTTP-Antwort auf den Upload-Request enthält im Body also lediglich die Ticket-ID. Diese Antwort enthält den HTTP-Fehler-Code 200 (OK). Tritt dagegen ein Fehler auf, so enthält die HTTP-Response keine Ticket-ID, und der zurückgegebene HTTP-Fehler-Code ist 500 (Internal Server Error).

Downloads

Alle Downloads über das Streaming-Interface sind HTTP-GET-Requests unter Angabe der Ticket-ID. Die URL ist also dem folgenden Beispiel entsprechend aufgebaut (geben Sie anstelle von mein.cmsserver Ihren CMS-Hostnamen an):

http://mein.cmsserver/stream/6528721

Im obigen Beispiel ist 6528721 die Ticket-ID, die beispielsweise in einem CRUL-Request angefordert und in der Antwort darauf zurück gegeben wurde:

<cm-request ...>
  <obj-where>
    <id>37634</id>
  </obj-where>
  <obj-get>
    <blob encoding="stream"/>
  </obj-get>
</cm-request>

<cm-response ...>
  <cm-code numeric="0" phrase="ok">
    <obj>
      <blob encoding="stream">78239162</blob>
    </obj>
  </cm-code>
</cm-response>

Nun lässt sich mit einem GET-Request zum Streaming-Interface des Content Management Servers der Blob abholen:

http://mein.cm/stream/78239162

Wird in der Download-URL keine Ticket-ID angegeben, ein Ticket mit der angegebenen ID nicht gefunden oder ein bereits ungültiges Ticket referenziert, so enthält die HTTP-Antwort den HTTP-Fehler-Code 404 (Not found). Ist das Ticket jedoch gültig, so enthält die HTTP-Response den HTTP-Fehler-Code 200 (OK), und im Body befinden sich die unter dem Ticket hinterlegten Daten. Keep-Alive wird auch hier unterstützt.

Die Ausgabe zusätzlicher Befehle abholen

Zusätzliche Befehle (custom commands) können nur vom Content Management Server ausgeführt werden. Möchte man die Ausgabe eines solchen zusätzlichen Befehls mittels Streaming abholen, so sendet man wie beim Download von Daten einen GET-Request zum Server und gibt in der URL die Ticket-ID an. Diese ID erhält man, wenn man den zusätzlichen Befehl ausführt. Auch in Bezug auf die Fehlerbehandlung bei ungültigen oder fehlenden Ticket-IDs verhält sich der Content Management Server wie beim Download.

Ist das Ticket gültig, so enthält die HTTP-Response den HTTP-Fehler-Code 200 (OK), und im Body befindet sich die Ausgabe des zum Ticket gehörenden zusätzlichen Befehls. Keep-Alive wird bei solchen Requests nicht unterstützt.

Wird die Ausgabe eines zusätzlichen Befehls in eine Webseite integriert (wie es beim GUI des Content Managers, dem Content Navigator, der Fall ist), so kann diese bei Bedarf so geschrieben werden, dass sie die Anzeige regelmäßig aktualisiert. Der Betrachter der Seite wird dadurch über den Ausführungsfortschritt des zusätzlichen Befehls auf dem Laufenden gehalten.

Um eine Seite alle 15 Sekunden zu aktualisieren, verwenden Sie ein Meta-Tag entsprechend dem folgenden Beispiel:

<meta http-equiv="Refresh" content="15; url=http://my.cm/stream/7891528">