Synchrone Anbindung eines domänen spezifischen S3 Storages für Integrationen

[lmoesle]

Kontext

Wenn eine Integration mit dem S3 Storage interagieren muss, dann werden in einem eigenen Prozessschritt zuerst PresignedUrls erzeugt und anschließend an die Integration übergeben.

Hierbei kann in der Prozesskonfiguration eingestellt werden, welche S3 Integration verwendet werden soll:

{
  "key": "MeinProzessKey",
  "statusConfig": [  ],
  "configs": [
    [...]
    {
      "key": "app_file_s3_sync_config",
      "value": "http://my-document-storage-service:8080"
    },
      {
      "key": "app_instance_schema_key",
      "value": "myschemakey"
    },
    [...]
  ]
}

Wenn man jetzt in einer Integration synchron (also ohne PresignedUrls) auf den S3 Storage zugreifen möchte, dann muss die Prozessconfig synchron aus der Engine geladen werden. Hierfür haben wir die digiwf-process-api erweitert (see 8f76fe04fb2c563fea1073193fa2546637e99425).

Problem:

Das Problem hierbei ist, dass die Integration keine Möglichkeit hat an den ProcessDefinitionKey zu kommen und deswegen die Bibliothek nicht nutzen kann. Der Hintergrund hierbei ist, dass die Integration über die CallActivity StreamingTemplateV02 aufgerufen wird und dementsprechend vom digiwf-connector die ProcessInstanceId von der CallActivity übergeben wird. Wir benötigen jedoch die ProcessInstance vom aufrufenden Prozess.

Note: Den Connector können wir mit wenig Aufwand anpassen, dass neben ProcessInstanceId auch ProcessDefinitionKey und ProcessDefinitionId weitergegeben werden. Hier besteht aber dasselbe Problem.

Describe the solution you'd like

Wir können die ProcessDefinitionId bzw. ProcessDefinitionKey (des aufrufenden Prozesses) als Prozessvariablen an die CallActivity (StreamingTemplateV02) weitergeben und im digiwf-connector auslesen und als Kafka Header an die Integration übergeben.

Describe alternatives you've considered

Die Konfigurationen für den domänen spezifischen S3 aus der Prozessconfig könnten wir bei Prozessstart auslesen und als Prozessvariablen global speichern und durch den Prozess schleifen.

• Vorteil: Integration muss nicht noch extra die Prozessconfig laden (1 Rest call weniger)
• Nachteil: Wir müssten das für jede DigiWF Config machen -> In Zukunft könnte das noch mehr Configs betreffen

Acceptane criteria

• [ ] Neuer Header mit Root-ProzessDef-Key digiwf.processdefinition geht über Connector an die Integrationen

[dominikhorn93]

Finde das soweit passend. Eventuell könnten wir uns aber davor über das Thema "Bundle" Gedanken machen und schauen ob wir das schon damit kompatibel umsetzen können. @darenegade was meinst du?

[darenegade]

Ich würde hier gerne nochmal die Alternativen durchgehen. Vielleicht können wir das einfach nach einem Daily mal gemeinsam machen 😊

[darenegade]

Hängt auch mit #468 zusammen (Hier als Alternative Lösung)

[lmoesle]

Das Ticket ist auf impediment, bis wir das Vorgehen geklärt haben

[darenegade]

Abstimmung zur Lösung 15.01.

Fachliche Definition: Es gilt immer die Konfig. vom obersten Prozess. Dieser Key soll an die Integrationen weitergereicht werden, sodass diese damit z.B. Configs nachladen können. Es erfolgt kein Merge oder Überschreiben von Configs auf Sub-Prozessen

[darenegade]

Mögliche Lösung: Der Connector lädt den Key nach

[darenegade]

Hey team! Please add your planning poker estimate with Zenhub @darenegade @dominikhorn93 @lehju @lmoesle @markostreich @simonhir @StephanStrehlerCGI @zambrovski

[lmoesle]

PR ist auch #1168