• Thomas Pollinger
• 30.11.2017
• DE

RQL: Kommandos zum steuern von Prozessen in der async. Warteschlange (ASYNCQUEUE)

Als wir in der Online-Hilfe, des Web Site Management (RedDot CMS) Servers Release 16, bzgl. CleanerJobs für den Delivery Server uns eingelesen haben. Sind wir auf diesen RQL gestoßen, welcher erst mit SP2 in der RQL-Dokumentation nun fast vollständig dokumentiert ist. Es handelt sich um die Steuerung der asynchronen Prozesse wie WebService ;)

---

WICHTIG: Dieser RQL (load/save) steht zwar nun in der offiziellen RQL-Dokumentation. Ist jedoch erst ab Release 16 SP2 vollständig dokumentiert. Es gibt keine Garantie seitens OpenText und dem Support, dass dieser RQL auch mit älteren Versionen genauso funktioniert. Daher bietet es sich an, dass man sich zuvor über den Support bei R&D die Bestätigung einholt, dass der RQL auch für z.B. eine ältere Version 11.2 funktioniert. Man kann zwar mit diesem RQL nicht viel kaputt machen, jedoch empfehle ich immer vorher eine Bestätigung sich einzuholen.

---

List

Request: Auflisten der Aufträge in der Prozess-Warteschlage, damit man z.B. die korrekte GUID für einen einzelnen Auftrag ermitteln kann.

<IODATA loginguid="[!guid_login!]">
  <ADMINISTRATION>
     <ASYNCQUEUE action="list" />
  </ADMINISTRATION>
</IODATA>

Response: Es werden nun alle Aufträge über alle Kategorien zurückgegeben.

<IODATA>
  <PROCESSLIST1>
    <!-- ... -->
    <ASYNCQUEUE guid="[!guid_process!]" nextaction="" now="0" name="Process name" editorialserver="[!guid_server!]" editorialservername="Server name" server="[!guid_server!]" servername="Server name" category="1" active="1" sendstartat="0" automatic="1" status="0" lastexecute="41897,5455752199" lastexecuteuser="" nextexecute="41918,5630449421" nextexecuteuser="" priority="1" user="[!guid_user!]" username="User name" lastexecuteusername="" nextexecuteusername="" project="[!guid_project!]" projectname="Project name" jobguid="[!guid_job!]" />
    <!-- ... -->
  </PROCESSLIST1>
  <PROCESSLIST2>
    <!-- ... -->
    <ASYNCQUEUE guid="[!guid_process!]" nextaction="" now="0" name="Process name" editorialserver="[!guid_server!]" editorialservername="Server name" server="[!guid_server!]" servername="Server name" category="15" active="1" sendstartat="0" automatic="1" status="0" lastexecute="0" lastexecuteuser="" nextexecute="41918,5630450116" nextexecuteuser="" priority="1" user="[!guid_user!]" username="User name" lastexecuteusername="" nextexecuteusername="" project="[!guid_project!]" projectname="Project name" jobguid="[!guid_job!]" />
    <!-- ... -->
  </PROCESSLIST2>
</IODATA> 

 

Load

Request: Hiermit kann man sich einen einzelnen Auftrag (Prozess) laden.

<IODATA loginguid="[!guid_login!]" > 
  <ADMINISTRATION>
    <ASYNCQUEUE action="load" guid="[!guid_prozess!]" />
  </ADMINISTRATION>
</IODATA>

Response: Es wird nun nur der Datensatz zu dem auswählten Auftrag (Prozess) zurückgegeben.

<ADMINISTRATION>   
  <ASYNCQUEUE guid="[!guid_process!]" nextaction="" editorialserver="[!guid_server!]" editorialservername="Server name" name="Process name" server="[!guid_server!]" servername="Server name" category="0" sendstartat="41661,7283166435" automatic="1" active="0" status="0" lastexecute="41731,41775625" lastexecuteuser="" nextexecute="41731,4594212963" nextexecuteuser="" priority="0" user="[!guid_user!]" username="User name" lastexecuteusername="(SYSTEM)" nextexecuteusername="(SYSTEM)" project="[!guid_project!]" projectname="Project name" jobguid="[!guid_job!]" />   
</ADMINISTRATION>

 

Save

Request: Mit diesem Befehl kann man nun die unterschiedlichen Aktionen für einen Auftrag ausführen. In diesem Beispiel das "Starten" des Auftrags.

<IODATA loginguid="[!loginguid!]">
  <ADMINISTRATION>
    <ASYNCQUEUE action="save" guid="[!processguid!]" server="[!guid_server!]" priority="2" nextaction="start"/>
  </ADMINISTRATION>
</IODATA>

---

