Services in GP-Komponenten

Die Implementierung von Services in Geschäftsprozesskomponenten erfolgt ähnlich zu der in Ländern. Im Standard hingegen persistieren diese nicht, sondern orchestrieren lesende Services zu übergeordneten Query Services.

Dies ist allerdings nur in ausgewählten Szenarien akzeptabel, da synchrone Serviceaufrufketten insbesondere bzgl. möglicher Timeouts problematisch sind. Schreibende synchrone Aufrufketten sind nicht erlaubt, da so etwas wie ein Transaktions-Manager benötigt wird, was wiederum Workflows in GP-Komponenten darstellen.

Diese orchestrierenden lesenden Query Services bestehen entsprechend im Wesentlichen aus Gateways und dahinter liegenden Assemblern. Die Gateways lesen die Daten der Zielservices und mappen diese auf die Contracts des Services. Sie besitzen daher keine weitergehende Logik.

Erweiterte Szenarien: Services mit Persistenz

In einigen Fällen werden allerdings auch Services mit Persistenz benötigt, um

• unvollständige Daten zwischenzuspeichern
• einen Status für den Gesamtprozess abzubilden
• ein spezifisches Monitoring zu erhalten.

Wenn Services eine Persistenz nutzen, dann wird dasselbe Datenbank-Schema wie für die Workflows verwendet. Die Strukturierung erfolgt dann analog zu Ländern, wobei die Domäne die des Prozesses ist, also beispielsweise der Prozessstatus oder die vorläufigen Daten, die aufgefüllt und an die Ziel-Komponenten übergeben werden.

Ein Beispiel hierzu ist die Aufbereitung von Reports wie in CQRS beschrieben.

Subscriber-Implementierungen als Reaktion auf Ereignisse sind möglich, aber in der GP-Komponente als normale Service-Implementierung sehr selten. Im Standard besitzen meist die Workflows eine Subscriber-Schnittstelle, um auf Ereignisse zu reagieren. Wird dennoch ein einfacher Subscriber als Service implementiert, so gilt dasselbe wie für Services anderer Kategorien in der GP-Komponente. Die Implementierung erfolgt analog zu denen in Ländern.