Workflow-Bewegung mit Aktualisierungssätzen

Das System verfolgt Workflows in Aktualisierungssätzen anders als andere Datensätze, da Workflow-Informationen in mehreren Tabellen gespeichert werden.

Änderungen, die an einer Workflow-Version vorgenommen wurden, werden erst im Aktualisierungssatz hinzugefügt, wenn der Workflow veröffentlicht ist - an diesem Punkt wird der gesamte Workflow zum Aktualisierungssatz hinzugefügt. Aktualisierungssätze speichern Workflows als einen einzigen Workflow-Datensatz [wf_workflow] und behalten nur die neueste Version mit dem Aktualisierungstyp des Workflows bei.

Informationen zu Update-Sätzen finden Sie unter System-Update-Sätze.

Migrationsanwendungsfall für Workflow-Aktualisierungssätze - einfach

Erstellen Sie einen neuen Workflow ohne Abhängigkeiten und migrieren Sie dann den Workflow in einem Aktualisierungssatz.

1. Benutzer A wählt Aktualisierungssatz A aus.
2. Benutzer A erstellt einen neuen Workflow namens Workflow A.
3. Benutzer A veröffentlicht Workflow A.

   Zu Aktualisierungssatz A wird ein Datensatz für einen Kunden-Aktualisierungssatz hinzugefügt, der eine XML-Nutzlast enthält, einschließlich des veröffentlichten Workflow A und aller Aktivitätsabhängigkeiten. Die XML-Nutzlast enthält auch die Workflow-Eingabevariablen, die dem Workflow zugeordnet sind.

4. Benutzer A schließt den Aktualisierungssatz A ab und migriert ihn zur Produktionsinstanz.
5. Aktualisierungssatz A wird erfolgreich übernommen.
6. Workflow A funktioniert wie erwartet.

Migrationsanwendungsfall für Workflow-Aktualisierungssatz - Unterflussabhängigkeit (Erfolg)

Bearbeiten und migrieren Sie erfolgreich einen vorhandenen Workflow und seinen abhängigen Unterfluss.

1. Benutzer A wählt Aktualisierungssatz B.
2. Benutzer A checkt Workflow A aus.
3. Anwender A fügt einen Subflow namens Workflow B zu Workflow A hinzu.

   Angenommen, Workflow B wurde zuvor veröffentlicht und zur Produktionsinstanz migriert.

4. Benutzer A veröffentlicht Workflow A.

   Ein Datensatz für einen Kunden-Aktualisierungssatz wird zu Aktualisierungssatz B hinzugefügt, der eine XML-Nutzlast enthält, einschließlich des veröffentlichten Workflow A und aller Aktivitätsabhängigkeiten. Die XML-Nutzlast enthält auch die Workflow-Eingabevariablen, die dem Workflow zugeordnet sind.

5. Benutzer A schließt den Aktualisierungssatz B ab und migriert ihn zur Produktionsinstanz.
6. Die Aktualisierung von Set B wurde erfolgreich ausgeführt.
7. Workflow A arbeitet erwartungsgemäß mit Workflow B als Subflow.

Migrationsanwendungsfall für Workflow-Aktualisierungsatz – Subflow-Abhängigkeit (Fehler)

Bearbeiten Sie einen vorhandenen Workflow und migrieren Sie ihn von einer Testinstanz zu einer Produktionsinstanz, die aufgrund eines fehlenden abhängigen Subflows nicht auf der Produktionsinstanz ausgeführt werden kann.

1. Benutzer A wählt Aktualisierungssatz C.
2. Benutzer A checkt Workflow A aus.
3. Anwender A fügt einen Subflow namens Workflow B zu Workflow A hinzu.

   Angenommen, Workflow B wurde zuvor veröffentlicht, wurde jedoch nicht zur Produktionsinstanz migriert.

4. Benutzer A veröffentlicht Workflow A.

   Ein Datensatz für einen Kunden-Aktualisierungssatz wird dem Aktualisierungssatz C hinzugefügt, der eine XML-Nutzlast enthält, einschließlich des veröffentlichten Workflow A und aller Aktivitätsabhängigkeiten. Die XML-Nutzlast enthält auch die Workflow-Eingabevariablen, die dem Workflow zugeordnet sind.

   In Aktualisierungssatz C fehlt der Subflow Workflow B. Workflow B wurde veröffentlicht, bevor Benutzer A den Aktualisierungssatz C ausgewählt hat.

5. Benutzer A schließt Aktualisierungssatz C ab und migriert ihn zur Produktionsinstanz.
6. Aktualisierungssatz C schreibt sich mit Warnungen fest.
7. Workflow A wird in der Produktionsinstanz mit den folgenden Ergebnissen aufgerufen:

   Bei Workflow A schlägt die Laufzeitüberprüfung fehl und der Workflow wird nicht auf dem Produktionssystem ausgeführt. Das System fügt dem Workflow-Kontext einen Workflow-Protokolleintrag hinzu, der die Fehlerursache detailliert aufführt, insbesondere das Fehlen eines abhängigen Workflows.

   Weitere Informationen zu den Validierungsprüfungen von Workflowabhängigkeiten und Aktualisierungssätzen finden Sie unter ValidateUpdateSetDependencies .

