Zammad-Integration Init

[darenegade]

Is your feature request related to a problem? Please describe.

Als Bürger:in der LHM möchte ich über den aktuellen Stand meiner Anliegen informiert sein. Dazu hat die LHM eine Kontakthistorie (Zammad) eingeführt und verbindet diese mit allen Eingangskanälen, z.B. Formularserver. Damit Bürger:innen nun auch den Status ihrer Anliegen zu DigiWF-Prozessen erhalten, soll hierzu eine neue Integration erstellt werden.

Describe the solution you'd like

• Neue Integration erstellen in DigiWF-Core
• Initiale Schnittstelle "Ticket anpassen" erstellen
  • Link zu Swagger Doku
  • Über die Schnittstelle soll entweder ein Status angepasst, eine Nachricht geschrieben oder beides zusammen gemacht werden können
  • Offen: Warum PUT Methode und was ist mit Feldern die nicht angegeben werden bzw. wozu Titel/ID mitgeben?
    • Antwort:
      • ~~Auch wenn hier PUT genutzt wird, wird nichts überschrieben. Titel/ID muss vorher ausgelesen werden. Erfolgt in der Zammad-Integration, damit das nicht im Prozess gemacht werden muss ~~
      • Die Zammad Kollegen passen ihre EAI an, damit dies nicht mehr notwendig ist
  • Element-Template anlegen und in CoCreation (BPM-Modeller) sowie Doku ausbringen
  • DigiWF-Ops anlegen für alle Umgebungen
  • Kafka-Topics für alle Umgebungen erstellen lassen
  • Klärung mit Zammad-Team: Wie läuft das mit der Security?
  • Sec-Doku: https://git.muenchen.de/digitalisierung/mpdz-ticketing/mpdz-ticketing-eai#security-towards-consuming-clients
  • AP Roland W.
    • Kurze Abstimmung mit Roland: Wichtig ist, dass TicketID und UserID/LHMExtID nicht vom End-User geändert werden können. Das muss über Qualitätssicherung vor Release von Prozessen sichergestellt werden. Wir müssen das bei der Zammad-Int. so dokumentieren im Modellierungshandbuch
  • S3 Int. wird nicht in diesem Ticket umgesetzt (Keine Dateien anhängen)
  • Lokale Tests per Wiremock bzw. allgm. API Mock

Describe alternatives you've considered

Acceptance Criteria

• [ ] Über einen DigiWF-Prozess lässt sich eines der folgenden Dinge machen: Status ändern, Artikel schreiben, beides zusammen
• [ ] Element-Template kann von Prozessdesigner genutzt werden
• [ ] Integration ist auf Dev Deployed
• [ ] Konfigurationen für alle Umgebungen sowie Kafka Topics sind vorbereitet
• [ ] Showcase gebaut
• [ ] Doku für Integration und Modellierung erstellt (auch Betriebshandbuch)

Additional context

[darenegade]

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

[dominikhorn93]

@darenegade macht es Sinn hier 3 Use Cases daraus zu machen?

• Ticketing: Status ändern
• Ticketing: Artikel schreiben
• Ticketing: Ticket anpassen

[darenegade]

Ticketing: Status ändern Ticketing: Artikel schreiben

Auf der Prozessebene kann man das natürlich gerne machen, nachdem dies ein Subset von Ticket anpassen ist. Ich würde es aber nicht auf der API Ebene machen, da ich hier keinen Mehrwert in der Trennung sehe und wir so näher an der API des eigentlichen Systems sind (KISS)

[dominikhorn93]

D.h. wir haben ein Out-Port "Ticket anpassen" Ich würde hier aber 3 In-Ports definieren.

• Sonst wird das etwas komisch mit der Validierung.
• In den In-Ports wollen wir ja eigentlich fachlich sein und nicht an der API von Zammad dran.

[dominikhorn93]

[darenegade]

Wir nutzen ja eh schon nicht die Zammad-eigene API, sondern eine fachlich definierte API der EAI.

Ich würde die Aufteilung der Funktionen eher auf der Prozess-Ebene sehe, wenn dies benötigt wird. Je einfacher unsere Integration ist, desto einfacher haben wir es. Wenn der Bedarf dann wirklich noch da ist, können wir immernoch zwei dedizierte Ports für Status und Artikel hinzufügen

[dominikhorn93]

"Ticket anpassen" ist für mich aber kein Use Case, sondern eine generische Möglichkeit etwas mit Tickets zu machen... fühlt sich nach CRUD an.

Wenn beides optional ist, könnte man auch 2 leere Strings mitgeben. Was passiert dann? Error oder einfach skippen? Validierung der Inputs ist so nicht ganz klar.