Hinweis: Dieser RQL ist leider immer noch nicht vollständig in der letzten RQL-Dokumentation (Release 16 SP2) dokumentiert. Der Hinweis, dass man mit "nextaction" die Aufträge steuern kann, wurde mir über den Support mitgeteilt. Es ist aber ein internes Ticket offen, damit die Dokumentation vervollständigt wird.

---

Response: Es werden dann als Ergebnis wieder die aktuellen Daten des Jobs zurückgegeben.

<IODATA>
  <ADMINISTRATION> 
    <ASYNCQUEUE guid="[!guid_process!]" nextaction="" editorialserver="[!guid_server!]" editorialservername="Server name" name="Process name" server="[!guid_server!]" servername="Server name" category="0" sendstartat="41661,7283166435"
        automatic="1" active="0" status="0" lastexecute="41731,41775625" lastexecuteuser="" nextexecute="41731,4594212963" nextexecuteuser="" priority="0" user="[!guid_user!]" username="User name" lastexecuteusername="(SYSTEM) " nextexecuteusername="(SYSTEM)" project="[!guid_project!]" projectname="Project name" jobguid="[!guid_job!]" /> 
  </ADMINISTRATION>
</IODATA>

 

LoadCategories

Request: Mit dieser Anfrage lassen die Kategorien der Aufträge ermitteln.

<IODATA loginguid="[!guid_login!]">
  <ADMINISTRATION>
    <ASYNCQUEUE action="loadcategories"/>
  </ADMINISTRATION>
</IODATA>

Response: Es wird eine Liste aller aktuell gültigen Kategorien für Aufträge zurückgegeben.

<IODATA>
  <ADMINISTRATION>
    <ASYNCQUEUE>
      <JOBTYPE type="0" value="Publication" actionflag="63"/>
      <JOBTYPE type="1" value="Clean up live server" actionflag="32"/>
      <JOBTYPE type="2" value="Escalation procedure" actionflag="39"/>
      <JOBTYPE type="3" value="XML export" actionflag="47"/>
      <JOBTYPE type="4" value="XML import" actionflag="47"/>
      <JOBTYPE type="5" value="Import 3-&gt;4" actionflag="47"/>
      <JOBTYPE type="6" value="Copy project" actionflag="47"/>
      <JOBTYPE type="7" value="Inherit publication package" actionflag="39"/>
      <JOBTYPE type="8" value="Check URLs" actionflag="47"/>
      <JOBTYPE type="9" value="RedDot database backup" actionflag="39"/>
      <JOBTYPE type="10" value="Content class replacement" actionflag="32"/>
      <JOBTYPE type="11" value="Upload media element" actionflag="0"/>
      <JOBTYPE type="12" value="Copy tree segment" actionflag="39"/>
      <JOBTYPE type="13" value="Page forwarding" actionflag="36"/>
      <JOBTYPE type="14" value="Scheduled job" actionflag="39"/>
      <JOBTYPE type="15" value="Publishing queue" actionflag="63"/>
      <JOBTYPE type="16" value="Delete pages via FTP" actionflag="0"/>
      <JOBTYPE type="17" value="FTP transfer" actionflag="16"/>
      <JOBTYPE type="18" value="Export instances" actionflag="63"/>
      <JOBTYPE type="19" value="Start user-defined job" actionflag="1"/>
      <JOBTYPE type="20" value="XCMS project notifications" actionflag="37"/>
      <JOBTYPE type="21" value="Check spelling" actionflag="2"/>
      <JOBTYPE type="22" value="Validate page" actionflag="2"/>
      <JOBTYPE type="23" value="Find and replace" actionflag="33"/>
      <JOBTYPE type="24" value="Project report" actionflag="2"/>
      <JOBTYPE type="25" value="Check references to other projects" actionflag="2"/>
      <JOBTYPE type="26" value="Delete pages via FTP" actionflag="7"/>
    </ASYNCQUEUE>
  </ADMINISTRATION>
</IODATA>

 

CancelAllCurrentProject

Request: Mit diesem neuen RQL (ab Release 16 SP1) kann man für ein Projekt alle Publizierungsaufträge abbrechen.

<IODATA loginguid="[!guid_login!]">
  <ADMINISTRATION>
    <ASYNCQUEUE action="cancelallcurrentproject" />
  </ADMINISTRATION>
</IODATA>

Response: Als Bestätigung bekommt man diese Rückmeldung.

<IODATA></IODATA>

---

Hinweis: Man sollte auf jedenfall aufmerksam und gewissenhaft mit den o.g. RQLs umgehen. Denn jenachdem wie z.B. ein Benutzerdefinierter Auftrag oder Publizierungsauftrag konfiguriert ist, kann es auch mal unschön enden. Vor allem wenn solche Aufträge Daten aufräumen oder erzeugen und man es beim Test nicht möchte ;)

---

Viel Spaß beim ausprobieren und bitte den Hinweis (WICHTIG) von oben beachten!

---

Über den Autor: