Default Kafka topics for all integrations

[simonhir]

Currently the element templates for cosys, dms and other integrations require to add the Kafka topic for outgoing messages. As these are different for all environments (topic suffix) this requires the process developers to define different configs for all envs and also they need to know what exact topic is the correct one for each of the integrations.

Goal

Business analysts should not know anything about the technical integration, but should rather select the business use case.

Describe solution

• Various solutions
  • Variant 1: (Wird umgesetzt)
    • Introduction of a new header "app_integration_name"
    • Connector sets the correct topic based on Config
    • For #874 and #734 it would be a good idea to also add a header for the starting process key
      • After first discussion ( @simonhir , @darenegade ) -> use root-definition-key (could be more then 2 "layers")
    • Validate if digiwf.messagename is still needed or type is enough
  • Variant 2:
    • Extension of the StreamingTemplate with DMN, which maps to topics using a variable from the element template

Migrations path

1. provide new element template and motivate process designers to switch over
2. if necessary, coordinate process migration for long-running process instances
3. after a certain period of time, e.g. 1 month, switch to the new Kafka in the maintenance window

Acceptance criteria

• [ ] The topic input in the element template is optional and if not set the default topic for the correlating env is used
• [ ] The topics can be renamed with no effect on processes using only the default topics (needed for switch to new Kafka cluster)
• [ ] DigiWF-Ops configured

[darenegade]

@dominikhorn93 @lmoesle Habt ihr eine Idee, wie man das gut lösen kann?

[lmoesle]

Wir könnten auch die DIGIWF_ENV Property auslesen und bei Prozessstart als Prozessvariable setzen. Dann könnten wir in den Element Templates ein default Topic angeben (dwf-email-${digiwf-env}). Der Vorteil wäre, dass die Prozessentwickler die Topics nicht mehr selbst setzen müssen und die Variable bei Bedarf auch für andere Funktionen nutzen könnten.

Wenn man das so machen würde, dann müsste man:

• Die DIGIWF_ENV Property auslesen und beim Prozessstart als Prozessvariable setzen
• Die Element Templates aller Integrationen anpassen, dass ein default Topic gesetzt wird

[simonhir]

@lmoesle das Problem ist dann aber, dass wir damit die Topics nicht mehr einfach ändern können, weil ja dann jeder neu das Template auswählen müsste. Für den Schwenk auf das neue Cluster brauchen wir das aber. Hab das gerade mal noch als Akzeptanz-Kriterium hinzugefügt hatte davor gefehlt.

[lmoesle]

Ein Feature unserer Platform ist es ja auch, dass jeder Prozessentwickler seine eigenen Integrationen anbinden kann. Dafür muss nur das Streaming Template mit dem richtigen Kafka Topic und Message Body aufgerufen.

@simonhir Die Variante 2 würde ich da dann eher nicht machen und Variante 1 bevorzugen. In diesem Schritt könnte man dann gleich den app_integration_name an die spring.cloud.function.definition der jeweiligen Integration anpassen. Aktuell sind die Namings da auch alle unterschiedlich. Wenn wir das angleichen, könnten wir den app_integration_name als type Header setzen und aus der Config des Connectors das passende Topic auswählen.

[LenaB34]

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

[lmoesle]

For https://github.com/it-at-m/digiwf-core/issues/874 and https://github.com/it-at-m/digiwf-core/issues/734 it would be a good idea to also add a header for the starting process key

@darenegade, @simonhir Aktuell ist es nicht ohne weiteres möglich den ProcessDefinitionKey an den Connector bzw. auch an die Integrationen weiterzugeben. Deswegen habe ich damals das Ticket #734 aufgemacht. Soll ich #734 dann gleich umsetzen? Also, dass der ProcessDefinitionKey beim Prozessstart als Prozessvariable gesetzt wird und dadurch an den Connector aufruf weitergegeben wird?

[simonhir]

Wir hatten das damals aufgenommen, weil wir dachten, dass das zeitlich weniger Aufwand bedeutet, da man da ja die gleichen Sachen anpassen müsste. Aus meiner Sicht, müsste das nur spätestens im nächsten Sprint angepasst werden, weil das für die Paula-Integration benötigt wird. Also je nachdem ob du das auch so siehst, dass das einfacher ist das gleich zu machen, würde ich sagen macht das schon Sinn.

[lmoesle]

Passt für mich, dann zieh ich #734 auch noch mit rein in den Sprint und setzte das im selben Branch um 👍🏻

[lmoesle]

Ich habe das Ticket auf Impediment verschoben, bis das Vorgehen bei #734 geklärt ist