Migrationsanwendungsfall für Workflow-Aktualisierungsatz – Subflow-Abhängigkeit (Risiko)

Mehrere Benutzer migrieren einen Workflow von einer Testinstanz zu einer Produktionsinstanz ohne ordnungsgemäße Koordination. Dieser Anwendungsfall kann erfolgreich sein, jedoch nur, wenn jeder Benutzer die Abhängigkeiten versteht und die abhängigen Teile des Workflows ordnungsgemäß auf die neue Instanz migriert.

Dieses Beispiel stellt keinen Fehler eines Aktualisierungssatzes dar, obwohl Aktualisierungssätze in diesem Anwendungsfall meistens dafür verantwortlich gemacht werden. Durch die Überprüfung wird die Sichtbarkeit von Workflow-Abhängigkeiten in mehreren Aktualisierungssätzen erhöht und die Entwickler erhalten bessere Informationen. In den meisten Fällen verhindern die Warnungen keine Aktion, sondern identifizieren nur das Risiko. Der Konstrukteur ist dafür verantwortlich, auf Empfehlung bei den Validierungsprüfungen vorzugehen.

1. Benutzer A wählt Aktualisierungssatz C.
2. Benutzer A checkt Workflow A aus.
3. Benutzer A fügt einen Subflow namens Workflow B hinzu, der eine Benutzer-ID ausgibt.
   Hinweis:

   Angenommen, Workflow B wurde zuvor veröffentlicht und zur Produktionsinstanz migriert.
4. Benutzer A verwendet den Ausgabewert von Workflow B, um Genehmigungen zu generieren.
5. Benutzer B wählt Aktualisierungssatz D.
6. Benutzer B checkt Workflow B aus (den Subflow in Workflow A).
7. Benutzer B ändert den Ausgabewert des Workflows, indem er den Wert von einer Benutzer-ID in eine String-Nachricht ändert.
8. Benutzer A veröffentlicht Workflow A.
   Hinweis:

   In einem Dialogfeld werden mit Workflow A verknüpfte Warnungen angezeigt, und Benutzer A wird aufgefordert, den Workflow vor der Veröffentlichung zu überprüfen.
9. Benutzer A bricht die Veröffentlichung ab und bestätigt Workflow A.
10. Benutzer A wird gewarnt, dass Workflow B von einem Benutzer in einem anderen Aktualisierungssatz geändert wurde.
11. Benutzer A ignoriert diese Warnung und veröffentlicht Workflow A.
    Hinweis:

    Ein Datensatz für einen Kunden-Aktualisierungssatz wird dem Aktualisierungssatz C 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.
12. Benutzer A schließt Aktualisierungssatz C ab und migriert ihn zur Produktionsinstanz.
13. Workflow A wird in der Produktionsinstanz aufgerufen und läuft erfolgreich mit der älteren Version von Workflow B, die bereits im System vorhanden ist.
14. Benutzer B veröffentlicht Workflow B.
    Hinweis:

    Benutzer B wird nicht vor der Abhängigkeit des Aktualisierungssatzes C gewarnt, da der Aktualisierungssatz nicht mehr ausgeführt wird. Benutzer B wird jedoch über ein Dialogfeld informiert, dass mit der Workflowversion Warnungen verbunden sind, und er wird angewiesen, Workflow B zu validieren. Wenn Benutzer B die Veröffentlichung abbricht und den Workflow validiert, wird Benutzer B gewarnt, dass es Workflows gibt, die Workflow B als Subflow verwenden. Da der Ausgabewert geändert wurde, sollte Benutzer B diese Workflows ebenfalls testen. Siehe ValidateUpdateSetDependencies, um die Parameter der Aktualisierungssatz-Warnungen zu verstehen.
15. Benutzer B veröffentlicht schließlich Workflow B.
    Hinweis:

    Ein Datensatz für einen Kunden-Aktualisierungssatz wird zu Aktualisierungssatz D hinzugefügt, der eine XML-Nutzlast enthält, einschließlich des veröffentlichten Workflow B und aller Aktivitätsabhängigkeiten.
16. Benutzer B schließt Aktualisierungssatz D ab und migriert ihn zur Produktionsinstanz.
17. Aktualisierungssatz D wird ohne Warnungen festgeschrieben.
18. Workflow A wird in der Produktionsinstanz aufgerufen und kann nicht erfolgreich ausgeführt werden, da der Ausgabewert von Workflow B keine Benutzer-ID mehr generiert.