Falsche Revision der Seite bei der Generierung

[MMerwar]

Hallo zusammen,

wir haben folgendes Problem:

Für unseren Kunden haben wir ein Modul erstellt, welches mehrere Executables enthält, welche über verschiedene Workflows gestartet werden. Einer dieser Workflows dient zur Freigabe und Weiterleitung eines Datensatzes an eine Suchmaschine.

Wenn dieser Workflow alleine gestartet wird, läuft alles fehlerfrei ab. Wenn nun allerdings der Workflow von einem anderen Benutzer relativ zeitnah (ca. 1 - 2 Sekunden Abstand) ausgeführt wird, erhalten wir einen merkwürdigen Fehler.

Es gibt hierbei folgenden Ablauf:

- Ein User startet den Workflow bei einem Datensatz

- Der Workflow stoßt die Executable des Moduls an

- Das Modul gibt den Datensatz frei und setzt einen Filter bei einer bestimmten Seite. Diese Seite enthält eine Tabellenvorlage und soll die Daten des aktuellen Datensatzes als XML generieren

- Nach dem Setzen des Filters stoßt das Modul einen separaten Deploymentauftrag an, welcher die Seite generiert und an die Suchmaschine weiterleitet

Wenn nun der Workflow zweimal gleichzeitig ausgeführt wird, wird bei dem Deploymentauftrag des als zweiten ausgeführten Workflows die Seite mit dem Filter des ersten Workflows generiert, obwohl von der zeitlichen Abfolge her der zweite Filter verwendet werden sollte. Laut der Versionshistorie wird der Filter korrekt und vor dem Deployment gesetzt.

Beispiel:

- User 1 startet den Workflow bei dem Datensatz 123

- User 2 startet den Workflow bei dem Datensatz 456

- Filter 123 wird gesetzt und das Deployment wird gestartet -> seite_123.xml wurde korrekt generiert

- Filter 456 wird gesetzt und das Deployment wird gestartet -> seite_123.xml wurde generiert anstatt von seite_456.xml

Wir können uns diesen Fehler nicht erklären, denn wenn die Workflows in einem zeitlichen Abstand von ca. > 5 Sekunden ausgeführt werden, taucht dieser Fehler nicht auf.

Vielen Dank im voraus für alle Tipps und Hinweise.

Viele Grüße

Max

[hoebbel]

Hallo Max,

das klingt erst einmal nach einem Timing Problem.

Es gibt hierbei folgenden Ablauf:

- Ein User startet den Workflow bei einem Datensatz

- Der Workflow stoßt die Executable des Moduls an

- Das Modul gibt den Datensatz frei und setzt einen Filter bei einer bestimmten Seite. Diese Seite enthält eine Tabellenvorlage und soll die Daten des aktuellen Datensatzes als XML generieren

- Nach dem Setzen des Filters stoßt das Modul einen separaten Deploymentauftrag an, welcher die Seite generiert und an die Suchmaschine weiterleitet

Hier fehlt mir der Schritt, dass die geänderte Seitenreferenz freigegeben wird. Da es ohne diese Freigabe nicht funktioniert, gehe ich davon aus, dass es die gibt

Kann es sein, dass diese Freigabe auf dem Server aufgeführt wird (also mittels AccessUtil.release(...)?

Wird auf die Freigabe gewartet, bevor der Auftrag gestartet wird? (also auf das ServerActionHandle ein getResult(true) angewendet?

Wenn AccessUtil genutzt wirdm, aber nicht auf das ergebnis gewartet wird, könnte folgendes passieren:

- Freigabe wird aufgerufen

- bevor diese beendet wird, wird der Auftrag gestartet

Könnte es das sein?

Viele Grüsse aus Dortmund,

  Holger

[mbergmann · Accepted solution]

Hallo Max,

mal ein allgemeiner Hinweis: Seit FS 5.0 gibt es die Möglichkeit, an Generierungstasks per API nicht nur die allgemeinen StartNodes (=Seitenreferenzen) zu setzen sondern sog. "EntityStartNodes".

Letztlich kann man damit einzelne Detailseiten generieren ohne die Seitenreferenz jedes Mal "anzufassen".

Damit sollte der in FS4 noch notwendige Umweg über ein Setzen des Filters nicht mehr notwendig sein.

Viele Grüße

Michael

[MMerwar]

Hallo Holger,

danke dir für den Hinweis. Hatte nun eine kurze Wartezeit eingebaut, aber der Fehler tratt auch weiterhin auf. Laut Logfile beträgt der Abstand zwischen der Freigabe und dem Deployment ca. 5 Sekunden, deswegen denke ich, dass die Freigabe schon fertig sein sollte.

Viele Grüße

Max

[MMerwar]

Hallo Michael,

habe das Modul umgestellt, sodass die Seite via EntityStartNodes gesetzt wird. Nun tritt der Fehler nicht mehr auf und finde diese Lösung auch eleganter, da der Workaround mit dem Filter setzen entfällt.

Vielen Dank für den Hinweis, dass es diese Methode gibt. Das hat mir sehr geholfen.

Viele Grüße

Max