# <deprecated?->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:
