Workflows

Die ursprüngliche Idee von Geschäftsprozesskomponenten war, grobgranular die Schritte des Geschäftsprozesses in Workflows zu modellieren und zu implementieren. Hierbei war die grundlegende Idee, dass jeder Schritt des Geschäftsprozesses genau einen Service (im Standard einen ActivityService) aufruft. Die Konsequenz hieraus ist, dass diese Services lange Laufzeiten hatten und zu viel Logik besaßen. Somit lief der Service-Client (BusinessEventDispatcher, BED bei der Implementierung von Request-Reply, siehe Resilienz bei Workflows) in ein Timeout.

Entsprechend wurden die Schritte im Workflow und somit die Service-Aufrufe gesplittet, was wiederum dazu führte, dass Workflow zu groß wurden und ebenfalls geteilt wurden. In Summe sind die grobgranularen Schritte verloren gegangen und die Hierarchisierung und das ursprüngliche Ziel somit nicht erreicht.

Durch die getroffene und hier dokumentierte Entscheidung, Workflows in Ländern zu erlauben, kann der grobe Ablauf in den GP-Komponenten verbleiben und entsteht eine Hierarchisierung entstehen.

Der Schnitt von GP-Komponenten entwickelte sich anhand von Fachlichkeit und Team-Verantwortlichkeit damals zu einer 1:1 Beziehung von GP-Komponente zu Land. Der logische Schluss war, diese feingranularen Workflows in den Ländern / Provinzen zu implementieren, da sehr viel Detailwissen notwendig ist, der Sprachgebrauch identisch ist und die Fachlichkeit sich sehr stark überschneidet. Es ergibt sich somit eine einfachere und schnellere Implementierung durch Implementierung von Workflows in den Ländern, da hierdurch einfacher Cross-funktional entwickeln werden kann.

Entsprechend können Workflows, die in Ländern / Provinzen implementiert sind, durch GP-Komponenten aufgerufen werden. Dies ist in nachfolgender Abbildung dargestellt:

Der Aufruf von Workflows muss wie üblich dabei über die öffentliche Schnittstelle (Published Language) erfolgen!

Die Workflows rufen wiederum nur Services über ihre öffentliche Schnittstelle, da auch hier ein Customizing möglich sein muss.

Details zur Implementierung findest zu in Workflows.

Regeln

• Workflows rufen nur Services auf. Interne Logik darf nicht per Library angebunden werden.
  • Workflows dürfen also zu den anderen Projekten keine Abhängigkeit haben. Die Kopplung darf nur über Services erfolgen.
• Workflows in Ländern / Provinzen dürfen schreibende Services nur des eigenen Landes / der eigenen Provinz (außer Services der Plattform) auf.
  • Workflows in Ländern / Provinzen beziehen sich als nur auf die Funktionalität des eigenen Bounded Contexts.
  • Lesende Services dürfen auch von anderen Ländern / Provinzen aufgerufen werden.
• Der Aufruf von Services aus Workflows heraus muss über die jeweilige Published Language erfolgen.
• Workflows stellen eine Form der Implementierung von ProcessServices dar.
• Die Modellierung von ProcessServices im "logischen" kanonischen Modell erfolgt in dem entsprechenden Land-/Provinz-Namensraum.
• Ein Land / eine Provinz hat - falls es Workflows implemenetiert - ein weiteres DB-Schema für die als MassTransit-Code implementierten Workflows.

Es ist wichtig, die Granularität der Workflows in den Ländern zu beachten: In Ländern sollen keinen transkontinentalen Geschäftsprozesse entwickelt werden, sondern "asynchrone ActivityServices". Daher wird sehr darauf zu achten sein, die Kopplung der Ländern untereinander nicht zu erhöhen!

Diese asynchronen Services müssen - falls notwendig - eine Antwort per Event propagieren.