Was machen wir, wenn sich die "Ticket anpassen" Schnittstelle um neue Parameter erweitert? Erweitern wir dann auch unsere Schnittstelle oder bauen wir eine neue um eventuelle Inkompatibilitäten zu verhindern?

Das ist auch gar nicht aufwendig hier 2 weitere Ports zu definieren. Gleichzeitig wird die Validierung einfacher und wir haben voraussichtlich weniger Kompatibilitätsfragen in der Zukunft.

[dominikhorn93]

Nach Abstimmungen gibt es folgenden In Port:

ArtikelSchreibenInPort

• Nachricht (Pflicht)
• Status (optional)

[darenegade]

@dominikhorn93 Hier noch die Doku für Zammad: https://wiki.muenchen.de/betriebshandbuch/wiki/MPdZ-Ticketing_(Zammad)#Test_2

Wir sollen die PreLive anbinden. Bei den Tests bitte immer in einem Ticket arbeiten, da wir sparsam mit dem Neuanlegen von Tickets sein sollen

[darenegade]

@dominikhorn93 Hab die Rückmeldung vom Zammad Team bekommen, dass sie die API nochmal anpassen morgen, damit kein PUT mit vorher auslesen der Daten (Titel ID) notwendig ist. Sollte die Tage dann auf der Testumgebung bereit stehen

[FabianWilms]

@dominikhorn93 Ich grätsch hier auch gleich mal rein: Es wird in den nächsten Tagen noch eine kleine Änderung an den "intenal" Schnittstellen geben: Bisher musstest du verpflichtend entweder lhmExtId oder userId als Kontext mitgeben. Das wird optional weiterhin möglich sein, allerdings gibt es auch die Möglichkeit ohne "Userkontext" auf die API zuzugreifen. Das wird insbesondere dann relevant, wenn der auslösende User z.B. unauthentifiziert arbeitet und man somit keinen Userkontext hat.

Macht ggf. keinen Unterschied für eure Anbindung, wollte es nur vorher schonmal mitteilen, falls ihr doch Bedarf an der Änderung habt.

[dominikhorn93]

Wir werden erst einmal die TicketsApi nutzen und davon den Aufruf updateTicket mit folgendem body:

{
  "id": "<string>",
  "state": "closed",
  "pending_time": "<dateTime>",
  "article": {
    "body": "<string>"
  }
}

[darenegade]

@lmoesle @dominikhorn93 Wie ist hier der Stand?

[dominikhorn93]

@darenegade Lukas hat festgestellt, dass die UserId im Aufruf momentan nicht optional ist. Die Verbindung funktioniert soweit... Ob wir das so bis test ausrollen können, ist aber fraglich.

[darenegade]

Lukas hat festgestellt, dass die UserId im Aufruf momentan nicht optional ist.

Das ist ja genau das, was einfach in der Swagger steht und schon immer stand. Das andere von dir, waren doch nur Diskussionen mit Fabian.

Das müssen wir an den Prozess durchreichen als Parameter.

[dominikhorn93]

Die UserId kennen wir aber nicht, da es sich um die Zammad UserId handelt. Deshalb hatte ich nachgefragt und die Info bekommen, dass es eigentlich auch ohne UserId funktioniert - das ist aber leider nicht korrekt.

[darenegade]

Die UserId kennen wir aber nicht, da es sich um die Zammad UserId handelt.

Der Plan war doch, dass dies in der Zammad-EAI von der LHM-Objekt-ID aufgelöst wird, nachdem es externe Systeme nie wissen können. Das war mMn auch Konsens beim Zammad-Team bzw. Fabian.

Sonst nehme ich das gerne nochmal in die Hand, wenn wir aktuell hier einen Blocker haben

[FabianWilms]

Deshalb hatte ich nachgefragt und die Info bekommen, dass es eigentlich auch ohne UserId funktioniert - das ist aber leider nicht korrekt.

Das soll der Fall werden, ist aber bisher noch nicht umgesetzt:

https://jira.muenchen.de/browse/MPDZ2-282

Ich komme voraussichtlich diese Woche dazu das umzusetzen, sodass ihr keinerlei User-Informationen mehr angeben müsst.

[FabianWilms]

Das Ticket ist durch und der neue Stand der EAI steht in der Testumgebung bereit. Wenn euch noch Probleme auffallen, bitte in Issue aufmachen und mir zuweisen, ich versuche mich dann schnellstmöglich drum zu kümmern 👍

[lmoesle]

FYI Für den Ops Part von der Integration habe ich #1377 aufgemacht, damit wir weiter an der Integration arbeiten können und z.B. mit #1266 starten können.