ankn/Orchestrator
1
0
Fork 0
Code Issues Pull Requests Actions Packages Projects Releases Wiki Activity

Migrate all repos into monorepo context folders

Browse Source 
Bahn: aisupport, Analyse-O2C-C2S, awesome-bahn-mcp-servers, beam-mcp,
      Confluence_Bot, db-planet-mcp-server, O2C-Harness, project-audit,
      Projekt-KIQ-HP, teamlandkarte-mcp
Dhive: Jury-Voting
Privat: CV, NoteGraph (NOTE: NoteGraph needs complete redo after consolidation)
Shared: AI-Orchestrator, OrgMyLife, power_skills_and_more
Shared/references: symphony (read-only)

Bahn repos remain available as independent remotes - this monorepo
pulls them in via subtree, the originals are untouched.
This commit is contained in:
ankn
2026-06-30 20:39:52 +02:00
parent 2f2b295531
commit a5f8fb49ab
1717 changed files with 447332 additions and 0 deletions
Download Patch File Download Diff File Expand all files Collapse all files
bahn/Analyse-O2C-C2S/sources/o2c/O2C-APN/APN-Architektur.md
+95
View File
@@ -0,0 +1,95 @@
# APN Architektur
Version: 44 | Last modified: 2024-05-27T13:28:35.191+02:00
Source: confluence page ID 244623148
---
ThemenradarNeue Funktionen:
LuLP - IDeadline Start GLV Vorbereitung ab 21.10.2024 (letztes Release also nach PI 34 Sprint 1, mit Puffer also letztes sinnvolles Release nach PI33 Sprint 5).
Rückwärtsgerechnet 2 Sprints für Performanceverbesserung, 1 Sprint  für Lasttests, d.h. LuLP Grundlagen müssen Einsatzfähig sein nach PI33 Sprint 2)
TracingAufbau eines eigenen Grafana Stacks
AuroraDB Abzüge und genereller PU Support - M
Messaging abziehen, neu aufsetzen? Initial Load?ggf Kafka betrachten?
 
Health Dashboard + Alerting multistage 1173Prio Low, vielleicht erhöht mit TS3
TS3Prio Low
Vereinfachung bestehender Prozesse:
zentrales Rollout - I (nur bis Tags funktionieren)npm Version/Tag setzen
Pipelines umbauen/reparieren
triggern der Pipelines
Ergebnis transparent machen
(Volldeployments+Kompatibilitätsnetze)
Renovate
Nutzung bestehender Tools
Sonarcube - alle (auf 30% selektiv)min Coverage erhöhen
WhitesourceFunktionsfähigkeit prüfen (Pipeline Konfig)
Dual Lizenzen prüfen
zentrales API Repository
Wartung der Platform:
Versionsupdates (Spring, Java, CNP, EIP, ...?) - G2 CNP Upgrades von der CNP Platform
2 MoqAP Upgrades einpflegen
5.15 Tibco BW PU Upgrade betreuen (26.6.?)
SAG Patches für Pentest Findings einspielen
US1204 Technische User über zentrale Authentifizierung anmelden
Pentest & ScannerMedium/Low Findings
KarpenterPrio High
Deadline nicht genau spezifiziert, wir erwarten aber PI33/34
SDLC Reifegradwir hatten bis Ende 2023 die Pflicht Reifegrad 1 zu erreichen
für Reifegrad 1 fehlt noch: DAST Scanner (z.b. OWASP Zap Scanner oder ggf Invictus Scanner),
Reifegrad 2 hat keine uns bekannte Deadline 
Renamingeigene Konventionen weiterhin nicht 100% eingehalten
+ Restarbeiten PI32
npm zentral rollout
(karpenter)
central rest API 
Wie ist das Architektur Backlog aufgebaut?Es gibt einen Haupt-Anker, das sogenannte Architektur Backlog. Das ist der Enabler O2CAAPN-16.
das I.NVI IT Lifecycle Management Toold1143f0d-33c0-3f1c-b44b-7720150f306eO2CAAPN-16 ← hier gehts los, das ist der Haupt-Anker. Das sogenannte Architektur Backlog.
truedarstellungfalseautotoptrue6034
Die Architekten nutzen nur die relates to Beziehung, um Stories zu verwalten. Andere Beziehungen, vor allem die parent / child of Beziehung, werden von den Produkt Owner genutzt um Stories z.b. in Features einzuteilen.
Sammelbecken (sowohl PI als auch Themen Sammelbecken) beginnen mit "APN-A: ", damit schnell ersichtlich ist, dass es sich um etwas handelt, was die Architekten erstellt haben.
Prioritäten?Die Architekten nutzen die Prioritäten bereits im Architektur Backlog, und zwar wie folgt:
critical / very high → muss sofort, also im laufenden PI, abgearbeitet werden
high → muss ins nächste PI
medium → kann ins nächste PI, muss aber nicht
low → ist explizit nicht für das nächste PI geeignet
very low → muss vielleicht garnicht gemacht werden → neu betrachten und bewerten
Sobald Stories in ein Feature wandern kann und sollte die Prioritär neu gesetzt werden um dann eine Abarbeitungsreihenfolge im Sprint wiederzuspiegeln.
AB HIER GGF VERALTETVersuch einer Ordnung alter Storys, Enabler und Features (ab hier ggf. verwaltet)PI spezifische Aufgabenplanungdas I.NVI IT Lifecycle Management Toold1143f0d-33c0-3f1c-b44b-7720150f306eO2CAAPN-308 (leer)
das I.NVI IT Lifecycle Management Toold1143f0d-33c0-3f1c-b44b-7720150f306eO2CAAPN-307 (leer)
das I.NVI IT Lifecycle Management Toold1143f0d-33c0-3f1c-b44b-7720150f306eO2CAAPN-306 (leer)
das I.NVI IT Lifecycle Management Toold1143f0d-33c0-3f1c-b44b-7720150f306eO2CAAPN-289 (10+ stories)
das I.NVI IT Lifecycle Management Toold1143f0d-33c0-3f1c-b44b-7720150f306eO2CAAPN-108 (3+ Stories)
Aufgabenspezifische SammelbeckenAlle mit APN-A im Summary
das I.NVI IT Lifecycle Management Toolproject = O2CAAPN AND resolution = Unresolved AND summary ~ APN-A ORDER BY priority ASC, updated DESCd1143f0d-33c0-3f1c-b44b-7720150f306e
Reine Mig Backlogs??das I.NVI IT Lifecycle Management Toold1143f0d-33c0-3f1c-b44b-7720150f306eO2CAAPN-209
das I.NVI IT Lifecycle Management Toold1143f0d-33c0-3f1c-b44b-7720150f306eO2CAAPN-199
Reaktives Incidentmanagementdas I.NVI IT Lifecycle Management Toold1143f0d-33c0-3f1c-b44b-7720150f306eO2CAAPN-286
das I.NVI IT Lifecycle Management Toold1143f0d-33c0-3f1c-b44b-7720150f306eO2CAAPN-186
das I.NVI IT Lifecycle Management Toold1143f0d-33c0-3f1c-b44b-7720150f306eO2CAAPN-312
das I.NVI IT Lifecycle Management Toold1143f0d-33c0-3f1c-b44b-7720150f306eO2CAAPN-164
Securitydas I.NVI IT Lifecycle Management Toold1143f0d-33c0-3f1c-b44b-7720150f306eO2CAAPN-286
das I.NVI IT Lifecycle Management Toold1143f0d-33c0-3f1c-b44b-7720150f306eO2CAAPN-294
bahn/Analyse-O2C-C2S/sources/o2c/O2C-APN/APN-Roadmap-Epics.md
+27
View File
@@ -0,0 +1,27 @@
# APN Produktvision, Roadmaps, EPICS, PI Plannings
Version: 62 | Last modified: 2025-07-25T10:00:56.568+02:00
Source: confluence page ID 341222189
---
Produktziel:
"APN 2.0 deckt Ende 2026 die notwendigen Funktionen ab" (siehe Roadmap)
LEAN Portfolio-Management:
Im LEAN Portfolio-Management des ITD Boards sind die Epics für die ARTS aufgehangen.
Hier sind die EPICS von O2C bzw. APN
APN ART-Programm-Kanban-Board:
Auf unserem ART-Programm-Kanban-Board finden sich die Features & Enabler
APN ART-Programm-Backlog
APN Program Kanban Board - O2C | APN | ART - Agile Board - DB InfraGO ITD Lifecycle Management Tool (deutschebahn.com)
Weiterführende Links:
Confluence Seite vom Lean-Portfolio-Management
bahn/Analyse-O2C-C2S/sources/o2c/O2C-APN/APN-Startseite.md
+421
View File
@@ -0,0 +1,421 @@
# APN
Version: 60 | Last modified: 2026-03-15T23:37:25.422+01:00
Source: confluence page ID 175079641
---
Das Produkt:
Infrastruktur-Nutzungsbedingungen (INB 26) ganz:
Infrastrukturnutzungsbedingungen der DB InfraGO AG (INB) 2026 
DoR + DoD auf Value Team Ebene:
Definition of Ready und Definition of Done - O2C | Order2Cash - ariJa Confluence
Zuständigkeiten + Ansprechpartner:
APN interne Stakeholder-Kommunikations-Matrix (Zuständigkeiten + Ansprechpartner) - O2C | Order2Cash - ariJa Confluence
Betriebshandbücher der Kernprozesse:
APN Classic (auf dem Portal unter "Hilfe"): My webMethods: Betriebshandbuecher
Alle aktuellen Betriebshandbücher des Systems APN auf einen Blick zum Downloaden:
Modul. 1 - Allgemeines
Modul 2a - Anlagenportal Netz: Netzkarte
Modul 2b - Anlagenportal Netz: SucheSE
Modul 3 - Persönlicher Bereich
Modul 4a - Benutzerverwaltung (extern)
Modul 4b- Benutzerverwaltung (intern)
Modul 5 - Kundenmanagement
Modul 6 - Faktura
Modul 8 - VOV
APN 2.0 im Sharepoint: APN - Dokumente - Unterlagen zu APN Migration (APN 2.0) - Alle Dokumente
Portalzugänge:
Klassik: My webMethods: Startseite (db.de)
APN 2.0: APN Anlagenportal Netz (db.de)
 
1{"body":{"text":{"color":"#465671","textAlign":"left","fontWeight":"normal","fontSize":14}},"header":{"backgroundColor":{"color":"#0149b0"},"icon":{"size":26,"name":"faTrain","color":"#fff"}},"headline":{"text":{"text":"APN - Anlageportalnetz","color":"#fff","textAlign":"left","fontWeight":"normal","fontSize":18},"alignment":{"horizontal":"center"}},"base":{"backgroundColor":{"color":"#ffffff"},"border":{"color":"#0049b0","style":"solid","width":1,"bottom":true,"top":false,"left":true,"right":true},"borderRadius":{"radius":20},"boxShadow":{"shadows":[{"color":"rgba(0, 0, 0, 0.08)","x":0,"y":1,"blur":1,"spread":0},{"color":"rgba(0, 0, 0, 0.16)","x":0,"y":1,"blur":3,"spread":1}]}}}Mit dem Anlagenportal Netz (APN) ...… werden Serviceeinrichtungen aus Infrastrukturdaten zur Vermarktung aufbereitet, zur Bestellung angeboten, bei Konflikten koordiniert und die Abrechnung vorbereitet. Im Vermarktungsbereich wurde ein Online Shop zur Suche und zur Buchung von Serviceeinrichtungen auf Grundlage der individuellen Bedürfnisse bereitgestellt, in dem Eisenbahnverkehrsunternehmen Gleise und Zusatzausstattungen bestellen können.​
… werden aus den Infrastrukturdaten des SAP R3 Netz vermarktungsfähige Nutzungsobjekte erzeugt und von den Regionen konfiguriert.​
… werden jährlich ca. 16.500 Gleise (Abstellung, Zugbildung, Ladegleis, etc.) und 17.000 Zusatzausstattungen (z.B. Wasserfüllständer, Elektranten, Innenreinigungsanlagen, etc.) vermarktet.​
… wird die Koordinierung und das Entscheidungsverfahren von konfliktbehafteten Anmeldungen durchgeführt.​
… werden Angebote an den Kunden verschickt und die Verträge erstellt.​
… werden Abrechnungspositionen zu Verträgen erstellt und zur Rechnungslegung an das Abrechnungscockpit ​
    (AC) übergeben.
Parallel arbeitet aktuell ein weiteres Team an einem neueren, modernen und nutzerfreundlicherem APN. Hierbei steht die Technologieumstellung hin zu Angular + CNP und weg von TIBCO und S-AG. 
Die Vision ist es eine Anwendung  zu entwickeln, die einfach zu benutzen, robust und sicherer sein wird. 
 
{"generalSettings":{"tabSpacing":0,"tabWidth":100,"tabHeight":80,"direction":"horizontal"},"activeSettings":{"backgroundColor":{"color":"#0052cc"},"text":{"fontSize":18,"color":"#fff","textAlign":"left","fontWeight":"lighter"}},"inactiveSettings":{"backgroundColor":{"color":"#f4f5f7"},"text":{"fontSize":18,"color":"#5e6c84","textAlign":"left","fontWeight":"lighter"}},"contentSettings":{"backgroundColor":{"color":"#fff"},"boxShadow":{"shadows":[{"color":"rgba(0, 0, 0, 0.08)","is":"drop-shadow","x":0,"y":0,"blur":1,"spread":0},{"color":"rgba(0, 0, 0, 0.16)","x":0,"y":3,"blur":2,"spread":-2}]},"border":{"style":"solid","width":1,"top":false,"bottom":true,"left":true,"right":true,"color":"#0065ff"},"padding":{"top":10,"right":10,"bottom":10,"left":10}},"hoverSettings":{"backgroundColor":{"color":"#dfe1e6"},"text":{"fontSize":18,"color":"#5e6c84","textAlign":"left","fontWeight":"lighter"}}}1
faBookOpenGlossar
Begriff | Erklärung |
Logistikgleise (Vorsystem) | Unter Logistikgleise aus dem VOV verstehen wir, dass das "Logistikgleisanfragen" von technischen Anmeldern sind. |
Kombimodul | Produkteinführung: Das Kombimodul ist eine Zusatzausstattung (ZA), die aus einer WC-Entsorgungsanlage hervorgeht. Wird das Kombimodul der regionalen Vermarktung manuell gewählt, so ist dies eine Kombination aus einer WC-Entsorgungsanlage und einem Wasserfuellstaender. Das Kombimodul kann in drei unterschiedlichen Ausprägungen vorkommen: T-System, Schrank, Unterflur |
fiddeln / gefiddel | Sachen zusammen suchen; "make it work" |
Moini | Grußformel, Betonung auf dem zweiten I
|
reinwurschteln/hinwurschteln | Ein Werb für eine unprofessionelle Arbeitsweise - etwas machen, etwas umsetzen. Wird bei APN defaultmäßig bei allem verwendet, auch wenn die Arbeiten fachgerecht und professionell ausgeführt wurden/werden.
|
faListAbkürzungen
Abkürzung | Begriff | Weiteres Feld Erklärung? Kategorie? |
ABM | Arbeitsbeschaffungsmaßnahme |
|
AC | Abrechnungscockpit |
|
AIO | Aufbereitete Infrarstrukturobjekte |
|
AnDI | Anlagedisponent|innen |
|
APN | Anlageportalnetz (Ehemals VMSE) |
|
APS | Anlagepreissystem |
|
APS Team - |
|
|
ART | Agile Release Train |
|
AU | Abnahmeumgebung |
|
BAE |
|
|
BAKO | Baukommunikation (Tool für Baustellenplanung) |
|
BAPSI | Bauinformation Anlagenpreissystem-Anlagen und Infrastrukturanschlüsse |
|
BBP Neo | Baubetriebsplanung |
|
BBZR | Baumaßnahmen und baubetriebliche Zugregelungen |
|
BNetzA | Bundesnetzagentur |
|
BOA | Verordnung über den Bau und Betrieb von Anschlussbahnen |
|
BS / Bst | Betriebsstelle |
|
bve |
|
|
BW | BusinessWorks (Software von TIBCO mit der die Backendservices in der alten Welt implementiert sind) |
|
C&R | Click & Ride |
|
CI/CD | Continuous Integration / Continuous Delivery |
|
CNP | Cloud Native Plattfrom |
|
Da ViT | Datenverarbeitung und Trassenmanagement |
|
DaViT | Datenverarbeitung im Trassenmanagement |
|
DB FV | Fernverkehr |
|
DB-RIL | DB Richtlinie |
|
DeBI | Deutsche Bahn Identity |
|
DLT | Dead Letter Topic (Kafka Fehlerbehandlung) |
|
EB | Eigenbedarf |
|
EBA | Eisenbahnbundesamt |
|
EBO | Eisenbahn Bau- & Betriebsordnung |
|
EBSÜ | Übersichtsschaltpläne für die elektrischen Betriebsstellen |
|
EBuLa | Elektronischer Buchfahrplan und Lagsamfahrstellen |
|
EMS | Enterprise Messaging Service (Enterprise Implementierung von JMS) |
|
ENKO | Energiekorridore |
|
EU | Entwicklungsumgebung |
|
EV | Entscheidungsverfahren |
|
EVU | Eisenbahnverkehrsunternehmen |
|
FANSE | Fahrdienstleiter Aufschreibungen ANDI und SEBA |
|
FAT | Fachlicher Abnahmetest |
|
FBN | Fahrplanbearbeitungsbereiche |
|
FDL | Fahrdienstleiter (Aufschreibung) |
|
FPLO | Fahrplananordnung |
|
FPP | Fahrplanperiode |
|
FV-NE | Fahrdienstvorschrift Nichtbundeseigene Eisennahn |
|
GeKo | Geschwindigkeitskonzeption |
|
GF | Geschäftsfelder |
|
GFD-I | Gemeinsame Fahrplandaten Infrarstruktur |
|
GFD-Z | Gemeinsame Fahrplandaten Zugdaten |
|
GLAD | Gleisanschlussdatenbank |
|
GLV | Gelegenheitsverkehr |
|
IAK | Invest auf Kundenwunsch |
|
IAV | Infrarstruktur Anschlussverträge |
|
IAVEN |
|
|
IAV DB |  Infrarstruktur Datenbank |
|
IAV mit IPS |
|
|
IDA | Infrarstrukturdatenaktualisierung |
|
INB (früher NBN) | Infrastrukturnutzungsbedingungen |
|
IRE |  Innenraumreinigung |
|
IO | Infrastrukturobjekt (SAP-Datensatz) |
|
IU | Integrationsumgebung |
|
JMS | Java Messaging Service |
|
KatAna | Kapazitäts- und Analysetool |
|
KDV | Kundendatenversorgung (Service)     |
|
KV | Koordinierungsverfahren |
|
KVDB - Nr. | Kundenvertriebsdatenbank - Nummer? |
|
LGA | Logistikgleisanfrage |
|
LGK | Langfristige Gebundenen Kapazitäten (dazu gehören LV, MV und IAK) |
|
LKD | Logisch kompletter Datensatz |
|
LV | Langlaufender Vertrag |
|
MV | Mehrjahresvertrag |
|
NBN | Nutzungsbedingung Netz der DB Netz AG |
|
NBS | Nutzungsbestimmungen |
|
NFP | Netzfahrplan |
|
Nfpl | Netzfahrplan |
|
NO / NOs | Nutzungsobjekt (vermarktbares APN-Objekt) |
|
NSS | Normierte Schnittstelle |
|
NV | Nichtverfügbarkeit |
|
O2C | Order 2 Cash |
|
PU | Produktivumgebung |
|
RB | Regionalbereich |
|
RIS  | Reisendeninformationssystem |
|
RUT-K | Rechnerunterstüztes Trassenmanagement Konstruktion |
|
SAG | Software AG  (Softwarehersteller von Webmethods, mit der das Frontend von APN implemtiert ist) |
|
SAT | System und Abnahmetest |
|
SE | Serviceeinheiten |
|
SE | Serviceeinrichtung |
|
SEAZ | Serviceeinrichtungen-Anreizsystem (Abrechnungspositionen) |
|
SEBA | Sichere Ermittlung beim Abstellen auf Trassengleisen |
|
SEVEN |
|
|
SGV | Schienengüterverkehr |
|
Soap UI | Soap User Interface |
|
SOS
|
|
|
SPV
| Schienenpersonenverkehr |
|
SPFV | Schienenpersonenfernverkehr |
|
SPNV | Schienenpersonennahverkehr |
|
Spurplan |
|
|
SSO | Single-Sign-On |
|
SST | Schnittstelle (SAP-Datenlieferung) |
|
TabuFa | Tageaktueller Buchfahrplan |
|
TAT | Technischer Abnahmetest |
|
TBF | Technische Betriebsführung |
|
TFZ | Triebfahrzeug |
|
TIBCO | The Information Bus Company (Softwarehersteller von BusinessWorks und EMS |
|
TP | Technischer Platz |
|
TPN | Trassenportal Netz |
|
TPS |
|
|
Trafo | Transformation |
|
TS | Teamserver |
|
tVe | technische Verfügbarkeitseinschränkung |
|
VMSE | Vermarktung Serviceeinrichtungen |
|
VOV | Vorsystem |
|
VTS | Verkehrstagesschlüssel |
|
VzG | Verzeichnis der örtlich zulässigen Geschwindigkeiten |
|
WIP | Work in progress |
|
ZA | Zusatzausstattung |
|
ZB | Zugangsberechtigte |
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
faInfoCircleZusätzliche Quellenhttp://www.bahnseite.de/purespace/Abkuerzungen.html
https://db-planet.deutschebahn.com/pages/konzeptionen-aim-fuer-dsd/apps/wiki/abkuerzungen/list/view/6c2f7157-c87f-45b8-83d1-2a9a9d8bdb23?currentLanguage=NONE
Bereich APN durchsuchen:
bahn/Analyse-O2C-C2S/sources/o2c/O2C-APN/teams/10-2-Team-Migration.md
+29
View File
@@ -0,0 +1,29 @@
# 10.2 Team Migration
Version: 9 | Last modified: 2026-01-29T07:11:53.943+01:00
Source: confluence page ID 525205609
---
Team Migration ab 2026:
  | Team Migration | Status |
1
| Markus Fritzsche (BA) 
| Extern angestellt |
2 | Jonas Spiegel (ScM) | DB Systel |
3 | Michael Mats (BA) | DB Systel Team DigiSec |
4 | Feyzi Erden (RE)  | DB Systel Team HEROS |
5 | Georgios Chatziefstratiou (Dev) | DB Systel Team DAS (ab 2026) |
6 | Sebastian Menrath (Dev) | Extern angestellt |
7 | Hüseyin Korkut (Dev) | Extern angestellt |
8 | Alexandra Thöne (UX) | Extern angestellt |
9 | Anais Casanova (Test) | Extern angestellt |
10 | Gael Tchatchou (Dev) | Extern angestellt |
11 | Khalid Aaliuate (Dev) | DB Systel Team TPT |
12 | Mads Kristian Hansen (Dev) | DB Systel Team Tops |
13 | N.N. (Dev) | - |
14 | Kouassi Sepenou Klousseh (QA) | DB Systel Team A4DB |
15 | Kenan Esau (Dev) | Extern angestellt |
16 | Michael Haslauer (Dev) | Extern angestellt |
17 | Rainer Schuster (Dev) | Extern angestellt |
bahn/Analyse-O2C-C2S/sources/o2c/O2C-APN/teams/2-2-APN-Beteiligte-Teams.md
+12
View File
@@ -0,0 +1,12 @@
# 2.2 APN Beteiligte Teams
Version: 5 | Last modified: 2026-01-15T14:43:31.872+01:00
Source: confluence page ID 513446330
---
DB InfraGO ART Order2Cash (O2C)Team NEO
Team Migration
Team Fachliche Betriebsführung
Team Technische Betriebsführung (fällt ab November 2026 weg)
Diverse Schnittstellenpartner
bahn/Analyse-O2C-C2S/sources/o2c/O2C-APN/teams/APN-Migration-Team.md
+19
View File
@@ -0,0 +1,19 @@
# APN Migration - Team
Version: 54 | Last modified: 2025-06-04T13:41:14.131+02:00
Source: confluence page ID 178881227
---
ProduktvisionWir stellen APN auf moderne Technologien um, damit es in Zukunft ohne die Produkte von Tibco und Software AG auskommt.
Die Anwendung soll einfach zu benutzen, robust und sicher sein. 
Umgebungen APN 2.0Infrastruktur | Stage | URL |
Entwicklung | DEV (TS1) | https://apn-dev.apn-iat.cnp-test.comp.db.de |
Feature Abnahme | TEST (TS2, Wartung) | https://apn-wartung.apn-iat.cnp-test.comp.db.de |
| Common GUI | https://apn-dev.apn-iat.cnp-test.comp.db.de/apn-gui-common |
Integration | IU | https://apn-iu.apn-iat.cnp-test.comp.db.de |
Abnahme | AU  | https://apn-au.apn-abn.cnp-test.comp.db.de |
Produktion | PU  | https://apn-prod.apn-prod.cnp.comp.db.de |
RoadmaptrueRoadmap V2falseautotoptrue16425
Sprint AblaufSprint Ablauf11069446841343
bahn/Analyse-O2C-C2S/sources/o2c/O2C-APN/teams/APN-Team-Neo-DoR-DoD.md
+12
View File
@@ -0,0 +1,12 @@
# APN Team Neo DoR + DoD
Version: 3 | Last modified: 2025-12-17T19:11:32.627+01:00
Source: confluence page ID 528160381
---
Erster Entwurf von Marius - auf Basis diverser DoDs von O2C, anderen Teams und Vorgaben der I.IVI 12 der DB InfraGO 8.2 APN Aktuelle Orgathemen - O2C | Order2Cash - ariJa Confluence
DoR
DoD
bahn/Analyse-O2C-C2S/sources/o2c/O2C-APN/teams/APN-Wartung-Weiterentwicklung-Teams.md
+8
View File
@@ -0,0 +1,8 @@
# APN Wartung & Weiterentwicklung - Teams
Version: 13 | Last modified: 2023-12-19T15:45:58.776+01:00
Source: confluence page ID 290164572
---
1{"body":{"text":{"color":"#465671","textAlign":"center","fontWeight":"normal","fontSize":14}},"header":{"backgroundColor":{"color":"#0149b0"},"icon":{"size":26,"name":"faBolt","color":"#fff"}},"headline":{"text":{"text":"APN Wartung & Weiterentwicklung Roadmap","color":"#fff","textAlign":"left","fontWeight":"normal","fontSize":18},"alignment":{"horizontal":"center"}},"base":{"backgroundColor":{"color":"#ffffff"},"border":{"color":"#0049b0","style":"solid","width":1,"bottom":true,"top":false,"left":true,"right":true},"borderRadius":{"radius":4},"boxShadow":{"shadows":[{"color":"rgba(0, 0, 0, 0.08)","x":0,"y":1,"blur":1,"spread":0},{"color":"rgba(0, 0, 0, 0.16)","x":0,"y":1,"blur":3,"spread":1}]}}}Roadmap APN Weiterentwicklung und Wartung.xlsx
bahn/Analyse-O2C-C2S/sources/o2c/O2C-APN/teams/APN-Wartung-Weiterentwicklung.md
+8
View File
@@ -0,0 +1,8 @@
# APN Wartung & Weiterentwicklung - Teams
Version: 13 | Last modified: 2023-12-19T15:45:58.776+01:00
Source: confluence page ID 290164572
---
1{"body":{"text":{"color":"#465671","textAlign":"center","fontWeight":"normal","fontSize":14}},"header":{"backgroundColor":{"color":"#0149b0"},"icon":{"size":26,"name":"faBolt","color":"#fff"}},"headline":{"text":{"text":"APN Wartung & Weiterentwicklung Roadmap","color":"#fff","textAlign":"left","fontWeight":"normal","fontSize":18},"alignment":{"horizontal":"center"}},"base":{"backgroundColor":{"color":"#ffffff"},"border":{"color":"#0049b0","style":"solid","width":1,"bottom":true,"top":false,"left":true,"right":true},"borderRadius":{"radius":4},"boxShadow":{"shadows":[{"color":"rgba(0, 0, 0, 0.08)","x":0,"y":1,"blur":1,"spread":0},{"color":"rgba(0, 0, 0, 0.16)","x":0,"y":1,"blur":3,"spread":1}]}}}Roadmap APN Weiterentwicklung und Wartung.xlsx
bahn/Analyse-O2C-C2S/sources/o2c/O2C-APN/teams/Arbeitsweisen-im-Team-Migration.md
+10
View File
@@ -0,0 +1,10 @@
# Arbeitsweisen im Team Migration
Version: 2 | Last modified: 2026-02-24T09:32:30.725+01:00
Source: confluence page ID 553944594
---
Allgemeiner Überblick über wie arbeiten wir als Team.
Â
bahn/Analyse-O2C-C2S/sources/o2c/O2C-APN/teams/ITERATIVES-TESTING-FÃ-R-TEAM-MIGRATION.md
+88
View File
@@ -0,0 +1,88 @@
# ITERATIVES TESTING FÜR TEAM MIGRATION
Version: 40 | Last modified: 2026-02-03T10:40:59.868+01:00
Source: confluence page ID 301350453
---
TESTCOVERAGE ZIELBILD
(Team Migration)
> Präsentiert in der MiKo am 21.2.2025
BAUSTEINE DES QA-IMPLEMENTIERUNGSKONZEPTS
Präsentiert im PIP 37 (25.6.2025) und PIP 38 (17.9.2025)
(in Umsetzung seit März 2024 in Team Migration)
AGILES TESTING
Vorgestellt PIP 34 (11.9.2024)
Wir wollen APN2.0 Workflows abbilden und anhand der Workflows Test Repository aufbauen.
TESTKONZEPT
Vorgestellt PIP 33 (12.6.2024, extra Folie), siehe Folien PIP 34 als Rückblick 11.9.2024
trueTestingfalseautotoptrue8205
Offene Fragen : 
X-Ray über 3 Teams = 3 x Jira aktuell, die Testfälle sind aber übergreifend (Vorschlag : eigenes Jira und von dort aus verknüpfen)
Branching Konzept für die Cypress Tests
Konzept, wann welche Tests ausgeführt werden
IMPELENTATION STEPS FOR END2END TESTING 
(gehört zum obigen Schaubild (Implementierungsanleitung), wurde in Einzelevents POs + SCMs vorgestellt)
Pipelines Testing APN Migration 
e2e Test: 
- Belegungsplan 
Voraussetzungen 
- Ein Projekt in GitLab, für das Sie CI/CD verwenden möchten. 
- Die Rolle Maintainer oder Owner für das Projekt. 
Schritte 
1.Stellen Sie sicher, dass Sie über Runner verfügen, die Ihre Aufträge ausführen können. (Wenn Sie GitLab.com verwenden, können Sie diesen Schritt überspringen. GitLab.com stellt Instanz-Runner für Sie bereit.) 
2.Erstellen Sie eine Datei .gitlab-ci.yml im Stammverzeichnis Ihres Repositorys. In dieser Datei definieren Sie die CI/CD-Jobs. 
Stellen Sie sicher, dass Runners verfügbar sind 
- Gehen Sie zu Einstellungen > CI/CD und erweitern Sie Runners. 
Wenn Sie keinen Runner haben 
1.Installieren Sie GitLab Runner auf Ihrem lokalen Rechner. 
2.Registrieren Sie den Runner für Ihr Projekt. Wählen Sie den Shell-Executor. 
Erstellen Sie eine .gitlab-ci.yml-Datei 
1.Wählen Sie in der linken Seitenleiste Code > Repository. 
2.Wählen Sie oberhalb der Dateiliste den Zweig aus, an den Sie die Datei übergeben möchten. 
3 Geben Sie als Dateinamen .gitlab-ci.yml ein. 
wählen Sie Änderungen festschreiben.
Anzeigen des Status Ihrer Pipeline und Aufträge 
1.Gehen Sie zu Build > Pipelines. Es sollte eine Pipeline mit drei Stufen angezeigt werden. 
2.Zeigen Sie eine visuelle Darstellung Ihrer Pipeline an, indem Sie die Pipeline-ID auswählen. 
3.Zeigen Sie Details zu einem Auftrag an, indem Sie den Auftragsnamen auswählen. Zum Beispiel: deploy-prod 
 
SHORTENING TEST CYCLE 
Wurde im PI Anfang (März / April) 2024 umgesetzt und in diversen Einzelrunden: Janne, Andrea, Masut, mit allen Testern vorgestellt.
How to handle features once it reaches testing phase:
Run test cycle for one feature repeatedly until test is sucessfull: test, fix, deliver
One feature with all its test cycles should be finalized in one sprint
TEST CASES ERSTELLEN UND AUTOMATISIEREN
TBD
API Testing
> Präsentiert im PIP XX und Präsentiert in der MiKo am 21.2.2025
SIT - System Integration Test (Automation Pipeline)
> Präsentiert im PIP 38, 17.9.2025
Der Testautomatisierer liefert Code.
GitLab übernimmt das Bauen, Testen und Paketieren.
Das fertige Paket landet in der Registry.
Von dort aus wird es automatisch in die SIT-Umgebung deployt.
Dort läuft es in Pods und tauscht sich mit allen angebundenen Systemen aus.
Damit haben wir einen durchgängigen, weitgehend automatisierten Prozess, der sicherstellt, dass Änderungen schnell, reproduzierbar und konsistent in eine Testumgebung gebracht werden.
Regression Testing
> Präsentiert im PIP 37, 25.6.2025
Manuelles Testing in Sprints
> Präsentiert im PIP 38, 17.9.2025
bahn/Analyse-O2C-C2S/sources/o2c/O2C-APN/teams/Retrospektiven-Team-Neo.md
+54
View File
@@ -0,0 +1,54 @@
# Retrospektiven Team Neo
Version: 5 | Last modified: 2026-03-03T08:15:03.294+01:00
Source: confluence page ID 551029606
---
Themensammlung:
31
42dbae4d-d569-42c3-856b-4be6687c55a4
incomplete
Zusammenarbeit im Team
32
ae2c4a9a-f548-40a8-b642-99f5eba0f2c2
incomplete
Zusammenarbeit mit Team Migration / Zusammenarbeit im ART (Richtung Ende des PI - bei I&A)
33
6ccfabb7-d393-4aa1-96fe-482b575ff71c
incomplete
Retro auf das Retro Vorgehen
34
d2ce8d56-8ee8-4ce2-8cc4-c2a32fd9b46a
incomplete
Retro auf weitere Meetings
35
e7444ea1-d4d2-47dc-bb1a-cf586be65b2b
complete
Retro zum Stories schätzen: wie werden wir besser, was sind unsere Problemfelder
39
8a1e56be-7a39-4b80-a660-73da7a41c09c
complete
Review zu Story-Umfang: sind unsere Stories zu groß, da sie immer nur am Ende des Sprints fertig werden
Wir wollen keine Stories >5 pro Sprint angehen - diese werden kleiner geschnitten.
Wir wollen konservativer Schätzen
Wir wollen mehr explizit die Komplexität mit betrachten / einschätzen
36
1f16aace-2eeb-4633-bfc4-be321a423af0
incomplete
Retro zum Story Review: wie bekommen wir das „smoother“ und pro-aktiver hin: Verweildauer „in Review“ weniger
37
ff5bb4e0-ed39-4fdc-8662-e36d54f13a0e
incomplete
Learnings aus unseren Retros (werden den Team-Regeln hinzugefügt)Wir benennen einen "Schreiber", sollten wir technisch / fachlich in unseren Meetings diskutieren, um die Erkenntnisse daraus nicht zu verlieren
Wir validieren Story Points im Review
bahn/Analyse-O2C-C2S/sources/o2c/O2C-APN/teams/Story-Template-Team-OnePiece.md
+83
View File
@@ -0,0 +1,83 @@
# Story Template - Team OnePiece
Version: 3 | Last modified: 2025-09-05T10:38:01.964+02:00
Source: confluence page ID 485040169
---
TitelAPN (Komponente): Titel 
Titel: Was gemacht wird -> ähnlich zu Git-Commits (Imperativ)
AkzeptanzkriterienDie Akzeptanzkriterien sollen einen bestimmten Zustand oder ein bestimmtes Verhalten der Komponente beschrieben. Im idealen Fall ist jedes einzelne AK unabhängig voneinander testbar und erfüllbar.
Akzeptanzkriterien sollten möglichst in Gherkin-Schreibweise als testbares Szenario beschrieben sein. Die Formulierung sollte immer im positiv geschrieben sein, selbst bei einem Szenario mit negativem Ausgang. Das hat gleich mehrere Vorteile:
Bessere Verständlichkeit
Positive Aussagen sind für Fachbereiche und Nicht-Entwickler leichter zu lesen.
Beispiel:
Negativ: Then the user is not logged in
Positiv: Then the user stays on the login page
→ Die zweite Variante beschreibt klarer, was tatsächlich passiert.
Eindeutigkeit
Negative Formulierungen führen oft zu Interpretationsspielraum („nicht eingeloggt“ – heißt das: Fehlermeldung? Zurück zur Loginseite? Einfach nichts passiert?).
Positive Formulierungen beschreiben ein beobachtbares Ergebnis.
Bessere Testautomatisierung
Tests lassen sich einfacher prüfen, wenn ein klarer Zustand überprüft wird.
Positiv: Then I see an error message "Invalid credentials"
Negativ: Then I do not see the dashboard
→ Beim negativen Test könnte der Test "bestehen", auch wenn etwas völlig anderes angezeigt wird (z. B. eine leere Seite).
Weniger kognitive Belastung
Menschen müssen bei Negationen öfter gedanklich „um die Ecke denken“.
Positiv formulierte Szenarien sind intuitiver nachzuvollziehen.
Eine Schablone dafür wäre:
Scenario: Komponente XYZ macht etwas
Given ein bestimmter Input 
Given eine mögliche Bedingung
When eine bestimmte Aktion oder Situation geschieht
Then wird ein bestimmtes Verhalten beobachtet
Then ist eine bestimmtes Ergebnis eingetreten
Es sollte immer mindestens ein Positiv- und ein Negativ-Beispiel vorhanden sein.
DetailbeschreibungZu klärende Fragen:
Was soll in der Story geschehen?
Welche Vorbedingung soll erfüllt sein?
Was ist der Nutzen, den diese Story kreiert?
Fachliche BeschreibungFachliche Einordung der Anforderung in den Business Kontext
Gerne auch eine grafische Übersicht mit Figma:
Technische InformationenFür die Umsetzung hilfreiche Informationen, Links etc.
SST-Beschreibung
Beispiel-Datenset
AusblickGibt es Auswirkungen auf andere Komponenten?
Out-of-ScopeWas soll nicht getan werden?
NFAVerfügbarkeit?
Umgang mit Daten?
Monitoring?
Skalierbarkeit?
ReminderDefinition of Ready:Vor Refinement von PO/BA's zu klären:* Die USER-Story ist ins Gesamtprojekt eingeordnet ("Als ... möchte ich, dass..., WEIL..."). Motivation wird erklärt und These über Nutzen der Story aufgestellt.
* Akzeptanzkriterien sind formuliert (wünschenswert: konkretes BDD given/when/then, Example-Mapping)
* Zusammenstellung verfügbarer fachlicher Dokumentation (verlinkt oder direkt in der Story)
* Verfügbarkeit der Testdaten ist geklärt
* Abhängigkeiten zu anderen Teams im Projekt oder extern sind geklärt
* Story kann nicht fachlich sinnvoll kleiner geschnitten werden
Vor Schätzung einer Story von den Entwicklern zu klären* Identifikation der betroffenen (Software)-Komponenten (intern und extern)
* Aktueller Zustand der betroffenen Software-Komponenten
* Testbarkeit ist abgeklärt
* Notwendige Zugangsdaten/Tools sind bekannt
* Abhängigkeiten zu anderen Stories oder Teams
* Verfügbare technische Dokumentation ist bekannt
* Story kann nicht technisch sinnvoll kleiner geschnitten werden
bahn/Analyse-O2C-C2S/sources/o2c/O2C-APN/teams/Teams-Chat-Teams-KanÃ-le.md
+28
View File
@@ -0,0 +1,28 @@
# Teams-Chat / Teams-Kanäle
Version: 3 | Last modified: 2024-02-15T11:36:02.611+01:00
Source: confluence page ID 314182207
---
Wofür benötigen wir einen eigenen Kanal?Für Announcements (keine Diskussion)Wer reported: PM, PO (SCM), SysArch
Wer hört zu: Alle Teams
Wer reagiert: Keine Interaktion vorgesehen über diesen Channel. Bei Diskussionsbedarf PM
Für Prod-Issues/Incidents:Wer reported: FB, PO, PM
Wer hört zu: PO's, SCM!? Fachbereich, Value-Ops'ler
Wer reagiert: PO's deligieren/verteilen und informieren Issuebezogen über den Stand
Welche Inhalte werden gepostet;Fehler in Produktion
Systemausfälle
Schwerlast
Staging Issues:Wer reported: Tester, Fachbereich, Devs (app, Infrastruktur)
Wer hört zu: TO BE DISCUSSED
Wer reagiert: jeweils ein Verantwortlicher(PO?) antwortet auf die initiale Info-Messsage, deligiert und informiert über Stand
APN All Stars:Wer
.
.
Welche Inhalte:
Monitoring Board Serviceübersicht (eigene App)Weiteren Ausbau gestalten und planen
bahn/Analyse-O2C-C2S/sources/o2c/O2C-APN/teams/deprecated-ask-Team-Neo-APN-Arch-Eigenbedarf-Backend-2-0.md
+106
View File
@@ -0,0 +1,106 @@
# <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:
bahn/Analyse-O2C-C2S/sources/o2c/O2C-APN/teams/Ã-bergabeprotokoll-â-Testautomatisierung-QualitÃ-tssicherung-im-APN-Team-NEO.md
+116
View File
@@ -0,0 +1,116 @@
# Übergabeprotokoll – Testautomatisierung & Qualitätssicherung im APN Team NEO
Version: 8 | Last modified: 2026-01-14T11:49:29.717+01:00
Source: confluence page ID 533416420
---
Dieses Dokument beschreibt die durchgeführten Test- und Automatisierungsaktivitäten im Rahmen der Projektübergabe.
Aktuell werden zwei Frontends parallel durch das Testteam betrieben und getestet (alte Welt APN-Classic auf der EIP-Plattform / neue Welt APN 2.0).Aufgaben im Bereich EIP / APN-Classic
Selenium-Testfälle AllgemeinDas Projekt wurde ursprünglich von einer externen Automatisierungsexpertin aufgebaut. Die Testfälle wurden in Java mit Selenium und Cucumber implementiert.
Repository URL: https://git.tech.rz.db.de/apn/quality-assurance/apntestsuite
Die Tests werden in 8 Threads parallel ausgeführt. Laufzeit ± 1 Stunde.
Secret-Handling (CNP):Die Secrets des Automatisierungsprojekts werden zur Job-Laufzeit aus dem AWS Secretmanager geladen. Der Zugriff erfolgt je nach Job und Umgebung (Stage).
TS1: /run/secrets/testautomation--apn-dev/gitlabrunner--testautomation--apn-dev
TS2: /run/secrets/testautomation--apn-wartung/gitlabrunner--testautomation--apn-wartung
IU: /run/secrets/testautomation--apn-iu/gitlabrunner--testautomation--apn-iu
AU: /run/secrets/testautomation--apn-abn/gitlabrunner--testautomation--apn-abn
Testfallmanagement & Reporting (Jira / Xray) Die Testfälle werden in Jira (Xray) gemanaged.
Insgesamt sind ca. 150 Testfälle in Jira angelegt
Das Xray-Reporting erfolgt automatisiert über die CI/CD-Pipeline
Nach jeder Ausführung wird der Report im folgenden Test-Plan-Ticket hochgeladen: das I.NVI IT Lifecycle Management Toold1143f0d-33c0-3f1c-b44b-7720150f306eO2CAPN-7935
Fehlgeschlagene Testfälle werden lokal auf dem Rechner nachgetestet. Bei erfolgreichem Retest wird der Status im Test-Plan auf PASS gesetzt.
Für den Upload der Reports nach Jira wird ein persönlicher API-Token verwendet, der 365 Tage gültig ist. Nach Ablauf muss ein neuer Token erstellt und in CNP deployt werden. Dazu bitte im Team fragen.
Zusätzlich steht der Cucumber-Report auch in den Job-Artifacts der Pipeline zur Verfügung.
CI/CD-Konfiguration & TestjobsDie gitlab-ci.yml ist so aufgebaut, dass pro Umgebung ein eigener Stage definiert ist. Ist abgelegt unter: Pipelinetemplates Projekt
Innerhalb jedes Stages sind die jeweiligen Ausführungsjobs hinterlegt. Ausnahme: TS1, da dort überwiegend vollständige Regressionstests ausgeführt werden.
Verfügbare Jobs pro Stage:Smoke Tests
Test der Grundfunktionalitäten
Geplant über Pipeline Schedule täglich um 07:45 Uhr auf allen Umgebungen
Security Tests
Aufruf bestimmter webMethods-Seiten mit Anmeldung
Prüfung, ob angemeldete Benutzer Zugriff haben
Durchstich Tests
Ausführung der Durchstich-Testfälle
Ebenfalls täglich um 07:45 Uhr auf allen Umgebungen
Security Tests (Anonym)
Aufruf bestimmter webMethods-Seiten ohne Anmeldung
Prüfung, dass nicht angemeldete Benutzer keinen Zugriff haben
Full Regression Tests
Werden nach jeder erfolgreichen Lieferung ausgeführt
(z. B. nach Deployment auf AU)
Hotfix Tests
Nach jedem Hotfix werden folgende Jobs ausgeführt:
Security
Security Anonymous
Smoke Tests
Hotfix Tests
Selektiv
Ermöglicht die gezielte Ausführung einzelner Testfälle, die entsprechend getaggt sind
Manuelle Tests & Bug-RetestsDurchführung manueller Tests bei:
Bugfixes
neuen Feature-Implementierungen
Die Tests werden als Unteraufgabe mit dem Titel „Test“ im Jira-Board zugewiesen
Bei Fragen oder Auffälligkeiten erfolgt eine direkte Abstimmung mit dem jeweiligen Entwickler
Aufgaben im Bereich APN 2.0Testautomation Dashboard: https://arija.jaas.service.deutschebahn.com/secure/Dashboard.jspa?selectPageId=37600Testautomatisierung & ReportingIntegration von Cypress inklusive Xray-Reporting
Cypress-Projekt-Repository:
https://git.tech.rz.db.de/apn/quality-assurance/apn-cypress
Verwendung von Pipeline-Modulen des PipelineTeams der MoQ-AP
Einbindung und Nutzung von AWS Secret Keys
Xray-Reporting:
Bei jeder Ausführung wird das Ergebnis in den entsprechenden Jira Test-Plan hochgeladen:  das I.NVI IT Lifecycle Management Toold1143f0d-33c0-3f1c-b44b-7720150f306eO2CAPN-8281
Wichtig: Der Upload der Testergebnisse nach Jira (Xray) erfolgt derzeit nicht automatisch, sondern wird über einen manuell auszulösenden CI/CD-Job (rule: manual) gesteuert.
Für eine automatische Ausführung muss diese Rule entfernt werden.
Ressourcen für die Testfall ErstellungAnlage der Testfällen in Jira auf Basis von:
Definierter Workflows: https://arija-confluence.jaas.service.deutschebahn.com/spaces/BES/pages/464844624/Workflows+Logistkgleise+und+GLAD
Bestehender Diagramme und Konzepte: 
Figma: https://www.figma.com/file/qq3zIZ7ZCvGGw0lOZ3n8DV/apn
4-Augen-Prinzip
Review der angelegten Testfälle gemeinsam mit TestManager und BusinessAnalyst
Ablage der Testfälle in JiraGLAD: https://arija.jaas.service.deutschebahn.com/secure/XrayTestRepositoryAction!default.jspa?entityKey=O2CAPN&path=APN%202.0%2FGLAD
Logistikgleise: https://arija.jaas.service.deutschebahn.com/secure/XrayTestRepositoryAction!default.jspa?entityKey=O2CAPN&path=APN%202.0%2FLogistikgleise
Manuelle Tests & Bug-RetestsDurchführung manueller Tests bei:
Bugfixes
neuen Feature-Implementierungen
Zuweisung über Jira-Unteraufgabe mit dem Titel „Test“
Abstimmung bei Fragen direkt mit dem jeweiligen Feature-Entwickler
Hinweis für die ÜbergabeSelenium wird ausschließlich für die Regression der alten Welt genutzt
Cypress ist das strategische Zielsystem für die neue Welt (APN 2.0)
Weitere Erweiterungen der Testabdeckung sollten ausschließlich in Cypress erfolgen für die neue Welt, da EIP zum 12/2026 abgeschaltet wird.Â