[Epic] PoC Starter-Webseite für prozessmodellbasierte Fachverfahrensentwicklung [RICE 26]

Epic

Warum

• Die E2E-Digitalisierung erfordert die Umsetzung vernetzter Prozesse in den Fachverfahren und das reibungslose zusammenwirken der Fachverfahren.
• Vernetzte Prozesse werden am besten in BPMN beschrieben.
• Fachverfahren mit integrierter Workflow Engine wären der beste Ansatz für die Umsetzung einer Rolle (Pool) innerhalb eines Prozessmodells.
• Die gesetzeskonforme Implementierung eines Pools erfordert in erster Linie, dass das Fachverfahren alle im betreffenden Pool eingehenden Nachrichtenflüsse empfangen und alle ausgehenden Nachrichtenflüsse senden kann (beides mit FIT-Connect).

Ziel

Als Entwickler eines Fachverfahren, insbes. eines mit integrierter Workflow Engine, möchte ich bei der Implementierung auf BPMN Prozessmodellen basierender vernetzter Verwaltungsprozesse bestmöglich unterstützt werden.

In diesem PoC soll gezeigt werden, wie schon eine einfache Webseite Entwickler unterstützen kann, indem sie zu den Pools aus einem festgelegten Prozessmodell das Projektgerüst generiert und dabei die alle relevanten Nachrichtenflüsse berücksichtigt.

Links, Hinweise, Bemerkungen

Prozessmodell für den PoC: diagram_abstrakter_demoprozess_v2.bpmn

SPP-PU verwendet ein Camunda-Framework, um Prozessmodelle anzuzeigen und darin Elemente auswählbar anzubieten. Das könnte auch für den PoC verwendet werden.

Stories

Akzeptanzkriterien

