# ask Team Neo> APN Arch: Eigenbedarf-Backend 2.0 Version: 68 | Last modified: 2025-10-17T15:13:03.693+02:00 Source: confluence page ID 361137191 --- Diese Seite Beschreibt das Migration des Services eigenbedarf-backend ins APN 2.0 Die Empfehlung ist das Migration in zwei Iterationen durchzuführen. Iteration 1: enthaltet die für die Migration unbedingt notwendige Schritte: Umzug ins Aurora DB im Rahmen eines neues Services eigenbedarf-backend-2.0 und das dazugehörige Frontend Umleitung im Rahmen des eigenbedarf-frontend 2.0 Iteration 2: kann nur später durchgeführt werden, wenn die im jeweiligen Iteration genannten Voraussetzungen erfüllt sind. Das beinhaltet die Ausbau der Datenquelle VOV und die Umsetzung als neues Feature, die Anlage der Anmeldungen/Verträgen Das Migration soll erstmal nur für 1 Stage (ts1/apn_dev) durchgeführt werden, und nach erfolgreichen Test für die andere Umgebungen. Iteration 1 1. DB Umzug: Oracle -> AuroraDie EB-Tabellen sollen aus Oracle ins Aurora DB inklusive Inhalt umgezogen werden. Notwendige Tools/Clients einrichten: Anbindung zum Aurora. Die notwendige Schritte befinden sich an der folgende Seite: Howto Einrichtung APN Migration-Services mit Aurora DB - O2C | Order2Cash - ariJa Confluence (deutschebahn.com) (Story-1: das I.NVI IT Lifecycle Management Toolissuekey,summary,issuetype,created,updated,duedate,assignee,reporter,priority,status,resolutionkey,summary,type,created,updated,due,assignee,reporter,priority,status,resolutiond1143f0d-33c0-3f1c-b44b-7720150f306eO2CAPN-7161) Neues Schema anlegen für Eigenbedarf - neue Schema für jede Services (Story-2: das I.NVI IT Lifecycle Management Toolissuekey,summary,issuetype,created,updated,duedate,assignee,reporter,priority,status,resolutionkey,summary,type,created,updated,due,assignee,reporter,priority,status,resolutiond1143f0d-33c0-3f1c-b44b-7720150f306eO2CAPN-7162) 2 neue technische Benutzern anlegen: (Story-2) Für die Regelbetrieb analog zu Oracle, sowie apn_iu_betrieb Für Schema Migration mit erweiterte Rechte, sowie apn_iu_owner Neue Benutzern im Kubernetes Secrets hinterlegen. Das erfolgt sich im Rahmen des Secret Managements - Setup Secret für jede notwendige Benutzern, wie folgt: (Story-2) 1. Ein Secret ins lokale Datei "activemqconnection--apn-wartung" herunterladen: kubectl get secret activemqconnection--apn-dev -o yaml > activemqconnection--apn-wartung    Beispiel secret yaml files: .\OpenLens\beispiel_secret_yaml_files\activemqconnection--apn-wartung, .\OpenLens\beispiel_secret_yaml_files\auroraconnection--apn-wartung  2. Editieren heruntergeladene Date "activemqconnection--apn-wartung" 3. Neues Secret hochladen: kubectl apply -f activemqconnection--apn-wartung    Rückmeldung: secret/activemqconnection--apn-wartung created 4. Füge das entsprechende secret-claim (zum Beispiel: activemqconnection) zur Datei    https://git.tech.rz.db.de/cnp/apn/apn-ops/-/blob/develop/apn-iat/cnp-api-iat-v4/secret-claims.yml?ref_type=heads 5. Merge ins develop.     secret-claim holt das Secret und schreibt ins AWS Secret Manager (AWS-SM) und fügt Berechtigungen hinzu. 6. secret-claim wird via ArgoCD geladen.    Prüfe die neu hochgeladene secret-claim in ArgoCD (zum Beispiel: https://argocd.cnp.comp.db.de/applications/argocd/apn-iat-v4-claims?view=tree&node=cnp.comp.db.de%2FSecret%2Fapn-iat%2Fauroraconnection--apn-wartung%2F0&resource=)    Die Name des secret-claim wird erstellt aus die folgende Attributewerte:    apiVersion: cnp.comp.db.de/v1alpha1    kind: Secret 7. Hole die secret claims: kubectl get secret.cnp.comp.db.de 8. Es muss danach der secret-provider angelegt werden, der auf das AWS-SM secret verweist. (den hash im Namen kann man aus der secret-claim-Ressource ablesen, via kubectl oder OpenLens):    Hole das secret claim für Aurora connection: kubectl get secret.cnp.comp.db.de auroraconnection--apn-wartung  9. Wenn der Secret-Provider steht und richtig konfiguriert ist, sollte man das Service neu deployen können. Dieser packt dann das secret via secret-provider automatisch aus und mounted es in den zugehörigen Applikations-Pod DDL migration via Liquibase (Story-3: das I.NVI IT Lifecycle Management Toolissuekey,summary,issuetype,created,updated,duedate,assignee,reporter,priority,status,resolutionkey,summary,type,created,updated,due,assignee,reporter,priority,status,resolutiond1143f0d-33c0-3f1c-b44b-7720150f306eO2CAPN-7163) Liquibase Module ins EB-Backend integrieren Liquibase DDL ins maven Module integrieren Hinweis: Dieser Ansatz ist schon beim Migration-Services Umgesetzt, wodurch die relevante Logik dementsprechend übernommen werden soll. Laden der Daten - Das Ladeprozess soll sich mit Event-getriebene Datensynchronisation, basierend auf das Outbox Pattern (Pattern: Transactional outbox (microservices.io)) erfolgen. Team Migration hat schon ähnliche Logik bzgl. der Anmeldungen Implementiert. (Story-4: das I.NVI IT Lifecycle Management Toolissuekey,summary,issuetype,created,updated,duedate,assignee,reporter,priority,status,resolutionkey,summary,type,created,updated,due,assignee,reporter,priority,status,resolutiond1143f0d-33c0-3f1c-b44b-7720150f306eO2CAPN-7164, Story-5: das I.NVI IT Lifecycle Management Toolissuekey,summary,issuetype,created,updated,duedate,assignee,reporter,priority,status,resolutionkey,summary,type,created,updated,due,assignee,reporter,priority,status,resolutiond1143f0d-33c0-3f1c-b44b-7720150f306eO2CAPN-7165) Da bei allen Eigenbedarf-Änderungen die Tabelle EIGENBEDARF_REVINFO gefüllt wird, für die Oracle Tabelle EIGENBEDARF_REVINFO einen Trigger hinzufügen, der die betroffene (neue/geänderte/gelöschte) Rekord in einer sogenannte Outbox Tabelle schreibt Beispiel Trigger, der die Anmeldenummer ins Outbox Tabelle EVENT schreibt: DB/db_skripte/release320700/APN_EDIT_TRIGGER_SYNC_ANMELDUNG.sql · master · apn-eip / src / DatenbankDevelopment · GitLab (Story-4) Initial Laden Implementieren. Dazu gibt es 2 Möglichkeiten: (Story-4)Bevorzugt: Logik für das initiale Laden zu Implementieren, die die schon existierende Rekorde zur Outbox Tabelle hinzufügt. Diese Logik soll via eine Rest-Endpunkt zur Verfügung gestellt werden. Beispiel: src/test/java/com/dbnetz/apn/event/service/messaging/initialload · develop · apn / common / spring / modules / event-classic-backend · GitLab Zusätzliche Spalte (zum Beispiel mit der Name "status" und mit dem Wert "updated") zur Tabelle EIGENBEDARF hinzufügen, um das Trigger für alle schon existierende Rekorde zu initiieren. Daher wird der Trigger für alle schon existierende Zeilen gefeuert. Andere Tabelle im Bezug eigenbedarf muss nicht geändert werden, da die alle eine Verknüpfung zum Tabelle EIGENBEDARF haben. Trigger schreibt die Daten in der Outbox Tabelle (Story-4) Das schon existierende Eventing Service event-classic-backend zieht das ganze eigenbedarf Struktur zusammen (dazu muss das Service erweitert werden oder alternativ neue Service erstellt werden) und fügt zu einem Queue hinzu. Klären mit Team Mig. ob die verarbeitete Zeilen in der EVENT Tabelle gelöscht werden können. (Story-5) neue Version von eigenbedarf-backend 2.0 mit Aurora DB wird mit Event Topic Abarbeitung erweitert und arbeitet die Queue Elemente ab (Story-5) Das Ladeprozess muss nur in die hier beschriebene Richtung implementiert werden: Oracle DB → Aurora DB Frontend auf eigenbedarf-backend 2.0 umleiten (siehe nächste Punkt 2) (Story-6: das I.NVI IT Lifecycle Management Toolissuekey,summary,issuetype,created,updated,duedate,assignee,reporter,priority,status,resolutionkey,summary,type,created,updated,due,assignee,reporter,priority,status,resolutiond1143f0d-33c0-3f1c-b44b-7720150f306eO2CAPN-7166, Analyse Story-7: das I.NVI IT Lifecycle Management Toolissuekey,summary,issuetype,created,updated,duedate,assignee,reporter,priority,status,resolutionkey,summary,type,created,updated,due,assignee,reporter,priority,status,resolutiond1143f0d-33c0-3f1c-b44b-7720150f306eO2CAPN-7167 → Story-8) Prüfen ob und wann eigenbedarf-backend 1.0 abgebaut werden kann (Analyse Story-7 → Story-8) 2. Anpassung der Suchen im Frontend auf die Aurora Datenbankeigenbedarf-frontend-2.0 mit neue Endpunkt Aufrufe Richtung eigenbedarf-backend 2.0 anzulegen (Story-6) eigenbedarf-frontend-2.0 testen und Fehlerbehebung, während damit parallel eigenbedarf-frontend weiterhin lauft. Es ist möglich zwischen die 2 Frontends umzuschalten (Story-6) Prüfen ob und wann eigenbedarf-frontend 1.0 abgebaut werden kann (Analyse Story-7 → Story-8) Iteration 21. Ausbau Zugriff zum externen Datenquellen bzgl. VorsystemAnhängigkeit: das Migration des Services, die die notwendige Daten (Nutzungsobjekte, Steurende Attribute, usw.) liefern (VOV - vorsystem-persistence, usw.). Auf Grund dessen, in der Erste Iteration des Migration, diese Logik kann unverändert so bleiben wie es aktuell ist, erweitert mit der Aurora Zugriff. Daher das Service eigenbedarf-backend 2.0 wird zuerst auf drei Datenquellen zugreifen: VOV (SteuerndeAttributen), Oracle, CNP (Aurora) Klären, ob die Funktionalität 1-1 so wie es aktuell ist, übernommen werden kann? IST StandDas aktuelle eigenbedarf-backend holt direkt die notwendige Daten (Nutzungsobjekte, Steurende Attribute, usw.) aus zwei Oracle Schemata: Oracle VOV (Steuerndeattribute) und Oracle APN. SOLL StandIm Gegensatz dazu, in APN 2.0 es wird pro Domäne ein Service laufen, und die notwendige externen Daten sollen anstatt Direkt DB Zugriff bei der Verwendung das Outbox Pattern abgeholt sein. VorgehenEs sollen die Services migriert werden, die Daten für das Service eigenbedarf-backend 2.0 produzieren. → Abhängigkeit zum Team Mig. Als alternative Lösung die notwendige Services können selber migriert werden. Wenn das Migration des betroffenen Services sowie VOV - vorsystem-persistence durch sind, dann wird es möglich sein bei der eigenbedarf-backend 2.0 die Daten zu holen. Für die Umsetzung diese zwei Punkte, siehe nächste Punkt "Allgemeine Konzept für Outbox Pattern". Allgemeine Konzept für Outbox PatternNeben eigenbedarf, es gibt andere Services, die externen Daten von anderen Services benötigen. Im System existieren also mehrere Services in der Rollen Producer und Consumer. Ziel ist es, die Producer und Empfänger Services zu entkoppeln. Daher in einem Separatem Konzept (Konzept Story-11) eine Systemübergreifende Lösung bzgl. der Verwendung des Outbox Patterns notwendig ist. In diesem Konzept die Umsetzung der folgende Funktionalität soll näher Beschrieben werden: Die Services, die Daten für andere Services zur Verfügung stellen, schicken bei allen Änderungen via event-service (z.B. event-classic-backend) die Steuernde Attribute, Nutzungsobjekte in einem Queue/Topic in ActiveMQ. Klären (ggf. ADR erstellen): kann dafür event-classic-backend verwendet werden, oder sollte mehrere event-service existieren? Die Services, die Daten von andere Services benötigen, subscriben auf die Topics, woher die benötigte daten kommen, und diese Daten dann verarbeiten. Das Service eigenbedarf-backend 2.0 soll auch dieses Vorgehen realisieren, und anschließend die relevante Daten in der Aurora DB ablegen (Story 12). 2. Anlegen von Anmeldungen/Verträgen aus APN 2.0 ins Altsystem/Tibco (in Abstimmung mit Migration)Abhängigkeit (nur Punkt 3): eigenes Konzept wurde erstellt, wie die TIBCO Logik bzgl. des Anlegens der Anmeldungen/Verträgen in APN 2.0 umgesetzt werden kann. TIBCO verfügt schon die Logik bzw. SSt., die Ermöglichen Anmeldungen/Verträgen anzulegen. Diese SSt. ist bei MWS verwendet. MWS verfügt aber keine SSt., via es - bei der eigenbedarf-frontend - möglich ist, diese TIBCO Funktionalität zu nutzen, und Anmeldungen/Verträgen anzulegen. Seit die neuere MWS Versionen es ist auch nicht möglich solche SSt. zu definieren. Daher hier es um eine neue Feature handelt. VorgehenGenerell gilt, das neue APN 2.0 und das Altsystem zu entkoppeln, daher es Event basierte Ansatz mit der Benutzung Outbox Pattern verwendet werden soll: Bzgl. des Anlegens von Anmeldungen/Verträgen, das neue eigenbedarf-frontend 2.0 ruft das Service eigenbedarf-backend 2.0 auf, das dann diesbezüglich ein Event in einem Queue ablegt. MWS abarbeitet die Event und ruft die TIBCO SSt. auf (Story 13) Im Altsystem (TIBCO) die neu angelegte Anmeldungen/Verträgen werden ins Event Queue geworfen. APN 2.0 liest anschließend die Elemente aus und legt die Anmeldungen/Verträgen in der Aurora DB an. (Story 14) Umsetzung des Anlegens der Anmeldungen/Verträgen (die aktuell nur in TIBCO vorhanden ist) direkt in APN 2.0 → eigenes Konzept ist notwendig. (Konzept Story 15) truekonzept-eigenbedarf-backend-2.0falseautotoptrue14918 Das APN - Datenmodell für Eigenbedarfe: Das Fachdatenmodell  Versionierung/Bearbeitungshistorie (HibernateEnvers): Datenbanktabellen inklusive Versionierung/Bearbeitungshistorie (HibernateEnvers): Hilfreiche Ressourcen für den KontextSteuernde Attribute publizieren:Screenshots und Beispiele kann man sehen anhand des  Datenbank-Trigger an einem Beispiel: Event-Tables: Zur Erklärung: Die Spalte Eventtyp ist ein Enumeration (siehe Javacode oder Typ-Tabelle). Die Spalte EventValue ist typspezifisch. Allgemein wird hier die Referenz auf das Root-Aggregate des zu übermittelnden Datensatzes referenziert.Für Anmeldungen ist das die Anmeldenummer Für Eigenbedarfe müsste das hier entsprechend die Eigenbedarf_ID sein. Der Eventservice nimmt den Eventvalue, um daraus den Payload der einzustellenden Nachricht zu berechnen (und als JSON zu serialisieren). Bestehende Topics/Queues/CompositeTopics:https://git.tech.rz.db.de/cnp/cnp-managed/apn-iat/-/blob/master/cnp-api/activemq/config/broker-config.xml?ref_type=heads Message Producing-Example:https://git.tech.rz.db.de/apn/common/spring/modules/event-classic-backend/-/blob/develop/src/main/java/com/dbnetz/apn/event/service/messaging/ApnAnmeldungEventPollingService.java?ref_type=heads#L54-58 Migrations-Fahrplan und Kontext zum zeitlich geplanten Ablauf einer Migrationsstrategie: