Vertragsservice

vertrag-service ideas - Verbesserungen

Epic

Stabilize Vertrag-Service

[FONL-32238] Stabilize Vertrag-Service - JMP JIRA

Vertragsservice - organisatorisch: Festlegung welches Team dafür erster AP und Einflugschneise (im Sinne von Koordination/Verantwortung/Treiber des Themas) ist und Kommittent im Tribe sich zu unterstützen, wenn in dem Team Hilfe benötigt wird.

→ Kommunikation in der Etappenretro: Verantwortung ist in ConDa, aber Know-How ist noch nicht da um die Probleme zu lösen Kuhnle, Tanja (Allianz Lebensversicherungs-AG)

→ Kommunikation an den Rest des Tribes

Vertragsservice - technisch: Ideen von Alex R., Alex Z. und Chris W. "decouple the import of contract changes from the normal vertrag-service means 2 services (one only importing fonl and abs contract changes and one service is for read access the vertrag-service →"

→ wurde NICHT in der Retro besprochen

jir→ Vorschlag aus der AM/AC Runde: Wir sollen Transparenz haben woran die Entwickler kurz und mittel/langfristig zum Thema arbeiten. Idee war ursprünglich zwei Epics in ConDa zu erstellen und die Entwickler bitten, die jeweiligen User Stories und Tasks hier anzuhängen. Es gibt hier aber bereits eine Epic, dass die Devs nutzen: https://jmp.allianz.net/browse/FONL-32238 Es ist einfacher dieses auch weiterhin zu benutzen, anstatt die neuen, von Mareike erstellten zu nutzen.

→ notwendigen Gespräche um die technische Lösung zu definieren finden bereits statt. ConDa im Lead in Absprache mit Alex Rolfes.

[OneDIA] SPIKE: Concept migration strategy and required code/config changes

• Vertrag-Service needs to be capable to perform the migration without data loss while maintaining data consistency at all times -> this needs to be thought through thoroughly.
• Open Question:
  • is it acceptable to have inconsistent setup between ATA0 and Prod while implementing the new data flow?
  • is it acceptable to have lags / outages in data processing in ATA0 (e.g. we deactivate DP Http endpoints in favor of Kafka consumers but face an unexpected error in Kafka processing)
  • we are in favor of an initial load on migration day. What implications does it have on DP/OneDIA and on FONL (e.g. size of mongo storage)