1. Es gibt eine lokal laufende Webseite mit Java-Backend.
2. In de Webseite wird die gewünschte Programmiersprache (Java-Spring oder C#) und ein Pool aus dem Demo-Prozessmodell ausgewählt.
3. Für Receive-Tasks wird ausgewählt, ob man Callback und/oder Polling verwenden will und für jeden Messageflow ein Fachdatenschema (URL zu einen JSON-Schema) eingegeben. Die Schemata liegen vorerst im FIT-Connect-Schema-Repo (https://schema.fitko.de/fit-connect/).
4. Die Webseite generiert daraufhin das Projektgerüst für ein Fachverfahren das diesen Pool übernehmen soll.
5. Es wird eine Klasse/Methode zum Anlegen des Zustellpunktes generiert, die die empfangenden Nachrichtenflüsse und die Fachdatenschemata konfiguriert.
6. Darin enthalten sind Gerüste (Interfaces) für alle Tasks aus diesem Pool insbes. die Send- und Receive-Tasks zu den Nachrichtenflüssen, die dieser Pool sendet oder empfängt.
7. Bei den Send- und Receive-Tasks ist das jeweilige SDKs integriert.
8. In Abstimmung mit dem SDK-Team wurden SDK-Versionen (Java & C#) für die Prozessunterstützung erstellt.
9. Send-Tasks beinhalten das Generieren des Fachdatensatzes und die Schema-Validierung
10. Receive-Tasks beinhalten die Schema-Validierung
11. Ebenfalls enthalten sind Tests, die sicherstellen, das die Tasks für alle Nachrichtenflüsse implementiert sind.
12. Das Projektgerüst kann als ZIP heruntergeladen und mit der der gewünschten IDE geöffnet werden.
13. Definition of Done wurde überprüft.

Mögliche Folgeaktivitäten

Offene Fragen

Pitch

Outcome:

Auf welches strategische Ziel zahlt das Feature ein? Was ändert sich, wenn das Feature verfügbar ist?

Förderung der Implementierung der E2E-Digitalisierung auf der Basis von Prozessmodellen, indem die Entwicklung von Fachverfahren (Onlinedienste & Verwaltungssysteme) vereinfacht wird. Es soll Entwicklern möglichst leicht gemacht, die durch ein Prozessmodell beschriebene Kollaboration standardgemäß zu implementieren.

Zielgruppe:

Wer profitiert von diesem Feature?

• Entwickler von Fachverfahren (Onlinedienste & Verwaltungssysteme), die eine Workflowengine verwenden.

Opportunity:

Welches Problem lösen wir bei unserer Zielgruppe?

• E2E-Digitalisierung geht über Antrag hinaus (Prozessunterstützung basierend auf Prozessmodellen)
• Standardisierte Prozessmodelle in einem Repo erklären, wie Akteure kolaborieren
• Die Annahme, dass im Wesentlichen die SDKs die Kolaboration unterstützen trifft nicht zu. Das Entwickeln der Logik passiert früher.
• Entwickler stehen also vor der schweren Aufgabe, eine große Zahl von Prozessen samt Kolaboration zu implementieren. Je standardisierter und einfacher das umgesetzt werden kann, desto weniger Aufwand entsteht für sie.

Kurzbeschreibung:

• (lokal laufende) Webseite mit Java-Backend
• Die Webseite generiert daraufhin das Projektgerüst für ein Fachverfahren für diese Rolle (Java oder C#).
  • Darin enthalten sind Gerüste (Interfaces) für alle Tasks aus diesem Pool insbes. die Send- und Receive-Tasks zu den Nachrichtenflüssen, die diese Rolle sendet oder empfängt.
  • Bei den Send- und Receive-Tasks ist das jeweilige SDKs integriert.
  • Send-Tasks beinhalten das Generieren des Fachdatensatzes und die Schema-Validierung
  • Receive-Tasks beinhalten die Schema-Validierung
  • Ebenfalls enthalten sind Tests, die sicherstellen, das die Tasks für alle Nachrichtenflüsse implementiert sind
• Dort kann man aus einem fest vorgegebenen Prozessmodell eine Rolle (Pool/Participant) und die gewünschte Programmiersprache auswählen.
• Das Projektgerüst kann als ZIP heruntergeladen und mit der der gewünschten IDE geöffnet werden.

Was ist sonst noch wichtig zu wissen?

Entscheidungen:

Gibt es Entscheidungen, die jetzt schon getroffen werden sollten? Sind Beschaffungen notwendig?

(Externe) Deadline:

Gibt es externe Deadlines die berücksichtigt werden müssen?

Prioritätsbewertung:

Wie gewichten wir die RICE Faktoren auf einer Skala von 1 bis 10?

Reach: 5,5

Impact: 5,3

Effort: 4,9

Confidence: 5

RICE-Gesamtscore: 26

Vorbereitung Epic Refinement

• Wer kümmert sich darum, dass ein Epic "refinement ready" gemacht wird?
• Welche Teams werden perspektivisch am Feature arbeiten? Welche Devs aus den Teams sollten jetzt schon eingebunden werden?
• Bei welchem Epic Refinement kann dieses Feature voraussichtlich besprochen werden?

Persona

Name und Rolle:

User Story:

Jobs

Pains

Gains

Epic Ausarbeitung

Warum

Ziel

Links, Hinweise, Bemerkungen

Ideensammlung bzgl. der Features

Click to expand

Plugin - Bsp. IntelliJ-Plugin (Auswahl der IDEs muss geklärt weden) bietet Wizard an:

• Neue Projekt anlegen mit Typ Government-E2E-Prozess
• Auswahl Leistung
• Auswahl Prozess
• Auswahl Rolle(n)
• Prozessmodell wird geladen
• Auswahl Workflowengine (Übertragung von Objekten zwischen Workflowengines wird von den Engines nur begrenzt unterstützt)
• Packagestruktur wird angelegt
• Service & User-Tasks - (Standard-)Klassen (besser Interfaces) werden bereitgestellt, bei Camunda 8 wird die Engine z.B. per REST-API angesprochen (Job-Worker Pattern)
• Send- und Receive-Tasks sind vorgeneriert (ggf. mit Integration der SDKs), samt Generierung des Fachdatensatzes und der Schema-Validierung (Interface erzwingt das)
• Alternativ/zusätzlich FIT-Connect-Connector für die Send- & Receive-Tasks bei (cloudbasierte) Workflowengines
• Alternativ/zusätzlich workflowengine- bzw. sprachspezifische Bausteine z.B. für Receive-Tasks (Polling)
• Alle anderen Tasks sind Teil der Fachlichkeit und werden nicht spezifisch generiert
• Klare Sichtbarkeit, wo eigener Code geschrieben werden muss
• Bevorzugt werden Boardmittel der IDE werden genutzt
• Ist KI eine Alternative zum Plugin?
• Unterstützung nicht nur beim Erstellen eines neuen Softwareprojekts, sondern auch bei der Erweiterung (= Hinzufügen der Send- & Receive-Tasks) eines bestehenden? Könnte einfach das Hinzufügen eines neuen Ordners mit Interfaces / Klassen für die S&R-Tasks sein
• Unterstützung bei Updates zu FIT-Connect-Major-Releases
• Generierung von Tests, insbes. samt Simulation anderer Akteure (Participants) im Prozessmodell -> in Richtung UnitTests gibt es bereits einige Tools.
• Monitoring der REST-Calls gegenüber der Engine
• Test der Steuerung des Prozesses auf Basis von Entscheidungen aufgrund von Variablen
• Update des Prozesmodells: eindeutige konstante IDs sollen Erleichterung bringen (Anforderung an das Prozessmodell)
• Sicher stellen, dass Nachrichtenfluss implementiert wird/ist -> Interface muss implementiert sein & generierte Test prüfen das.

Zu klären:

• Verwenden alle Engines (insbes. die Open Source Forks) das Steuerungs-Pattern Job-Worker (Camunda 7 / 8)?
• Welche IDE verwenden die meisten Fachverfahrenshersteller?
• Welche Sprachen verwenden die meisten Fachverfahrenshersteller? -> Pragmatisch aufgrund der SDKs Java, C#, Kotlin?
• Bieten Workflowengine-Hersteller bereits Plugins an, sodass wir uns dort integrieren könnten/müssten?

Notizen zur Aufnahme beim Opem Space:

Click to expand

- E2E-Digitalisierung - Prozessunterstützung basierend auf Prozessmodellen - Standardisierte Prozessmodelle in einem Repo - Prozessmodell erklärt, wie die Akteure kolaborieren - Die Annahme, dass im Wesentlichen die SDKs die Kolaboration unterstützen trifft nicht zu. Das Entwickeln der Logik passiert früher. - Wir leisten durch Bereitstellung von Pugins für IDEs eine Unterstützung bei der Entwicklung von Fachverfahren (Onlinedienste & Verwaltungssysteme). - Es soll Entwicklern möglichst leicht gemacht werden, die durch ein Prozessmodell beschriebene Kolaboration standardgemäß zu implementieren. - Wizard des Plugins - Bsp. IntelliJ-Plugin (Auswahl der IDEs muss geklärt weden): - Neue Projekt anlegen mit Typ Government-E2E-Prozess - Auswahl Leistung - Auswahl Prozess - Auswahl Rolle - Prozessmodell wird geladen - Auswahl Workflowengine (Übertragung von Objekten zwischen Workflowengines wird von den Engines nur begrenzt unterstützt) - Packagestruktur wird angelegt - Service & User-Tasks - (Standard-)Klassen (besser Interfaces) werden bereitgestellt, bei Camunda 8 wird die Engine z.B. per REST-API angesprochen - Send- und Receive-Tasks sind vorgeneriert - Alle anderen Tasks sind Teil der Fachlichkeit und werden nicht spezifisch generiert - Klare Sichtbarkeit, wo eigener Code geschrieben werden muss - Ist KI eine Alternative zum Plugin? - Unterstützung nicht nur beim Erstellen eines neuen Softwareprojekts, sondern auch bei der Erweiterung (= Hinzufügen der Send- & Receive-Tasks) eines bestehenden? Könnte einfach das Hinzufügen eines neuen Ordners mit Interfaces / Klassen für die S&R-Tasks sein - Unterstützung bei Updates zu FIT-Connect-Major-Releases - Generierung von Tests, insbes. samt Simulation anderer Akteure im Prozess - Test der Steuerung des Prozesses auf Basis von Entscheidungen aufgrund von Variablen