Workflow-Bewegung mit Update-Sätzen
Das System verfolgt Workflows in Update-Sätzen anders als andere Datensätze, da Workflow-Informationen in mehreren Tabellen gespeichert werden.
An einer Workflow-Version vorgenommene Änderungen werden dem Update-Satz erst hinzugefügt, wenn Workflow wird veröffentlicht , An dem der gesamte Workflow dem Update-Satz hinzugefügt wird. Update legt die Speicherung von Workflows als einzelnen Workflow-Datensatz [wf_Workflow] fest und behält nur die neueste Version mit dem Update-Typ „Workflow“ bei.
Informationen zu Update-Sätzen finden Sie unter System-Update-Sätze .
Anwendungsfall für Workflow-Update-Satz-Migration – einfach
Erstellen Sie einen neuen Workflow ohne Abhängigkeiten, und migrieren Sie den Workflow dann in einem Update-Satz.
- Anwender A wählt Update-Satz A. aus
- Anwender A erstellt einen neuen Workflow mit dem Namen „Workflow A.“
- Anwender A veröffentlicht Workflow A.
Ein Kundenupdate-Satz-Datensatz wird dem Update-Satz A hinzugefügt, der eine XML-Nutzlast enthält, einschließlich des veröffentlichten Workflows A und aller Aktivitätsabhängigkeiten. Die XML-Nutzlast enthält auch die Workflow-Eingabevariablen, die dem Workflow zugeordnet sind.
- Anwender A schließt Update-Satz A ab und migriert es zur Produktionsinstanz.
- Commits erfolgreich aktualisiert.
- Workflow A funktioniert wie erwartet.
Anwendungsfall für Workflow-Update-Satz-Migration – Subflow-Abhängigkeit (Erfolg)
Bearbeiten und migrieren Sie einen vorhandenen Workflow und seinen abhängigen Subflow erfolgreich.
- Anwender A wählt Update-Satz B. aus
- Anwender A checkt Workflow A. aus
- Anwender A fügt Workflow A einen Subflow namens Workflow B hinzu
Nehmen Sie an, dass Workflow B zuvor veröffentlicht und zur Produktionsinstanz migriert wurde.
- Anwender A veröffentlicht Workflow A.
Dem Update-Satz B wird ein Kundendatensatz hinzugefügt, der eine XML-Nutzlast enthält, einschließlich des veröffentlichten Workflows A und aller Aktivitätsabhängigkeiten. Die XML-Nutzlast enthält auch die Workflow-Eingabevariablen, die dem Workflow zugeordnet sind.
- Anwender A schließt Update-Satz B ab und migriert es zur Produktionsinstanz.
- Commits von Satz B erfolgreich aktualisiert.
- Workflow A funktioniert wie erwartet mit Workflow B als Subflow.
Anwendungsfall für Workflow-Update-Satz-Migration – Subflow-Abhängigkeit (Fehler)
Bearbeiten und migrieren Sie einen vorhandenen Workflow von einer Testinstanz zu einer Produktionsinstanz, die aufgrund eines fehlenden abhängigen Subflows in der Produktionsinstanz nicht ausgeführt werden kann.
- Anwender A wählt Update-Satz C. aus
- Anwender A checkt Workflow A. aus
- Anwender A fügt Workflow A einen Subflow namens Workflow B hinzu
Angenommen, Workflow B wurde zuvor veröffentlicht, wurde jedoch nicht zur Produktionsinstanz migriert.
- Anwender A veröffentlicht Workflow A.
Dem Update-Satz C wird ein Kundendatensatz hinzugefügt, der eine XML-Nutzlast enthält, einschließlich des veröffentlichten Workflows A und aller Aktivitätsabhängigkeiten. Die XML-Nutzlast enthält auch die Workflow-Eingabevariablen, die dem Workflow zugeordnet sind.
Im Update-Satz C ist der Subflow „Workflow B.“ nicht vorhanden. Workflow B wurde vor dem Anwender Eines ausgewählten Update-Satzes C veröffentlicht
- Anwender A schließt Update-Satz C ab und migriert es zur Produktionsinstanz.
- Update-Satz C-Commits mit Warnungen.
- Workflow A wird in der Produktionsinstanz mit den folgenden Ergebnissen aufgerufen:
Workflow A schlägt die Laufzeitvalidierungsprüfung fehl und kann nicht auf dem Produktionssystem ausgeführt werden. Das System fügt dem Workflow-Kontext einen Workflow-Protokolleintrag hinzu, der die Fehlerursache beschreibt, insbesondere das Fehlen eines abhängigen Workflows.
Weitere Informationen zu den Validierungsprüfungen für Workflow-Abhängigkeiten und Update-Sätze finden Sie unter ValidateUpdateSetAbhängigkeiten.
Anwendungsfall für Workflow-Update-Satz-Migration – Subflow-Abhängigkeit (Risiko)
Mehrere Anwender migrieren einen Workflow von einer Testinstanz zu einer Produktionsinstanz ohne ordnungsgemäße Koordination. Dieser Anwendungsfall kann erfolgreich sein, aber nur, wenn jeder Anwender die Abhängigkeiten versteht und die abhängigen Teile des Workflows ordnungsgemäß zur neuen Instanz migriert.
Dieses Beispiel stellt keinen Update-Satz-Fehler dar, obwohl Update-Sätze in diesem Anwendungsfall am häufigsten für die Schuld verantwortlich gemacht werden. Die Validierung erhöht die Transparenz von Workflow-Abhängigkeiten über mehrere Update-Sätze hinweg und bietet Designern bessere Informationen. In den meisten Fällen verhindern die Warnungen keine Aktion, sondern identifizieren nur das Risiko. Der Designer ist dafür verantwortlich, Maßnahmen aufgrund von Ratschlägen in den Validierungsprüfungen zu ergreifen.
- Anwender A wählt Update-Satz C. aus
- Anwender A checkt Workflow A. aus
- Anwender A fügt einen Subflow namens Workflow B hinzu, der ein zurückgibt Anwender-ID .Hinweis:Nehmen Sie an, dass Workflow B zuvor veröffentlicht und zur Produktionsinstanz migriert wurde.
- Anwender A verwendet den Rückgabewert von Workflow B, um Genehmigungen zu generieren.
- Anwender B wählt Update-Satz D. aus
- Anwender B checkt Workflow B aus (der Subflow in Workflow A).
- Anwender B ändert den Rückgabewert des Workflows, indem er von A geändert wird Anwender-ID Bis A Zeichenfolgennachricht .
- Anwender A veröffentlicht Workflow A.Hinweis:In einem Dialogfeld werden Warnungen angezeigt, die Workflow A zugeordnet sind, und Anwender A wird aufgefordert, den Workflow vor der Veröffentlichung zu validieren.
- Anwender A bricht die Veröffentlichung und ab Validiert Workflow A.
- Anwender A wird gewarnt, dass Workflow B von einem Anwender in einem anderen Update-Satz geändert wurde.
- Anwender A ignoriert diese Warnung und veröffentlicht Workflow A.Hinweis:Dem Update-Satz C wird ein Kundendatensatz hinzugefügt, der eine XML-Nutzlast enthält, einschließlich des veröffentlichten Workflows A und aller Aktivitätsabhängigkeiten.die XML-Nutzlast enthält auch die Workflow-Eingabevariablen, die dem Workflow zugeordnet sind.
- Anwender A schließt Update-Satz C ab und migriert es zur Produktionsinstanz.
- Workflow A wird auf der Produktionsinstanz aufgerufen und erfolgreich mit der älteren Version von Workflow B ausgeführt, die sich bereits im System befindet.
- Anwender B veröffentlicht Workflow B.Hinweis:Anwender B wird nicht vor der Abhängigkeit von Update-Satz C gewarnt, da der Update-Satz nicht mehr ausgeführt wird. Anwender B wird jedoch über ein Dialogfeld darüber informiert, dass der Workflow-Version Warnungen zugeordnet sind, und wird angewiesen, Workflow B zu validieren. Wenn Anwender B die Veröffentlichung abbricht und den Workflow validiert, wird Anwender B gewarnt, dass Workflows Workflow B als Subflow verwenden. Wenn der Rückgabewert geändert wurde, sollte Anwender B auch diese Workflows testen. Siehe ValidateUpdateSetAbhängigkeiten Um die Parameter von Update-Satz-Warnungen zu verstehen.
- Anwender B veröffentlicht schließlich Workflow B.Hinweis:Dem Update-Satz D wird ein Kundendatensatz hinzugefügt, der eine XML-Nutzlast enthält, einschließlich des veröffentlichten Workflows B und aller Aktivitätsabhängigkeiten.
- Anwender B schließt Update-Satz D ab und migriert es zur Produktionsinstanz.
- Update-Satz-D-Commits ohne Warnungen.
- Workflow A wird in der Produktionsinstanz aufgerufen und kann nicht erfolgreich ausgeführt werden, da der Rückgabewert von Workflow B keine Anwender-ID mehr generiert.