Migrate all repos into monorepo context folders
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:
+59
@@ -0,0 +1,59 @@
|
||||
# 2020-12-14 Userstory Pipeline Planning
|
||||
|
||||
> Confluence Page ID: 105775927
|
||||
> Version: 4
|
||||
> Pfad: /pathOS/Kommunikationskanäle, Termine, Besprechungsnotizen pathOS/Besprechungsnotizen/Sonstige Termine/2020-12-14 Userstory Pipeline Planning
|
||||
> Labels: meeting-notes
|
||||
|
||||
---
|
||||
|
||||
## Datum
|
||||
|
||||
|
||||
Anwesend:Â Â Â Â
|
||||
## Abstimmung des internen Datenformats
|
||||
|
||||
In Vorbereitung auf PI 19 muss entschieden werden, in welchem Format die Daten bestellsystemintern vorgehalten und verarbeitet werden. ZielgröÃen sind Wartbarkeit, Versionierbarkeit und Minimierung von Abhängigkeiten nach auÃen.Â
|
||||
## Fragestellung
|
||||
|
||||
Folgende Alternativen stehen zur Entscheidung:Â
|
||||
| | Variante |
|
||||
- Neues internes Datenmodell | 2. Interne Verwendung von TAF/TAP | 3. Portal-Datenmodell
|
||||
| | Bewertung |
|
||||
- Vorleistung wegen fehlendem IFP-Modell notwendig
|
||||
- Konvertierung
|
||||
- CI von TAF/TAP XML
|
||||
- SV zum IFP- und AC-Modell
|
||||
- Portal-MW aus dem eigenen Modell (kann ggfls. auch umgestellt werden)
|
||||
- SV und AV müssten umgestellt werden, da sie aktuell noch TAF/TAP XML nutzen |
|
||||
- Konvertierung
|
||||
- SV von TAF/TAP XML zu IFP- und AC-Modell
|
||||
- Portal-MW aus dem eigenen Modell zu TAF/TAP XML
|
||||
- Update der TAF/TAP Versionen weiterhin problematisch
|
||||
- spätere Migration auf 1 oder 3 möglich, aber relativ aufwändig |
|
||||
- Qualität und Reifegrad unklar
|
||||
- Konvertierung
|
||||
- CI von TAF/TAP XML zum Portal-Modell
|
||||
- SV vom Portal-Modell zu IFP und AC
|
||||
|
||||
|
||||
|
||||
Variante 1: Neues internes Datenmodell
|
||||
|
||||
Variante 2: Interne Nutzung von TAF/TAP
|
||||
|
||||
Variante 3:Â Portal-Datenmodell
|
||||
## Entscheidung
|
||||
|
||||
Die Wahl fiel auf Variante 1. Diese soll möglichst nah am TAF/TAP-Modell gehalten werden, da dieses fachlich richtig erscheint und es zumindest innerhalb der Vertriebs-Domäne wenig Veranlassung gibt, davon abzuweichen. In PI 19 soll das interne Datenmodell nahe an TAF/TAP weiterentwickelt werden (gröÃtenteils BE-Tätigkeit). Mögliche Anpassungen / Weiterentwicklungen sind:Â
|
||||
- Entfernung von Redundanzen (z.B. Location-Code und -Name)
|
||||
- Präzisierung des Datentyps bei nationalen Parametern, die in TAF/TAP immer als Zeichenkette modelliert sind.
|
||||
- Interne Umstellung von xml auf json
|
||||
## Vorbereitung PI-Planning
|
||||
|
||||
Zu den in PI 19 vorgesehenen Features gibt es folgende Anpassungen:Â
|
||||
- Anbindung Bestellsystem an IFP: Muss auf einen technischen Durchstich beschränkt werden, weil seitens IFP die Schnittstelle in PI 19 noch nicht implementiert wird und fraglich ist, ob die Modellierung in PI 19 feststeht.Â
|
||||
- Einführung eines internen Datenmodells: siehe oben
|
||||
- Anbindung Portal an Backend: Wird aus PI 19 geschoben, weil das interne Datenmodell noch nicht klar ist.
|
||||
- Geschäftsprozess Gelegenheitsverkehr in Camunda abbilden (Single PRM): Aufgaben aus PI 18 müssen noch umgesetzt werden. Im Fokus ist hier der Prozess bis Vertragsschluss. Nachträgliche Vertragsanpassungen / Stornierungen sind nicht Teil des Features.Â
|
||||
- Umgang mit 1:n an Vertriebsschnittstelle: Schwappt aus PI 18 rüber.Â
|
||||
+50
@@ -0,0 +1,50 @@
|
||||
# 2021-02-01 Besprechungsnotizen AC Trasse- Bestellsystem
|
||||
|
||||
> Confluence Page ID: 112328767
|
||||
> Version: 3
|
||||
> Pfad: /pathOS/Kommunikationskanäle, Termine, Besprechungsnotizen pathOS/Besprechungsnotizen/Sonstige Termine/2021-02-01 Besprechungsnotizen AC Trasse- Bestellsystem
|
||||
> Labels: meeting-notes
|
||||
|
||||
---
|
||||
|
||||
## Datum
|
||||
|
||||
|
||||
## Teilnehmer
|
||||
|
||||
-
|
||||
@erwähnen Sie eine Person, um diese als Teilnehmer hinzuzufügen und darüber zu informieren.
|
||||
## Zusammenfassung der ErgebnisseÂ
|
||||
|
||||
-
|
||||
Folgend noch mal die Zusammenfassung der Ergebnisse vom Termin am 17.12.20:
|
||||
- Es wird 2 Services zwischen dem Bestellsystem und AC geben:
|
||||
- Service BestellsystemAdapterAbrechnung -> Preisauskunft, Abrechnung, Vertragsänderungen, Ablehnung von Angebote für Abrechnung Angebotserstellungsentgelt, Prüfung Bonität vor Versand Vertragsbestätigung
|
||||
- Service BestellsystemAdapterDokumentation -> Kaufmännisch revisionssichere Dokumentation und Archivierung des rechnungsbegründenden Unterlagen aus dem Verkaufsprozess
|
||||
- Der BestellsystemAdapterAbrechnung wird sich an dem von TAF/TAP TSI abgeleiteten Formats des Bestellsystem orientieren. Sobald auf Seiten des Bestellsystem PathRequest und PathDetailMessage beschrieben sind kann in AC-Trasse basierend darauf eine OpenAp 3.0-Defintion des Service bereitstellen und mit der Umsetzung beginnen.
|
||||
- Der Service BestellsystemAdapterDokumentation benötigt die Original-Nachrichten, die in Kommunikation mit dem Kunden empfangen oder versendet werden. Wie dies genau auszusehen hat, v.a. bei Eingaben des PathRequest in der UI des Bestellsystems, muss noch mit PWC abgestimmt werden. Im Nachgang wird AC eine OpenApi-Definition bereitstellen und den Service umsetzen
|
||||
- Roadmap
|
||||
- 01/21 â Abstimmung Anforderungen für kaufmännische Dokumentation der Bestellsystem-Verkaufsbelege mit PWC
|
||||
- 02/21 â Bereitstellung des Service BestellsystemAdapterDokumentation
|
||||
- 03/21 - Umsetzung des Service BestellsystemAdapterDokumentation fertig
|
||||
- Ab 04/21 â Konzeption und Umsetzung des Service BestellsystemAdapterAbrechnung
|
||||
|
||||
|
||||
## Handlungspunkte
|
||||
|
||||
|
||||
2
|
||||
incomplete
|
||||
|
||||
Offene Punkte für die Detaillierung der Roadmap:
|
||||
- Wann kann der Service BestellsystemAdapterDokumentation in der Integration mit dem Bestellsystem getestet werden?
|
||||
- Wann wird die Konzeption des Bestellsystem - internen PathRequest und PathDetail â Fachobjekte abgeschlossen sein, damit die Konzeption des Service BestellsystemAdapterAbrechnung im Detail beginnen kann?
|
||||
|
||||
|
||||
|
||||
|
||||
1
|
||||
incomplete
|
||||
Â
|
||||
- Wir gehen davon aus, dass integrierte Tests zu ~Dokumentation im PI 21 (ca. Q3 dieses Jahr) laufen können
|
||||
- Eine Indikation, wie es mit dem BS-internen OM aussieht, sollte bis Ende Februar lieferbar sein. Ausspezifiziert (im agilen Wortsinn) soll es Ende PI 19, also Ende März, sein. Ich schlage vor, dass wir euch da regelmäÃig auf Stand halten, dann könnt Ihr eventuell schon vorab in die Konzeption einsteigen.
|
||||
+10
@@ -0,0 +1,10 @@
|
||||
# 14 Besprechungsnotizen Vorstudie
|
||||
|
||||
> Confluence Page ID: 115016236
|
||||
> Version: 2
|
||||
> Pfad: /pathOS/Start / Vorstudie Bestellsystem/00_Vorstudie Bestellsystem/14 Besprechungsnotizen Vorstudie
|
||||
> Labels:
|
||||
|
||||
---
|
||||
|
||||
|
||||
@@ -0,0 +1,985 @@
|
||||
# Architekturrunde PathOS
|
||||
|
||||
> Confluence Page ID: 116555799
|
||||
> Version: 743
|
||||
> Pfad: /pathOS/Kommunikationskanäle, Termine, Besprechungsnotizen pathOS/Besprechungsnotizen/Architekturrunde PathOS
|
||||
> Labels:
|
||||
|
||||
---
|
||||
|
||||
Dies ist der Regeltermin um über anstehende Architekturentscheidungen zu sprechen und diese voranzutreiben.
|
||||
Die Ablage der Entscheidungen erfolgt weiterhin in Gitlab.
|
||||
Eine Auflistung hier soll primär der Vorbereitung der Termine dienen, insbesondere um sicherzustellen, dass relevante Entscheider dabei sind.
|
||||
Die aktuelle Version der Architekturbeschreibung findet man hier.
|
||||
Ãltere Termine sind im zu finden.
|
||||
## ADRs in Arbeit
|
||||
|
||||
| | Nr | Titel | Branch | MR
|
||||
| | ADR-72 | Technische Anbindung von Click&Ride an PathOS | <Master> |
|
||||
|
||||
| | ADR-74 | Technische Anbindung von TrassenPortal an PathOS | <Master> |
|
||||
|
||||
| | ADR-75 | Maximierung Verfügbarkeit der genutzten Container-Registries |
|
||||
| https://git.tech.rz.db.de/bestellsystem1/docs/runbook/-/merge_requests/553
|
||||
|
||||
|
||||
## Agenda-Backlog
|
||||
|
||||
|
||||
|
||||
## Agenda 10.4.2026
|
||||
|
||||
- Yellow-Lane soll perspektivisch abgeschaltet werden
|
||||
- Beginn mit ITU Anfang Mai
|
||||
- weitere Informationen folgen
|
||||
- Staging-Pipelines: Momentan laufen die Staging Pipelines auch für HF-Pipelines, dass führt dazu, dass HF-Versionen auf Base, IEU, SIT und E2E eingetragen werden, obwohl sie ggf. nicht mehr mit der jetzigen Release-Version kompatibel sind und ältere Funktionalitäten beinhalten.
|
||||
- keine automatische Ãbernahme von Hotfiix-Versionen in Base-, IEU- und SITx-UmgebungenÂ
|
||||
- Steuerungsparameter an Pipeline, um das Verhalten zu überschreiben
|
||||
- Ticket bei SUPB anlegen
|
||||
- API-Projekt data-model: Â
|
||||
- Das Projekt hat die falsche groupId:Â https://git.tech.rz.db.de/bestellsystem1/apis/data-model/-/blob/master/pom.xml?ref_type=heads#L12
|
||||
- wurde bereits korrigiert â muss in den Apps berücksichtigt werden
|
||||
- Zyklische Abhängigkeit:Â
|
||||
- https://git.tech.rz.db.de/bestellsystem1/apis/api-parent-pom/-/blob/main/pom.xml?ref_type=heads#L473
|
||||
- https://git.tech.rz.db.de/bestellsystem1/apis/data-model/-/blob/master/pom.xml?ref_type=heads#L8
|
||||
- data-model-Abhängigkeit in api-parent-pom soll entfernt werden
|
||||
## Agenda 6.3.2026
|
||||
|
||||
- Vorstellung Entwurf ADR-72 Technische Anbindung von Click&Ride und TrassenPortal an PathOS
|
||||
- Weiterentwicklung Systemtest
|
||||
- Schritt 1: Umstellung auf Plain-JUnit (das I.NVI IT Lifecycle Management Toold1143f0d-33c0-3f1c-b44b-7720150f306eO2CDEVOPS-794)
|
||||
- Schritt 2: TestDataContext entzerren (das I.NVI IT Lifecycle Management Toold1143f0d-33c0-3f1c-b44b-7720150f306eO2CDEVOPS-795)
|
||||
- Bing/Team-Zero: Kafka-Topic Option "retentionMS" vereinheitlichen?
|
||||
- Aktuell in Prod: Topic Tbv-Absicherung mit 365 Tage und alle andere Topics mit 7 Tage.Â
|
||||
- Normale Topics: Standard 7 Tage, bei fachlich abweichender Anforderung wie z.B. TBV oder Stationsportal auch höhere Werte
|
||||
- Error-/DLTs: Standard 30 Tage
|
||||
- Einen einheitlichen Wert für die ABN/SAT-Umgebungen zu finden?
|
||||
- Information: TBV ist eine sensible Schnittstelle. Ãnderungen an der Konfiguration bitte nicht ohne Rücksprache durchführen!
|
||||
- Information:Â Mit TBV ist eine abweichende Retention vereinbart, deshalb muss die Konfiguration so bestehen bleiben.
|
||||
- David/Team-Subp: Sub-Artefakte wie libraries oder apis automatisiert veröffentlichen
|
||||
- Aktuell wurde von Subp Seite eine Umstellung der Pipeline auf "release by tagging only" vorbereitet
|
||||
- Das wurde der CI/CD Runde kritisiert, weil damit zusätzlich nach allen Renovate MRs noch zusätzlich zum Zeitpunkt X manuell eine Version getaggt werden muss und nachgelagert dann alle Apps auf diese neue Version updaten muss.Â
|
||||
- Man möchte das weiterhin der stable Branch ins release-Artifactory veröffentlicht wird.Â
|
||||
- Fragen:
|
||||
- will man das prinzipiell von der Architekturrunde?
|
||||
- wie werden die Version dann gebildet? aktuell ist bspw. bei apis der stable Branch ein semver Pre-Release "next"
|
||||
- Diskussionsergebnis:
|
||||
- Libraries: Händisches Tagging bei manuellen Ãnderungen, Automatismus bei Renovate-Bot-Anpassungen
|
||||
- APIs: Händisches Tagging grundsätzlich sinnvoll zwecks Nachvollziehbarkeit bei Bestellsystem-Releases.
|
||||
## Agenda 6.2.2026
|
||||
|
||||
- Aktuelle Situation in den Pipelines: wurde durch die SIT2 die Situation aus Sicht der Teams besser?
|
||||
- Hat geholfen â Pipelines sind nicht mehr blockiert, wenn manuelle Tests auf der SIT stattfinden
|
||||
- SAT 3 für LuPs und DRT (temporär)
|
||||
- Integration der AV in die Portal-Middleware (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-7720150f306eO2CBS-647)
|
||||
- Refactoring und Code-Cleanup in Portal-Middleware vorab
|
||||
- SAB-Team benötigt ggf. die AV
|
||||
- Höhere Priorisierung von Themen zur Verbesserung der Qualitätssicherung von PathOS
|
||||
- Henrik/OpsSquad: Metrics und Alerts
|
||||
- JVM-Metrics notwendig, um den tatsächlichen Speicherverbrauch auswerten zu können
|
||||
- Jonas/CIB: Umstellung auf https://git.tech.rz.db.de/devex/hardenedimages
|
||||
- Vorschlag Jonas: Verwendung ab Java 25Â
|
||||
- Enabler für Umstellung erstellen â Â
|
||||
- Vorschlag Christian P.: Parallele Pipeline zum Testen der nächsten Major-Version
|
||||
- Auf Applikations-Ebene in MR-Pipelines
|
||||
- Auf Deployment-Ebene wäre es nochmal zu prüfen
|
||||
- Testgrenzen klarer fassen â , Â
|
||||
- API-Informationen in Release-/Hotfix-Tickets mit aufnehmen (Sicherstellung der Abwärtskompatibilität)
|
||||
- eigener Abschnitt für APIs
|
||||
## Agenda 1.12.2025
|
||||
|
||||
- Henning/CIB: Spring Boot 4 Upgrade (Spring Boot 3 OSS EOL 2026-06)
|
||||
- Thema für PI 40 â Enabler â 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-7720150f306eO2CBS-1001
|
||||
- Separater Enabler für JUnit 5 â JUnit 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-7720150f306eO2CBS-1002
|
||||
- Saurav/CIB: Gibt es ein definiertes Konzept oder einen Plan für die Migration auf Camunda 8.8 oder 8.x? In diese Versionen sind zahlreiche Breaking Changes enthalten, die möglicherweise zu Datenverlust in der Produktion führen könnten.
|
||||
https://docs.camunda.io/docs/apis-tools/migration-manuals/
|
||||
- Analyse der notwendigen Migrationsschritte hinsichtlich Aufwand und Risiko im Bestellsystem â Team CIB, Â
|
||||
- Saurav/CIB: Die Blockierungen der SIT Runners führen dazu, dass die gesamte Pipeline stillsteht. Gibt es einen Plan, dieses Problem vor der Produktivsetzung zu verbessern?
|
||||
- Automatisierte SITs nur noch in der Tag-Pipeline; nicht mehr in der Master-Pipeline â Â
|
||||
- Frank/Zero: Logging von Messages (Datenschutz)
|
||||
- Personenbezogene Daten in Logs sind zu maskieren
|
||||
## Agenda 17.11.2025
|
||||
|
||||
- STeam: PostMortem Rotation Artifactory Token
|
||||
- Tokens sollten über Releaseprozess rotiert werden, was aber aus nicht ganz geklärten Gründen nicht funktioniert hat. Frage: Was ist konkret schief gegangen und wie können wir sicherstellen, dass es beim nächsten Mal klappt?
|
||||
- Secrets wurden in umgebungs-konfiguration nicht vollständig ersetzt
|
||||
- TODO: Secrets aufräumen, auf fehlerhafte Secret-Namen prüfen Â
|
||||
- TODO: Struktur in bestellsystem-ops für alle Umgebungen/Cluster usw. vereinheitlichen Â
|
||||
- Manager-Rolle in Artifactory benötigt, um neue Tokens zu generieren (â Berechtigungen prüfen )
|
||||
- Dead Letter Topics:
|
||||
- Einheitliches Namensschema: <Ursprungstopic>-<Consumer>-error
|
||||
- Dokumentation Â
|
||||
## Agenda 17.10.2025
|
||||
|
||||
## Agenda-Backlog
|
||||
|
||||
- Martin / STeam: ADR für ECR-Nutzung ist in Writing
|
||||
- Entscheidung â ECR nur als Backup
|
||||
             â ECR nur für Prod und Tests in Preprod (alle 3-4 Monate)
|
||||
- Martin/STeam, was genau soll eigentlich der Systemzustands-Check mit dem Developer Portal machen?
|
||||
- in der Praxis sehe ich das nur als Check darauf ob Secret-Leaks erkannt werden.
|
||||
- alles weitere erlebe ich persönlich nur als sinnloses Abtippen von bekannt false positive Zahlen aus einem Dashboard in einen Teams-Kanal.
|
||||
â nur Secrets in DXC Portal prüfen und Security Findings nur aus Trivy/Aqua betrachten
|
||||
â Henning macht Doku Â
|
||||
- Einheitliches Hotfix-Vorgehen
|
||||
- Vorlage aus CIB besprechen
|
||||
- Ãnderungen am Vorgehen abstimmen und beschlieÃen siehe: https://git.tech.rz.db.de/bestellsystem1/docs/runbook/-/merge_requests/431
|
||||
- CDaaS-Update via Renovate automatisieren? Yay or nay? Soll heissen: Wie können wir hier autoamtisieren, ohne gegen den Releaseprozess zu arbeiten?
|
||||
- Wenn nein, gibt es Teilaufgaben eines Updates, die sich automatisieren lassen, ohne die Releaseprozess zu "gefährden"?
|
||||
â update in höheren Versionen via Release Prozess
|
||||
â ja updates via Renovate
|
||||
- Zusammenlegung der APIs in ein Multi-Modul-Maven-Projekt
|
||||
â erstmal nicht umsetzen
|
||||
## Agenda 19.09.2025
|
||||
|
||||
- Hotfix-Releases: Problematisch, dass durch reguläre Releases die SIT gesperrt ist
|
||||
- Abwägung der Prioritäten von Hotfix + Release
|
||||
- Um Sperrzeiten herum arbeiten
|
||||
- SITs automatisieren
|
||||
- Java 25: EOL Java 21 Amazon Corretto ist 31.10.2030 bzw. Eclipse Temurin ist 31.12.2029 â Umstellung auf Java 25 nach Go-Live
|
||||
- Martin / STeam: brauchen wir den infra/infrastruktur-kafka-container noch?
|
||||
- das ist ein Bitnami-Image mit Security-Findings ohne Updates, und wir haben aktuell keinen 1:1-Ersatz dafür
|
||||
- wir schlagen vor das Image und Repo zu löschen
|
||||
- AFAIK gab es drei Use-Cases:
|
||||
- Helm kafka-setup-Jobs => wurde durch neues Tool ersetzt
|
||||
- Topics Debugging => wurde durch kafbat/kafka-ui ersetzt
|
||||
- Tool-Image für Notfall-Debugging und Runbook-Scripte => wurde vermutlich nicht vorbereitet, ist im Runbook nicht dokumentiert => noch relevant?
|
||||
- Entscheidung: Wird nicht mehr benötigt; kann archiviert werden
|
||||
- Auch aus versions.yaml entfernen
|
||||
- Martin / STeam: ADR für ECR-Nutzung ist in Writing
|
||||
- Gerne mit- und gegenlesen. Wir haben aktuell grob drei offene Fragen vor einem Einbau von Amazon ECR als Ergänzung zu Artifactory als OCI-Image-Speicher.
|
||||
- Richtlinien-Klärung: können wir ECR-Repos im Prod-AWS-Account für alle Stages benutzen? Wie kleinteilig müssen wir die Zugriffspolicies schreiben?
|
||||
- Design-Entscheidung: ab welcher Stage wollen wir ECR anstatt Artifactory nutzen?
|
||||
- Design-Entscheidung: in welchen CI-Pipelines wollen wir Images nach ECR kopieren? Zentral in der staging-Pipeline, oder verteilt in allen Build-Repos und mehr?
|
||||
- TODO für alle: ADR lesen bis Architekturrunde am 17.10.2025; wird dort diskutiert
|
||||
- Martin / STeam: wer bekommt Zugriff auf unsere Kafka-UIs?
|
||||
- die Zugriffsrechte sind inzwischen alle auf GitLab-Gruppen abgebildet und die werden von Thorsten verwaltet. Der technische Teil ist also schon verbessert.
|
||||
- Haben wir Regeln wer hier genau Zugriff braucht und bekommt?
|
||||
|
||||
- Zugriffsvergabe über ART Trio â Anfragen weiterleiten
|
||||
## Agenda 05.09.2025
|
||||
|
||||
- Frank / Team Zero: zu klärende Fragen aus Refinement / Daily:
|
||||
- O2CZERO-2221 Talo Logging - ist das noch aktuell
|
||||
- Umgang mit dem GET "/"
|
||||
- und schlieÃen sich kurz
|
||||
- Martin / STeam: wir brauchen bessere und einheitlichere Log-Levels
|
||||
- Beobachtung aus dem Systemzustands-Check, der täglich zeigt wie wenig hilfreich unsere Logs sind
|
||||
- falsche Nutzer-Eingaben sind keine (System-)Errors
|
||||
- ein einmaliger Verbindungs-Retry (z.Bsp. bei REST-API) ist kein Error
|
||||
- Entscheidung: Prüfen der Logausgaben in allen Teams. Error nur bei technischen Fehlern, die einen Eingriff benötigen; nicht in den beschriebenen Fällen.
|
||||
-
|
||||
## Agenda 08.08.2025
|
||||
|
||||
- Access-Proxy - wie geht es weiter?
|
||||
- Access-Proxy ist bestellt. Aktuelle Hindernisse durch noch nicht aktivierten Leistungsschein
|
||||
- Access-Proxy läuft unter anderen Hostnamen:
|
||||
- PROD: pathos.app.db.de
|
||||
- TEST: pathos-test.app.db.de â pathos-test-portal-ui.bsz-abn.cnp-test.comp.db.de
|
||||
- In Arbeit:
|
||||
- Aufbau neue EVU-Test mit Access-Proxy
|
||||
- Vorübergehender Parallelbetrieb alte und neue EVU-Test
|
||||
- Kundenkommunikation
|
||||
- Â Systemzustandsmeldung
|
||||
- Wie gehen die einzelnen Teams mit den Rückmeldungen um?
|
||||
- Ist nachvollziehbar, dass die gemeldeten neuen Fehler behandelt (entweder neues Ticket oder nicht relevant) wurden?
|
||||
- Anpassungen an ÃbersichtÂ
|
||||
- Nummerierungsspalte hinzugefügt
|
||||
- Neue Einträge werden hintenangestellt
|
||||
- ExternalDNS ausbauen â neue URLs für betroffene Umgebungen 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-7720150f306eO2CSYS-1436
|
||||
- Schritt 1: IEU
|
||||
- Anpassung ankündigen
|
||||
- Anpassung vornehmen
|
||||
- Anpassung validieren und dokumentieren
|
||||
- Schritt 2: SIT
|
||||
- Anpassung SIT mit Stakeholdern zeitlich abstimmen
|
||||
- Anpassung vornehmen
|
||||
- Anpassung validieren und dokumentieren
|
||||
- Kommunikation an Stakeholder
|
||||
- Schritt 3: E2E
|
||||
- Ankündigen
|
||||
- Durchführen
|
||||
- Validieren und dokumentieren
|
||||
- Frank T./Staging für Nicht-Apps
|
||||
- E.g. curl, infrastruktur-basis-container, flyway
|
||||
- Aktuell passiert dies entweder manuell per renovate (ohne Staging, z.B. curl oder flyway landen parallel auf allen Umgebungen â ohne Testing auf unteren Testumgebungen wie IEU) oder manuell (mit Stagingmöglichkeit, z.B. infrastruktur-basis-container)
|
||||
-
|
||||
- Das führt dazu, dass wir...
|
||||
- Kein Staging für wichtige Images haben
|
||||
- CVEs mitschleifen, z.B. O2CSYS-1720
|
||||
- Wie wollen wir es lösen?
|
||||
- Vorschläge
|
||||
- Staging Staging (Repo/Pipeline) ausbauen
|
||||
- Für unsere eigenen Images (nicht Apps, z.B. infrastruktur-basis-container)
|
||||
- Für andere Images (z.B. curl)
|
||||
- Manuellen Prozess aufsetzen und durchsetzen
|
||||
- Renovate-Updates auf bestellsystem-deployment
|
||||
- Update erst nur auf IEU, danach reguläres Staging (nochmal verifizieren )
|
||||
## Agenda 25.07.2025
|
||||
|
||||
- Release 23.07. - Lessons Learned: SIT nicht mehr an E2E angleichen, sondern an Release-Stand
|
||||
- aktueller ZustandÂ
|
||||
- SIT â erfolgreich â Versionsstand übernommen in SIT-versions.yaml â keine Ãbernahme + Deployment auf E2E
|
||||
- neues Deployment auf die SIT nimmt effektiven Versionsstand der E2E als Ausgangspunkt für das Deployment; nicht den SIT-Versionsstand
|
||||
- NICHT Release-Stand
|
||||
- benötigter Zustand
|
||||
- SIT â erfolgreich â Versionsstand übernehmen nach SIT versions.yaml
|
||||
- Ausgangspunkt für Deployments auf SIT ist SIT versions.yml und nicht mehr die E2E versions.yaml
|
||||
- Deployments auf E2E und folgende Umgebungen per Full-Update von SIT
|
||||
- Manuelle Ãnderungen an der SIT versions.yaml nur noch in begründeten Ausnahmefällen
|
||||
- Umsetzung bei STeam â Review bei SUBP  schreibt Enabler â 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-7720150f306eO2CSYS-1792
|
||||
- Fragen aus Team Zero/Steam: Was ist der Stand für E2E oder was ist geplant?
|
||||
- E2E wird als Umgebung für TTT-IEU verwendet
|
||||
- Zukünftig wieder automatisches Bespielen der E2E
|
||||
- Brauchen wir ein echtes Zertifikat für Demo (aktuell ist dort eines für ABN1)?
|
||||
- Nein â Testzertifikat verwenden
|
||||
- Keystores müssen korrigiert werden â Â
|
||||
- ein Testzertifikat für mehrere Umgebungen ist erstmal ausreichend
|
||||
- Anpassung des EVU-Recorders später zur Prüfung von Client-Zertifikaten (Mutual SSL)
|
||||
- Steven / Zero: Sollen wir weiterhin User mit lesendem DB Zugriff für ITT/Quest gestatten? Kann das nicht über evu-recorder erfolgen? Datenbankzugriffe (extern) - O2C | Order2Cash - ariJa Confluence Â
|
||||
- Temporär für TTT-Testumgebungen Lesezugriff ok
|
||||
- Anfang September Anforderungen bzgl. Zugriff auf PathOS Informationen durch ITT/Quest klären und Folgelösung konzipieren Â
|
||||
- : Uninstall base-Umgebungen jeden Abend
|
||||
- Nach Umbauten am Deployment erfolgen diese deutlich schneller (~ 6 Minuten)
|
||||
- Uninstall auf base-Umgebungen abends (bis auf PVCs)
|
||||
- Deployment erfolgt manuell bei Bedarf (Starten der Pipeline in bestellsystem-deployment)
|
||||
- Uhrzeit für das Uninstall: 20:00 Uhr
|
||||
- Rollback des Portal-Releases
|
||||
- Unterschiedliche Handhabung leerer Arrays: [] vs null
|
||||
- Wenn required true â immer ein Array setzen
|
||||
- Wenn required false â kann null sein, kann ein leeres oder ein gefülltes Array sein
|
||||
- Kein automatisches Umwandeln von leeren Arrays auf null mehr im Bestellsystem
|
||||
## Agenda 27.06.2025
|
||||
|
||||
- Martin / STeam: Klärung Service-Verfügbarkeit einzelner Komponenten und Auswirkung auf Gesamt-Bestellsystem-Verfügbarkeit
|
||||
- Hintergrund: wir aktualisieren mal wieder die Kubernetes-Version und müssen dafür alle K8s-Nodes neustarten. In einem "Kubernetes-Design" funktioniert das komplett ohne Downtime bzw. Service-Unterbrechung, weil alle Komponenten mit mindestens zwei Pods laufen sollten und K8s dafür sorgt dass immer einer davon online bleibt.
|
||||
- In unseren Umgebungen sehen wir allerdings mehrere Komponenten mit nur einem Pod, z.Bsp. in (dev-)E2E:
|
||||
- Stammdaten-Bereitstellung
|
||||
- TTK
|
||||
- Camunda-Services
|
||||
- Frage 1: sind das bei SB und TTK nur Deployment-Bugs, die wir schnell hochskalieren können? Oder gibt es noch Bugs, die mehr Replicas verhindern?
|
||||
- Deployment-Bug â Umstellen auf Replica 2 â stellt das um â infra/bestellsystem-deployment MR 2051
|
||||
- Frage 2: sind die Camunda-Komponenten so gut gekapselt, dass ein Neustart unproblematisch ist (z.Bsp. weil SV alle Requests queued)?
|
||||
- Nach aktuellem Kenntnisstand ja
|
||||
- Themen SUBP-Team:
|
||||
- Umstellungen Bestellsystem-DeploymentÂ
|
||||
- Ausbau AppMesh zur Vereinfachung Bestellsystem-Deployment
|
||||
- application-setup, database-setup-full werden nach bestellsystem-application umgezogen
|
||||
- Vereinheitlichung der Umgebungskonfigurationen
|
||||
- DNS-Konfiguration
|
||||
- Lokales Bestellsystem + lokale Systemtests
|
||||
- TTTneo-Kompatibilität VNP/ENP
|
||||
- DRT-MaÃnahmen
|
||||
- Aufbau PROD
|
||||
- Ãberblick/Kanban Board:Â https://arija.jaas.service.deutschebahn.com/secure/RapidBoard.jspa?rapidView=2569
|
||||
- trivy-operator über CNP "bestellen" â Â
|
||||
- NodePools wären anzupassen (expiration time z.B. 60 m â 30 m)
|
||||
- Ggf. E2E?
|
||||
- Bitte an alle: Base-Umgebungen bei Nichtnutzung abräumen
|
||||
- kein Cleanup, aber tägliches Downscale wäre eine Option â prüfen, ob einfache Umsetzung möglich Â
|
||||
- alternativ: Alerts, wenn Base-Umgebungen mehr als 2 Tage "laufen"
|
||||
## Agenda 13.06.2025
|
||||
|
||||
150
|
||||
- Planung Umgebungsmapping TTTneo ITU/KTU (siehe Präsentation)
|
||||
- ADR 71 - Authentifikation und Autorisierung im Bestellportal (siehe Präsentation)
|
||||
- ARD 70 - Weiteres Vorgehen bzgl. System- und Systemintegrationstests â Testing Jour Fixe
|
||||
- Aus DRT:
|
||||
- Wie Verhalten sich unsere Services bzw. einzelne Services wenn Kafka (ähnliches Szenario bei Keycloak mitdenken) nicht verfügbar ist? Wann Soll sich das Gesamtsystem auf nicht mehr verfügbar stellen?Â
|
||||
- Erste Betrachtung:
|
||||
- PM: Ohne Kafka nur Lesezugriff (Hinweis an Nutzer wäre sinnvoll) / Ohne DB â nicht verfügbar
|
||||
- CI: Ohne Kafka /ohne DB â nicht verfügbar
|
||||
- TTK: Ohne Kafka â nicht verfügbar
|
||||
- SV: Ohne Kafka /ohne DB (RDS, Zeebee, Opensearch) â nicht verfügbar
|
||||
- Weiteres Vorgehen:Â
|
||||
- Services in einzelnen Teams betrachten, Abhängigkeiten identifizieren
|
||||
- Besprechung im nächster Architekturrunde
|
||||
- Verhalten in Anwendungen prüfen bzgl. Nicht-Verfügbarkeit einzelner Infrastrukturservices (z.B. Kafka oder RDS) â Transaktionsklammer richtig gesetzt? Fehlt Transaktionsklammer?
|
||||
- Services in einzelnen Teams auf entsprechendes Fehlerhandlung und Transaktionssicherheit prüfen
|
||||
## Agenda 26.05.2025
|
||||
|
||||
- Disaster Recovery Test - Vorbereitungen
|
||||
- Preprod vorbereiten
|
||||
- Protokoll aus 2024:
|
||||
- Aktuelles Testprotokoll:
|
||||
- Anpassungen zur Senkung der Cloud Kosten
|
||||
- Zeigen Wirkung: https://grafana-v2.cnp.comp.db.de/d/de2jmcogii8zkd/aws-cloud-costs?orgId=69&from=now-14d&to=now
|
||||
- Probleme auf IEU wurden behoben
|
||||
- Auswirkungen bitte aufmerksam beobachten, bei Problemen Meldung an STeam
|
||||
- Frank L. Critical/High Findings im Developer-Portal: Findings aus gelöschten Branches? / Keine Ãnderung durch Container-Umbau? Nimmt er Caches?
|
||||
- Findings aus gelöschten Branches? â Change Request bereits an Umsetzungsteam vom Developer Portal gestellt, Findings aus gelöschten Branches zu entfernen
|
||||
- Keine Ãnderung durch Container-Umbau? Nimmt er Caches? â Scan manuell anstoÃen, sonst nur 1 Scan pro Woche
|
||||
- Fragestellung: wie geht man mit Branches um, für die es noch keinen MR gibt?
|
||||
- Fokus auf Master-Branch
|
||||
- Thorsten: Hostnamen sind keine Secrets â keine verschlüsselten Hostnamen in der Konfiguration
|
||||
- Ticket erstellen und einplanen
|
||||
- Frank T.: (Wiedervorlage, da Inhalt am Thema vorbei besprochen worden ist) Müssen wir das Thema readOnlyRootFilesystem auch für GitLab CDAAS Runner einhalten?
|
||||
- Für Kaniko (und dann später auch buildah) verstoÃen wir gegen die Regel runAsNonRoot
|
||||
- GitLab Runner Job PODs sind nur kurzlebige ad-hoc "Batch Jobs", braucht es dafür wirklich eine Ãnderung?
|
||||
- Die Ãnderung wäre recht aufwändig, da wir für jeden Job prüfen müssen, wohin er schreibt und ob da nicht bereits Daten liegen, die recovered werden müssten, sollte man es mittels "EmptyDirMount" lösen...
|
||||
- Könnten wir das beim CISO (oder so) erfragen? Oder gibt es für GitLab Runner Job PODs eine Ausnahme?
|
||||
- FALSCH: "Thema ist in Ticket O2CSYS-1666 aufgenommen. Sollte angegangen werden, wenn die restlichen MUSS-Themen erledigt sind." â runAsNonRoot != readOnlyRootFilesystem
|
||||
- Regelung nach Rücksprache:
|
||||
- Gitlab-Runner müssen readOnlyRootFilesystem einhalten
|
||||
- Job-Runner-Pods müssen das nicht einhalten
|
||||
- Frank T.: CNB Ausbau / Maven Wrapper und sonstige Ergänzungen
|
||||
- Wir müssen darüber reden, da die Richtung unklar ist, wohin die individuellen App Repos sich hinentwickeln sollen
|
||||
- CNB Ausbau war nicht geplant und kostet viel Aufwand
|
||||
- Maven Wrapper eingeführt (Pipeship)
|
||||
- CIB macht es wieder ganz anders
|
||||
- Keine Einheitliche Lösung
|
||||
- Caching in 404 fehlt (noch)
|
||||
- Fat-Jar ohne Layer
|
||||
- TODO: Dokumentation
|
||||
- Einplanung in PI 37: Vereinheitlichung der Lösung (Anpassung CI-Files) + Berücksichtigung von System-(Integrations-)Tests
|
||||
## Agenda 16.05.2025
|
||||
|
||||
- Bing/STeam: Ãberprüfen und ggfs. Reduzieren der Anwendungsmetriken sowie Metriken der C8-Services (z.B. zeebe). Siehe auch das I.NVI IT Lifecycle Management Toold1143f0d-33c0-3f1c-b44b-7720150f306eO2CSYS-1651Â
|
||||
- Zeebe schreibt viele Metriken
|
||||
- Vorschlag:
|
||||
- Schritt 1: Deaktivieren auf den Umgebungen auÃer E2E und EVU-E2E â Â
|
||||
- Schritt 2: Analysieren, wie die Metriken konfiguriert und reduziert werden können â Team CIB, erstellt ein Ticket
|
||||
- Spring-Metriken reduzieren (an Team 404-Umsetzung orientieren)
|
||||
- in Team CIB und 404 schon in den jeweiligen Anwendungen umgesetzt
|
||||
- in Team Zero noch offen â Ticket ergänzen Â
|
||||
- Thorsten: Abhängigkeit zu CXF / Generell: Umgang mit Dependencies / bestellsystem-parent-pom  â Â
|
||||
|
||||
- Verwendung von CXF, Guava prüfen
|
||||
- Entfernen aus bestellsystem-parent-pom und prüfen, welche Anwendungen damit Probleme haben
|
||||
- Mehr mit Dependency Management arbeiten
|
||||
- Ãberschreiben von in Spring Boot definierten Versionen vermeiden (erzeugt Inkompatibilitäten)
|
||||
- Aufteilung in BOM (bestellsystem-bom) und core-dependencies (bestellsystem-parent-pom)Â
|
||||
- Entwurf in Branch â Testen in den Projekten â Merge auf Master
|
||||
- Frank L.: DatenbankgröÃe (z.b. aktuell in IEU ca. 8 GB).
|
||||
- Idee: Auslagern der Json-Blobs auf S3
|
||||
- Vor Go-Live keine Kapazität
|
||||
- Später nochmal betrachten
|
||||
- Partitionen nutzen, um Datenmenge besser zu handhaben
|
||||
## Agenda 28.04.2025
|
||||
|
||||
- CNP-Risiken von C2S - welche sollten wir für PathOS übernehmen?
|
||||
-
|
||||
https://arija.jaas.service.deutschebahn.com/browse/C2SPT-32
|
||||
- Probleme eher beim Aufbau neuer Umgebungen â weniger während des Betriebs
|
||||
-
|
||||
https://arija.jaas.service.deutschebahn.com/browse/C2SPT-35
|
||||
- Risiko aufnehmen, allerdings geringe Wahrscheinlichkeit und geringerer Impact â 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-7720150f306eO2CBS-662
|
||||
-
|
||||
https://arija.jaas.service.deutschebahn.com/browse/C2SPT-36
|
||||
- Probleme eher beim Aufbau neuer Umgebungen â weniger während des Betriebs
|
||||
-
|
||||
https://arija.jaas.service.deutschebahn.com/browse/C2SPT-29
|
||||
- Risiko aufnehmen, geringere Wahrscheinlichkeit, gleicher Impact â 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-7720150f306eO2CBS-663
|
||||
-
|
||||
https://arija.jaas.service.deutschebahn.com/browse/C2SPT-33
|
||||
- Trennung von CNP-API-basierten Deployments und Bestellsystem-Deployments
|
||||
- Probleme werden in Testumgebungen erkannt â keine Auswirkungen auf Betrieb
|
||||
-
|
||||
https://arija.jaas.service.deutschebahn.com/browse/C2SPT-28
|
||||
- Mitigiert durch CNP-interne Limits â aber grundsätzlich auch ein RIsiko für PathOS â übernehmen â 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-7720150f306eO2CBS-664
|
||||
- Security-Scanner:
|
||||
- Umgang mit False Positives
|
||||
- Fortify & Branches â als "False Positive" geschlossene Findings können auf anderem Branch wieder auftauchen
|
||||
- Entscheidung
|
||||
- Markieren in den jeweiligen Tool (Fortify) bzw. Hinterlegen einer entsprechenden Tool-Konfiguration im Git-Repo
|
||||
- Bzgl. Fortify, siehe auch: https://git.tech.rz.db.de/bestellsystem1/docs/dokumentation/-/wikis/Umgang-mit-Fortify-Ergebnissen#user-content-tag-not-an-issue-link-auf-gitlab
|
||||
- DevPortal-Scanner (Grype, Gitleaks und Compliance) bzw. Trivy in der Bearbeitung priorisieren
|
||||
- Info: portal-ui cnb-builder enthält veraltete Chrome-Version
|
||||
## Agenda 23.04.2025
|
||||
|
||||
- SITs:
|
||||
- Access Denied beim Zugriff auf Kafka
|
||||
- + STeam schauen sich das gemeinsam an
|
||||
- Setzen des Offsets für einen Kafka-Consumer: welche Lösung wollen wir umsetzen? Hintergrund: Wir (Zero) hätten das zu einer schnellen Problembehebung in der E2E gebraucht, aber keinen aktuell gangbaren Weg gefunden (das I.NVI IT Lifecycle Management Toold1143f0d-33c0-3f1c-b44b-7720150f306eO2CZERO-5498).
|
||||
- , + STeam evaluieren eine Lösung (kafka-consumer-groups.sh)
|
||||
- Frank T.: Müssen wir das Thema readOnlyRootFilesystem auch für GitLab CDAAS Runner einhalten?
|
||||
- Für Kaniko (und dann später auch buildah) verstoÃen wir gegen die Regel runAsNonRoot
|
||||
- GitLab Runner Job PODs sind nur kurzlebige ad-hoc "Batch Jobs", braucht es dafür wirklich eine Ãnderung?
|
||||
- Die Ãnderung wäre recht aufwändig, da wir für jeden Job prüfen müssen, wohin er schreibt und ob da nicht bereits Daten liegen, die recovered werden müssten, sollte man es mittels "EmptyDirMount" lösen...
|
||||
- Könnten wir das beim CISO (oder so) erfragen? Oder gibt es für GitLab Runner Job PODs eine Ausnahme?
|
||||
- Thema ist in Ticket O2CSYS-1666 aufgenommen. Sollte angegangen werden, wenn die restlichen MUSS-Themen erledigt sind.
|
||||
- Breaking Changes API
|
||||
- Breaking Changes vermeiden â Abwärtskompatibilität leben und üben
|
||||
- Kompatiblitätstests erstellen (alte Nachrichtenversionen müssen noch funktionieren)
|
||||
- Vulnerabilities regelmäÃig prüfen
|
||||
- Tools:
|
||||
- Developer Portal: https://dp.dxc.comp.db.de/
|
||||
- Defect Dojo: https://vistadojo-prd2-igo.vista.comp.db.de/
|
||||
- Vorgehen:
|
||||
- zu Beginn für jedes Team: 1x pro Woche Vulnerabilities prüfen und behandeln (entweder beheben oder entsprechend dokumentieren)
|
||||
- zunächst Behebung auf Master-Branch
|
||||
- bis Ende des PIs konsequente Behebung auch auf E2E + EVU-E2E (bzw. SAT1) + alle anderen Umgebungen
|
||||
- bestehende + neue Vulnerabilities der Stufe hoch und kritisch abbauen bis Ende Sprint 3
|
||||
- bestehende + neue Vulnerabilities der Stufe kritisch, hoch und medium abbauen bis Ende PI 36
|
||||
- Frequenz steigern auf 1x pro Tag in PI 37
|
||||
## Agenda 04.04.2025
|
||||
|
||||
- Sebastian / STeam: Haben wir Backup bzw. Recoverystrategien für alle Produkte? RDS/Postgres adressieren wir in PI36 schon. Was ist mit dem Rest? Frage kam auf bzgl unserer Kafkas, stellt sich aber sicherlich auch für Zeebe, Opensearch, ...
|
||||
- Bzgl der Kafkas haben wir die Option, diese als "stateless" zu deklarieren (und somit die Verantwortung auf die einzelnen Apps zu verlagern) oder entsprechende Backup- und Recoverystrategien zu etablieren.
|
||||
- Aktuell keine Unterstützung für MSK-Backups über die CNP API. Wäre relevant für einen gleichzeitigen Datenverlust von RDS und MSK. Wahrscheinlichkeit verschwindend gering. Dennoch: zukünftig Anforderung an CNP stellen
|
||||
- Momentan Behandlung als Kommunikationsmedium
|
||||
- Zeebe, Opensearch â Camunda â 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-7720150f306eO2CBS-556 in PI 36 ( fachliche Betrachtung in Enabler ergänzen)
|
||||
- Martin / STeam: mit den verschiedenen ServiceAccounts und IAM Roles per-Service ist etwas mehr Setup-Aufwand in der CNP-API (d.h. in bestellsystem-ops) notwendig
|
||||
- wir wünschen uns dass wir trotzdem alle Roles für alle Umgebungen erzeugen (also auch eine IAM-Role "prod-ifp-mock", obwohl in Prod eigentlich nie ein Mock laufen sollte)
|
||||
- Begründung: die Einheitlichkeit und Konsistenz der Umgebungen führt zu weniger Komplexität und ermöglicht mehr Automatisierung. Das finden wir wichtiger als die initiale Arbeitsersparnis einzelne Teile wegzulassen.
|
||||
- das gleiche gilt im Prinzip auch für die MSK Consumer/Producer Policies. Es wäre schön wenn die auch über alle Umgebungen hinweg gleich sind. Da könnte "Least Privilege" aber ein Gegenargument sein.
|
||||
- Entscheidung: Für alle Umgebungen auÃer PROD ok (inkl. MSK Consumer/Producer Policies). PROD sollte separat behandelt/betrachtet werden.
|
||||
- Martin / STeam: wann finden wir denn Zeit für die Doku der Kafka-Topics (vgl. 7.2.)
|
||||
- im Runbook ist leider immer noch ein Fragezeichen, und viele seitdem neue Topics sind nicht eingetragen
|
||||
- STeam kann das Erstellen der Policies übernehmen (Anfang in bestellsystem-ops MR 709), aber nur wenn wir die nötigen Infos bekommen
|
||||
- würde es uns helfen, wenn wir in bestellsystem-deployment in der _environment.yaml.gotmpl die Attribute 'producer' und 'consumer' einfügen?
|
||||
- Wurde erledigt Â
|
||||
## Agenda 07.03.2025
|
||||
|
||||
- Neue Umgebungen für TTTneo bzw. Parallelbetrieb TTTneo/TTTclassicÂ
|
||||
- 8 Umgebungen von TTTneo müssen angebunden werden (1 DEV, 1 TU, 2 SAT, 3 AU, 1 PROD)
|
||||
- TTTclassic benötigt weiterhin 2 Umgebungen für ITU und KTU
|
||||
- pathOS hat aktuell 7 integrative Umgebungen
|
||||
- Staging für TTTneo vs. TTTclassic
|
||||
- TTTneo-Staging; Anpassung bisheriges Staging: ABN* + PREPROD nach E2E (nicht mehr parallel und als komplettes BS)?
|
||||
- TTTclassic-Staging: Staging-Prozess für ITU + KTU (möglichst einfach, da nur temporär)
|
||||
- Nachrichtensignatur an externe Systeme. Erarbeitung eines Vorschlags zum Schlüsseltausch mit Drittsystemen.
|
||||
- Drittsysteme: TPN Adapter, KOMBau, TBV, Archivierung, Abrechnung
|
||||
- Schlüsseltausch mit externen Systemen:
|
||||
- Variante Kafka-Topic
|
||||
- Variante Artifactory: Ãffentliche Schlüssel + Bibliothek für andere Verfahren zur Verfügung stellen
|
||||
- JSON-Struktur in Signatur-Header vermeiden â Aufteilung in 2 HTTP-Header Â
|
||||
- Kurze Frage zu CM-MAEP: Management-Endpoints absichern oder deaktivieren das I.NVI IT Lifecycle Management Toold1143f0d-33c0-3f1c-b44b-7720150f306eO2CZERO-3419
|
||||
- Teams:
|
||||
- Prüfen, dass nur relevante Actuator-Endpoints freigeschaltet sind
|
||||
- Ãber Ingress-Konfiguration und Network Policies festlegen, auf welche Endpoints zugegriffen werden darf und durch welches System der Zugriff erfolgen darf
|
||||
- Prüfen, welche Ingresses überhaupt noch benötigt werden (z.B. NuR-Mock)
|
||||
- Wiedervorlage, Martin/STeam: Umstrukturieren der GitLab-Gruppen
|
||||
- Update tools/ vs. infra/:
|
||||
- Wir haben keine sinnvolle Kategorisierung gefunden; deshalb möchte ich den Vorschlag zum Neu-Sortieren zurückziehen.
|
||||
- Wir möchten tools/service-certificate-generator nach infra/ verschieben.
|
||||
- Update libraries/ und mocks/:
|
||||
- Vorschlag in Teams-Nachricht: GitLab-Gruppen-Ãnderungen Vorschlag zu den besprochene...
|
||||
- Wenn es keine Einwände gibt, dann kann ich die neuen Untergruppen sofort anlegen und die Repos entsprechend verschiebene.
|
||||
- Auswirkung: Update der git remote URLs notwendig, ggf. Update von Doku und Readmes notwendig
|
||||
- Deadline 14.03.2025 zum Review von Martins Vorschlag. Gibt es keine Einwände, wird sein Vorschlag so umgesetzt.
|
||||
## Agenda 21.02.2025
|
||||
|
||||
- Frank/Zero: Umgang mit Lup-Metriken (Mimir-Zugang), siehe Reaktion auf https://arija.jaas.service.deutschebahn.com/servicedesk/customer/portal/11/CNPSUP-4400
|
||||
- CNP möchte zeitnah einen alternativen Vorschlag zur Anbindung machen, damit wir den im PIP einplanen können.
|
||||
- verfolgt die Infos im Ticket und bringt Updates in Team Zero und in zukünftiger Architekturrunde ein
|
||||
-
|
||||
Martin/STeam: Im Kontext von Compliance und scm-info überlegen wir wie wir mit archivierten GitLab-Projekten umgehen (O2CSYS-1521).
|
||||
-
|
||||
anstatt uralte Repositories nochmal anzufassen würden wir die lieber alle löschen
|
||||
- archivierte Repositories, die nicht mehr benötigt werden, werden ab 24.02. gelöscht (kann 30 Tage rückgängig gemacht werden)
|
||||
- möchte jemand noch archivierte Repos behalten? (ich wäre selbst dafür infra/bestellsystem-deployment-helm bzw. dessen commit-History zu behalten, das ist aber auch das einzige)
|
||||
- @alle: Rückmeldung an STeam asap für noch benötigte archivierte Repositories
|
||||
- Frank/Team Zero: Umgang mit den Cluster-internen Keycloak-Logins auf Evu-E2E und Evu-Test, siehe auch:Â
|
||||
Kathrin Schleich: Applikationen in Evu-Test und Evu-E2E nicht via Thunderclient zu...
|
||||
veröffentlicht in VT Order2Cash / Team STeam am Dienstag, 11. Februar 2025 16:06
|
||||
- Ggf. Möglichkeit über /etc/hosts Workaround (Vorschlag von )
|
||||
- nimmt das Thema nochmal mit in Team Zero. Bessere Analysefähigkeit über Logging/Monitoring schaffen, damit wir auch in Testumgebungen die Möglichkeiten der späteren Produktionsumgebung nutzen und dadurch ggf. vorhandene Lücken frühzeitig aufdecken.
|
||||
- Martin/STeam: Wäre es sinnvoll unsere GitLab-Gruppen weiter zu entwickeln?
|
||||
- tools/ sind "Externe Tools, die wir nicht selbst pflegen", da sind jetzt seit Jahren keine zum rne-common-interface und den excel-tools (werden die benutzt?) hinzugekommen.
|
||||
- Vorschlag: Gruppe für alle (intern + ggf. extern) Tools nutzen. Dann wäre da auch der "Service-Certificate-generator" wieder richtig, und vieles aus infra/ könnte dahin umziehen (fortify-util, installierte-versionen-image, ...)
|
||||
- TODOÂ STeam: konkreter Vorschlag per Teams-Channel, weitere Diskussion dann ggf. in folgender Architekturrunde
|
||||
- apps/ enhält jetzt doch einige Java-Libraries (die aber auch keine APIs sind)
|
||||
- Entscheidung: Gruppe 'libraries/' anlegen. Da passen dann signature-database, logging-utils, parent-pom rein...
|
||||
- Entscheidung: Gruppe 'mocks/' anlegen (für ifp-mock, nur-mock, evu-recorder...).Â
|
||||
- TODOÂ STeam:
|
||||
|
||||
372
|
||||
complete
|
||||
konkreter Vorschlag per Teams-Channel zum Review
|
||||
|
||||
|
||||
- Ausfallfreie Secret-Rotation (siehe Keycloak); wie sieht es mit den anderen Infrastrukturkomponenten aus?
|
||||
- Keycloak: Ausrollen neuer Secrets bisher nicht ausfallfrei
|
||||
- prinzipielles Vorgehen:
|
||||
- neue Secrets erstellen, alte Secrets weiterverwenden
|
||||
- Keycloak: speziell 2. Paar ClientID und ClientSecret erstellen (z.B. portal-ui â portal-ui-b)
|
||||
- Apps auf neue Secrets umstellen
|
||||
- alte Secrets löschen
|
||||
- Enabler (Team Zero):
|
||||
|
||||
373
|
||||
incomplete
|
||||
dedizierter Test der Secret-Rotation bei der Service-2-Service-Authentifizierung auf statischer Umgebung inkl. A/B-Deployment & Doku Â
|
||||
|
||||
|
||||
- PostgreSQL:
|
||||
|
||||
374
|
||||
incomplete
|
||||
Enabler im Backlog von Team STeam
|
||||
|
||||
|
||||
- Bei der Dokumentation von Secrets im Runbook an ausfallfreie Secret-Rotation denken; Besonderheiten/Probleme in Architekturrunde einbringen
|
||||
## Agenda 07.02.2025
|
||||
|
||||
- Thorsten: Branching für parallelen Betrieb von TTTclassic und TTTneo
|
||||
- Zu einem Zeitpunkt X soll ein Branch von SV für TTTclassic erstellt werden. Zeitpunkt X = zu TTTclassic inkompatible Ãnderungen an den Prozessen von SV für TTTneo
|
||||
- TTTclassic: Betrieb des Bestellsystems auf dem letzten funktionierenden Stand auf einer Umgebung. Wartung von Bestellsystem auf diesem Stand hinsichtlich Schwachstellen weiterhin notwendig.
|
||||
- TTTneo: Umstellung des Stagings auf TTTneo
|
||||
- Offene Fragen:
|
||||
- Können die Wartungsaufwände reduziert werden? Z.B. Relevante Architekturänderungen (z.B. PM â SV über Kafka) vor Zeitpunkt X, reine Wartung nur für SV + IFP-Connector, andere Komponenten werden immer mit neuen Versionen und Features versehen.
|
||||
- Umstellung auf Kafka zwischen PM und SV (O2CBS-487) sollte vor dem Branchen umgesetzt werden. bei Planung berücksichtigen
|
||||
- Welche Umgebung wird für TTTclassic verwendet? Benötigen wir eine neue?
|
||||
- ABN2, es sei denn es gibt neue Anfordungern vonseiten C2S
|
||||
- Wie gestalten wir das Staging/Deployment von TTTclassic?
|
||||
- Idee: Reguläres Deployment auf ABN2 bis auf Steuerung-Vertrieb. Manuelles Deployment für Steuerung-Vertrieb.
|
||||
- Martin/STeam: CNP bittet uns weniger Metriken zu erfassen, die Datenmenge führt zu instabilen Grafana-Agents (CNPSUP-4363)
|
||||
- persönliche Vermutung: wir haben viele default-Metriken (aus Spring/Micrometer, OpenTelemetry, AppMesh, ...) von denen wir nicht mal wissen ob sie nützlich sind und wie wir sie abschalten könnten
|
||||
- wie können wir damit umgehen?
|
||||
- Scraping-Intervall auf mindestens 30 sec. setzen
|
||||
- Enabler: Anhand eines Service (+ ggf. Steuerung-Vertrieb) prüfen, welche Metriken wir schreiben  (â 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-7720150f306eO2CBS-588) Â
|
||||
- Martin/Sebastian/STeam: Einheitliche Benennung Kafkatopics: Wir sollten ggf ein einheitliches Format für die Benennung unserer Kafkatopics einführen. Hier sind wir aktuell recht uneinheitlich. Ggf analog zu https://www.confluent.io/learn/kafka-topic-naming-convention/?
|
||||
|
||||
- Aktuell listet das Runbook die folgenden Topics: https://bestellsystem1.gitpages.tech.rz.db.de/docs/runbook/02-architecture/07_deployment_view.html#chapter-internal-systems
|
||||
- Es existieren aber auch andere wie zBÂ "tbvAbsicherung" oder "versandErgebnis"
|
||||
- Der CNP-Validator bemängelt GroÃbuchstaben in Topics. STeam geht hier auf die CNP zu, das zu ändern das I.NVI IT Lifecycle Management Toold1143f0d-33c0-3f1c-b44b-7720150f306eO2CSYS-1484 und CNPSUP-4362 (offizielle Doku von Kafka sieht keine derartige Limitierung vor) => der Validator ist angepasst Â
|
||||
- TODO für Zero und CIB: Vereinheitlichung der Topic-Namen "tbvAbsicherung" und "versandErgebnis" auf Kleinschreibung mit Bindestrichen
|
||||
- TODO Ãberprüfung der Topic-Namen im Runbook (alle Teams)
|
||||
- Frank T. / Henrik Scholl: Laut Richtlinie darf die ABN und PROD Umgebung nur via PAN benutzt werden
|
||||
- Laut CNP ist es nur PROD, dass nur per PAN benutzt werden darf
|
||||
- Das merkt man ja auch an der Zugriffskonfig â DB Admin User für PROD verpflichtend
|
||||
- "Für Editor bzw. Schreibberechtigungen in der CNP-PROD-Umgebung (allgemein in PROD-Umgebungen) dürften nur privilegierte 2er Account-ACAT-Gruppen eingetragen werden (beginnend mit der Zeichenkette gmu). Die Autorisierung von nicht-privilegierten ACAT-Gruppen ist nicht gestattet. (Bitte den Support bei Spezialfällen kontaktieren.)"
|
||||
|
||||
- https://cnp.gitpages.tech.rz.db.de/core/docs/cnp/latest/cnp-q-a-session/acat.html
|
||||
- Systel Richtlinie: https://dbsw.sharepoint.com/sites/sw-informationsecuritydbsystel/SitePages/Nav%20(Confluence)/Vorgaben%20in%20Arbeit/Privileged%20Access%20Management.aspx#:~:text=f%C3%BCr&text=pan&text=welche&text=Umgebungen
|
||||
- Ist das ein Clash DB InfraGO (geltend für CNP) vs. DB Systel?
|
||||
- Enabler: Umstellung Umgebungen auf der ABN-Stage auf PAN-Client (â 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-7720150f306eO2CBS-589) Â
|
||||
|
||||
|
||||
## Agenda 27.01.2025
|
||||
|
||||
- Access-Proxy:
|
||||
- Infos: https://db-planet.deutschebahn.com/pages/sipsteam/apps/content/application-proxy-mobile-app-gateway
|
||||
- Funktioniert für B2B Guests, siehe https://db-planet.deutschebahn.com/pages/b2b-accessmanagement/apps/content/b2b-accessmanagement
|
||||
- NuR-Benutzer werden als B2B Guests angelegt â Nutzung des Access-Proxys möglich
|
||||
- TTTneo: Durchstich Bestellsystem â TPN über eigenes MSK-Cluster letzte Woche erfolgreich. Allerdings musste MSK-Cluster in primäres Subnetz gestellt werden.
|
||||
- Wenn wir das für TPN grundsätzlich über unser MSK-Cluster umsetzen, müssen wir das für alle Umgebungen anpassen, die an TTTneo/TPN angebunden werden. Werden hier Probleme erwartet? Gibt es alternative Vorschläge?
|
||||
- TPN kann kurzfristig kein eigenes MSK-Cluster betreiben.
|
||||
- Trennung internes/externes MSK-Cluster? Betrachtung Berechtigungen & Backup/Recovery notwendig.
|
||||
- Entscheidung: Wahl der Alternative: 1 MSK-Cluster im primären Subnetz mit Einschränkung der IP-Range
|
||||
- Schrittweise Umstellung von JDK 17 auf JDK 21 (Corretto)
|
||||
- Können die RDS-Instanzen aus dem primären Subnetz genommen werden (zumindest in höheren Umgebungen)?
|
||||
- Anmerkung Martin/STeam: wenn wir die Subnetze ändern, dann kann die fachliche Betriebsführung nicht mehr drauf zugreifen (vgl. O2CZERO-4892)
|
||||
- Entscheidung: Festlegung der Vorgehensweise im Zusammenhang mit der späteren DevOps-Betriebsführung â dann ausführliche Dokumentation
|
||||
- Martin / STeam: Stage von ABN2 ändern?
|
||||
- Wenn wir auf ABN2 den Durchstich zu TTTneo herstellen wollen und dafür doch noch Anpassungen erwarten, dann wollen wir vermutlich öfter als im 2 Wochen Release-Zyklus neue Image-Versionen deployen.
|
||||
- Wäre es sinnvoll ABN2 dafür im Staging-Prozess anders einzusortieren, auf Ebene von SIT oder IEU?
|
||||
- Entscheidung: Abwarten bis das weitere Vorgehen bzgl. TTTneo geklärt ist. Bis dahin keine Ãnderungen an ABN2.
|
||||
- Bing / STeam: PR-LPRV: Anwendungsspezifische Consumer/Producerrechte für Kafkatopics: das I.NVI IT Lifecycle Management Toold1143f0d-33c0-3f1c-b44b-7720150f306eO2CSYS-1471
|
||||
- Dokumentation der Producer/Consumer im Runbook: https://bestellsystem1.gitpages.tech.rz.db.de/docs/runbook/02-architecture/07_deployment_view.html#_kafka
|
||||
- TODO für alle Teams: Prüfung, dass die Dokumentation im Runbook korrekt ist
|
||||
- TODO für alle Teams: Ãbernahme der Konfiguration, KOMBau-Konfig kann als Blaupause verwendet werden (Consumer.yaml, Producer.yaml)
|
||||
- Frank L. / Zero: Fehlerbehandlung Validierungsfehler (evtl. auch für andere Fehler: gibt es best Practices - Fehlertopics scheinen mir nicht immer optimal)
|
||||
- Schema-Validierung bei Producer und Consumer
|
||||
- Nicht-lesbare Nachrichten in DLQ-Topic sammeln, Monitoring auf diesem Topic mit Alert, ggf. Verarbeitung weiterer Nachrichten von diesem Topic stoppen
|
||||
## Agenda 29.11.2024
|
||||
|
||||
- Frank/Martin/STeam: Artifactory-Downtime am 7.12.
|
||||
- ProblemstellungÂ
|
||||
- CNP-MaÃnahmen dazu, Daniel Werdermann: 07.12.2024: Artifactory Update + Downtime
|
||||
- Wollen wir das Bestellsystem weiterentwicklen um künftig besser damit umzugehen?
|
||||
- für den Betrieb
|
||||
- für Dev-Pipelines?
|
||||
- Wir hatten schon über ECR als zusätzliche OCI-Quelle gesprochen, doch das nützt uns relativ wenig weil wir auch Datei- und Helm-Repos benötigen. Und für Dev dann auch Maven+NPM.
|
||||
- Lösungsfindung:
|
||||
- Kopieren der Images nach ECR über entsprechenden Pipeship-Job
|
||||
- SL-Ausschluss (in SL-Dokumentation mit aufnehmen): Wenn Artifactory ausfällt, können wir keinen Hotfix erstellen
|
||||
- Durchstarten von Nodes beim Ausfall von Artifactory möglich
|
||||
- Helm-Charts entweder (wäre zu testen)
|
||||
- in S3 über Helm S3-Plugin (Race-Condition bei index.yaml-Editierung)
|
||||
- oder in ECR (siehe https://docs.aws.amazon.com/AmazonECR/latest/userguide/push-oci-artifact.html)
|
||||
- Enabler:
|
||||
- Umgang Nicht-OCI-Artefakte bei Verwendung von ECR (CA-Zertifikaten usw.)
|
||||
- Helm-Charts S3 vs ECR
|
||||
- ECR in Pipelines einbinden
|
||||
- auf Jan bzgl. Access-Proxy für Portal zugehen (längere Patchfristen)
|
||||
- Nach Erstklärung â Wiedervorlage in Architekturrunde
|
||||
- Â DR-Test:
|
||||
- Camunda-Backup-Konzept (siehe https://docs.camunda.io/docs/self-managed/operational-guides/backup-restore/zeebe-backup-and-restore/)
|
||||
- Team CIB: Backup-Vorgehen testen und dokumentieren â Enabler für PI 36
|
||||
- DB-Schnitt:
|
||||
- am Ende vom DR-Test liefen 2 DB-Cluster parallel â Migration im laufenden Betrieb wäre notwendig
|
||||
- DB-Schnitt doch anders wählen?
|
||||
- zu beachten:
|
||||
-
|
||||
DB Gold: 99,91% Verfügbarkeit im Jahresmittel, RTO: 2 Stunden
|
||||
Erwartete Datenbank-GröÃe (AVT): ca. 2 TB
|
||||
- Zugriff auf die Datenbank nur von PAN aus - dort maximale Storage-Size: 50 GB
|
||||
- UKA-Ausfall-Zeit-Ziel pro Jahr: <12 Minuten
|
||||
- ADR ausarbeiten â + Architekturrunde
|
||||
- DB-Instanztyp:
|
||||
- Multi-AZ RDS DB-Cluster empfindlich für deaktivierte KMS-Keys
|
||||
- Risikoabwägung: Instanztyp beibehalten oder Alternativen nochmal in Betracht ziehen?
|
||||
- ADR bzgl. DB-Cluster überarbeiten: + Architekturrunde
|
||||
- Norbert: Wo sollen wir Alles dokumentieren? (Confluence, Runbook, GIT)
|
||||
- Testprotokolle: Weiterhin in Confluence
|
||||
- Wiederanlaufpläne: im Runbook
|
||||
## Agenda 15.11.2024
|
||||
|
||||
- DR-Test-Dokumentation: https://arija-confluence.jaas.service.deutschebahn.com/pages/viewpage.action?pageId=386382061
|
||||
- Martin/STeam: Unsere Anwendungen haben sehr unterschiedliche Datenbank-Einstellungen in den application.yml-Dateien (spring.flyway, spring.jpa, spring.datasource). Können/wollen wir das mal vereinheitlichen?
|
||||
- Timeout-Werte und sonstige relevante DB-Parameter möglichst vereinheitlichen und im Configuration-Management-Abschnitt dokumentieren
|
||||
- /  / Konfiguration in Teamanwendungen betrachten und Abweichungen von Default-Werten begründen
|
||||
- Wiedervorlage in nächster Architekturrunde
|
||||
- STeam: Archivieren von bestellsystem-deployment-helm
|
||||
- Wird von Team 404 noch verwendet
|
||||
- Kann noch nicht archiviert werden
|
||||
- Empfehlung: Ãberschreiben der Werte in der values.yml
|
||||
- ZAP-Test wird von AT/Review-Umgebung über ci-files auf andere Umgebung umgestellt. Team STeam stellt neue Version von ci-files zur Verfügung (Zeitpunkt abhängig von DR-Test-Umfang).
|
||||
- CI & TTK prüfen im health-Check ob Partnerdaten vorhanden sind, dies führt zu Problemen im neuen Kubernetes-Job zum Befüllen der Daten in der KB (Team ZERO)
|
||||
- Health-Check unabhängig von vorhandenen Partnerdaten â Smoketest prüft Validität der Partnerdaten nach dem Deployment
|
||||
- Alternativ: Einspielen der Partnerdaten via Sidecar
|
||||
- Weiteres Tracking des Themas in CI/CD-Runde
|
||||
- Diego/Team 404: WebSSO für E2E-Umgebungen: Das Portal unterstützt Keycloak und WebSSO als Login-Maske, aber WebSSO wird momentan nirgendwo verwendet. Sollen wir für (einige) E2E-Umgebungen nicht WebSSO einsetzen? WebSSO kann nicht automatisch getestet werden, aber für Umgebungen mit ausschlieÃlichen manuellen Tests kann es Sinn machen, WebSSO als Login-Maske zu konfigurieren.
|
||||
- Prüfung, ob ABN1 oder ABN2 an WebSSO angebunden werden kann
|
||||
## Agenda 01.11.2024
|
||||
|
||||
- Flyway: Entscheidung für Umsetzungsvariante
|
||||
- Enscheidung:Â Variante 4 per Default, Variante 1 bei Bedarf (wie z.B. SV)
|
||||
- Flyway-Bibliotheken müssen aus Images entfernt werden
|
||||
- Bei lokaler Entwicklung ggf. mit Maven-Profilen arbeiten
|
||||
- CNB: wird beibehalten mit Ausnahme von SV und zukünftig ggf. Projekten mit Bedarf an Multi-Modul/-Image-Umsetzung.
|
||||
- Systemtests laufen maÃgeblich auf Base-Umgebungen. Ãnderungen an Systemtests führen zu einem MR. dessen Pipeline die Tests auf IEU ausführt
|
||||
- Pipeline-Id + ENVIRONMENT-Wert anpassen/überschreiben
|
||||
- & stimmen sich bilateral ab
|
||||
- Diego: Wie gehen wir mit der Token-Rotation für den Azure-AD-Token um, den die PM für die Verbindung mit NuR verwendet? Momentan muss der Token nach 1 Jahr ersetzt werden.
|
||||
|
||||
- Im Entwicklungshandbuch zu dokumentieren
|
||||
- Martin/STeam: Wann wollen wir nochmal PostgreSQL updaten? Und wie oft wollen wir das vor dem Live-Gang noch machen? â geklärt?
|
||||
- ein Update auf v16 wäre sinnvoll, wollen wir das machen und wann? Liegt in PI34S5: das I.NVI IT Lifecycle Management Toold1143f0d-33c0-3f1c-b44b-7720150f306eO2CSYS-1318
|
||||
- ab Ende 2024 könnten wir auch auf v17 gehen: das I.NVI IT Lifecycle Management Toold1143f0d-33c0-3f1c-b44b-7720150f306eO2CSYS-1319
|
||||
- Background: PostgreSQL released jährlich im September/Oktober und unterstützt major Versionen für 5 Jahre, der AWS-RDS-Support für Versionen läuft immer ein paar Monate nach. Generell ist es wünschenswert jetzt im Dev-Stadium eine möglichst neue Version zu benutzen, damit im Live-Betrieb möglichst viel Flexibilität und Zeit bis zu einem Zwangs-Update bleibt.
|
||||
- STeam: ZAP Scans in Build-Pipeline oder anderem Kontext?
|
||||
- In Enabler das I.NVI IT Lifecycle Management Toold1143f0d-33c0-3f1c-b44b-7720150f306eO2CSYS-1325 wurde ein Trigger-Job in bestellsystem-deployment umgesetzt. Der Trigger-Job triggert die Gitlab-Repo owasp-zap-scanner um die Zap-API-Scans und Zap-Baseline-Scans auszuführen. Bsp. Pipeline: https://git.tech.rz.db.de/bestellsystem1/infra/bestellsystem-deployment/-/pipelines/39649981
|
||||
- Zur Abstimmung: Gegen welche Umgebung (nach welchem Deployment) soll der Trigger-Job angestoÃen werden. Wäre IEU an der Stelle passend? Info: die Zap-Scans dauert es ca. 30 Min
|
||||
- Entscheidung:
|
||||
- Tests auf Umgebung IEU
|
||||
- Einschränkung der Tests nur bei Ãnderungen von Services mit Zugriff aus dem Internet: Common Interface, Portal-Middleware, Stammdaten-Bereitstellung
|
||||
- zukünftige Alternative für Whitesource?
|
||||
## Agenda 11.10.2024
|
||||
|
||||
- Lösungsansatz für AT/Review-Deployment in Bezug auf der Umstellung auf Helmfile abstimmen: Alternative Lösung und aktuelle Nutzung der AT/Review-Umgebung findet man in das I.NVI IT Lifecycle Management Toold1143f0d-33c0-3f1c-b44b-7720150f306eO2CSYS-1324
|
||||
- Nutzung der Umgebungen:Â
|
||||
- Nutzung der AT-/Review-Umgebung maÃgeblich für ZAP-Scans â kann auf Base-Umgebung stattfinden (sinnvoll: Durchführung in bsz-abn-Umgebungen)
|
||||
- Team 404: Nutzung für Cypress-Tests â kann auf Base-Umgebung stattfinden
|
||||
- Team CIB: Nutzung für KITs â Deployment bereits separat umgesetzt
|
||||
- Varianten
|
||||
- Variante 1: Beibehaltung der AT/Review-Umgebungen
|
||||
- Replizierung von Helmfiles in die jeweiligen Projekte notwendig
|
||||
- Durch die Projektteams umzusetzen
|
||||
- Variante 2: Verwendung der Base-AT-Umgebung für Cypress- und KI-Tests
|
||||
- Zentrale Verwaltung der Deployment-Konfiguration in bestellsystem-deployment
|
||||
- "Basiskonfiguration" wird von STeam erstellt
|
||||
- Aufwand vergleichbar zu Variante 1
|
||||
- Entscheidung:
|
||||
- Umstellung auf Variante 2
|
||||
- Vorgehen wird in CI/CD-Runde detailliert
|
||||
- Vereinheitlichung (KITs von SV) nachrangig zu Umstellung von z.B. Team 404 Cypress-Tests
|
||||
- Flyway
|
||||
- Umsetzungsvarianten:
|
||||
- Variante 1 (siehe SV): separates Maven-Modul + separates Container-Image, Images werden via Dockerfile erstellt
|
||||
- Ablauf
|
||||
- Beim Erstellen der Images im Buildprozess wird auf Dockerfile zurückgegriffen. Dabei wir direkt ein separates Flywayscripts-Image für SV gebaut. Siehe Diagramm.
|
||||
- Beim Helm-Deployment wird ein Kubernetes-Job ausgeführt, der das Image startet. Dadurch wird automatisch die Migration durchgeführt. AnschlieÃend wird der Container wieder beendet. Siehe Diagramm.
|
||||
- Vorteile/Nachteile:
|
||||
- Vorteile:
|
||||
- Application Image enthält keine unbenötigten Dateien (Flyway-Skripte)
|
||||
- Flywayscripts-Image wird parallel zu Application-Image gebaut
|
||||
- Nachteile:
|
||||
- Umbau des Buildprozesses in allen Projekten notwendig (siehe Umstellung CNB â Dockerfile)
|
||||
- Updates/Wartung alles Images muss durch das jeweilige Projektteam sichergestellt werden
|
||||
- Variante 2: Image dynamisch erstellten und Flyway-Migrationsskripte aus Applikations-Image auslesen
|
||||
- Ablauf
|
||||
- In der CI/CD-Pipeline werden nach dem Erstellen des OCI Images der Application die Flyway-Skripte aus dem Image als Artefakte herausgeschrieben. Im Folgeschritt wird dynamisch ein Flywayskripte-Image gebaut (siehe Diagramm); kann ggf. parallelisiert werden.
|
||||
- Die Ausführung kann wie in Variante 1 erfolgen.
|
||||
- Vorteile/Nachteile
|
||||
- Vorteile:
|
||||
- Funktioniert auch mit CNB â Anpassungen maÃgeblich in CI/CD-Pipeline
|
||||
- Nachteile:
|
||||
- Erhöht weiter die Logik/Komplexität der Pipeline
|
||||
- Variante 3: Kombination aus CNB für Applikation + Dockerfile für Flywayscripts-Image
|
||||
- Ablauf
|
||||
- In jedem Projekt mit Flywayskripten wird ein Dockerfile ergänzt für das Erstellen eines Flywayscripts-Images. Der Buildprozess wird so angepasst, dass er zusätzlich zum Application Image ein Flywayscripts-Image bauen kann (unter Verwendung des Dockerfiles)
|
||||
- Die Ausführung kann wie in Variante 1 erfolgen.
|
||||
- Vorteile/Nachteile
|
||||
- Vorteile
|
||||
- Application Image enthält keine unbenötigten Dateien (Flyway-Skripte)
|
||||
- Nachteile
|
||||
- Updates/Wartung des Flywayscript-Images muss durch das jeweilige Projektteam sichergestellt werden
|
||||
- Zusätzliche Logik in Pipeline bzgl. Entscheidung: CNB, Dockerbuild oder Kombination aus CNB + Docker
|
||||
- Martin: Wissen wir eigentlich dass wir zwingend ein eigenes Image für die Flyway-Scripte brauchen? sonst schlage ich vor
|
||||
Variante 4: Der Build bleibt so wie jetzt, wir schreiben nur einen eigenen Flyway-Setup-Job
|
||||
- Ablauf
|
||||
- Wir bauen die Anwendung wie bisher
|
||||
- Beim Deployment starten wir einen Flyway-Job und mounten die Scripte aus unserem Application Image
|
||||
- Vorteile/Nachteile
|
||||
- Vorteile
|
||||
- Keine Ãnderung am Build-Prozess nötig
|
||||
- Keine zusätzlichen Images zu pflegen und abzusichern (unter der Annahme dass die Open Source Flyway Images okaye Qualität haben)
|
||||
- Nachteile
|
||||
- Application Image enthält die Flyway-Skripte, die könnte man als unbenötigten Dateien sehen
|
||||
- Entscheidung:
|
||||
- Annahme Minimal Image: Keine Flyway-Bibliotheken. Flyway-Migrations-Skripte (*.sql) können enthalten sein.
|
||||
- Entscheidung zwischen Varianten 3 oder 4. Team Zero und Team 404 besprechen das nochmal im Team.
|
||||
- Deployment-Job vs. Init-Container zu klären
|
||||
- Extra Termin für Thema
|
||||
- CNB (Fortsetzung)
|
||||
- Weiteres Vorgehen abhängig von Entscheidung zu Flyway
|
||||
- Wollen/Brauchen wir eine einheitliche Lösung im Bestellsystem oder ist es ok, wenn einzelne Projekte bei Bedarf vom "Standard" abweichen (Bsp. aktuell: SV)?
|
||||
- Entscheidung: tbd
|
||||
## Agenda 27.09.2024
|
||||
|
||||
- CI-Files in den Projekten auf Version 3.6.0 aktualisieren (helmfile + C8) bis heute EOB
|
||||
- CNB: behindernde Einschränkungen von CNB bzgl. Multi-Modul-Projekten und Multi-Image-Projekten; (wie) lässt sich das mit CNB lösen? Was ist die Alternative?
|
||||
- target-Verzeichnis in build_application_image_heroku hartkodiert
|
||||
- Stellen:Â
|
||||
- https://git.tech.rz.db.de/bestellsystem1/infra/ci-files/-/blob/master/dist/git/customize-job-build_application_image_heroku.yaml?ref_type=heads#L533
|
||||
- https://git.tech.rz.db.de/bestellsystem1/infra/ci-files/-/blob/master/dist/git/customize-job-build_application_image_heroku.yaml?ref_type=heads#L534
|
||||
- https://git.tech.rz.db.de/bestellsystem1/infra/ci-files/-/blob/master/dist/git/customize-job-build_application_image_heroku.yaml?ref_type=heads#L773
|
||||
- Für Projekte konfigurierbar machen?
|
||||
- Job kann pro Ausführung nur 1 Image bauen. Werden mehrere Images benötigt, mehrmalige Ausführung notwendig â negative Auswirkung auf Performance in der Pipeline
|
||||
- Test-Report aus dem Build wird verworfen â zusätzliche Logik in Pipeline für Testauswertung notwendig
|
||||
- Job-Komplexität: build_application_image_heroku hat ca. 900 Zeilen, Build-Job in SV: 40 Zeilen + 180 Zeilen in 5 Dockerfiles
|
||||
- Image-GröÃe: mit CNB > 500 MB, nach Umstellung auf Dockerfile ~300 MB
|
||||
- Abgesehen vom Umstellungsaufwand: Mit welchen Nachteilen müssten wir leben, wenn wir auf CNB verzichten?
|
||||
- SV-Variante des Image-Bauens nachvollziehen und in STeam diskutieren
|
||||
- Wiedervorlage in Architekturrunde am 11.10.
|
||||
- End of support für AWS AppMesh am 30.09.2026 im Zusammenhang mit das I.NVI IT Lifecycle Management Toold1143f0d-33c0-3f1c-b44b-7720150f306eO2CCIB-6343
|
||||
- Ticket O2CCIB-6343 zurückstellen, bis eine Entscheidung über das weitere Vorgehen getroffen wurde. Danach einplanen.
|
||||
- Review von ADR-67, https://git.tech.rz.db.de/bestellsystem1/docs/runbook/-/blob/feat/O2CZERO-4414-adr-anbindung-stationsportal/02-architecture/103-adrs/0067-datenbereitstellung-stationsportal.adoc?ref_type=heads
|
||||
- Frank (aus CI/CD-Runde): Prod und Dev Repos für Apis (renovate erstellt aktuell MRs für alles)
|
||||
- Ziel für alle Projekte: Renovate berücksichtigt nur "getaggte" Versionen von APIsÂ
|
||||
- Gewünscht ist: nur die "getagged" Versionen sollen released werden. => also Benutzen des ADR58-Release-Workflows auch für APIs und Libraries => O2CSYS-1210
|
||||
- Einfache Variante: Eine CI/CD-Pipeline, Ziel-Repository ist abhängig von Tag (â Prod) oder "Nicht Tag" (â Dev)
|
||||
- nochmal in STeam abstimmen
|
||||
- Frank L./Team Zero: Talo-Logging nur für Cockpit? das I.NVI IT Lifecycle Management Toold1143f0d-33c0-3f1c-b44b-7720150f306eO2CZERO-2221
|
||||
- Neue Variante von Netcool/Cockpit verwenden: nur definierte Alarme an Netcool senden, nicht mehr das komplette Log; Talo-Logging damit nicht mehr notwendig
|
||||
- stellt Links zur Dokumentation zur Verfügung
|
||||
- Wiedervorlage in Architekturrunde am 11.10.
|
||||
- STeam/Michael: Kafka-ui generell (intern) deployen? Hilft beim prüfen der Funktionalität von MSK
|
||||
- Kafka-UI steht auf dem Dev-Cluster bereit. Was ist mit generell gemeint?
|
||||
- In ABN und PROD müssen die Zugriffsrechte minimal sein (Least-Privilege-Prinzip) â keine Schreib- oder Löschrechte
|
||||
- Bereitstellung aktuell über Port-Forwarding; Zurverfügungstellung ohne Port-Forwarding nur mit entsprechender Authentifizierung (z.B. Anbindung an Keycloak)
|
||||
- Klärung mit Michael, Umsetzungskonzept
|
||||
## Agenda 06.09.2024
|
||||
|
||||
- Festlegung von Trust Boundaries â Teil der Bedrohungsanalyse mit Security Engineers Anfang Oktober
|
||||
- PI 33: Produktionsumgebung: Jeder Services läuft mit einem eigenen Datenbank-Cluster? (siehe auch 8.4.2024)
|
||||
- ADR-65. Aufteilung der Datenbank-Instanzen 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-7720150f306eO2CBS-493Â
|
||||
- eigene DB für SV + IFP-Connector
|
||||
- Status ändern auf Akzeptiert
|
||||
- ADR 66 - Nutzung von helmfile 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-7720150f306eO2CBS-505
|
||||
- Thema in PI 34 einplanen
|
||||
- Team-Enabler für Umstellung erstellt ; jedes Team soll min 1 Service umstellen
|
||||
- Feedback zu ADR wird noch gegeben (von Team STeam)
|
||||
- Frank L./Team Zero: Besprechung des ADR Datenbereitstellung für das Stationsportal https://git.tech.rz.db.de/bestellsystem1/docs/runbook/-/blob/feat/O2CZERO-4414-adr-anbindung-stationsportal/02-architecture/103-adrs/0067-datenbereitstellung-stationsportal.adoc?ref_type=heads WICHTIG - noch vor PI-Planning 34
|
||||
- Keine Logik in SV zur "Filterung" von Nachrichten für externe Systeme (Nachrichtenstatus)
|
||||
- Konverter sollten alle Nachrichten aus dem AV-Topic lesen und Filterung selbst vornehmen
|
||||
- Datenstruktur für Stationsportal (für aktuelles Vertragsdaten-Dritte-Topic) wird im Laufe von PI 34 geklärt (und im ADR nachdokumentiert)
|
||||
- passt ADR an
|
||||
## Agenda 09.08.2024
|
||||
|
||||
- Ankündigung von STeam: Zusammenlegung der DEV-Datenbanken sowie Zusammenlegung der Datenbanken  EVU-Test und EVU-E2E (ADR-59)
|
||||
- Umstellungsdetails:
|
||||
- Umsetzung: PI 33 O2CBS - S4 - O2CSYS, das I.NVI IT Lifecycle Management Toold1143f0d-33c0-3f1c-b44b-7720150f306eO2CSYS-1123
|
||||
- Nur Daten von Keycloak werden mitgenommen
|
||||
- Downtime für Umschwenken von IEU/SIT/E2E wird in Teams-Kanal angekündigt
|
||||
- Wie ist der Kommunikationskanal über Downtime für Umschwenken von EVU-Test/EVU-E2E? Keine Daten werden mitgenommen auÃer KeyCloak!
|
||||
- Abstimmung bzgl. E2E und EVU*-Umgebungen mit TTT-Koordinatoren notwendig!
|
||||
- Keine Umstellung von SIT, E2E, EVU-Test und EVU-E2E bis 4.9. (Zeitpunkt Entscheidung Go-Live 2025)
|
||||
- SV-Datenbank wird nach Camunda-8-Umstellung sowieso gelöscht
|
||||
- Info: Update von CA-Cert durch Amazon am 22.8. (Hintergrund/Links in O2CSYS-871 und O2CSYS-1068)
|
||||
- Einbindung Netzgrafik in das Bestellportal - Fortsetzung
|
||||
- Frontend über Angular-Bibliothek
|
||||
- Abhängigkeit durch Angular-Version
|
||||
- Datenaustausch (relevante Netzdaten) über Kafka
|
||||
- Backend
|
||||
- berechnet Netzgrafiken - teilweise anhand von Benutzerfiltern; dauert teilweise 3-4 Minuten (ressourcenlastig)
|
||||
- Vorschläge zur Umsetzungsvarianten von KuK:
|
||||
- Bibliothek zur Einbindung in eine BS-eigene Komponente
|
||||
- Netzlotse wird als Docker Image zur Verfügung gestellt und in das Bestellsystem-Deployment eingebunden
|
||||
- Konsequenzen der KuK-Vorschläge: Betrieb "fremder" Komponenten im Bestellsystem mit sämtlichen Konsequenzen
|
||||
- Alternative: Betrieb des Netzlotsen durch KuK
|
||||
- Zugriff über synchrone Schnittstelle auf Netzlotse (durch z.B. Portal-Middleware)
|
||||
- KuK müsste auch SL Gold anbieten
|
||||
- Variante: Netzlotse bei KuK betreiben und als optionales Feature behandeln; vorberechnete Netzgrafiken zwischenspeichern; wenn nicht verfügbar keine Filteroption
|
||||
- Feature-Ticket ergänzen
|
||||
- Aus Security-Assessment: Code-Review Enforcement in Gitlab?
|
||||
- Gegen Enforcement spricht die schnelle Fehlerbehebung im Falle eines Notfalls
|
||||
- Kein Enforcement in Gitlab um Fehlerbehebungen nicht zu behindern
|
||||
- Code-Reviews sind bereits Bestandteil der DoD
|
||||
- Rückfrage bei Security Engineers bzgl. Formulierung in DoD
|
||||
- Neue Umgebungen: Was ist der Prozess / was sind die Zuständigkeiten des Deployments und der Konfiguration (und des Monitorings) für das deployment der bsz-Apps? Hintergrund: PREPROD ist noch nicht vollständig mit allen bsz-Apps bespielt worden. Insbesondere die Konfiguration der Apps untereinander ist von Interesse! Wunsch: Vorgehen für ABN1/ABN2/PROD planen.
|
||||
- Smoketest:
|
||||
- Je 1 Bestellung über beide Eingangskanäle (CI und Portal-UI) auslösen und prüfen, ob sie in den entsprechenden Kafka-Topics (â IFP) ankommen
|
||||
- Bei Produktion: Abstimmung mit TTT notwendig
|
||||
- Abstimmung mit und Â
|
||||
- Gemeines Review der Umgebungskonfiguration mit allen Teams pro Umgebung und bei Bedarf
|
||||
- Dokumentation der Umgebungen im Runbook
|
||||
|
||||
|
||||
## Agenda 12.07.2024
|
||||
|
||||
- Einbindung Netzgrafik in das Bestellportal
|
||||
- C2S Capability: das I.NVI IT Lifecycle Management Toold1143f0d-33c0-3f1c-b44b-7720150f306eC2SLS-2090
|
||||
- Netzgrafik Beispiel: https://netzlotse-frontend-kuk-iat.cnp-test.comp.db.de/netzgrafik
|
||||
- DB Backup & Recovery: Störfälle, Wiederherstellung, Konsequenzen
|
||||
- Kein DB-Split, da es bei Wiederherstellung die Komplexität deutlich erhöht
|
||||
- Eingänge von SV sollten auf Kafka basieren
|
||||
- Kafka-Backup separat zu betrachten
|
||||
- RocksDB in Camunda 8 berücksichtigen!
|
||||
## Agenda 17.05.2024
|
||||
|
||||
- Aktueller Stand Systemtests
|
||||
- Aufgabe für das kommende Sprint-Planning: Klärung bei 404 und CIB, ob Jan 1-2 Tage bzgl. Selenium-Tests aushilft
|
||||
- Erste Ausführung mit dynamischen Umgebungen immer noch häufig fehlerhaft? â zunächst Selenium-Problematik betrachten
|
||||
- ART-Enabler für PI 33 vorbereiten Â
|
||||
- O2CBS-353: Die Systemtests sind in Anlehnung an die KITs von SV refaktoriert
|
||||
- Aus PI 33 Planung entfernen
|
||||
- Umstellung Architekturdokumentation
|
||||
- Architekturdokumentation ins Runbook übernehmen, bisheriges Repository archivieren
|
||||
- O2CBS-408: Vorbereitung Produktivsetzung: Ausarbeitung des Runbooks
|
||||
- Testdaten für Kundendaten-Bereitstellung (bis 300 Partner über SQL in Datenbank insert): Die SQLs in Helm-Chart oder in Artifactory? siehe ADR 47
|
||||
- Falls es eine Pflegeschnittstelle gibt â Testdatenimport über Schnittstelle
|
||||
- Daten, die in integrativen Umgebungen aus externen Systemen geladen werden, werden über (Wire-)Mocks zur Verfügung gestellt
|
||||
- Neuer ADR + Enabler Â
|
||||
## Agenda 19.04.2024
|
||||
|
||||
- Runbook-Vorstellung:
|
||||
- Git-Repo: https://git.tech.rz.db.de/bestellsystem1/docs/runbook
|
||||
- Gerenderte Variante: https://bestellsystem1.gitpages.tech.rz.db.de/-/docs/runbook/-/jobs/207310721/artifacts/public/doctoolchain/04-runbook/05-processes/01-configuration-management.html
|
||||
- TTT-Produktivsetzung in Confluence: https://arija-confluence.jaas.service.deutschebahn.com/pages/viewpage.action?pageId=316973165
|
||||
## Agenda 8.04.2024
|
||||
|
||||
- Frage von Team Zero: Gibt es eigentlich ein Rechte- und Rollenkonzept für das neue Bestellsystem?
|
||||
- Dokumentation für Entwicklungs-/Betriebsrollen
|
||||
- Dokumentation technischer Benutzer und Rollen
|
||||
- Dokumentation für CI
|
||||
- Dokumentation für Portal
|
||||
- : Template für Dokumentation + Enabler erstellen
|
||||
- Produktionsumgebung: Jeder Services läuft mit einem eigenen Datenbank-Cluster? (Problem in der Metrikerhebung der Stammdatenbereitstellung führt zu systemweiten Problemen)
|
||||
- Ein Datenbank-Cluster für alle Services: weniger Wartungsaufwand, konsistenter Datenbankstand über komplettes Bestellsystem
|
||||
- Ein Datenbank-Cluster pro Microservice: bessere Isolation (Burst-Balance), überschaubarere GröÃe bei Backups/Snapshots, individuelle Skalierung
|
||||
- Informationen sammeln bzgl. Wartungsaufwänden
|
||||
- Arbeitsorganisation im Betrieb berücksichtigen: ein Team für ein DB-Cluster zuständig? Oder arbeiten mehrere Teams an einem DB-Cluster?
|
||||
- Last- und Performancetests hinsichtlich Datenskalierung auswerten
|
||||
- Datenmigration bei ggf. notwendigen Cluster-Strukturänderungen berücksichtigen!
|
||||
- : Wiedervorlage in PI 33
|
||||
## Agenda 22.03.2024
|
||||
|
||||
- Klärung, ob bestellsystem-parent-pom in der Form weiterbestehen sollte
|
||||
- Enge Abhängigkeiten führen zu manuellem Anpassungs- und Testaufwand
|
||||
- Zentrale Stelle zum Aktualisieren von Abhängigkeiten (z.B. für APIs und bei Schwachstellen)
|
||||
- Camunda in SV "bremst" Aktualisierung von bestellsystem-parent-pom
|
||||
- Vorschlag: PoC in einem IP-Sprint
|
||||
- Thema wird in CI/CD-Runde mit aufgenommen ( : in Agenda eintragen)
|
||||
- Aus Problem Solving: Versionsnummern von Releases noch nicht gut von Snapshots zu unterscheiden
|
||||
- Fragestellung: Was ist der Nutzen des Timestamps in der aktuellen Versionsnummer? Wird das irgendwo zwangsläufig benötigt?
|
||||
- Vorschlag:
|
||||
- Bei Trigger durch Git-Tag: Name des Tags
|
||||
- Bei Trigger auf Master-Branch: Basis-Versionsnummer gemäà POM + â-m-PIPELINE_ID-COMMIT-SHA-SHORTâ + â-SNAPSHOTâ
|
||||
- Bei Trigger auf Nicht-Master-Branch (z.B. "feat/"): Basis-Versionsnummer gemäà POM + â-b-PIPELINE_ID-COMMIT-SHA-SHORTâ + â-SNAPSHOTâ
|
||||
- Bei "-SNAPSHOT"-Suffix in den Abhängigkeiten kann Create-Release-Tag-Job abbrechen (Prüfung der Abhängigkeiten wäre einzubauen)
|
||||
- Weitere Frage:
|
||||
- Verwendung von Maven-Release-Plugin? Ggf. besser: Version-Plugin, da Release-Plugin auch Git-Operationen vorsieht; auÃerdem muss NPM-Projekt (Portal UI) berücksichtigt werden
|
||||
- Separater Termin ( : einladen)
|
||||
- ACAT: Wir müssen wohl die ACAT Gruppen neu definieren...
|
||||
- Warum? Wir haben für das WRITING nur gmu Gruppen, welche einen Admin Account brauchen â separater Termin ( )
|
||||
- Betreibervorgaben werden nochmal geprüft ( )
|
||||
- Martin/STeam: hat unser Keycloak eigentlich noch irgendwelche Verbindungen zu Nachbarsystemen (mit Systel-TLS-Zertifikaten)?
|
||||
- in der Vergangenheit benutzten wir den eBRS-AD, das ist lange deaktiviert, oder? â Systel-TLS-Zertifikate können entfernt werden
|
||||
- wir würden dann gerne unser keycloak-Login-Theme und das custom-CA-Cert-Setup aus dem Deployment entfernen, das I.NVI IT Lifecycle Management Toold1143f0d-33c0-3f1c-b44b-7720150f306eO2CSYS-1018
|
||||
- erst nach Umstellung auf WebSSO in EVU-Testumgebungen umsetzen
|
||||
## Agenda 8.03.2024
|
||||
|
||||
- DoD: Abnahme der Story in integrierter Umgebung vs. ADR 58
|
||||
- Entscheidung:
|
||||
- IEU Deployment in Testing-Pipeline aufnehmen (unabhängig vom E2E-Stand) â Abnahme kann weiterhin auf IEU stattfinden
|
||||
- erfolgreiches IEU-Deployment ist nicht notwendig für erfolgreichen Abschluss der Pipeline
|
||||
- Systemtests werden auf IEU nicht erneut ausgeführt bei Trigger durch Testing-Pipeline
|
||||
- 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-7720150f306eO2CSYS-1020
|
||||
- Abhängigkeiten zwischen Projekten beim Deployment
|
||||
- zwischenzeitlich über manuelle Anpassung in bestellsystem-deployment.
|
||||
- Lösung über Multi-Artefakt-Projekte.
|
||||
- Neuer Enabler für STeam: PoC für Portal-UI + Portal-Middleware 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-7720150f306eO2CSYS-1043
|
||||
- das I.NVI IT Lifecycle Management Toold1143f0d-33c0-3f1c-b44b-7720150f306eO2CBS-338
|
||||
- Aufgabenteilung zwischen Teams Zero und CIB
|
||||
- Ideen bzgl. API-UmsetzungÂ
|
||||
- Serialisierungsmechanismus (vor Deserialisierung auf Server-Seite bzw. nach Serialisierung auf Client-Seite Byte-Stream verwenden) erweitern (REST + Kafka); ggf. über Aspekte
|
||||
- Einheitlich konfigurierter ObjectMapper von Jackson
|
||||
- Ideen bzgl. Datenbank
|
||||
- Felder/Entitäten über Annotations inkludieren/exkludieren
|
||||
- Relevante Felder konkatenieren und aus Ergebnis die Signatur erstellen; Reihenfolge der Felder muss beim Speichern der Metadaten zur Signatur berücksichtigt werden â beim Auslesen wird in Metainformationen gespeicherte Reihenfolge zur Validierung gespeichert
|
||||
- Bei Assoziationen zu anderen Tabellen Grenze bei Fremdschlüsseln ziehen (assoziierte Entität wird nicht signiert/validiert)
|
||||
- Konzept â ADR
|
||||
## Agenda 23.02.2024
|
||||
|
||||
- klären, wie Kafka in den base-at-Umgebungen zukünftig aufgesetzt wird
|
||||
-  â Frage: Wer löscht die Kafka-Topics in base-at ? (siehe Agenda 2.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-7720150f306eO2CSYS-977
|
||||
- Entscheidung: Variante 3 - eigene Kafka-Cluster pro Umgebung / Verwendung von MSK auf den statischen Umgebungen (IEU, SIT, ...)
|
||||
- Martin/STeam: wir hatten beim PI-Planning die Anregung mitgenommen den Workflow unserer Security-Scanner in der Pipeline zu überarbeiten, das I.NVI IT Lifecycle Management Toold1143f0d-33c0-3f1c-b44b-7720150f306eO2CSYS-838
|
||||
- jetzt haben wir ein Enabler-Ticket mit vielen Gedanken aus dem PIP, aber seitdem keine Stakeholder die irgendwelche Anforderungen formulieren und konkretisieren
|
||||
- Frage hier in die Runde: was wollen wir ändern?
|
||||
- Ticket in PI32 neu betrachten (nach weiteren Tests mit DefectDojo)
|
||||
- Entscheidung: Security-Scanner sollen per Default nur noch auf Master-Branch laufen
|
||||
- Folgende Security-Scanner nur in Master-Branch: Fortify, Whitesource, trivy, OWASP ZAP
|
||||
- neues Ticket für STeam in PI31 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-7720150f306eO2CSYS-987 anstelle von O2CSYS-838 (verschoben nach PI 32)
|
||||
- Martin/STeam: wollen wir auch für die Libraries und APIs die geplanten neuen Release-Prepare-Jobs übernehmen? das I.NVI IT Lifecycle Management Toold1143f0d-33c0-3f1c-b44b-7720150f306eO2CSYS-896
|
||||
- bei Libraries natürlich ohne Testing- und Staging-Pipelines und Deployment
|
||||
- passende Funktion die wir nutzen können: nur bei Git Tag Upload ins Prod-Repo, GitLab-Release mit Changelog, bei Bedarf auch Jira-Lösungsversion
|
||||
- Entscheidung: Kein akuter Handlungsbedarf. Neubetrachtung bei Diskussion über Refactoring von gemeinsam verwendeten JAR-Dateien/Bibliotheken
|
||||
- MSK Sizing
|
||||
- erste MaÃnahme: Speicherplatz erhöhen (30 GB), perspektivisch gröÃeren Wert wählen als RDS
|
||||
- â Monitoring der Volumeauslastung prüfen
|
||||
- â Retention-Property prüfen
|
||||
- â Auto-Scaling-Konfiguration prüfen ( )
|
||||
- â Gehen Nachrichten beim Hochskalieren des Speichers verloren? ( )
|
||||
## Agenda 9.02.2024
|
||||
|
||||
- DevOps: Synergien mit C2S möglich und gewünscht?
|
||||
- Vorstellung: Virtuelle ART-übergreifende Teams zur Optimierung der Bereitschaftszeit in der Betriebsführung
|
||||
- ART-übergreifende fachliche Betriebsführung sinnvoll
|
||||
- technische Betriebsführung als ART-eigenes virtuelles Team
|
||||
- Michael/STeam: Multireplicafähigkeit von Bestellsystem-Service Stack in Namespaces bsz-ieu/bsz-sit/bsz-e2e etc. - Was wäre noch zu tun um alle mind. 2x auszuführen?Â
|
||||
- Portal-Middleware in bsz-sit (Grund: BBZ + Metrik, BBZ soll durch NuR abgelöst werden, ggf. alternativ Metrik aus-/umbauen bzw. Test im system-integration-test deaktivieren)
|
||||
- taftap-tdm-konverter â noch in Entwicklung + nicht eingebunden in Tests â wird multireplicafähig
|
||||
- e2e Namespace â kann hochskaliert werden
|
||||
- stammdaten-bereitstellung â Ticket für Multireplicafähigkeit: das I.NVI IT Lifecycle Management Toold1143f0d-33c0-3f1c-b44b-7720150f306eO2CZERO-3391
|
||||
## Agenda 2.02.2024
|
||||
|
||||
- Klärung notwendig: Partnerkonfiguration im CI / TTK (Team-Zero)
|
||||
- Partnerkonfiguration in CI; keine erneute Zertifikatsprüfung in TTK
|
||||
- Klärung mit KomBau, ob Zertifikate weitergeleitet werden müssen Â
|
||||
- Enabler zur Umstellung der Partnerkonfiguration von Yaml auf ein dauerhaft gut wartbares Konfigurationskonzept
|
||||
- Enabler zur Prüfung des kompletten Subjects (nicht nur CN)
|
||||
- Frage: Wer löscht die Kafka-Topics in base-at ?
|
||||
- Muss Kafka-Server dafür gestoppt werden? (https://stackoverflow.com/questions/33537950/how-can-i-delete-a-topic-in-apache-kafka/33538299#33538299)
|
||||
- prüft bis zur nächsten Architekturrunde, was zum Löschen von Topics notwendig ist (Standalone-Kafka + MSK)
|
||||
- Technische Dokumentation: Wo und Wie? (Team Zero)
|
||||
- Strukturiere Ablage von Dokumentation von Microservices + ggf. Betriebshandbuch Â
|
||||
- Martin/STeam: Benennung neuer Services
|
||||
- wir wünschen uns dass unsere Services bzw. Komponenten präfixfreie Namen bekommen. Weil wir besonders in den Helm-Charts viel mit Text-Präfixen und Suffixen arbeiten, befürchten wir sonst Kollisionen.
|
||||
- Ein kompletter Service-Name sollte nicht Präfix eines anderen Service-Namens sein
|
||||
- und können wir uns im Bestellsystem auf eine Schreibweise von "konnektor" oder "connector" einigen? Anscheinend sind die ADR 57 (Kombau) Enablertickets da nicht einheitlich.
|
||||
- Beachtung einheitlicher Schreibweise
|
||||
- Git-Tags:
|
||||
- Format release-vX.Y.Z führt zu Problemen in den Pipelines â Vorschlag: Versionsnummern ohne Präfix verwenden X.Y.Z
|
||||
- Umsetzung ohne Präfix; bei Problemen erneut betrachten
|
||||
- Bing/STeam: CNP-MSK bei Base-Umgebung: wollte mit Euch kurz diskutieren, ob CNP-MSK (oder Bestellsystem-Kafka) in Base-Umgebung insbesondere bei System-Tests verwendet werden soll.
|
||||
- Wunsch wäre CNP-MSK zu nutzen
|
||||
- Abhängigkeit zum Thema "Löschen von Topics" (siehe oben)
|
||||
- Besprechung in CI/CD-Runde Â
|
||||
|
||||
|
||||
## Agenda 19.01.2024
|
||||
|
||||
- Dringend: Umgang mit Versandergebnis nach der Trennung CI / TTK
|
||||
- Entscheidung: Versandergebnis über eigenes Kafka-Topic von CI â TTK bzw. CI â KomBau
|
||||
- Daniel/CIB: Konzept zu Kompatibilitätstests https://git.tech.rz.db.de/bestellsystem1/docs/architektur/-/merge_requests/220 für das I.NVI IT Lifecycle Management Toold1143f0d-33c0-3f1c-b44b-7720150f306eO2CCIB-4746 vorstellen
|
||||
- ELK Stack (ELK ähnliches Stack) als KombauMock
|
||||
- stattdessen Kafka-Consumer in System Tests einbinden
|
||||
- EVU-Test-Umgebung: Nachrichten an KomBau verbleiben in Kafka-Topic; können mithilfe Kafka UI betrachtet werden
|
||||
- Camunda 8: Anforderungen an CNP (z.B. OpenSearch)
|
||||
- Security-Requirements-Prüfung: Annette, ggf. Diego, Jan, Bing+1, Frank oder Norbert
|
||||
+391
@@ -0,0 +1,391 @@
|
||||
# Abstimmungen mit Cloud Native Platform (CNP)
|
||||
|
||||
> Confluence Page ID: 121274378
|
||||
> Version: 191
|
||||
> Pfad: /pathOS/Kommunikationskanäle, Termine, Besprechungsnotizen pathOS/Besprechungsnotizen/Abstimmungen mit Cloud Native Platform (CNP)
|
||||
> Labels:
|
||||
|
||||
---
|
||||
|
||||
## DIESE TERMINREIHE FINDET NACH 19.5.2022 ERSTMAL NICHT MEHR STATT, DA CNP-ABSTIMMUNGEN INS SYSTEM-TEAM GEWANDERT SIND
|
||||
|
||||
## Allgemeine Infos
|
||||
|
||||
CNP - Cloud Native Platform ist unsere Zielplattform für den Produktionsbetrieb, anstelle der noch für die Entwicklung genutzten DBCS - DB Container Services.
|
||||
Unsere Ansprechpartner: (PL CNP), (Architekt CNP), (technischer Ansprechpartner), (PMO - insb. Teams und Planet-Freischaltungen)
|
||||
Direkte Anfragen und Support über Teams CNP DB Netz - Bestellsystem (privat - Freischaltung erforderlich)
|
||||
Ab 4.5.21 neuer Regeltermin 9:00-9:45 (organsisiert von )
|
||||
Monitoring/Status: CNP-Grafana-Dashboards
|
||||
Dokumentation auf den CNP Confluence Seiten
|
||||
## Impediments im Bestellsystem/System Team
|
||||
|
||||
das I.NVI IT Lifecycle Management Toolissuekey,summary,statuskey,summary,status20project = O2CSYS AND summary ~ CNP AND issuetype = Impediment AND ((status = Fertig AND updated >= -3w) OR status != Fertig) ORDER BY status ASC, updated ASC, priority DESC d1143f0d-33c0-3f1c-b44b-7720150f306e
|
||||
## Themenspeicher
|
||||
|
||||
-
|
||||
Unter-Themensammlung Monitoring
|
||||
- können wir über die K8s-API eigene Prometheus- bzw. Alertmanager-Regeln einpflegen? (Die CRDs sind ja vorhanden.) â Anleitung/Prozess vorhanden? Â
|
||||
- Prometheus bzw Servicemonitor Doku gibt es, wird von referenziert.
|
||||
- Alertmanager Regeln Doku bzw Konfiguration über k8s Objekte gibt es noch nicht. Bzw ist diese nicht CNP Endanwender "ready".
|
||||
- können wir einen Grafana-API-Key (für einen technischen Benutzer) bekommen, um Annotations (für Deployments) zu senden? Â
|
||||
- können wir eine Grafana Tempo Instanz für Anwendungs-Tracing gestartet (und in Grafana als Datenquelle konfiguriert) bekommen?
|
||||
- wenn wir per ServiceMonitor K8s-Label erfassen, dann bekommen die in Prometheus einen Namensprefix (label_app_kubernetes_io_instance) und wir können sie nicht mit Werten aus der CNP-Metrik kube_pod_labels (app_kubernetes_io_instance) korrelieren (beschrieben in O2CZERO-13). Es wäre schöner und für uns benutzbarer wenn das gleich wäre.
|
||||
## Agenda 19.5.2022
|
||||
|
||||
- Dringende Themen
|
||||
- Sean: OIDC-Login => siehe das I.NVI IT Lifecycle Management Toold1143f0d-33c0-3f1c-b44b-7720150f306eO2CSYS-285 für Ursachen und einen Workaround. Die richtige Lösung kommt erst mit dem Wechsel des AWS-Accounts.
|
||||
- Konstantin: Wir planen den Umzug in den neuen AWS-Account am Anfang des PI 25 durchzuführen. Aktuell laufen im System-Team Readyness-Tests für die bereitgestellten Cluster.
|
||||
- GröÃere Ausfälle sind nicht geplant, aber es werden sich insbesondere die URLs ändern.
|
||||
- Alte Todos durchgehen!!!
|
||||
- Konstantin: Fortführung des Termins?
|
||||
- Zusammenlegung mit der CI/CD Runde beschlossen.
|
||||
- Ad hoc Themen im Teams Kanal (CNP-Bestellsystem oder Systemteam)
|
||||
- Klärungstermine bei Bedarf.
|
||||
- Für spezielle Themen gibt es u.a. die CoP.
|
||||
## Termin 05.05.2022
|
||||
|
||||
Teilnehmer: Â
|
||||
- Dringende Themen
|
||||
- Bishara: Grafana-Logs beinhalten nur die Daten der letzten 2-3 Stunden.
|
||||
- Martin: das gleiche Problem ist uns bei Metriken aufgefallen.
|
||||
- Sean: heute Nacht gab es einen Ausfall in der Infrastruktur (Cortex), daher vermutlich der Datenverlust.
|
||||
- Wunsch: mind. eine Woche Aufbewahrung, bei Metriken mind. ein Monat oder noch viel länger.
|
||||
|
||||
181
|
||||
complete
|
||||
: nimmt die Anforderung an CNP mit. => das I.NVI IT Lifecycle Management Toold1143f0d-33c0-3f1c-b44b-7720150f306eO2CSYS-291
|
||||
|
||||
|
||||
- Martin: Es gab mehrere Ausfälle in den letzten Wochen. Es betraf vor allem Load Balancer (Ingress Setup) und Router. (vgl. vom 29.4)
|
||||
- Sean: hervorgerufen wurde das durch eine IP-Adressenknappheit in einem Subnetz.
|
||||
- Sean: Es gab Probleme beim Abrechnen der Infrastruktur.
|
||||
- Natalia: Es gab spürbaren Kostenanstieg beim Bestellsystem. Untere Stages sollten idealerweise nachts und am Wochenende Umgebungen heruntergefahren werden.
|
||||
|
||||
182
|
||||
complete
|
||||
: erstellt ein Ticket
|
||||
Bestellsystem-Ticket dazu: das I.NVI IT Lifecycle Management Toold1143f0d-33c0-3f1c-b44b-7720150f306eO2CSYS-288
|
||||
|
||||
|
||||
- Martin: wir haben weiterhin den Wunsch nach Cluster-Autoscaling.
|
||||
|
||||
183
|
||||
complete
|
||||
: Impediment zwecks Tracking anlegen. => das I.NVI IT Lifecycle Management Toold1143f0d-33c0-3f1c-b44b-7720150f306eO2CSYS-266
|
||||
|
||||
|
||||
- Natalia: Die Vorgaben zu Patch/Schwachstellen-Management sind bis 1.7 umzusetzen.
|
||||
- Konstantin: es gibt noch offene Fragen bzgl. der konkreten Details.
|
||||
- Natalia: prüft, ob ein Stand für alle CNP-Verfahren eingeholt werden kann und mit Richtlinien-Verantwortlichen ein FAQ-Termin nötig ist
|
||||
- Natalia: Es gibt bzgl. Security diese Punkte zu erfüllen:
|
||||
- Anbindung an SIEM (Security, Incident und Event-Management) => passiert auf der Infrastruktur-Ebene vgl. das I.NVI IT Lifecycle Management Toold1143f0d-33c0-3f1c-b44b-7720150f306eO2CSYS-158
|
||||
- Konfiguration und Asset-Management: das muss normalerweise automatisiert im SESAM-Tool gepflegt werden. Prüfen, ob das beim Bestellsystem funktioniert.
|
||||
|
||||
184
|
||||
complete
|
||||
wird separat mit Konstantin geklärt. => das I.NVI IT Lifecycle Management Toold1143f0d-33c0-3f1c-b44b-7720150f306eO2CSYS-292
|
||||
|
||||
|
||||
- Registrierung der Internet-Verbindungen: erfüllt, da alle Verbindungen über ISGW bzw. Web-Proxy laufen.
|
||||
- Khalid: Der Bedarf für CloudSearch bzw. OpenSearch hat sich beim Bestellsystem erstmal erledigt. Wir setzen direkt Lucene als interne Bibliothek ein.
|
||||
## Termin 7.04.2022
|
||||
|
||||
Teilnehmer: Â
|
||||
- Dringende Themen?
|
||||
- Qualys-Scan zu Spring4Shell? => müsste in Masterdata sichbar sein => fragt Emilia
|
||||
- Heute nachmittag werden unsere K8s-Nodes aktualisiert, also alles einmal neugestartet
|
||||
- Wie können wir künftig den Grafana- und EKS-/K8s-Zugriff verwalten?
|
||||
- K8s-Benutzer für uns lesbar unter bestellsystem-ops/.../user.yaml
|
||||
- Grafana-Teams (d.h. Gruppenzugehörigkeiten) nur für CNP editierbar, Ordner-Zugriffe können wir selbst vergeben
|
||||
- wir benutzen faktisch nur Ordner Bestellsystem
|
||||
- ergänzt das im Entwicklungshandbuch, Onboarding-und-Offboarding
|
||||
- Roadmap für Tracing bzw. CNP-Bereitstellung von Grafana Tempo?
|
||||
- frühestens in PI25, siehe Themenspeicher
|
||||
## Termin 10.03.2022
|
||||
|
||||
Teilnehmer: Â
|
||||
- Besprechung Tehmenspeicher
|
||||
- Aktuelle Probleme?
|
||||
- Cognito
|
||||
- Integration mit eBRS fragwürdig.Â
|
||||
- Â wartet Termin mit ELBA zu u.A. Cognito ab.
|
||||
- Info zu AWS Account Migration die in unbestimmter Zukunft ansteht.
|
||||
- können wir in Grafana Zugriff auf die "Explore"-Funktion bekommen? â Status: Abhängigkeit von der Mandantenfähigkeit des Monitoring Backends. Ticket CNP: das I.NVI IT Lifecycle Management Toold1143f0d-33c0-3f1c-b44b-7720150f306eCNP-2521
|
||||
- Â gibt allen Cluster Nutzern "Editor" Rechte. â erledigt
|
||||
- Für alle Nutzer, welche auch cluster zugriff haben (siehehttps://git.tech.rz.db.de/cnp/bestellsystem/bestellsystem-ops/-/blob/master/bestellsystem-dev/cnp-crossplane-v3/provider-kubernetes/user.yaml) wurde der Zugriff als Editor eingerichtet. Mit Ausnahme von  "jasminkeskin", da sie sich noch nicht bei der Grafana Instanz https://grafana.cnp.comp.db.de/ angemeldet hat.
|
||||
## Termin 24.02.2022
|
||||
|
||||
Teilnehmer: Annette, Diego, Natalia, Martin, Frank, Konstantin, Sean
|
||||
- Aktuelle Punkte
|
||||
- Natalia: CNP-Neuigkeiten
|
||||
- Stabilisierung von Logging und Monitoring => Umstieg auf AWS AMG und AMP geplant. Die Migration beginnt im April.
|
||||
- Wichtigste Features sind Mandantenfähigkeit und längere Log-Aufbewahrung.
|
||||
- Credentials Store Service ist bereit zur Nutzung
|
||||
|
||||
173
|
||||
complete
|
||||
: Link zur Doku posten: hier?
|
||||
|
||||
|
||||
- CNP-API wird um neue Dienste erweitert, AWS SNS, Cognito, AWS Transfer Gateway
|
||||
|
||||
174
|
||||
complete
|
||||
: Termin mit ELBA und Konstantin organisieren
|
||||
|
||||
|
||||
- Â Cloudwatch-Metriken werden in Grafana integriert (bis Ende Q1)
|
||||
|
||||
175
|
||||
complete
|
||||
: bitte mitnehmen, dass zunächst die "Standardmetriken" für RDS, SQS und S3 wichtig fürs Bestellsystem sind => das I.NVI IT Lifecycle Management Toold1143f0d-33c0-3f1c-b44b-7720150f306eO2CSYS-156
|
||||
|
||||
|
||||
- Fehlende Fargate-Metriken sind in Analyse
|
||||
- Die Nutzung von App-Mesh wird gerade für IFP vereinfacht.
|
||||
- Es gibt bei IFP eine Vorlage für ein Terraform-basierte Konfiguration und Deployment von Keycloak
|
||||
- Das ist aktuell noch nicht relevant fürs Bestellsystem, kann sich aber später ändern.
|
||||
- ArgoCD-basiertes Deployment wird bereits bei anderen Verfahren eingesetzt
|
||||
- Beim Bestellsystem aktuell noch nicht relevant.
|
||||
- Natalia: Das CNP-Team und die Kommunikation sowie Integration mit den Systemteams soll neu organisiert werden.
|
||||
|
||||
176
|
||||
complete
|
||||
Sean: Morgen findet eine CNP-interne Veranstaltung statt, die Infos werden nächste Woche verteilt.
|
||||
|
||||
|
||||
## Termin 10.02.2022
|
||||
|
||||
Teilnehmer: Sean, Martin, Diego, Annette, Frank, Konstantin
|
||||
- Aktuelle Punkte
|
||||
- Sean: Cluster-Nodes sollten runterskaliert werden, da Fargate inzwischen wieder funktioniert.
|
||||
|
||||
163
|
||||
complete
|
||||
: Ticket anlegen oder finden => das I.NVI IT Lifecycle Management Toold1143f0d-33c0-3f1c-b44b-7720150f306eO2CSYS-290
|
||||
|
||||
|
||||
-  Sean: Time-based Autoscaling wäre wünschenswert. Aktuell ist es problematisch, da wir zum einen keinen Ãberblick über reale Kosten haben, zum anderen aber auch unsere Umgebungen nicht nachts herunterfahren.
|
||||
|
||||
164
|
||||
complete
|
||||
: Ticket schreiben und mit Natalia (bzw. CNP-Betrieb) die Prio und Rahmenbedingungen klären. => das I.NVI IT Lifecycle Management Toold1143f0d-33c0-3f1c-b44b-7720150f306eO2CSYS-266
|
||||
|
||||
|
||||
- Aus dem Themenspeicher
|
||||
- kann die Verfügbarkeit des Monitorings seitens CNP "überwacht" werden? => s. das I.NVI IT Lifecycle Management Toold1143f0d-33c0-3f1c-b44b-7720150f306eO2CSYS-126
|
||||
- Martin: Wo kann ich unsere SSO-Benutzeraccounts sehen?
|
||||
- einige Entwickler brauchen noch Zugriff (auf EKS/K8s und Grafana): emmanuelkontcheutagn, norbertmaurer, aleksandrkil
|
||||
- fügt diese hinzu. Ich muss nach meinem UrlaubÂ
|
||||
- Martin: Update, 2022-02-10: mit unseren erweiterten K8s-Zugriffsrechten sehe ich (und Frank) jetzt die Liste im rolebinding/bestellsystem-user
|
||||
|
||||
165
|
||||
complete
|
||||
: die Anlage und Prüfung der Benutzer im Entwicklerhandbuch dokumentieren.
|
||||
|
||||
|
||||
- Frank: CNP-API sollte (auch) in unserem Cluster laufen, damit wir unsere Pipelines vereinfachen können.
|
||||
- Das wird aktuell in das I.NVI IT Lifecycle Management Toold1143f0d-33c0-3f1c-b44b-7720150f306eO2CSYS-119 geprüft.
|
||||
## Termin 27.01.2022
|
||||
|
||||
Teilnehmer: Natalia, Sean, Martin, Annette, Diego, Bishara, Bing
|
||||
- Aktuelle Punkte
|
||||
- Muss Keycloak wegen des log4j-Themas aktualisiert werden, obwohl laut Wildfly Keycloak nicht betroffen ist?
|
||||
- Nein, wir vertrauen dem Hersteller und aktualisieren Keycloak regulär auf die neuste Version nach dem Pentest (d.h. im Februar)
|
||||
- Benutzer-Liste für den Zugriff auf den BSZ-Cluster und Grafana
|
||||
- Norbert und Aleksandr sind schon drin, Emmanuel ist der nächste, Frank Lemke fehlt noch
|
||||
- CNP arbeitet an einer neuen Lösung mit Benutzer-Anlage über CNP-API
|
||||
- vorläufig sollen die Anfragen über den CNP-BSZ-Teams-Kanal eingesteuert werden.
|
||||
- Logs fehlen
|
||||
|
||||
- Aktuell sind die Entwickler im Blindflug, insb. was die EVU-Test-Umgebung angeht
|
||||
- : analysiert gerade, Zieltermin 28.1 EOB
|
||||
- Ingress-Limit verhindert aktuell den Zugriff auf neue Review-Umgebungen via ALB (s. das I.NVI IT Lifecycle Management Toold1143f0d-33c0-3f1c-b44b-7720150f306eOO-39)
|
||||
- Ist in Bearbeitung durch das CNP-OPS Team.
|
||||
- CIB: Können wir auf das Localstack (in den Umgebungen) verzichten? Aktuell wird es benutzt um SQS und S3 zu emulieren. Künftig sollen SQS-Queues und S3-Buckets aus der Pipeline im CNP-Cluster angelegt werden.
|
||||
- Konzeptionell ist das noch nicht final geklärt, wie man das am besten macht.
|
||||
- Der Wunsch-Weg der CNP läuft über anwendungsspezifische Crossplane-Compositions.
|
||||
- Alternativ könnte man auch client-side Tools nutzen, wie pulumi, terraform oder aws cdk8s
|
||||
- Sean und Martin schauen sich das an in das I.NVI IT Lifecycle Management Toold1143f0d-33c0-3f1c-b44b-7720150f306eOO-38
|
||||
- Evaluation von neuen AWS-Diensten kann künftig in einer AWS-Sandbox durchgeführt werden, z.B. für OpenSearch oder CloudSearch.
|
||||
- Neuigkeiten bzgl. Fargate (s. das I.NVI IT Lifecycle Management Toold1143f0d-33c0-3f1c-b44b-7720150f306eOO-22)
|
||||
- : prüft den Status
|
||||
## Termin 20.01.2022
|
||||
|
||||
Teilnehmer: Martin, Frank, Konstantin, Sean, Natalia
|
||||
- Offene Bugs (siehe oben)
|
||||
- OO-33 Logging => (Loki) im Bestfall bis Montag 24.1 gelöst
|
||||
- OO-21 Monitoring => (Cortex) langfristig ein Umstieg auf einen AWS-Managed-Service
|
||||
- hier fehlt aktuell noch Alarmierung in CNP, um ohne Kundenmeldung einen Monitoring-Ausfall zu erkennen und reagieren zu können.
|
||||
- OO-XY Aktuelle Probleme mit dem Propagieren von DNS-Records => bedingt durch einen Crossplane-Update, hier soll ein Patch ausgerollt werden
|
||||
- allgemeines Vorgehen mit OO-Tickets
|
||||
- : mittelfristig sollen alle aus dem System-Team Tickets in CNP-Jira anlegen können. Bestellsystem-bezogene Tickets sollen allgemein lesbar sein.
|
||||
- : aktuell offene Tickets durchgehen und mit CNP-Jira verlinken bzw. aktualisieren.
|
||||
- Folgetermin/Serie
|
||||
- erstmal wöchentlich Do 11:30-12:00
|
||||
- künftig wäre sogar eine Stunde wünschenswert
|
||||
## Termin 04.01.2022
|
||||
|
||||
Teilnehmende: Martin, Annette, Bishara, Sean
|
||||
Status:
|
||||
- Allgemeiner Sync
|
||||
- bestellsystem-dev monitoring ist offline. â keine Metriken. â Â
|
||||
- prüft Punkte aus Tehmenspeicher.
|
||||
## Termin 7.12.2021
|
||||
|
||||
Teilnehmer: Martin, Annette, Diego, Bishara, Konstantin (CNP-Vertreter abwesend)
|
||||
- Diego: AT- und Review-Umgebungen laufen noch auf DBCS.
|
||||
- Martin: Migration steht noch aus.
|
||||
- Martin: Monitoring funktioniert wieder. Leider kann es jederzeit wieder Ausfälle geben, solange CNP nicht die neue Lösung eingeführt hat (Hannes Blut ist dran). Die aktuelle Lösung von CNP ist noch nicht mandantenfähig.
|
||||
- Martin: Probleme mit Fargate-Selektoren (das I.NVI IT Lifecycle Management Toold1143f0d-33c0-3f1c-b44b-7720150f306eOO-22) wird evtl. doch zusätzliche EC2-Instanzen als Fallback erfordern.
|
||||
- Martin: Der Plan mit der Migration von DBCS bis Ende Januar steht weiterhin. Um riskante Ãnderungen vor den Feiertagen zu vermeiden, starten wir damit erst Anfang Januar.
|
||||
- Konstantin: Systemteam hat nun ein eigenes Jira-Projekt
|
||||
## Termin 23.11.2021Â
|
||||
|
||||
- Dringende Themen:
|
||||
- Pentest-Vorbereitung für Januar
|
||||
|
||||
155
|
||||
complete
|
||||
Keycloak läuft (danke ALB), Härtungsemepfehlungen kommen
|
||||
|
||||
|
||||
156
|
||||
complete
|
||||
DNS-Namen sind beauftragt, Bestätigung fehlt
|
||||
|
||||
|
||||
157
|
||||
complete
|
||||
Intranet-Zugang reicht für Pentester oder externe IP-Adressen?
|
||||
|
||||
|
||||
158
|
||||
complete
|
||||
Zieltermin für die Umgebung und Freischaltungen ist vor 15.12 (als Plan B 1. Jnauar woche)
|
||||
|
||||
|
||||
- Sean: App-Mesh kommt voran. BS hat erst ab Februar Ressourcen um das zu testen.
|
||||
- Martin/Konstantin: welche Anforderungen gibt es für unsere Systeme über die Weihnachtsfeiertage?
|
||||
-  kein Abschalten von Umgebungen nötig
|
||||
- CNP macht kein "Projekturlaub"
|
||||
- Natalia: Status des Umzugs der unteren Stages auf CNP?
|
||||
- Martin: feste Umgebungen wurden umgezogen, Build-Jobs sind in Arbeit, dynamische Umgebungen sind noch zu tun, DNS siehe unten
|
||||
- Frist ist 31.1.22
|
||||
- Konstantin: Teilnahme des neuen Systemteams an PI-Refinements und Plannings. PI Planning 8-9.12
|
||||
- Kern-Systemteam nimmt am PI Planning als eigenes Team teil (insb. nicht als Teil von Team Zero). Für andere Teams auf Zuruf. Keine durchgehende Break-Out Session.Â
|
||||
- Ziel: Dependencies zu anderen Teams und Objectives formulieren.
|
||||
- Neues Jira Projekt benötigt "O2C | Systemteam" (Alternativ: Ausgliederung des Feature-Teams).
|
||||
- Eine Mail an Holger und Bernd
|
||||
|
||||
159
|
||||
complete
|
||||
: Mail verfassen
|
||||
|
||||
|
||||
- Martin: wir haben (mal wieder) Beratungsbedarf zu GitLab-Runnern.
|
||||
Wir haben aktuell kein konfigurierbares Helm-Template für unsere GitLab-Runner in den EKS-Clustern, das heiÃt wir müssen jetzt auf jeden Fall Arbeit in einen Helm-Chart investieren, die Frage ist in welche Richtung?
|
||||
|
||||
- aktuell: wir benutzen eine veraltete Kopie des IPF-Setups. Wird von IFP/MoQ-AP nicht unterstützt, ist damit praktisch ein Bestellsystem-eigenes Projekte und unsinnig fortzuführen.
|
||||
- pro: -
|
||||
- con: Insellösung, wollen wir nicht dauerhaft selbst weiter entwickeln.
|
||||
- CDaaS: die hatte uns ihren Agent mit Helm-Chart empfohlen, leider können wir Labels und Ressources nicht konfigurieren und müssten da Merge Requests öffnen
|
||||
|
||||
- pro: potentieller Support und Integration mit pipeship (sops/CICRED)
|
||||
- con: CDaaS fokussiert die Entwicklung auf DBCS, wir wissen nicht ob sie unsere Merge Requests überhaupt akzeptieren
|
||||
- GitLab Community Chart: das wird inzwischen von MoQ-AP empfohlen
|
||||
- pro: sehr generisch, für alle Use-Cases passend
|
||||
- con: sehr generisch, ohne "DB-Vorkonfigurations-Layer" haben wir vieles selbst einzustellen
|
||||
- unklar: Setup ohne CDaaS (=weniger Kosten und theoretisch weniger Support, den wir noch nie nutzen konnten)
|
||||
- Zusammensetzen mit IFP (Andreas Leicher) und ELBA (Jochen Bachmann)
|
||||
|
||||
160
|
||||
complete
|
||||
organisiert einen Termin mit Martin =>s. das I.NVI IT Lifecycle Management Toold1143f0d-33c0-3f1c-b44b-7720150f306eO2CSYS-43
|
||||
|
||||
|
||||
- Martin: wir stellen den Feature Request external-dns als DNS-Controller laufen zu lassen.
|
||||
Je mehr wir mit unseren EKS-Clustern arbeiten desto mehr sehen wir dass eine DNS-Verwaltung per CNP-API nicht praktikabel ist. â Wir können kein einziges Helm-Chart einfach nachnutzen, sondern müssen dafür jede einzelne CI-Pipeline erweitern, um mit eigenen Skripten in verschiedenen Clustern zu arbeiten. Das ist bei uns viel Aufwand, viel busywork, und komplett ohne Wertschöpfung.
|
||||
Das bisherige Setup war alles ein netter Proof-of-Concept, aber es kann nicht so bleiben.
|
||||
- Konstantin: BS hat vor es auszuprobieren das I.NVI IT Lifecycle Management Toold1143f0d-33c0-3f1c-b44b-7720150f306eO2CZERO-49
|
||||
- Sean/Natalia: diskutieren das innerhalb von CNP. => Wiedervorlage und konkrete Planung am 7.12Â
|
||||
## Termin 15.11.2021 (Ersatztermin für 9.11)
|
||||
|
||||
Teilnehmer: Sean, Martin, Annette, Diego, Konstantin, Bing
|
||||
- Aktuelles
|
||||
- Sean: CNP macht ggfls. ab 15.12 bis Jahresende Projekturlaub
|
||||
- Martin: wir haben am 18.11. einen groÃen Demo-Termin. Gehen wir davon aus dass wir den auf CNP zeigen können und alles stabil ist (DNS, Loadbalancer, Monitoring), oder sollten wir dafür lieber eine DBCS-Installation vorbereiten?
|
||||
- Sean: Probleme mit RDS-Secretes liegen an den Namespaces (sie werden nativ in Crossplane angelegt und sind für CNP-API-Nutzer nicht sichtbar). Die Lösung kommt, wenn Datenbanken über die CNP-API angelegt werden.
|
||||
|
||||
141
|
||||
complete
|
||||
Martin: Es gab Probleme bei Anlage von Datenbanken über CNP API. Fehlersuche zusammen mit Sean geplant.
|
||||
|
||||
|
||||
- Martin: gibt es schon einen Workflow um neue Entwickler einzutragen?
|
||||
- neue Accountnamen im Bestellsystem sind: emmanuelkontcheutagn, norbertmaurer, aleksandrkil
|
||||
- die bitte in die OIDC-Listen für bestellsystem-dev und bestellsystem-evu-test eintragen (das liegt nicht im Git-Repo bestellsystem-ops, oder?)
|
||||
- das gleiche dann in Grafana. â Da benutze ich bisher schon meine Admin-Rechte um zusätzliche Nutzer in die Dashboard-Ordner"bestellsystem" und "bestellsystem-testing" einzutragen. Bei Gelegenheit könnten wir die Listen benutzen um die Benutzer-Gruppe "bestellsystem" zu aktualisieren.
|
||||
- Das Vorgehen für neue Benutzer sollte dokumentiert werden.
|
||||
|
||||
142
|
||||
incomplete
|
||||
: generisch für CNP
|
||||
|
||||
|
||||
143
|
||||
complete
|
||||
: im Entwicklerhandbuch
|
||||
|
||||
|
||||
- Konstantin: Pentest fürs Portal findet am 24-28.1.2022 statt (durchgeführt vom TÃV), Kickoff entweder im Dezember oder Anfang/Mitte Januar. Todos bis dahin (vgl. auch das I.NVI IT Lifecycle Management Toold1143f0d-33c0-3f1c-b44b-7720150f306eOO-7) Â
|
||||
|
||||
144
|
||||
complete
|
||||
bedingte Freischaltung fürs Intranet und ausgewählte Pentester-IPs (direkt SecApps anschreiben, CNP in CC), möglichst vor Ende November.
|
||||
|
||||
|
||||
145
|
||||
complete
|
||||
Keycloak-Setup vervollständigen
|
||||
|
||||
|
||||
- Konstantin: Status Service-Mesh (Blocker für die Verschlüsselung und Zugriffskontrolle der internen Kommunikation)
|
||||
|
||||
146
|
||||
complete
|
||||
Status intern bei CNP erfragen
|
||||
|
||||
|
||||
- Martin/Konstantin: restliche (auch dynamische in der Pipeline generierte) Umgebungen müssen von DBCS auf CNP umgezogen werden. Die Deadline ist 31.1.22, danach erlischt der Support für die von uns genutzten DBCS-Cluster.
|
||||
|
||||
147
|
||||
complete
|
||||
: Blocker bzw. gröÃere Todos sind CNP transparent zu machen.
|
||||
|
||||
|
||||
- Natalia: ist eine Migration auf DBCS v2 geplant? Nein, (siehe auch Punkt 6) das Bestellsystem plant direkt auf CNP zu gehen.
|
||||
- Martin: gibt es dokumentierte StorageClasses für PersistentVolumes?
|
||||
Ãbergangsweise (solange wir das RDS-Setup nicht in der CI-Pipeline haben) werden wir PostgreSQL-Instanzen im Cluster starten und möglicherweise möchten wir für einige persistenten Speicher aktvieren.
|
||||
|
||||
148
|
||||
incomplete
|
||||
: EBS kann bereitgestellt werden.
|
||||
|
||||
|
||||
149
|
||||
complete
|
||||
: prüfen, ob (und wann) wir von eigenen PostgreSQL Instanzen auf RDS wechseln (insb. wegen Secrets und Performance).
|
||||
|
||||
|
||||
- Martin: Dauer zur Bereitstellung von DNS-Einträgen
|
||||
- wir haben den Eindruck dass DNS-Einträge (nach Anlegen per CNP-API) innerhalb des EKS-Clusters (bzw. AWS-Accounts) relativ schnell verfügbar sind,
|
||||
- beim Entwickler-Zugriff per VPN (Nameserver 10.174.0.8 und 10.174.0.40) dauert es dann sehr lange bis der Name aufgelöst und eine URL abgefragt werden kann
|
||||
- lässt sich das Antwortverhalten für Benutzer verbessern?
|
||||
- so wie es jetzt ist wird es schwierig unsere Build- und Test-Pipelines zu benutzen
|
||||
- Natalia: die CNP-API wird am Donnerstag (18.11 um 12:30) vorgestellt.
|
||||
- Wann wird eine API-Dokumentation bereitgestellt?
|
||||
|
||||
150
|
||||
complete
|
||||
: prüft, wann eine API-Doku bereitgestellt werden kann.
|
||||
@@ -0,0 +1,275 @@
|
||||
# Kombinierte Roadmap
|
||||
|
||||
> Confluence Page ID: 133399373
|
||||
> Version: 441
|
||||
> Pfad: /pathOS/Roadmap Bestellsystem/Kombinierte Roadmap
|
||||
> Labels:
|
||||
|
||||
---
|
||||
|
||||
Neue Roadmap im iObeya
|
||||
Ab 01.08.2023: Die kombinierte Roadmap wird in iObeya weitergeführt. Hinweise und Erklärvideos zur Nutzung von iObeya finden sich u.a. in der ariJa Wissensdatenbank.
|
||||
VERALTET! Bitte in iObeya nachschauen! VERALTET! Bitte in iObeya nachschauen! VERALTET! Bitte in iObeya nachschauen! VERALTET! Bitte in iObeya nachschauen! VERALTET! Bitte in iObeya nachschauen! VERALTET! Bitte in iObeya nachschauen! VERALTET! Bitte in iObeya nachschauen! VERALTET! Bitte in iObeya nachschauen! VERALTET! Bitte in iObeya nachschauen! VERALTET! Bitte in iObeya nachschauen! VERALTET! Bitte in iObeya nachschauen! VERALTET! Bitte in iObeya nachschauen! VERALTET! Bitte in iObeya nachschauen! VERALTET! Bitte in iObeya nachschauen! VERALTET! Bitte in iObeya nachschauen! VERALTET! Bitte in iObeya nachschauen!Â
|
||||
Die Roadmap dient der mittelfristigen Planbarkeit, sodass man einen Ãberblick über zukünftig umzusetzende Funktionalitäten erhalten kann. Sie ist ein lebendes Dokument und wird fortlaufend erneuert. An dieser Stelle wird der aktuelle Stand hinterlegt.Â
|
||||
| | Lieferartefakte BS aus
|
||||
TTT-Roadmap |
|
||||
| NP1_2 | BP_2 |
|
||||
NP1_3
|
||||
BP_3
|
||||
AK_1 |
|
||||
NP2_1
|
||||
NP2_2
|
||||
AK_2 |
|
||||
|
|
||||
|
|
||||
|
|
||||
| Produktion? |
|
||||
|
|
||||
|
|
||||
|
|
||||
|
|
||||
|
|
||||
|
||||
| | PI/Quartal | 26 - Q4/2022 | 27 - Q1/2023 | 28 - Q2/2023 | 29 - Q3/2023 | 30 - Q4/2023 | 31 - Q1/2024 | 32 - Q2/2024 | 33 - Q3/2024 | 34 - Q4/2024 | 35- Q1/2025 | 36 | 37 | 38 | später |
|
||||
|
|
||||
|
||||
| |
|
||||
404 |
|
||||
- Portalunterstützung für Vertragsänderungendas 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-7720150f306eO2C-188
|
||||
- PI 26 Portalverbesserungendas I.NVI IT Lifecycle Management Toold1143f0d-33c0-3f1c-b44b-7720150f306eO2C-210
|
||||
- Last- und Performance-Tests (LuP) für Portal -weitere Abdeckung 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-7720150f306eO2C-171
|
||||
- Anzeige von Nicht-Konstruierbarkeiten
|
||||
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-7720150f306eO2C-142Â
|
||||
- Testbarkeit Netzfahrplan (Manipulation des Eingangszeitpunkts in PM)Â O2C404-1173
|
||||
- Unterstützung für Ãnderungsbestellungen nach Vertragsschlussdas 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-7720150f306eO2C-335 |
|
||||
- VNP und ENP im Portal anzeigen 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-7720150f306eO2C-365
|
||||
- EVU am Zuglaufpunkt festlegen (z.B. durchführendes EVU)  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-7720150f306eO2C-295
|
||||
- Anbindung Rabattnummernservice (API NVN-Tool)Â
|
||||
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-7720150f306eO2C-78
|
||||
- Portalverbesserungen
|
||||
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-7720150f306eO2C-367 |
|
||||
- PEN-Test E2E-Umgebung (Jun/Jul 2023) vorbereiten 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-7720150f306eO2C-485
|
||||
- Changelogs und Releaseprozess konzipieren 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-7720150f306eO2C-25
|
||||
- Anzeige fachlicher Fehlermeldungen im Portal
|
||||
das I.NVI IT Lifecycle Management Toold1143f0d-33c0-3f1c-b44b-7720150f306eO2C-476
|
||||
- Unterstützung Stornierung in Portal und Middleware 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-7720150f306eO2C-332
|
||||
- Nutzung von Spring Boot 3.0.XÂ 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-7720150f306eO2C-432
|
||||
- Schutz durch Web Application Firewall begleitendas 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-7720150f306eO2C-496
|
||||
- Erstellung Tooltipp-Hilfe für den externen Benutzer
|
||||
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-7720150f306eO2C-472
|
||||
- Prototyp Dashboard "Wie gehts dem Bestellsystem"
|
||||
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-7720150f306eO2C-491
|
||||
- Portalverbesserungen PI28das I.NVI IT Lifecycle Management Toold1143f0d-33c0-3f1c-b44b-7720150f306eO2C-473
|
||||
- Einstiegsseite - Willkommen im neuen Portal - Dashboarddas 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-7720150f306eO2C-477
|
||||
- Tracing mit CNP Integrierendas 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-7720150f306eO2C-442 |
|
||||
- PMW: Umsetzung einer Paginierung für abgerufene Aufträge
|
||||
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-7720150f306eO2C-273
|
||||
- Portalverbesserungen PI29 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-7720150f306eO2C-570
|
||||
- Erstellung Tooltipp-Hilfe-Modus für den externen Benutzer 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-7720150f306eO2C-580
|
||||
|
||||
das I.NVI IT Lifecycle Management Toold1143f0d-33c0-3f1c-b44b-7720150f306eO2C-597
|
||||
|
||||
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-7720150f306eO2C-220
|
||||
|
||||
|
||||
- Anbindung Ãnderungsprozesse 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-7720150f306eO2C-298
|
||||
- Unterstützung für Ãnderungsbestellungen nach Vertragsschluss
|
||||
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-7720150f306eO2C-335
|
||||
- Anmeldung von Trassen mit multiplen Anteilen im Plannetz DB Netz (Multi PRM Anmeldung)
|
||||
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-7720150f306eO2C-482
|
||||
- BS: Umstieg von TMT auf Xray 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-7720150f306eO2C-619 |
|
||||
- Unterstützung für Ãnderungsbestellungen nach Vertragsschluss das I.NVI IT Lifecycle Management Toold1143f0d-33c0-3f1c-b44b-7720150f306eO2C-646
|
||||
|
||||
- Tastaturbedienung  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-7720150f306eO2C-571
|
||||
- Portalverbesserungendas I.NVI IT Lifecycle Management Toold1143f0d-33c0-3f1c-b44b-7720150f306eO2C-645
|
||||
- Daten aus TPN importierendas I.NVI IT Lifecycle Management Toold1143f0d-33c0-3f1c-b44b-7720150f306eO2C-647
|
||||
- Umzug der BBZ Schnittstelle vorbereiten das I.NVI IT Lifecycle Management Toold1143f0d-33c0-3f1c-b44b-7720150f306eO2C-648
|
||||
- Stammdaten-Suche erfolgt über die Stammdaten-Bereitstellung 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-7720150f306eO2C-127
|
||||
- Anmeldung von Trassen mit multiplen Anteilen im Plannetz DB Netz (Multi PRM Anmeldung)
|
||||
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-7720150f306eO2C-482
|
||||
- Arbeiten mit Verträgen 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-7720150f306eO2C-140 |
|
||||
- Netzausgelöste Ablehnung nach Fristablauf zur Angebotsannahme 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-7720150f306eO2C-296
|
||||
- Netzausgelöste Ãnderungendas 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-7720150f306eO2C-589
|
||||
- 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-7720150f306eO2C-294
|
||||
- Umgang mit Case Reference  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-7720150f306eO2C-290
|
||||
- Arbeiten mit Vorlagen (Nicht Entwurfe) 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-7720150f306eO2C-591
|
||||
- Kontaktinformationen im Portal vorbefüllen
|
||||
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-7720150f306eO2C-92 |
|
||||
|
|
||||
|
|
||||
|
|
||||
|
|
||||
|
|
||||
|
|
||||
|
|
||||
- Anbindung Kundenportal (SSO, Login)
|
||||
- Wann können wir mit mehreren CompanyCodes im Portal rechnen?Â
|
||||
|
||||
- 2te Nfpl Phase
|
||||
3-Tg. Schreiben
|
||||
|
||||
- Fristenberechnung im Gelegenheitsverkehr und NetzfahrplanÂ
|
||||
- Kartendarstellung - Anbindung an Trassenfinder (15 PT an Einfachbahn)
|
||||
- Vorgangs-Detailansicht anpassen (Datenexport Detail, Status im Prozess grafisch anzeigen/nicht anzeigen?.)
|
||||
- Eintritt Dritter in einen Vertrag (§22 ERegG) 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-7720150f306eO2C-608
|
||||
- Rahmenvertragsanmeldungen komplett- Eingabe einer Anmeldung zum Kapazitätsrahmenvertrag 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-7720150f306eO2C-138
|
||||
- Rahmenvertragsanmeldungen Ãnderungsprozesse
|
||||
- Zugriff Vertragszustände C&R - Synchron- (keine Aktionen von ZB im BPortal möglich)
|
||||
- O2C-590 Bedienhilfe 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-7720150f306eO2C-590
|
||||
- Â Willkommen- Kategorie: Wie finde ich mich im neuen Portal zurecht 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-7720150f306eO2C-609 |
|
||||
- Nicht im Scope: es wird nicht mehr benötigt. Anbindung des OTN Generators (Vergabe und/oder Belegung einer Zugnummer)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-7720150f306eO2C-579 |
|
||||
|
||||
| |
|
||||
CIB |
|
||||
- Prozess Vertragsschluss Netzfahrplan (ENP) umsetzen
|
||||
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-7720150f306eO2C-91
|
||||
- BEP-Anbindungdas 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-7720150f306eO2C-271
|
||||
- Anbindung Produktionsauftrags-SST 0.12.0
|
||||
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-7720150f306eO2C-64
|
||||
-
|
||||
E2E-Tests (inkl. Umsysteme)Â 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-7720150f306eO2C-195 |
|
||||
- Rahmenvertragsanmeldungen komplett
|
||||
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-7720150f306eO2C-66
|
||||
- Unhappy Path IFP-SSTs
|
||||
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-7720150f306eO2C-324 |
|
||||
- PEN-Test E2E-Umgebung (Jun/Jul 2023) vorbereiten 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-7720150f306eO2C-485
|
||||
- Abruf von Preisinformationen aus AC Trasse
|
||||
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-7720150f306eO2C-8
|
||||
- Changelogs und Releaseprozess konzipieren 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-7720150f306eO2C-25
|
||||
- DevOps Workshop - Folgetermin Team CIBÂ 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-7720150f306eO2C-487
|
||||
- Nutzung von Spring Boot 3.0.XÂ 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-7720150f306eO2C-432
|
||||
- Unhappy Path IFP-SSTs
|
||||
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-7720150f306eO2C-324
|
||||
- Verarbeiten von Fehlermessages
|
||||
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-7720150f306eO2C-497
|
||||
|
||||
- Stornierungen von Trassenverträgen (EVU-seitig)
|
||||
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-7720150f306eO2C-330
|
||||
- Prototyp Dashboard "Wie gehts dem Bestellsystem"
|
||||
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-7720150f306eO2C-491
|
||||
- Fertigstellen der IFP-Schnittstellen
|
||||
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-7720150f306eO2C-42 |
|
||||
- Ãnderungsbestellungen (EVU-seitig)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-7720150f306eO2C-272
|
||||
- Umsetzung noch offener Validierungen in SVÂ Â 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-7720150f306eO2C-576
|
||||
- Verbesserung BEPdas 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-7720150f306eO2C-596
|
||||
- das I.NVI IT Lifecycle Management Toold1143f0d-33c0-3f1c-b44b-7720150f306eO2C-597
|
||||
- BS: Umstieg von TMT auf Xray 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-7720150f306eO2C-619 |
|
||||
- Zweite Anmeldephase Netzfahrplan 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-7720150f306eO2C-282
|
||||
- PoC Produktions- und Vertriebsauftrags-SST in Kafka
|
||||
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-7720150f306eO2C-643
|
||||
- Fristüberwachung (zu klären, ob Umsetzung in Teilprozessen oder als übergreifender Prozess) 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-7720150f306eO2C-286
|
||||
- Unhappy Path (Reaktion auf Error Messages durch EVU, unvollständige Ãnderungsbestellungen) (ZU KONKRETISIEREN) 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-7720150f306eO2C-285
|
||||
- Fehlende Vertriebsaufträge 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-7720150f306eO2C-498
|
||||
- Verarbeiten von ErrorMessages von EVU
|
||||
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-7720150f306eO2C-499 |
|
||||
- Netzausgelöste Ãnderung 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-7720150f306eO2C-283
|
||||
- Prozesstransfer in nachgelagerte Prozessphase bei Eingang nicht fristgemäÃer Ãnderungsbestellung [
|
||||
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-7720150f306eO2C-481
|
||||
- 3-Tages-Schreiben im Netzfahrplan |
|
||||
- Route Update Prozessdas 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-7720150f306eO2C-287Â |
|
||||
|
|
||||
|
|
||||
|
|
||||
|
|
||||
|
|
||||
|
|
||||
- Kommunikation mit Nachbar-EIUÂ 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-7720150f306eO2C-288
|
||||
- Referenzierung auf Rahmenverträge im Netzfahrplan
|
||||
- Validierung 1:n zwischen ReferenceTrain und Route 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-7720150f306eO2C-291
|
||||
- CaseReference KundenObjekte abrufen und speichern 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-7720150f306eO2C-290
|
||||
- QoL für Betriebsführung und Support 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-7720150f306eO2C-310
|
||||
- Unhappy Path (Reaktion auf Error Messages durch EVU, unvollständige Ãnderungsbestellungen) (ZU KONKRETISIEREN)
|
||||
- Umsetzung erster Systemintegrationstests mit IFPdas I.NVI IT Lifecycle Management Toold1143f0d-33c0-3f1c-b44b-7720150f306eO2C-377 |
|
||||
|
|
||||
|
||||
| |
|
||||
Zero |
|
||||
- Versionsanhebung CI das I.NVI IT Lifecycle Management Toold1143f0d-33c0-3f1c-b44b-7720150f306eO2C-297
|
||||
- Austausch einfacher Nachrichten mit PCS 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-7720150f306eO2C-193 |
|
||||
- Nutzung von Spring Boot 3.0.XÂ 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-7720150f306eO2C-432
|
||||
- Tracing-Informationen in Grafana initial bereitstellen 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-7720150f306eO2C-169 |
|
||||
- PEN-Test E2E-Umgebung (Jun/Jul 2023) vorbereiten 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-7720150f306eO2C-485
|
||||
- Changelogs und Releaseprozess konzipieren 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-7720150f306eO2C-25
|
||||
- Tracing-Informationen in die Anwendungen integrieren
|
||||
das I.NVI IT Lifecycle Management Toold1143f0d-33c0-3f1c-b44b-7720150f306eO2C-431
|
||||
- Finales Aufbereiten der Stammdatendas 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-7720150f306eO2C-534
|
||||
- LuP (PushGateway nutzen)Â 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-7720150f306eO2C-343
|
||||
- S-Bahn Berlin (Durchstich)
|
||||
das I.NVI IT Lifecycle Management Toold1143f0d-33c0-3f1c-b44b-7720150f306eO2C-316
|
||||
- Anbindung BI-Systeme
|
||||
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-7720150f306eO2C-154
|
||||
- Prototyp Dashboard "Wie gehts dem Bestellsystem"
|
||||
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-7720150f306eO2C-491
|
||||
- Support
|
||||
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-7720150f306eO2C-549 |
|
||||
- Kundendatenvalidierung fertigstellen
|
||||
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-7720150f306eO2C-65
|
||||
- ObjectInfoMessagesÂ
|
||||
das I.NVI IT Lifecycle Management Toold1143f0d-33c0-3f1c-b44b-7720150f306eO2C-638
|
||||
|
||||
- Tracing
|
||||
- Anbindung Bestellsystem an Abrechnung 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-7720150f306eO2C-284
|
||||
- das I.NVI IT Lifecycle Management Toold1143f0d-33c0-3f1c-b44b-7720150f306eO2C-597
|
||||
|
||||
- LuP (PushGateway nutzen)Â 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-7720150f306eO2C-343
|
||||
- BS: Umstieg von TMT auf Xray 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-7720150f306eO2C-619
|
||||
- Support
|
||||
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-7720150f306eO2C-621 |
|
||||
- S-Bahn Berlin (Durchstich)
|
||||
das I.NVI IT Lifecycle Management Toold1143f0d-33c0-3f1c-b44b-7720150f306eO2C-316 |
|
||||
|
|
||||
|
|
||||
|
|
||||
|
|
||||
|
|
||||
|
|
||||
|
|
||||
|
|
||||
- Vorjahresdaten importieren
|
||||
- Anbindung Click&Ride |
|
||||
|
|
||||
|
||||
| | STeam
|
||||
|
|
||||
|
|
||||
|
|
||||
- PEN-Test E2E-Umgebung (Jun/Jul 2023) vorbereiten 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-7720150f306eO2C-485
|
||||
- Vorgaben zu Patch- und Schwachstellenmanagement umsetzen 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-7720150f306eO2C-18
|
||||
- Changelogs und Releaseprozess konzipieren 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-7720150f306eO2C-25
|
||||
- Security Scans installieren/aktualisieren 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-7720150f306eO2C-489
|
||||
- Verschlüsselung interner Schnittstellen in IEW und EVU vertesten 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-7720150f306eO2C-486
|
||||
- Prototyp Dashboard "Wie gehts dem Bestellsystem"
|
||||
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-7720150f306eO2C-491
|
||||
- Tracing-Informationen in Grafana initial bereitstellen 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-7720150f306eO2C-169
|
||||
- CI/CD-Verbesserungen 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-7720150f306eO2C-488 |
|
||||
- BS: Umstieg von TMT auf Xray 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-7720150f306eO2C-619 |
|
||||
|
|
||||
|
|
||||
|
|
||||
|
|
||||
|
|
||||
|
|
||||
|
|
||||
|
|
||||
|
|
||||
|
|
||||
|
|
||||
|
||||
| |
|
||||
Teamzuordnung offen |
|
||||
|
|
||||
Anbindung des Konstruktionssystems für EVU-Tests 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-7720150f306eO2C-366 Â
|
||||
ART-übergreifende E2E-Tests das I.NVI IT Lifecycle Management Toold1143f0d-33c0-3f1c-b44b-7720150f306eO2C-375
|
||||
Staging einführen  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-7720150f306eO2C-136
|
||||
- Tracing 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-7720150f306eO2C-169 |
|
||||
| Stabilisierung der Systeme mit C2S |
|
||||
|
|
||||
|
|
||||
|
|
||||
|
|
||||
|
|
||||
|
|
||||
|
|
||||
|
|
||||
| Abnahmetests |
|
||||
|
|
||||
File diff suppressed because it is too large
Load Diff
@@ -0,0 +1,880 @@
|
||||
# Archiv CNP JF
|
||||
|
||||
> Confluence Page ID: 161972468
|
||||
> Version: 2
|
||||
> Pfad: /pathOS/Kommunikationskanäle, Termine, Besprechungsnotizen pathOS/Besprechungsnotizen/Abstimmungen mit Cloud Native Platform (CNP)/Archiv CNP JF
|
||||
> Labels:
|
||||
|
||||
---
|
||||
|
||||
## Termin 26.10.2021
|
||||
|
||||
Teilnehmen: Annette, Bing, Bishara, Diego, Konstantin, Sean, Martin
|
||||
- Aktuelles:
|
||||
- Portal in EVU-Test: Pen-Test noch ohne Termin. Der früheste mögliche Termin ist derzeit Anfang Januar. Ein Anbieter steht allerdings noch aus. Je nach Ergebnis müssen wir eine Verschiebung oder eine bedingte Freischaltung vor dem Pentest prüfen.
|
||||
- Kurzer Review der Punkte vom 12.10.
|
||||
- Konstantin: Tracking von Bugs und Zulieferungen könnte künftig über Jira erfolgen, sobald beide (Bestellsystem und CNP) auf das neue NVI-Jira migriert sind.
|
||||
â im Prinzip haben wir jetzt gegenseitig JIRA-Zugriff zwischen CNP und Bestellsystem
|
||||
- Umsetzung Container-Vorgaben
|
||||
- welche Frist gilt für das Bestellsystem: 1.1.2022
|
||||
- Wie ist die Arbeitsteilung zwischen CNP und ARTs?
|
||||
- aktuell gröÃte Lücke: privilegierte Container für Kaniko notwendig
|
||||
- Gibt es bei CNP schon einen Plan damit umzugehen?
|
||||
- Vorschlag/Planung Bestellsystem: ein eigener Namespace für Kaniko, und nur in diesem Namespace privilegierte Container zulassen. â damit können wir dann alle nicht-Build-Umgebungen absichern.
|
||||
- Martin: Ich habe neue Namespaces im Cluster bestellsystem-dev erstellt
|
||||
- Als Kürzel habe ich bsz benutzt (angelehnt an den Projektnamen in Beam),
|
||||
- Kann bei Gelegenheit jemand bestätigen dass das Erstellen mit kubectl hnc create so richtig war?
|
||||
-
|
||||
Ziel ist später nur noch in bsz-kaniko "privilegierte" Container zu benötigen (mangels besserer Container-Build-Lösung)
|
||||
-
|
||||
neue Namespace-Liste zur Info:
|
||||
|
||||
|
||||
- mit den neuen Namspaces haben wir auch begonnen zusätzliche Anwendungs-Installationen in bestellsystem-dev zu starten. Aktuell unsere 'vertriebsdemo', danach folgt 'IEU'.
|
||||
- Frage dazu: hilft es wenn wir in bestellsystem-ops die SubnamespaceAnchor Objekte einpflegen?
|
||||
â Ja, sollte per MR eingetragen werden.
|
||||
- Martin: Ingress Controller in bestellsystem-evu-test
|
||||
Der ALB-Ingress-Controller funktioniert in bestellsystem-dev gut und löst unsere offenen Probleme (HTTP-Header, Cluster-Erreichbarkeit, Portnummern im Hostnamen). Jetzt müssen wir auch bestellsystem-evu-test aktualisieren.
|
||||
â Sean und Martin aktualisieren evu-test am Donnerstag
|
||||
- Martin: wenn ich jetzt mehr Anwendungs-Installationen starte, dann brauche ich ein paar Monitoring-Daten von der RDS-Instanz um zu bemerken wenn wir die überlasten. (In Grafana finde ich nur eine Kombau-RDS, nicht unsere bestellsystem-dev).
|
||||
- Martin: aktuell haben wir Probleme mit DNS-Einträgen per CNP-API. â Bei Sean bereits angefragt und in Arbeit.
|
||||
## Termin 12.10.2021
|
||||
|
||||
## Hinweis: Konstantin und Martin sind im Urlaub
|
||||
|
||||
Teilnehmen: Natalia, Annette, Bing, Bishara, Frank, Diego
|
||||
- Aktuelles:
|
||||
- Aktuelle Ingress-Probleme sind gelöst.Â
|
||||
- Die Umstellung des Endpoints notwendig (Sean geht auf Diego zu)
|
||||
- Probleme mit der Testumgebung: IP-Adressen-Problem ist gelöst
|
||||
- Ãnderung des DNS-/Route53-Setups in Arbeit, das 63-Zeichen-Limit ist gelöst
|
||||
- Martin: Nachfrage zu Secrets:â kein Update
|
||||
- Martin: Nachfrage zu Git-Secretsâ kein Update
|
||||
- Bishara/Martin: MasterData Proxy-Eintrag-->E-Mail via Natalia an Ops-Team
|
||||
- Status Service-Mesh (Blocker für die Verschlüsselung und Zugriffskontrolle der internen Kommunikation)âkein Update.
|
||||
- Ist jetzt als Service angeboten, wird mit IDBF vertestet
|
||||
- Ziel: zum Jahresende für das Bestellsystem zum Testen bereitstellen
|
||||
- Ãberblick über den Rest des Themenspeichers.
|
||||
- Monitoring: in Entwicklungâ kein Update
|
||||
- Pen-Test-Terminâ Vertrag ist da, Termine sollen vereinbart werden, Kick-Off-Termin soll organisert werden (Annete)
|
||||
- SIEM-Anbindung:
|
||||
- OS-Ebene: keine ToDo'sÂ
|
||||
- App-Ebene: ab 2022 notwendig, Abstimmung mit SCIRT
|
||||
- Migration von Build- und Dev-Umgebungen von DBCS auf CNP
|
||||
|
||||
- Dynamische DNS-Einträge und Ingress-Controller.
|
||||
- Verhalten der Cluster unter Last: Fargate vs. Cluster-Autoscaling (erstmal time-based)â Anforderungen an Umgebungen sollen spezifiziert werden (BEâBing, FEâDiego, Annete))
|
||||
- (weitgehender) Verzicht auf priviligierte Container erfordert eigenes Anlegen von Namespaces (Martin hat Rechte zum Anlegen der Subnamespaces).
|
||||
- Konfiguration von OPA (Spezifizieren, was damit gemeint ist). â das heiÃt zum Beispiel Verhindern von privilegierten Containern auÃerhalb des Kaniko-Namespaces.
|
||||
## Termin 28.09.2021
|
||||
|
||||
Teilnehmen: Natalia, Annette, Bing, Bishara, Edmond, Konstantin, Martin
|
||||
- Aktuelles:
|
||||
- Aktuelle Ingress-Probleme: mit Hannes (als Seans Vertretung) halb in Arbeit
|
||||
- künftige Termine/Zusammenarbeit. CNP & Projekt Dailies geplant.
|
||||
- Ãnderung des DNS-/Route53-Setups in Arbeit, das 63-Zeichen-Limit könnte wieder obsolet sein.
|
||||
- Ãbersicht aktuelle Tickets, die im Bestellsystem als externe Abhängigkeit Dinge blockieren
|
||||
- Martin: Nachfrage zu Secrets:
|
||||
- Können wir bitte irgendwo dokumentieren wie Secrets gespeichert werden müssen, um den DB-Vorgaben zu entsprechen?
|
||||
- Bisher schreiben wir unsere Secrets nur in die K8s-API, unter der Annahme dass das reicht, also dass die Daten dann nicht im K8s-etcd, sondern im AWS-SecretsManager gespeichert werden.
|
||||
- Unter wird zusätzlich ein Secrets Claim per CNP-API beschrieben. Brauchen wir sowas auch, oder ist das schon automatisiert?
|
||||
- muss nochmal genauer besprochen werden â Folgeticket oder -Termin
|
||||
- Martin: Nachfrage zu Git-Secrets
|
||||
- Bei der Beschäftigung mit der pipeship-Implementierung für Secrets in Git-Repositories (mit PGP als Backend) sind uns Probleme aufgefallen.
|
||||
- Als Alternative wird ein AWS KMS-Schlüssel vorgeschlagen, das erscheint mir schwierig ohne AWS-Credentials für alle Entwickler.
|
||||
- Gibt es von CNP eine empfohlene Lösung, wie wir verschlüsselte Daten in Git an eine Laufzeitumgebung koppeln können?
|
||||
- muss nochmal genauer besprochen werden â Folgeticket oder -Termin
|
||||
- Bishara/Martin: Wir brauchen nochmal ein MasterData-Update (Proxy-Freigabe), wer kann uns das eintragen?
|
||||
- wir wollen von Anwendung "bestellsystem-commoninterface-test.dbnetze.com" aus zugreifen auf Hostnamen "commoninterface-dev.cos-test.comp.db.de"
|
||||
- â E-Mail via Natalia an Ops-Team
|
||||
- Status Service-Mesh (Blocker für die Verschlüsselung und Zugriffskontrolle der internen Kommunikation).
|
||||
- Ist jetzt als Service angeboten, wird mit IDBF vertestet
|
||||
- Ziel: zum Jahresende für das Bestellsystem zum Testen bereitstellen
|
||||
- Ãberblick über den Rest des Themenspeichers.
|
||||
- Monitoring: in Entwicklung, braucht nochmal ein Update
|
||||
- DNS-Namen für das Portal in EVU-Test sind bestätigt
|
||||
- Pen-Test-Termin weiter offen (?)
|
||||
|
||||
|
||||
## Termin 14.09.2021
|
||||
|
||||
## Teilnehmer: Natalia, Sean, Martin, Bishara, Diego, Konstantin
|
||||
|
||||
- Todos aus alten Terminen durchgehen
|
||||
- Nächste Schritte bzgl. X-Forward-Proto
|
||||
|
||||
128
|
||||
complete
|
||||
: versucht den Header im LB zu setzen (Infos zum Nachstellen des Fehlers siehe das I.NVI IT Lifecycle Management Toold1143f0d-33c0-3f1c-b44b-7720150f306eOO-2), siehe auch das CNP-Ticket
|
||||
|
||||
|
||||
- Vorgehen zum Tracken von Bugs
|
||||
- Bestellsystem tracket externe Abhängigkeit im neuen Jira
|
||||
- CNP plant ebenfalls auf das gleiche Jira umzusteigen: künftig kann Jira-intern verlinkt werden.
|
||||
- Natalia: die Einhaltung der Container-Richtlinien wurden für die DB-netz bis zum 1.1.2022 ausgesetzt. CNP arbeitet aktuell die Plattform-Vorgaben durch.
|
||||
- Martin erstellt gerade eine Todo-Liste, das I.NVI IT Lifecycle Management Toold1143f0d-33c0-3f1c-b44b-7720150f306eO2CZERO-53
|
||||
- GröÃte Baustelle ist Patch- und Schwachstellenmanagement (eingeplant für Q4).
|
||||
- Logging-Forwarding Richtung SIEM muss noch geklärt und eingeplant werden (komplex, aktuell bei IDBF in Besprechung).
|
||||
|
||||
129
|
||||
complete
|
||||
soll für 2022 eingeplant werden. => das I.NVI IT Lifecycle Management Toold1143f0d-33c0-3f1c-b44b-7720150f306eO2CSYS-158
|
||||
|
||||
|
||||
- Konstantin: zur Info: wir suchen derzeit Termine für Bedrohungsanalyse+Pentest Portal für Q4
|
||||
- Dynamische DNS-Einträge: Namensstruktur muss sich ändern.
|
||||
|
||||
130
|
||||
complete
|
||||
: gibt Sean Bescheid (voraussichtlich ab 17.9). => neue Namen festgelegt, durch PI-Planning leider erst spät umgesetzt
|
||||
|
||||
|
||||
- Zentraler Identity Provider
|
||||
- Diskussionen mit Jan-Sören Papp laufen aktuell.
|
||||
## Termin 31.08.2021
|
||||
|
||||
Teilnehmer: Bernd, Sean, Martin, Bishara, Diego
|
||||
- Sean: Probleme mit HTTP-Header X-Forward-Proto sollten spätestens bis 10.8 behoben sein. â Blocked by https://github.com/kubernetes/cloud-provider-aws/issues/234#issuecomment-885789048
|
||||
- Martin: Zugang zur CNP-API bekommen, technischer User fehlt noch. Zugang zur CNP-API wird prinzipiell für alle Entwickler benötigt (erstmal reichen Martin, Bing, Diego, Bishara). Die API-Doku ist bisher nur als FAQ verfügbar.
|
||||
|
||||
|
||||
123
|
||||
complete
|
||||
 : TechUser und Freischaltungen bis 1.9
|
||||
|
||||
|
||||
- Martin: Monitoring ist wieder in Bestellsystem-Dev ausgefallen.
|
||||
- Sean: CNP hat einen neuen Monitoring-Experten (Hannes Blut). Die Kommunikation läuft aber erstmal weiter über Sean bzw. den CNP/Bestellsystem Teams-Kanal.
|
||||
- Umstieg auf Aurora. Hier steht noch Aurora v1 (ginge sofort) oder v2 zur Auswahl (ist noch nicht von AWS freigegeben).
|
||||
|
||||
124
|
||||
complete
|
||||
: schickt eine kurze Info an Martin zu Aurora v1 (v1 reicht erstmal).
|
||||
|
||||
|
||||
## Termin 24.08.2021
|
||||
|
||||
Teilnehmer: Sean, Harald, Martin, Bing, Konstantin
|
||||
- Sean: Beim Monitoring sind gröÃere Setup-Ãnderungen inkl. Zugriffsrechte bis 13.September geplant.
|
||||
- Dann sollten auch Anpassungen der Dashboard durch Projekte möglich sein.
|
||||
- Sean: Ingress Controller sollten bis ca. 27.8 zum Testen bereit stehen.
|
||||
- EVU-Test bzw. Portal im Internet: Nach der SOAP-Schnittstelle wollen wir auch unser Web-Portal für Test-Partner (und dazu Keycloak) im Internet publizieren. Erster Merge-Request für DNS-Namen ist angelegt, die weiteren Schritte (Pen-Test, ISGW, folgen später).
|
||||
- Martin: Merge-Request vorbereitet. Installation der Portal-UI, MW und Keycloak in der evu-test-umgebung laufen.
|
||||
|
||||
112
|
||||
complete
|
||||
: Ausrollen der Ãnderungen aus dem Merge-Request.
|
||||
|
||||
|
||||
- Sean: Absicherung der Keycloak-Masken und f5-Konfiguration sollten mit Secure-Access-Services. Im Rahmen der ISGW-Vorgespräche.
|
||||
|
||||
113
|
||||
complete
|
||||
: ISGW-Team anschreiben und Anforderungen klären.
|
||||
|
||||
|
||||
- Konstantin: Planung der Penetrationstest. Bestellsystem geht direkt auf NVI6 zu (Natalia/Harald/Sean in CC).
|
||||
|
||||
114
|
||||
complete
|
||||
: NVI6 (Florian) anschreiben und Termine abstimmen.
|
||||
|
||||
|
||||
- Martin: brauchen wir einen anderen LB fürs Portal? Annahme: nein, die Unterscheidung nur im ISGW.
|
||||
- Netzwerk-Problem von EKS-Cluster zu ELB/Envoyâ siehe Termin 27.07.2021, Punkt 5
|
||||
|
||||
115
|
||||
incomplete
|
||||
schaut sich das an. Analysen haben bisher nichts ergeben. Die E-Mail-Kommunikation an Martin+Konstantin weiterleiten. das I.NVI IT Lifecycle Management Toold1143f0d-33c0-3f1c-b44b-7720150f306eOO-3
|
||||
|
||||
|
||||
- FYI, Nach ersten Erfahrungen mit SQS wollen wir unser Setup vereinfachen. Dazu verzichten wir künftig auf die dead-letter-queues und wahrscheinlich auch auf die FiFo-Queues (erfordert noch Absprache). â Erster Merge Request zum Hinzufügen der neuen Queues.
|
||||
- Künftige Termine: Im Bestellsystem haben wir jetzt einen 3-Wochen-Sprint. Um Kollision mit unseren Sprint-Terminen zu vermeiden würden wir alle folgenden Termine gerne um eine Woche verschieben, also nächste Abstimmungstermine am 31.8., 14.9. usw.
|
||||
|
||||
116
|
||||
complete
|
||||
: verschiebt die nächsten Termine um eine Woche vor.
|
||||
|
||||
|
||||
- CNP-API für Self-Service.
|
||||
|
||||
117
|
||||
complete
|
||||
gibt Martin Zugriff auf die API zum Ausprobieren.
|
||||
|
||||
|
||||
- Jetzt mit mehr Entwickler-Zugriff auf EKS wünschen wir uns ein Benutzer-Dashboard, könnt Ihr das was empfehlen?
|
||||
Wir können vermutlich selbst K8s-Dashboard oder k8dash starten...; aber bei der korrekten Konfiguration und einer OIDC-Anbindung (am besten an GitLab) würden wir lieber eine bestehende Vorlage nehmen anstatt alles selbst zu bauen und zu debuggen.
|
||||
- Sean: lens (wird aktuell beim Bestellsystem verprobt).
|
||||
- Martin: Session-Timeouts sind bei kubectl extrem kurz.
|
||||
|
||||
118
|
||||
complete
|
||||
: prüft, ob ein Hochsetzen möglich ist.
|
||||
|
||||
|
||||
## Termin 10.08.2021
|
||||
|
||||
- Service Mesh oder Ingress Controller: gibt es Neuigkeiten?
|
||||
- Service Mesh wird von neuem Kollegen implementiert, noch keine Termine
|
||||
- OIDC/Identity Provider:Â gibt es Neuigkeiten?
|
||||
- weiter in Arbeit, noch keine Termine
|
||||
- BBZ-API-Erreichbarkeit:Â gibt es Neuigkeiten?
|
||||
|
||||
104
|
||||
complete
|
||||
untersucht das weiter
|
||||
|
||||
|
||||
- Pentest-MaÃnahmen:Â gibt es Neuigkeiten?
|
||||
- TLS-Cipherliste am Loadbalancer
|
||||
- Zugriffsbeschränkung auf ISGW
|
||||
- HTTP-API-Pfade â ist in Envoy konfiguriertÂ
|
||||
## Termin 27.07.2021
|
||||
|
||||
- Pentest-MaÃnahmen seitens CNP prüfen
|
||||
- Nur ISGW soll auf Cluster-LB zugreifen dürfen (siehe ISGW-Doku für Port-Ranges)
|
||||
Nachtrag: einfacher Test mit Kommando curl -v https://evu-test-common-interface-bestellsystem-evu-test.cnp.comp.db.de/LIServices/LIHBMessage
|
||||
- TLS-Konfiguration in Cluster-LB härten => durch den oberen Punkt ist das vermutlich weniger kritisch, sollte auÃerdem ein allgemeines Thema für den LB sein.
|
||||
- Nur ausgewählte Pfade am LB durchlassen:
|
||||
-
|
||||
Das sollten "/LIServices/*", "/LIMessageProcessing/*" sein (mit Entwicklern gegenprüfen)
|
||||
- Merge Request:Â https://git.tech.rz.db.de/cnp/bestellsystem/bestellsystem-ops/-/merge_requests/27
|
||||
- Netzwerk-Probleme zu .eip.comp.db.de
|
||||
- wir benutzen eine API zur BenutzerBerechtigungsZuordnung (BBZ) unter https://awseip2iapigw103.eip.comp.db.de:5556/
|
||||
- Der Proxy webproxy.comp.db.de erlaubt keine Verbindungen dorthin,
|
||||
- Ohne Proxy bekommen wir keine Verbindung, nur einen Timeout (aus bestellsystem-dev und bestellsystem-evu-test)
|
||||
- ==> weitergegeben an Ops
|
||||
- dynamische DNS-Einträge: recht dringend, CNP arbeitet an einem Fallback (für Verfahren ohne Mesh) => siehe 13.07 => wartet auf CNP PI Planning
|
||||
- Schwachstellenmanagement (vgl. hier). Gibt es hier schon beispielhafte Prozesse in den anderen Projekten?
|
||||
- aktuell leben wir das bereits für Bibliotheken (Whitesource) sowie SonarQube-Findings
|
||||
- Fortify ist in Arbeit
|
||||
- Umgang mit Container-images ist schwieriger wegen der Abhängigkeiten
|
||||
- ==> es folgt ein CNP-Termin zum einheitlichen Umgang mit Security-Scannern und -Meldungen
|
||||
- ==> Wiedervorlage im September?
|
||||
- mögliche Netzwerk-Problem von EKS-Cluster zu ELB/Envoy?
|
||||
- Verbindungen von DBCS/VPN an unsere Loadbalancer-URLs (z.Bsp. https://cnp-common-interface-bestellsystem-fargate.cnp.comp.db.de/history/heartbeat) funktionieren, ebenso Verbindungen aus dem jeweils anderen Cluster (bestellsystem-dev oder bestellsystem-evu-test).
|
||||
- Verbindungen aus dem jeweils eigenen Cluster sind oft fehlerhaft und bekommen einen Fehler curl: (52) Empty reply from server , also
|
||||
- von bestellsystem-dev Request an https://cnp-common-interface-bestellsystem-fargate.cnp.comp.db.de/history/heartbeat
|
||||
- von bestellsystem-evu-test Request an https://evu-test-common-interface-bestellsystem-evu-test.cnp.comp.db.de/history/heartbeat
|
||||
-
|
||||
Nachtrag, 25.8.: in bestellsystem-evu-test haben wir jetzt einen festen Pod-Namen, da kann ich eine Kommandozeile zum Reproduzieren angeben:
|
||||
|
||||
|
||||
120
|
||||
complete
|
||||
mit Bitte um Fehlersuche im Envoy oder im AWS-Setup
|
||||
|
||||
|
||||
- Wir sehen immer wieder Probleme beim Starten von GitLab-Build-Pods in bestellsystem-dev.
|
||||
- DNS-Namensschema
|
||||
- Aktueller Stand Bestellsystem: wir vergeben für statische Deployments DNS-Namen nach Schema "<anwendungsumgebung>-<servicename>-<namespace>.cnp.comp.db.de" (z.Bsp. https://cnp-common-interface-bestellsystem-fargate.cnp.comp.db.de/)
|
||||
- Wir benutzen (künftig) auch pipeship für die CI-Pipeline, das vergibt temporäre Deploymentnamen aus Projekt- und Branch-Name (z.Bsp. `common-interface-review-build-pipe-13ekrh`) ==> damit wird es auch viele "unstrukturierte" Namen geben.
|
||||
- Wir verstehen den Wunsch noch das EKS-Cluster einzucodieren, aber zumindest in den temporären Build-/Test-Installationen bleibt uns praktisch kein Platz dafür. â Ist das wirklich notwendig, oder finden wir andere Wege dafür (vielleicht ein weiteres Element im Domain-Part, oder eine K8s-Annotation)?
|
||||
- ==> wird bei CNP weiter besprochen und refined
|
||||
## Termin 16.07.2021 (Sonderthema Monitoring)
|
||||
|
||||
- Bedarf an einer Grafana-Instanz mit Schreibrechten für Entwickler.
|
||||
- Ideen des Bestellsystems sind hier dokumentiert (primär eigene Instanzen basierend auf MaaS).
|
||||
- Alternativvorschlag CNP: Zugriff auf die "Beta" Instanz des Grafana inkl. SchreibrechteÂ
|
||||
|
||||
93
|
||||
complete
|
||||
: Infos zum Beta-Grafana verteilen
|
||||
|
||||
|
||||
- Input der Daten aus DBCS wünschenswert (falls nicht zu kompliziert)
|
||||
|
||||
94
|
||||
complete
|
||||
, : prüfen zusammen ob Federation über Cortex-Endpoint funktioniert
|
||||
|
||||
|
||||
- Alert-Manager: In Arbeit bei CNP?
|
||||
- CloudWatch-Metriken für RDS/SQS/S3 in Grafana benötigt (Ein Muss für DevOps)
|
||||
- Zentrales Monitoring: ist primär ein CNP-Thema, keine unmittelbaren Projekt-Todos.
|
||||
## Termin 13.07.2021
|
||||
|
||||
- Punkte aus den alten Terminen
|
||||
- Sean: http/2 sollte von AWS/K8s/ISGW unterstützt werden
|
||||
- Martin: Probleme mit Monitoring
|
||||
|
||||
87
|
||||
complete
|
||||
: prüft es. Monitoring ist derzeit im Umbau.
|
||||
|
||||
|
||||
- Martin: ADR zu Aurora geschickt. Passt für CNP.
|
||||
- Aurora RDS ist die aktuelle Lösung.
|
||||
- Martin:Â Protokoll-Header X-Forward-Proto via Merge-Request hat noch nicht funktioniert.
|
||||
|
||||
88
|
||||
complete
|
||||
prüft das
|
||||
|
||||
|
||||
- Natalia: Service-Mesh sollte besser als automatisierte Variante bereitgestellt werden.
|
||||
- Aktuelles Ziel: Bereitstellung App Mesh bis Mitte August
|
||||
- Abhängigkeiten
|
||||
- SSL für inter-service Kommunikation: ist nicht arg dringend
|
||||
- dynamische DNS-Einträge: recht dringend, CNP arbeitet an einem Fallback (für Verfahren ohne Mesh)
|
||||
|
||||
89
|
||||
complete
|
||||
Wiedervorlage in 2 Wochen
|
||||
|
||||
|
||||
- Bestellsystem-Entwickler-Zugriff
|
||||
- Um mehr Wissen in unseren Teams zu verteilen würden wir gerne unseren Entwicklern mehr Zugriff gewähren.
|
||||
|
||||
- im Teams-Kanal 'Bestellsystem' möchten wir Bishara Jaser und Frank Fk Thiele hinzufügen,
|
||||
- im GitLab-Repo 'bestellsystem-ops' würden wir denen auch Lese-Zugriff geben. Entweder der ganzen Gruppe Bestellsystem (falls das nicht "zu offen" ist), oder einzeln den Benutzern Bing Shi, Bishara Jaser und Frank Fk Thiele
|
||||
- S3 Object Lifecycle
|
||||
wir benutzen unsere S3-Buckets nur für temporäre Daten, die für SQS zu groà sind. Um die Verwaltung zu vereinfachen sollen die Daten nach bestimmter Zeit (in aktuellen Umgebungen nach 14 Tagen) gelöscht werden. â Merge Request in bestellsystem-ops
|
||||
- Konstantin: Pentest wurde durchgeführt.
|
||||
- Spannendste Ergebnisse und nächste Schritte besprechen.
|
||||
- fachliche Themen
|
||||
- Header-Handling im ISGW
|
||||
- Absicherung der Strecke ISGWÂ â ELB
|
||||
- SecurityGroup/ACL damit nur der ISGW auf ELB zugreifen darf
|
||||
|
||||
90
|
||||
incomplete
|
||||
einrichten ab 19.07 => danach Prüfung durch Entwickler, dass der interne Zugriff nicht mehr funktioniert.
|
||||
|
||||
|
||||
- prüfen, ob das für die EVU-Test-Umgebung ein Problem ist. Debug-Zugriff auf andere Umgebungen problematisch.
|
||||
- Annahme: interner Zugriff sollte nur über K8s-Proxy erfolgen. (Alternative wären 2 ELBs)
|
||||
- Folge-Aktionen
|
||||
- Bericht wird bis 17.7 erwartet
|
||||
- Verteilung an: CNP, NVI6 (db.netz.csac@deutschebahn.com)).
|
||||
- Freigabe durch NVI41
|
||||
- Plan: ab 1.8 soll EVU-Test extern verfügbar sein.
|
||||
- Konstantin: Status der Abstimmungen mit eBRS/MyNet/Kundenportal bzgl. der Einführung der SSO/MFA - aktuell nutzen wir als Workaround Keycloak. Falls keine Lösung von eBRS kommt, muss Keycloak (oder Alternative) zum Live-Gang durch das Projekt oder CNP  betrieben werden.
|
||||
- In Q3/Q4 wäre ein Pen-Test fürs Portal inkl. Keycloak  fällig.
|
||||
- 2 Freischaltungen notwendig: Portal + Login
|
||||
- evtl. schon mit der Keycloak-Alternative von CNP (siehe unten)
|
||||
- Vorlauf
|
||||
- ISGW ca. 1 Monat
|
||||
- Natalia: Keycloak braucht einen Support-Vertrag
|
||||
- Sean: arbeite gerade an einer AuthNAuthZ (A&A)-Lösung (als Alternative u.a. zu Keycloak)
|
||||
|
||||
91
|
||||
complete
|
||||
: Wiedervorlage in 2 Wochen
|
||||
|
||||
|
||||
92
|
||||
complete
|
||||
: schickt Sean Doku und Gitlab-Links zu Keycloak zu:Â hier
|
||||
|
||||
|
||||
## Termin 29.06.2021
|
||||
|
||||
- Diverses
|
||||
- Aktuelles Thema: gibt es Erfahrungen mit http/2? Unsere Entwickler haben das als Performance-Optimierung fürs Bestellportal identifiziert. Wir befürchten aber, dass dies von Proxies, LBs oder ISGW nicht unterstützt werden könnte.
|
||||
|
||||
75
|
||||
complete
|
||||
: prüfen, ob das im ELB aktiviert werden kann.
|
||||
|
||||
|
||||
- Wechsel von RDS zu Aurora
|
||||
- Optionen: Aurora RDS vs. Aurora Serverless
|
||||
|
||||
76
|
||||
complete
|
||||
: beim nächsten Termin ADR vorstellen
|
||||
|
||||
|
||||
- Stand EVU-Test Umgebung.
|
||||
- Erledigte Punkte
|
||||
- Weitere notwendige AWS-Dienste für EVU-Testumgebung bestellsystem-evu-test:  â Anmerkung Martin: ist inzwischen soweit erledigt, oder?
|
||||
- RDS-Datenbank (kleine Instanz so wie für bestellsystem-dev)
|
||||
- eigene Diskussion: im AWS-Kontext scheint Aurora der bessere Datenbank-Service zu sein, den würden wir gerne vertesten.
|
||||
- wir sind uns unsicher ob gerade dies eine gute Test-Umgebung ist, können wir da noch Monitoring für bekommen?
|
||||
- Meinung von Seite CNP? Habt Ihr Empfehlungen oder Präferenzen?
|
||||
- aktueller Status? â> laut bestellsystem-ops-Repo ist die RDS-Instanz eingerichtet, aber Martin hat noch kein Login-Passwort
|
||||
- die SQS-Zugriffsrechte stimmen noch nicht ganz, siehe Merge Request in bestellsystem-ops
|
||||
- DNS-Namen passen noch nicht, siehe Merge Request in bestellsystem-ops
|
||||
- Offen
|
||||
- Protokoll-Header X-Forward-Proto (muss https statt http sein).
|
||||
|
||||
77
|
||||
complete
|
||||
: konfigurieren in ELB
|
||||
|
||||
|
||||
- Zertifikate für PEN-Tester.
|
||||
|
||||
78
|
||||
complete
|
||||
 versucht Test-Zertifikate von RNE zu bekommen. Alternativ kann man die eigenen Zertifikate nutzen.
|
||||
|
||||
|
||||
- Roadmap Pipelines auf CNP (Migration von DBCS zu CNP) â Was wäre noch nötig, um das Bestellsystem im PI21 (~Q3) nach CNP umzuziehen?
|
||||
- Management-API (kein Blocker fürs Bestellsystem)Â
|
||||
- : Aktuell in Konzeption, PoC in Juli
|
||||
- separate (dezentrale) Management-APIs für Projekte notwendig. Lieferung bis Ende August möglich.
|
||||
- Die DNS-Einträge blockieren uns aktuell, weil automatische Tests per HTTPS so nicht funktionieren
|
||||
- Abhängigkeit zu Service-Mesh. Manuelle Bereitstellung (wie bei IFP) nicht empfohlen
|
||||
|
||||
79
|
||||
complete
|
||||
 Wiedervorlage in 2 Wochen.
|
||||
|
||||
|
||||
- Workaround mit Cluster-local URLs funktioniert nicht für alle Use Cases (z.B. Cypress)
|
||||
- Alternative mit Ingress-Controller (ohne Service Mesh)
|
||||
|
||||
80
|
||||
complete
|
||||
prüft bis 13.7
|
||||
|
||||
|
||||
- API-Zugriff um SQS-Queues anzulegen wäre hilfreich, aber nicht dringend notwendig (damit würden wir gerne localstack ersetzen)
|
||||
- siehe Management API oben.
|
||||
- Es wäre gut dafür im Cluster `bestellsystem-dev` neue Namespaces anzulegen (zur Info, in Abstimmung bei Martin und Sean):
|
||||
|
||||
- build â dies ist dann der einzige Namespace in dem wir "Container als Root"-Rechte für Kaniko brauchen, sowie Zugriff zum GitLab-S3-Cache
|
||||
- ieu â unsere pre-prod Installationsumgebung, bräuchte dann SQS/S3 und RDS als Dienste
|
||||
- Last-/Performance-Test?
|
||||
- Fargate oder extra-Cluster? Fargate für die initiale LuP Entwicklung ok.
|
||||
- Keycloak-Betrieb auf CNP: Erfahrungen und Optionen.
|
||||
- dex statt Keycloak intern in CNP verwendet.
|
||||
- Siehe IAM-Portal und ADR
|
||||
- PoC in CNP geplant ab 5.7
|
||||
- Bestellsystem unterstützt mit Ressourcen (Martin und ein Entwickler/in aus Team 404).
|
||||
## Termin 22.06.2021
|
||||
|
||||
- Anmerkung von : Web-Proxy-Policy webproxy.comp.db.de
|
||||
- nicht dringend, aber im Rahmen des EVU-Test-Setups aufgefallen: Anscheinend benutzt der Bahn-Web-Proxy verschiedene Policies für DBCS und CNP?
|
||||
- Test-Anfrage: https_proxy='http://webproxy.comp.db.de:8080' curl -v https://bestellsystem-commoninterface-test.dbnetze.com/history/heartbeat
|
||||
|
||||
- lokal per VPN => timeout, ist OK, weder EVU-Test noch Proxy sind allgemein zugänglich
|
||||
- in DBCS mit webproxy.comp.db.de => HTTP 404 von ISGW, soweit OK, wenn das ISGW-Setup noch nicht fertig ist
|
||||
- in CNP mit webproxy.comp.db.de =>Â `curl: (56) Received HTTP code 403 from proxy after CONNECT`, mit Header `X-Squid-Error: ERR_ACCESS_DENIED 0`
|
||||
- im Virtuellen Desktop (VDS) =>Â `curl: (56) Received HTTP code 403 from proxy after CONNECT`, mit Header `X-Squid-Error: ERR_ACCESS_DENIED 0`
|
||||
- Ist also kein "Problem" mit CNP, sondern eher ein zusätzlicher Zugriff aus DBCS.
|
||||
- Nachtrag: aus Sicht Bestellsystem wünschen wir uns eine allgemeine Verfügbarkeit im internen Bahn-Netz (besonders auch per VPN und VDS), damit wir selbst einfach testen können
|
||||
- ISGW funktioniert noch nicht.
|
||||
- Endpunkt leitet nicht â Aktuell noch ein HTTP 404 â TODO fragt bei ISGW nach ob der interne Endpunkt aufgelöst werden kann.
|
||||
-
|
||||
Custom SSL Zertifikat ist noch nicht gesetzt. â self signed cert â Zu klären ob das i.O. ist. â Erledigtbashaktueller Stand, Request mit RNE-Client-Zertifikattrue CONNECT bestellsystem-commoninterface-test.dbnetze.com:443 HTTP/1.1
|
||||
> Host: bestellsystem-commoninterface-test.dbnetze.com:443
|
||||
> User-Agent: curl/7.67.0
|
||||
> Proxy-Connection: Keep-Alive
|
||||
>
|
||||
GET /history/heartbeat HTTP/1.1
|
||||
> Host: bestellsystem-commoninterface-test.dbnetze.com
|
||||
> User-Agent: curl/7.67.0
|
||||
> Accept: */*
|
||||
>
|
||||
* Mark bundle as not supporting multiuse
|
||||
|
||||
|
||||
|
||||
- Vereinbarung war dass im header X-Client-Cert header mit eingetragen â können wir erst testen wenn die Requests an unsere Services durchkommen
|
||||
-
|
||||
offener punkt ist der redirect von https auf http
|
||||
Nachtrag dazu:
|
||||
â Envoy sendet der Anwendung den falschen Header X-Forwarded-Proto: httpHTTP-Request Headertrue
|
||||
|
||||
|
||||
|
||||
68
|
||||
complete
|
||||
können wir das in der Envoy-Config ändern? Als schnellen Fix für den EVU-Test könnten wir den Header immer überschreiben, weil wir von externen Clients nie HTTP-Verbindungen erwarten.
|
||||
|
||||
|
||||
- Wir brauchen eine Lösung für den Container-Image-Build.  nimmt Â
|
||||
Hatten wir im März aufgeschoben, ist jetzt aber notwendig weil Kaniko nur mit root-Rechten im Container funktioniert; das kollidiert mit der OPA-Policy.
|
||||
- perspektivisch ggf. in seperatem namespace
|
||||
- Enovy Config wird nach dem PenTest umkonfiguriert, sodass wir explizit routes erlauben, statt zu verweigern. Hierfür werden die routes benötigt.
|
||||
## Nachtrag, ISGW-Termin 24.06.2021
|
||||
|
||||
Ergänze ich hier, weil das thematisch anschlieÃt und einige offenen Fragen klärt.
|
||||
- HTTPS ist konfiguriert wie von uns angefragt
|
||||
- RNE-Server-Zertifikat für unsere CN
|
||||
- Client-Cert-Validierung gegen RNE-CA-Cert 'CA CCS 1'
|
||||
- Client-Cert-Daten werden base64-kodiert in den HTTP-Header X-Client-Cert eingefügt
|
||||
- es gab die Frage ob der Header bei jedem Request, oder nur beim ersten Request einer HTTPS/1.1 Session nötig ist. wir haben jetzt um jeden Request gebeten, â da gibt es künftig Optimierungsmöglichkeiten
|
||||
- Wie die Pen-Tester an Zertifikate kommen ist noch unklar â Kick-off-Termin
|
||||
- Die interne Erreichbarkeit der externen Domain ist schwierig und erfordert den Web-Proxy http://wwwproxy.tech.rz.db.de:8080
|
||||
- Zu Policy-Problemen/Fragen mit dem Proxy haben wir Alexander Perleth als Kontakt genannt bekommen.
|
||||
- weiterer Test: der webproxy.comp.db.de sperrt Zugriffe aus unserem EKS-Containern, aber der Proxy wwwproxy.tech.rz.db.de funktioniert
|
||||
- sehen wir da noch Handlungsbedarf?
|
||||
- Der aktuelle Fehler 404 wird durch einen falschen Hostnamen bzw. ein fehlendes Umschreiben des Hostnamen verursacht.
|
||||
- ISGW setzt auch in den internen Requests den HTTP-Header Host: bestellsystem-commoninterface-test.dbnetze.com
|
||||
- Der CNP-Envoy bzw. AWS-ELB kennt den Hostnamen nicht und antwortet mit 404
|
||||
- Korrektur dafür: den Hostnamen im CNP-Envoy einkonfigurieren --> wird von Sean eingetragen und mit Martin getestet
|
||||
## Termin 15.06.2021
|
||||
|
||||
- Pen-Test für EVU-Testumgebung ist bestätigt
|
||||
Kick-off-Termin (1h, voraussichtlich 28. Juni), Sean wird eingeladen
|
||||
- EVU-Test
|
||||
- ISGW ist eingerichtet, interner Ziel-DNS fehlt noch
|
||||
- Deployment-Diagramm, `bestellsystem-ops`-Repo bei CNP und `bestellsystem-deployment`-repo bei Bestellsystem werden verlinkt
|
||||
- IFP-SQS-Tests
|
||||
- aktuell fehlen KMS-Zugriffsrechte â Merge Request in bestellsystem-ops
|
||||
- Klärung FIFO-/Standard-Queues in SQS und Umgebungen
|
||||
- Stand Service Mesh?
|
||||
- wird aktuell mit IFP implementiert,
|
||||
- für das Bestellsystem erst in Q4 realistisch
|
||||
- Roadmap Pipelines auf CNPÂ â Das Bestellsystem plant im PI21 (~Q3) nach CNP umzuziehen
|
||||
- Die DNS-Einträge blockieren uns aktuell, weil automatische Tests per HTTPS so nicht funktionieren
|
||||
- eigener Namespace für build â Setup so wie in bestellsystem-dev mit EC2 und fargate
|
||||
- Martin und Sean besprechen das vor der PI-Planung
|
||||
- Bestellsystem-Testkonzept
|
||||
|
||||
- Konzept im Bestellsystem-Confluence
|
||||
- technische Doku im Bestellsystem-Entwicklungshandbuch
|
||||
- nach dem EVU-Test werden wir das Web-Portal ins Internet bringen, dafür müssen wir einen Keycloak im Internet betreiben â Folgetermin
|
||||
## Termin 01.06.2021
|
||||
|
||||
- Stand EVU-Test-Umgebung
|
||||
-  Wir haben im bestehenden Namespace `bestellsystem-fargate` einen neuen Service `cnp-ifp-mock` â für den hätten wir gerne DNS-Einträge um den im Review zeigen zu können.Â
|
||||
SQS-Queues:Â evu-test-produktionsauftrag, evu-test-vertriebsauftrag.
|
||||
S3-Bucket:Â evu-test-vertriebsauftrag.Â
|
||||
IAM-Role:Â bestellsystem-evu-test-sqs-access (mit read/write-Zugriff auf Queues und Bucket)
|
||||
|
||||
56
|
||||
complete
|
||||
: wird eingerichtet. â bitte testen und ggf. Rückmeldung an die Resourcennamen liegne im Teams Bestellsystem Channel
|
||||
|
||||
|
||||
- fehlende Zugriffsrechte â ist bei CNP in Arbeit
|
||||
|
||||
57
|
||||
complete
|
||||
Lösung bis Montag 7.6 notwendig (notfalls ohne WebSSO) â kubeconfig wurde an übermittelt
|
||||
|
||||
|
||||
- Monitoring funktioniert derzeit noch nicht für bestellsystem-evu-test
|
||||
|
||||
58
|
||||
complete
|
||||
in Arbeit, benötigt bis 9.6 für die System-Demo des PI 20 â Nachdem vergangende Woche die Nodegroup Resourcen gefixed wurden funktioniert nun auch wieder das Dashboard. Einige Dashboards für das bestellsystem-evu-test cluster werden erst etwas anzeigen wenn dort Workloads deployed wurden.
|
||||
|
||||
|
||||
- ISGW (und DNS)Â
|
||||
|
||||
59
|
||||
complete
|
||||
 :Domäne bestellsystem-commoninterface-test.dbnetze.com reserviert?
|
||||
|
||||
|
||||
60
|
||||
complete
|
||||
: ELB Probleme noch zu beheben. Ein ELB-Endpunkt für ISGW reicht aus.
|
||||
|
||||
66
|
||||
incomplete
|
||||
Antrag wurde gestellt, jedoch wurde der Endpunkt im Antrag falsch ausgefüllt. meldet sich sobald mehr Informationen verfügbar sind.
|
||||
|
||||
|
||||
|
||||
|
||||
61
|
||||
complete
|
||||
Zertifikat liegt vor. bei Bedarf bei Konstantin erfragen.
|
||||
|
||||
|
||||
62
|
||||
complete
|
||||
: Anforderung bzgl. Client-Zertifikate senden
|
||||
|
||||
|
||||
- PEN-Test vorbereiten
|
||||
|
||||
63
|
||||
complete
|
||||
Anmeldung erfolgt sobald Natalia da ist
|
||||
|
||||
|
||||
- Wichtig: die Umgebung sollte zum 1.8 im Internet (nach dem PEN-Test) verfügbar sein.
|
||||
- Filterung der Routen für ISGW (Monitoring-Endpunkte, interne APIs) - wird im Service verprobt
|
||||
- AWS Aurora
|
||||
|
||||
64
|
||||
complete
|
||||
 eine Aurora-Instanz zum Verproben
|
||||
|
||||
|
||||
- Pipelines
|
||||
- Bestellsystem hatte Austausch mit CDaaS-Team bzgl. Gitlab Agent. Es gibt ein Helm-Chart, der auch auf EKS benutzt werden darf.
|
||||
## Termin am 18.05.2021
|
||||
|
||||
- Monitoring: Bestellsystem-Dashboards zeigen aktuell NO DATA an:Â
|
||||
|
||||
37
|
||||
complete
|
||||
prüft es und lässt es korrigieren (siehe 1.6.2021)
|
||||
|
||||
|
||||
- Aktuelle Bestückung des Clusters bestellsystem-dev mit 3 EC-Nodes
|
||||
- Reicht aktuell aus
|
||||
- Zusammenspiel von Plattform (CNP), Pipelines (MoQ-AP) und Anwendung (Bestellsystem)
|
||||
|
||||
38
|
||||
complete
|
||||
: wird nach Natalias Rückkehr besprochen (siehe Themenspeicher, bzw. Termin am 8.6)
|
||||
|
||||
|
||||
- Umstellung des K8s-Logins auf Web-SSO:
|
||||
- es kann die selbe Nutzer-Liste wie für Dashboards genutzt werden
|
||||
- Erstmal keine Unterscheidung in Rechten
|
||||
- Service-Account für Gitlab-Runner
|
||||
|
||||
39
|
||||
complete
|
||||
: kann User selbst anlegen, Anleitung bei Sean besorgen und dokumentieren
|
||||
|
||||
|
||||
- DNS-Publikation für Ingress-Controller
|
||||
|
||||
40
|
||||
complete
|
||||
: fragt nach dem aktuellen Status (siehe 1.6.2021)
|
||||
|
||||
|
||||
## Termin am 11.05.2021
|
||||
|
||||
- Ankündigung: künftig gibt es zwei Domains für prod und non-prod-Betrieb (cnp.comp.db.de und cnp-test.comp.db.de).
|
||||
Wenn es soweit ist wird das von Sean mit Martin koordiniert und im Bestellsystem-Deployment angepasst
|
||||
- schneller Check der letzten Agenda-Punkte
|
||||
- ISGW-Bestellung für EVU-Test, mit GröÃe S
|
||||
|
||||
41
|
||||
complete
|
||||
 :wird im nächsten Sprint gemacht (siehe 1.6.2021)
|
||||
|
||||
|
||||
- Kurze Einordnung zur Roadmap Pipelines
|
||||
- Vorschlag: CNP-Distribution für den GitLab-Runner
|
||||
Wir haben jetzt einiges Trial-and-Error gebraucht um den GitLab-Runner für S3-Cache, für Fargate, und für non-privileged/non-root Pods zu konfigurieren. Für andere Projekte wäre es sicher hilfreich wenn es eine CNP-Default-Konfiguration gäbe. Zudem gibt es den Support-/Interne-Lizenzen-Graubereich dass wir gerade CDaaS-Setups und Container für CNP anpassen; auch da wäre ein CNP-Template hilfreich.
|
||||
=> wird vermutlich an MoQ-AP abgegeben
|
||||
- Ankündigung: Der K8s-Login (aktuell `bestellsystem-admin` mit Token) wird auf Web-SSO umgestellt, Sean und Martin sprechen sich dazu ab
|
||||
## Termin am 04.05.2021
|
||||
|
||||
- Bestellsystem-Benutzer zu den Bestellsystem-relevanten Dashboards hinzufügen (aktuell hat nur Martin Zugriff)
|
||||
|
||||
32
|
||||
complete
|
||||
: schickt Sean eine Liste der Bestellsystem-Benutzer
|
||||
|
||||
|
||||
33
|
||||
complete
|
||||
: Gruppe Bestellsystem ergänzen
|
||||
|
||||
|
||||
- Dediziertes Cluster für EVU-Testumgebung bestellsystem-evu-test, 2x m5-large EC2
|
||||
|
||||
34
|
||||
complete
|
||||
: legt Umgebung an
|
||||
|
||||
|
||||
- Service-Mesh Status: aktuell keine Neuigkeiten
|
||||
- Externer DNS-Name bestellsystem-commoninterface-test.dbnetze.com
|
||||
|
||||
35
|
||||
complete
|
||||
: fragt bei Natalia nach
|
||||
|
||||
|
||||
- Deployment-Sicht https://git.tech.rz.db.de/-/snippets/613
|
||||
|
||||
36
|
||||
complete
|
||||
: liefert Feedback
|
||||
|
||||
|
||||
- PEN-Test kann (soll?) inzwischen DB-intern durchgeführt werden. Unklar ob damit Systel AppSec oder DB-Netz eigene Leute gemeint sind.
|
||||
- OPA Policies haben neulich den Kaniko-Build verhindert.
|
||||
- Künftig werden Policy-Ãnderungen vorab angekündigt
|
||||
- Container-Image Build - eine saubere Lösung steht noch aus. Evtl. kann hier MoQ-AP etwas bereitstellen.
|
||||
- Gitlab-Runner - vom wem wird dieser künftig bereitgestellt werden: MoQ-AP, CDaaS, CNP?
|
||||
## Termin am 27.04.2021
|
||||
|
||||
- Neue Termin-Serie ab 4.5 9:15-9:45 alle 2 WochenÂ
|
||||
- Bedarf für eine MacOS Instanz (mit Safari für Frontend-Tests) in der Cloud
|
||||
- Lässt sich die auf EC2 starten (https://aws.amazon.com/ec2/instance-types/mac/)?
|
||||
- Hürden: erfordert dedicated hosts und ist nur in Irland (eu-west-1) verfügbar.
|
||||
- => Region eu-west-1 ist K.O.-Kriterium, deshalb ist das Setup nicht möglich. (Wir werden also versuchen stattdessen einen BKU-Rechner zu bestellen).
|
||||
- Externe (Sub-)Domäne fürs Bestellsystem steht endlich fest (siehe BSQ-384): Wer kann sie im Service Manager Service Manager anlegen?
|
||||
|
||||
21
|
||||
complete
|
||||
 : Auftrag über Natalia an TBF für den beschlossenen NamenÂ
|
||||
|
||||
|
||||
- Vorbereitung: EVU-Testumgebung und Pen-Test: dediziertes Cluster oder Namespace?
|
||||
- : schlieÃen sich kurz
|
||||
- Deployment-Sicht auf das Bestellsystem
|
||||
|
||||
22
|
||||
complete
|
||||
: Entwurf für 4.5.2021 â noch sehr vorläufig: https://git.tech.rz.db.de/-/snippets/613
|
||||
|
||||
|
||||
- Mit CI-Pipelines auf EKS brauchen wir auch mehr EC2-Ressourcen... grobe Abschätzung: 3 àm5.xlarge (jeweils 4 vCPUs, 16 Gb RAM)
|
||||
-- für drei Anwendungs-Installationen (jeweils 1-2vCPUs und 4Gb RAM), 10 GitLab-Runner (jeweils 2-3vCPUs und 1-10Gb RAM), und 5-10 AT-Deployments (die review-Deployments könnten nach Fargate)
|
||||
|
||||
23
|
||||
complete
|
||||
: erweitert die Node GroupÂ
|
||||
|
||||
|
||||
-
|
||||
Wir sehen gelegentliche Fehler beim Starten von Pods.
|
||||
-
|
||||
K8s-Events:Â
|
||||
|
||||
|
||||
-
|
||||
Das führt dann zum GitLab-Fehler:Â
|
||||
|
||||
Können wir das verbessern?
|
||||
-
|
||||
Speziell in Fargate gibt es auch Probleme mit Ressourcen-Quotas, das liegt vermutlich an Verhalten oder Konfiguration der GitLab-Runner, erscheint aber nur gelegentlich (und ist dadurch schwer zu demonstrieren oder zu beseitigen):
|
||||
|
||||
|
||||
- Storage für Gitlab Cache: S3 bevorzugt
|
||||
- erledigt: Bucket ist angelegt und wird vom GitLab-Runner benutztÂ
|
||||
- Nachfrage zu den ServiceAccount-Definitionen im bestellsystem-ops-Repo: sind die nur zur Info oder werden die irgendwann einmal eingespielt?
|
||||
Wir haben nämlich zusätzliche Einstellungen (imagePullSecrets), die wir dann ggf. einpflegen müssen.
|
||||
|
||||
24
|
||||
complete
|
||||
: schaut sich das an. Prinzipiell kann das über MergeRequest beantragt werden.
|
||||
|
||||
|
||||
## Termin am 13.04.2021
|
||||
|
||||
- Confluence für Mitschrift
|
||||
|
||||
13
|
||||
complete
|
||||
Konstantin: Freischaltungen für Natalia + Sean
|
||||
|
||||
|
||||
- Serien-Terminverschiebung um eine Woche, ab 20.4
|
||||
|
||||
14
|
||||
complete
|
||||
Natalia lädt ein
|
||||
|
||||
|
||||
- CNP-Umgebungen im Bestellsystem
|
||||
- Aktuell läuft eine PoC-Umgebung auf CNP, die fertige Docker-Images installiert, über einen Gitlab-Runner
|
||||
|
||||
15
|
||||
complete
|
||||
: Bestellsystem wird um CNP-Monitoring erweitert (war schonmal drin)
|
||||
|
||||
|
||||
- Sean: S3-Queues müssen neu angelegt werden, da das Namensschema sich geändert hat
|
||||
|
||||
16
|
||||
complete
|
||||
Sean geht auf Martin zu
|
||||
|
||||
|
||||
- Aktuell wird im Bestellsystem eine Build-Pipeline auf CNP aufgebaut
|
||||
- langfristigere Fragen:
|
||||
|
||||
- automatische DNS-Einträge für Ingress
|
||||
- noch keine Terminaussage möglich
|
||||
- API-Zugang
|
||||
- frühestens in einem Monat
|
||||
- Info zu Service Mesh
|
||||
- siehe DNS-Einträge, Rollout am 27.4 geplant
|
||||
- Secret-Ablage im Bestellsystem
|
||||
- Gitlab-Runner legt sie im Kubernetes ab
|
||||
- Zugriffe aus VPN per HTTPS auf Anwendungen immer noch langsam (3-4 Sec)?Â
|
||||
- scheinen sich gebessert zu haben
|
||||
## Termine am 01.03.2021, 16.03 und 30.03
|
||||
|
||||
Mitschrift
|
||||
- DNS-Einträge für neue Deployments/Ingresse (am 26.2. nochmal getestet; erfordert manuelle Schritte)
|
||||
- Sollte automatisch funktionieren --> kommt erst mit Service Mesh
|
||||
- Service Mesh: Recherche-Thema ganz am Anfang, wir wollen wissen was CNP anbietet bzw. plantâ
|
||||
- Roadmap und Dokumentation: Ende März erste Service Mesh Version geplant (app.mesh)
|
||||
- Wie kann eine Lösung für REST-API Authentifizierung? Gibt es hierzu Infos?
|
||||
- Sean prüft das und schickt einen Vorschlag
|
||||
|
||||
5
|
||||
incomplete
|
||||
(bis ca. 8.4)
|
||||
|
||||
|
||||
- Hängt von ausstehenden AWS Diensten ab (Ingress Controller)
|
||||
- In Q2 eher unrealistisch
|
||||
- Â PEN-Test
|
||||
- Verschlüsselung/Authentifizierung
|
||||
- Offener Punkt --> kann PEN Test verhindern!
|
||||
- Natalia teilt Detaillsplanung wegen ISGW --> temp. Auch ohne PEN-Test möglich max. 2-3 Wochen --> vermutlich über CNP. Details klären.
|
||||
- (PEN-Test pro Service oder System, Beauftragung durch CNP, Vorlaufzeit bis zu 6 Wochen, ca. Ende Q2)
|
||||
- Kapa-Bel von IFP --> steht im März an
|
||||
- OPA für Autorisierung
|
||||
- Kann erst nach app.mesh kommen, frühestens im Juni für Projekte
|
||||
- Routing für Diskriminierungsfreiheit
|
||||
- Analog KommBau
|
||||
- Interne Adresse gesperrt (über Whitelist)
|
||||
- Keine Auswirkung auf Betriebsdienste
|
||||
- Anhebung des Monitorings auf die nächste Stufe --> vom demo/PoC zum Regelbetrieb
|
||||
- Heraufstufen der Umgebung
|
||||
|
||||
6
|
||||
complete
|
||||
zwischen 15. und 25. März möglich, wird seitens CNP gemacht
|
||||
|
||||
|
||||
- Erstmal weiterhin ein Cluster-Admin-Account fürs Bestellsystem
|
||||
- falls wir ein Deployment ohne Fargate haben, dann auch Anwendungs-Logdaten in deren GrafanaÂ
|
||||
-
|
||||
Wird mit dem Heraufstufen der Umgebung voraussichtlich gelöst
|
||||
-
|
||||
Wann geht Logging mit Fargate?
|
||||
-
|
||||
Erfordert einen Log-Forwarder über Dateien und eigenen Sidecar-Deployment (promtail-agent)
|
||||
-
|
||||
Alternativ warten auf AWS-Feature --> wird von Bestellsystem derzeit bevorzugt
|
||||
-
|
||||
SQS-Zugriffsrechte (ist in Arbeit, Maximilian war krank)
|
||||
|
||||
7
|
||||
complete
|
||||
|
||||
Ist gerade in Arbeit
|
||||
|
||||
|
||||
-
|
||||
hybrider EKS-Namespace mit EC2 (für GitLab-Jobs) und Fargate (für skalierbare Installationen)
|
||||
-
|
||||
Martin schickt die Anforderungen an eine neue EC2 Instanz, CNP macht es zusammen mit der Heraufstufung (ebenfalls 15-25.03)
|
||||
-
|
||||
Reifegrad MoQ-AP Integration --> gibt es noch offene Punkte (insb. Privileged Mode)
|
||||
-
|
||||
Es kann in derselben Bestellsystem-Umgebung bei CNP laufen
|
||||
-
|
||||
Natalia kann das Wissen sharen (Betriebsstellen-Service) --> Austausch zwischen Projekten muss über MoQ-AP laufen
|
||||
-
|
||||
Privileged mode noch seitens MoQ-AP benötigt --> ist kein dringendes Problem
|
||||
-
|
||||
Vault vs AWS Secret Manager
|
||||
-
|
||||
Vault wird von Bestellsystem nicht benötigt
|
||||
-
|
||||
Wichtig sind Kubernetes Secrets
|
||||
-
|
||||
AWS Secrets Manager als Vorgabe
|
||||
-
|
||||
Regel-Termin alle 2 Wochen
|
||||
|
||||
8
|
||||
complete
|
||||
|
||||
Natalia lädt ein
|
||||
+388
@@ -0,0 +1,388 @@
|
||||
# Community of Practice (CoP)
|
||||
|
||||
> Confluence Page ID: 171574432
|
||||
> Version: 83
|
||||
> Pfad: /pathOS/Kommunikationskanäle, Termine, Besprechungsnotizen pathOS/Besprechungsnotizen/Community of Practice (CoP)
|
||||
> Labels: file-list
|
||||
|
||||
---
|
||||
|
||||
Community of Practice (CoP) ist eine Möglichkeit für Wissenstransfer und Erfahrungsaustausch für alle in unserem ART. Es soll uns ermöglichen Praktikern, Wissen und Fähigkeiten in dem Train auszutauschen, um bestehendes Wissen zu verteilen oder gemeinsam neues Wissen aufzubauen.Â
|
||||
Themen für CoP sind jeweils bis zum Freitag davor - bis 12 Uhr - einzutragen, ansonsten wird der Termin abgesagt.Â
|
||||
|
||||
|
||||
|
||||
|
||||
| | # | Datum | Wer | Timebox | Thema | Teilnehmer | Besprechungsnotizen
|
||||
| |
|
||||
| 16.12.2024 |
|
||||
|
|
||||
|
|
||||
 |
|
||||
|
|
||||
|
||||
| |
|
||||
| 18.11.2024 |
|
||||
|
|
||||
|
|
||||
 |
|
||||
|
|
||||
|
||||
| |
|
||||
| 04.11.2024 |
|
||||
|
|
||||
|
|
||||
 |
|
||||
|
|
||||
|
||||
| |
|
||||
| 21.10.2024 |
|
||||
|
|
||||
|
|
||||
 |
|
||||
|
|
||||
|
||||
| |
|
||||
| 07.10.2024 |
|
||||
|
|
||||
|
|
||||
 |
|
||||
|
|
||||
|
||||
| |
|
||||
| 23.09.2024 |
|
||||
|
|
||||
|
|
||||
 |
|
||||
|
|
||||
|
||||
| |
|
||||
| 26.08.2024 |
|
||||
|
|
||||
|
|
||||
Entfällt, wg. keine Themen |
|
||||
|
|
||||
|
||||
| |
|
||||
| 12.08.2024 |
|
||||
|
|
||||
|
|
||||
Entfällt wg. keine Themen |
|
||||
|
|
||||
|
||||
| |
|
||||
| 29.07.2024 |
|
||||
|
|
||||
|
|
||||
 |
|
||||
|
|
||||
|
||||
| |
|
||||
| 15.07.2024 |
|
||||
|
|
||||
|
|
||||
 |
|
||||
|
|
||||
|
||||
| |
|
||||
| 01.07.2024 |
|
||||
|
|
||||
|
|
||||
 |
|
||||
|
|
||||
|
||||
| |
|
||||
| 10.06.2024 | Entfällt wegen I& A |
|
||||
|
|
||||
 |
|
||||
|
|
||||
|
||||
| |
|
||||
| 27.05.2024 |
|
||||
|
|
||||
|
|
||||
 |
|
||||
|
|
||||
|
||||
| |
|
||||
| 13.05.2024 |
|
||||
|
|
||||
|
|
||||
 |
|
||||
|
|
||||
|
||||
| |
|
||||
| 29.04.2024 |
|
||||
|
|
||||
|
|
||||
 |
|
||||
|
|
||||
|
||||
| |
|
||||
| 15.04.2024 | Team Zero | 30 Min |
|
||||
Wir möchten mit euch über Grafana-Boards, Metriken und Alerts sprechen. Idee ist, dass wir uns in dieser COP gegenseitig unsere Dashboards vorstellen und offen diskutieren was wir für sinnvoll / überflüssig / hilfreich erachten.  |
|
||||
|
|
||||
Grafana-Boards von Team Zero und APN und CIB und wurden vorgestellt. Themen waren:
|
||||
-
|
||||
- Realisierung der AbfragenÂ
|
||||
- Erfahrungen mit Performanceproblemen
|
||||
- Loki (label spielen eine groÃe Rolle) vs. Prometheus -
|
||||
Vor- und Nachteile
|
||||
Kostenstelle ist auch eine Frage dabei, die dann bei CNP/AWS anfallen
|
||||
IO und Netzwerktraffik kosten zusätzlich Geld
|
||||
- Spike für fachliche Inszidens mit Countmetrik und Alerts
|
||||
- Thema ist noch nicht abgeschlossen und es gibt Ideen/Vorschläge zu guter Handhabung
|
||||
Für Fragen und weiteres Interesse gern Fragen direkt an die jeweiligen Teams.
|
||||
| |
|
||||
| 02.04.2024 | Ab jetzt wieder alle 2 Wochen CoP |
|
||||
|
|
||||
|
||||
|
|
||||
|
|
||||
|
||||
| | 27 | 18.03.2024 | Entfällt wegen I& A |
|
||||
|
|
||||
 |
|
||||
|
|
||||
|
||||
| | 26 | 19.02.2024 |
|
||||
|
|
||||
|
|
||||
 |
|
||||
|
|
||||
|
||||
| | 25 | 22.01.2024 |
|
||||
|
|
||||
|
|
||||
 |
|
||||
|
|
||||
|
||||
| | 24 | 20.11.2023 | Diego Da-Costa-Souza / Jan Lubenow | 30 Min |
|
||||
Parallelisierung von Cucumber-Basierten Tests am Beispiel der Systemtests des Bestellsystems.
|
||||
- Was haben wir umgebaut?
|
||||
- Welche Herausforderungen gab es?
|
||||
- Wie gehen wir mit Tests um, die nicht parallel laufen dürfen? |
|
||||
|
|
||||
|
||||
| | 23 | 23.10.2023 | Team Zero | 30 Min | Wir möchten mit euch über Code-Reviews sprechen/ mit euch diskutieren. Habt ihr in eurem Team eine definierte Vorgehensweise wie ausführlich ein Code-Review gemacht wird / ggf. eine Checkliste? |
|
||||
|
|
||||
|
||||
| | 22 | 07.08.2023 | Marcel Hufgard / Alexander Petioky | 45 Min | Camunda Cockpit für Nichtentwickler |
|
||||
|
|
||||
|
||||
| | 21 | 26.06.2023 | Team Zero | 1 Stunde |
|
||||
- Wer ergänzt der Entwicklerhanduch Wiki mit Antworten von CoP?
|
||||
Secrets:
|
||||
- Wie sind die Secrets strukturiert ?
|
||||
- Secrets unter Pipeship Verzeichnis. Nur für AT oder andere Stellen auch ?
|
||||
- Welche Schritte sind nötig Secrets für eine Anwendung zu definieren, der nur während der Pipeline lauft und nicht in ein eigene Container? (z.B. Lup)
|
||||
Git + Pipeship:
|
||||
- Umbenennung eine Applikation, was ist der beste/einfachste Weg?
|
||||
Extra wegen Postman Umstellung:
|
||||
- Wie ist der Stand mit Postman Ersatz, welche scheint der gewinner zu sein? (Insomnia oder andere)
|
||||
DevOps Allgemein:
|
||||
- Gibt es ein Wiki/FAQ für in CNP oft passierende Fehlern und zu ihre Behandlung? Wenn ja, wo ? (z.B. Ingress Nummer Limit überschritten, DB Ãbergelaufen) |
|
||||
|
|
||||
|
||||
| | 20 | 29.05.2023 | Team Zero | 30 Min | Fragen zum Thema DevOps |
|
||||
|
|
||||
|
||||
| | 19 | 15.05.2023 | Kai Barkschat, Frank Thiele | 1 Stunde | Gegenseitige Vorstellung von APN und BS Piplines |
|
||||
|
|
||||
|
||||
| | 18 | 03.04.2023 | Team Zero | 30-60 Minuten | Brainstorming zur Pipline Problematik. |
|
||||
 | Fragen bzw. Themen für FAQ:
|
||||
|
||||
- Ist es möglich die Pipeline Ausführung abzubrechen?
|
||||
- Mit welchen Parameter kann die Pipeline gesteuert werden
|
||||
- Ressourcen überprüfen & ggf. skalieren
|
||||
â das I.NVI IT Lifecycle Management Toold1143f0d-33c0-3f1c-b44b-7720150f306eO2CSYS-628
|
||||
| | 17 | 06.02.2023 | Team Zero | 15-30 Minuten | Brainstorming Tracing: Wie wollen wir sinnvoll filtern? |
|
||||
| Wir brauchen fürs Tracing a) ein sinnvolles Filtern (=Tail Sampling) als Defult zum Deployen und b) ein Verfahren und das Know How, wie man bei Bedarf das Tracing umkonfiguriert.
|
||||
| | 16 | 23.01.2023 | Alle | 15-30 Minuten | Infosammlung PAN Client | Alle |
|
||||
|
||||
| | 15 | 09.01.2023 |
|
||||
| ca. 5 Minuten | Vorteile der erweiterten Version (Developer Edition) von SonarQube |  |
|
||||
|
||||
| | 14 | 09.01.2023 |
|
||||
| ca. 30 Minuten | Nutzung von Camunda Cockpit für Prozesse von Steuerung-Vertrieb |
|
||||
 |
|
||||
|
||||
| | 13 | 21.11. und 5.12.2022 | System Team | -- | Diese Termine möchten wir für den Wissenstransfer-Workshop übernehmen (den müssen wir wegen Konflikten jeweils auf Montag verschieben). |
|
||||
 |
|
||||
|
||||
| | 12 | 7.11.2022 | System Team | 30-60min |
|
||||
Themenvorschlag, bei Interesse:
|
||||
Tracing mit OpenTelemetry Agent
|
||||
Vorstellen des Setups und der verfügbaren Java-Code-Annotations. (Doku im Entwicklungshandbuch ist noch in Arbeit.) |  |
|
||||
|
||||
| | 11 | 29.08.2022 | Team Zero |
|
||||
| Fragen zum Talo(spring) für Logging
|
||||
Gibt es einen Erweiterungspunkt in Talo-Java/Talo-Spring, was zum Ersetzen von geheimen Daten mit Sternen und zur Verkürzung von langen Strings genutzt werden kann ?Â
|
||||
Wie kann das mit Talo/log4j2 am einfachsten umgesetzt werden? |
|
||||
|
|
||||
|
||||
| | 10. | 01.08.2022 | Team Zero / Bestellsystem Teams | ca. 30 Min. | Springboot-Webflux-WebClient Erfahrungen mit OpenAPI und Springboot-Client |
|
||||
- Â (Zero)
|
||||
- Nach Interesse |
|
||||
|
||||
| | 9. | 11.07.2022 | Bestellsystem-Teams |
|
||||
|
|
||||
Git-Workflows
|
||||
(Fortsetzung) | Erstes Ausprobieren mit Erfahrungsberichten? |
|
||||
|
||||
textwenig strukturierte Notizentrue im Zweifelsfall wird eine Pipeline brechen (entweder letzter MR-Build oder erster master-Build)
|
||||
|
||||
## Schwierigkeit: Updates von zwei Services
|
||||
|
||||
Funktioniert im Realbetrieb nie wirklich gleichzeitig, Kompatibilität zwischen zwei Versionen ist immer mehr oder weniger notwendig.
|
||||
|
||||
### Komponenten-Integrations-Test
|
||||
|
||||
z.Bsp. ifp-mock-Version in SV .gitlab-ci.yml => kein groÃes Problem
|
||||
|
||||
### Unit-Tests
|
||||
|
||||
keine Nachbarsysteme beteiligt,
|
||||
aber mehr Pflege-Aufwand bei häufigeren Merges
|
||||
|
||||
## System-Tests
|
||||
|
||||
neue Features erfordern oft neue Branches im System-Test
|
||||
normalerweise einfach, schwierig zum Sprint-Ende wenn viele Branches gemergt werden
|
||||
|
||||
es würde helfen in den System-Test-Reports mehr Metadaten, vor allem Service-Versionsnummern, zu haben.
|
||||
|
||||
allgemein: System-Tests sind instabil und "blinken"
|
||||
Problem: viele Zeit-basierte Tests, mit schwankender Performance beim Nachrichten-Durchlauf (portal - SV - IFP und zurück) => unterschiedliche Test-Ergebnisse
|
||||
ohne IFP-Mock-Wartezeit geht es bisher auch nicht (SV ist nicht so schnell)
|
||||
|
||||
### System-Tests mit development-Branch
|
||||
|
||||
Der development-Branch in qa/system-test wird benutzt, sollte nicht gelöscht werden
|
||||
|
||||
# automatisiertes Update nach EVU-Test
|
||||
|
||||
Reihenfolge der Stages?
|
||||
=> IEU -> SIT -> EVU
|
||||
|
||||
Test-Zuverlässigkeit ist wichtig, je besser System-Test und System-Integration-Test desto sicherer ist das EVU-Test-Deployment
|
||||
|
||||
Offene Frage: wieviel Release-Management oder -Freigaben brauchen wir? Besonders in Richtung Kunden-Kommunikation (Sven-Ole).
|
||||
]]>
|
||||
|
||||
|
||||
| | 8. | 27.06.2022 | System Team | 1 |
|
||||
Git-Workflows
|
||||
Bei einem Git-Workflow geht es darum, wann man einen Branch anlegt, welchen existierenden Branch man als Grundlage nimmt und in welcher Reihenfolge und wann man Branches wieder integriert.
|
||||
Wir stellen vor, welches Workflow in Git aktuell und künftig Vorgehen im Bestellsystem eingesetzt wird. |
|
||||
|
||||
|
||||
|
||||
|
|
||||
Grundlage war das Bestellsystem-Konzept Git Workflow
|
||||
|
||||
textwenig strukturierte Notizentrue System Test
|
||||
|
||||
während der Entwicklung oft ein Diff zwischen Anwendungs-Code und System-Test-Code
|
||||
]]>
|
||||
|
||||
|
||||
| | 7. |
|
||||
20.6.2022 | Team APN |
|
||||
|
|
||||
Umgang mit Software-Lizenzmanagement. Whitesource wertet das ja aus. Mich würde interessieren, wie die anderen Teams damit umgehen und ob es bereits Automatismen gibt (Die wir vielleicht übernehmen können). So eine Art Auto-Action, Pattern -basiert
|
||||
-
|
||||
Haben wir einen Lizenzexperten (Jurist?) als Ansprechpartner?
|
||||
-
|
||||
duale Lizenz -Kombinationen für Open Source,
|
||||
-
|
||||
organisatorische Vorgaben/Policies bzgl. Lizenzen
|
||||
-
|
||||
Erkennung von DBISL
|
||||
-
|
||||
In-House Lizenzen verwalten (aktuell bei uns: nur als OrgAdmin über tomag-Team -> sehr aufwendig, nicht praktikabel) |
|
||||
|
||||
|
|
||||
Haben wir einen Lizenzexperten (Jurist?) als Ansprechpartner?
|
||||
->Â https://evi.intranet.deutschebahn.com/evi31/simpleSearchAction.do?filter=Cornelius%20Schumacher
|
||||
Cornelius Schumacher
|
||||
Open Source Steward der DB Systel GmbH
|
||||
Teams Kanal für Lizenz â Fragen
|
||||
organisatorische Vorgaben/Policies bzgl. Lizenzen
|
||||
-> Open-Source-Lizenzkompass
|
||||
https://git.tech.rz.db.de/foss/lizenzkompass/-/blob/master/index.adoc
|
||||
https://git.tech.rz.db.de/foss/lizenzkompass/-/blob/master/lizenzen/liste.adoc
|
||||
-> jedes Team kann selbst entscheiden, ob und wie in WhiteSource Policies verwendet werden
|
||||
mit Policies kann geregelt werden, dass bei bestimmten Lizenzen Alerts entstehen
|
||||
Erkennung von DBISL
|
||||
-> aus Sicht von WhiteSource gibt es keine DBISL, entsprechende Libraries können als In-House markiert werden
|
||||
In-House Lizenzen verwalten (aktuell bei uns: nur als OrgAdmin über tomag-Team -> sehr aufwendig, nicht praktikabel)
|
||||
-> alle als In-House markierte Libraries entfallen aus der Lizenz-Betrachtung, die Zuordnung muss über tomag-Team laufen, kann leider nicht delegiert werden, man kann ganz gut mit Pattern arbeiten, um Muster zu erkennen
|
||||
Mögliche Lösungsvorschläge für die Verwaltung von Lizenzen:
|
||||
- Klären üb es möglich wäre den Feature Flag zu aktivieren und die Lizenz - Verwaltung über Produkt Admins zu organisieren.
|
||||
- Klären, ob es möglich wäre, Anforderungen der Bahn beim Hersteller zu versenken.
|
||||
| | 6 | 30.05.2022 | Team Zero |
|
||||
|
|
||||
Kundendaten-Adapter
|
||||
Der Kundendaten-Adapter ist bereits durch viele Hände gegangen und nun beim Team Zero gelandet. Wir möchten gerne von denjenigen, die ihn bisher konzipiert und entwickelt haben, mehr KnowHow bekommen.
|
||||
Wozu ist er gut und was tut er eigentlich ?
|
||||
Gibt es besondere Fallstricke (Api oder ähnliches)?
|
||||
Wie ist das Datenvolumen? Gibt es Anforderungen bzgl. Last- und Performance? |
|
||||
|
|
||||
|
||||
| | 5. |
|
||||
16.05.2022
|
||||
23.05.2022 |
|
||||
| 1 |
|
||||
DevOps
|
||||
Was sind unsere Ziele bezüglich DevOps?Â
|
||||
Wie stellen wir DevOps bei uns vor? | Vertreter aus allen Teams |
|
||||
|
||||
| | 4. | 02.05.2022 |
|
||||
| 1 |
|
||||
DevOpsÂ
|
||||
Was sind unsere Ziele bezüglich DevOps?
|
||||
Wie stellen wir DevOps bei uns vor? | Vertreter aus allen Teams |
|
||||
|
||||
| | 3. | 11.04.2022 | Team Zero | 1 |
|
||||
Camunda:
|
||||
Einführung in die umgesetzten Prozesse
|
||||
Erläuterung: Marcel hat uns in der Einführungsveranstaltung die fachlichen Prozesse erläutert. In CoP vom 21.03. Haben uns die CIB-Entwickler an einem Prozess erläutert, wie das technisch realisiert ist und getestet wird. Jetzt wäre es gut, wenn Alexander noch die Lücke schlieÃen würde: Welche fachlichen Prozesse sind wie in Camunda modelliert? |
|
||||
(CIB)
|
||||
|
||||
|
|
||||
|
||||
| |
|
||||
2. | 21.03.2022 | Team Zero | 1 Stunde |
|
||||
Camunda:
|
||||
Welche Prozesse werden abgebildet?
|
||||
Wie ist die Integration in die SV technisch umgesetzt?
|
||||
Wie werden diese Prozesse getestet?
|
||||
Falls vorhanden: Offene Punkte/Erfahrungen/Ausblick |
|
||||
(Zero)
|
||||
(CIB)
|
||||
 (Zero) |
|
||||
|
||||
| |
|
||||
1. | 07.02.2022 | Team APN | 1 Stunde | Integration der CI-Pipeline:
|
||||
|
||||
- Welche Erfahrungen hab Ihr bezüglich der Pipeline gemacht?
|
||||
- Welche Features werden genutzt, welche nicht?
|
||||
- Welche Ergebnisse werden ausgewertet?
|
||||
- aktueller Stand der Integration der Pipeline in den Entwicklungsprozess (je Team)
|
||||
- Ansteuerung/Triggering via git (Vorgehensmodelle)
|
||||
- Ausblick/Zukunftspläne |
|
||||
 (Zero)
|
||||
(Zero)
|
||||
(System)
|
||||
(APN)
|
||||
Â
|
||||
(CIB)
|
||||
(404)
|
||||
(APN)
|
||||
(APN)
|
||||
(APN)
|
||||
 (404)
|
||||
(System)
|
||||
(404) |
|
||||
@@ -0,0 +1,10 @@
|
||||
# pathOS
|
||||
|
||||
> Confluence Page ID: 196749641
|
||||
> Version: 6
|
||||
> Pfad: /pathOS
|
||||
> Labels:
|
||||
|
||||
---
|
||||
|
||||
## InhaltsverzeichnisÂ
|
||||
@@ -0,0 +1,10 @@
|
||||
# QA Themen
|
||||
|
||||
> Confluence Page ID: 206667947
|
||||
> Version: 6
|
||||
> Pfad: /pathOS/Kommunikationskanäle, Termine, Besprechungsnotizen pathOS/Besprechungsnotizen/QA Themen
|
||||
> Labels:
|
||||
|
||||
---
|
||||
|
||||
|
||||
+56
@@ -0,0 +1,56 @@
|
||||
# Systemintegrationstests für BS â IFP-SST
|
||||
|
||||
> Confluence Page ID: 206667964
|
||||
> Version: 11
|
||||
> Pfad: /pathOS/Kommunikationskanäle, Termine, Besprechungsnotizen pathOS/Besprechungsnotizen/QA Themen/Systemintegrationstests für BS â IFP-SST
|
||||
> Labels: meeting-notes
|
||||
|
||||
---
|
||||
|
||||
Teilnehmer: Â
|
||||
|
||||
|
||||
Was soll genau mit SITs getestet werden? das I.NVI IT Lifecycle Management Toold1143f0d-33c0-3f1c-b44b-7720150f306eO2CCIB-1614
|
||||
  Relevante Aktionen zwischen BS und realen externen Partner zu testen. Pro Schnittstelle mind. ein Positiv und ein Negativfall testen.
|
||||
  Die Tests werden möglichst einen kleinen Teil des Ablauf im BS testen. In diesem Fall SV<->IFP
|
||||
|
||||
|
||||
Akzeptanzkriterien von https://nvi.jaas.service.deutschebahn.com/browse/O2CCIB-1614 :
|
||||
- Die Definition /Umfang von SIT ist für die IFP-SSTs geklärt
|
||||
- Die bereits definierten Systemintegrationstestfälle wurden ggf. überarbeitet bzw. Aktualisiert
|
||||
|
||||
|
||||
Die Tests müssen minimal die Kommunikation zwischen SV und IFP testen(Aufgrund Kosten der höheren Teststufen)
|
||||
Stand der Testfälle aus TK: Die vorhandene Regressionstestfälle im Testkonzept sind sehr umfangreich für Systemintegrationstest.
|
||||
|
||||
|
||||
Testfall: Ein konstruierbarer/nicht konstruierbarer Produktionsauftrag/Ãnderungsanmeldung(in TDM Format) wird von Steuerungsvertrieb an IFP geschickt.
|
||||
Beispiel für den Negativfall: Pflichtangaben fehlen. AnschlieÃend wird die Anfrage abgelehnt. Vorerst kein negativer Testfall.
|
||||
|
||||
|
||||
Anforderungen an Testfall:
|
||||
- Der erste Testfall soll SQS testen und der zweite Testfall S3
|
||||
- Die Nachrichten von SV(mit Trassenanmeldung API)Â an IFP schicken
|
||||
|
||||
|
||||
Bzgl. beteiligten Prozesse:
|
||||
Ãberlegung: Die BEP und AC für SIT werden wir nicht aufnehmen( Das kann gemockt werden)
|
||||
Idee: Sub-Prozesse direkt im Test starten und dadurch die Nachricht an IFP über Camunda API versenden.
|
||||
Ziel: Wir testen mit echtem Schnittstellen-Code auf SIT Umgebung. Ohne Code Ãnderung den Test durchführen. Z.B Prozess kopieren und den BEP-Aufruf weglassen.
|
||||
Die Datenbank auf SIT wird nicht migriert.
|
||||
|
||||
|
||||
Damit keine manuelle Aktion benötigt wird:Â
|
||||
- IFP erstellt statisch Angebote und SV Schickt Annahme für die von uns bekannten Aufträge
|
||||
- Wir schicken eine Trassenanmeldung, die nicht konstruierbar ist.
|
||||
|
||||
|
||||
Zusätzliche HealthChecks (Springboot, Kub Healthchecks)-> Ãberprüfen, ob die Nachricht verschickt und Response zurück kommt.
|
||||
Queue stellt sicher, dass die Nachrichten nicht verloren gehen. Daher verzichten wir von dieser doppelter Ãberprüfung.
|
||||
Bessere Alternative: Queuegrosse überprüfen (Gelegenheitsverkehr) -> vorerst nicht geplant
|
||||
Generieren von pathID für periodische Tests Durchführung (mit IFP abstimmen z.B für die Erstanmeldungen -> An Christian Meins )
|
||||
|
||||
|
||||
TODOs:
|
||||
- Der Testfall ist mit IFP zu klären(Jahan hält Absprache mit , um den Testfall mit IFP abzusimmen)Â
|
||||
- Alexander kümmert sich um die Prozesse für den Testfall
|
||||
@@ -0,0 +1,10 @@
|
||||
# Sonstige Termine
|
||||
|
||||
> Confluence Page ID: 208930190
|
||||
> Version: 1
|
||||
> Pfad: /pathOS/Kommunikationskanäle, Termine, Besprechungsnotizen pathOS/Besprechungsnotizen/Sonstige Termine
|
||||
> Labels:
|
||||
|
||||
---
|
||||
|
||||
Dies ist ein Sammler für Termine, die nicht Teil einer Serie sind.
|
||||
+76
@@ -0,0 +1,76 @@
|
||||
# 2023-04-03 Besprechungsnotizen Changelogs & Releaseprozess
|
||||
|
||||
> Confluence Page ID: 249539297
|
||||
> Version: 7
|
||||
> Pfad: /pathOS/Kommunikationskanäle, Termine, Besprechungsnotizen pathOS/Besprechungsnotizen/Sonstige Termine/2023-04-03 Besprechungsnotizen Changelogs & Releaseprozess
|
||||
> Labels:
|
||||
|
||||
---
|
||||
|
||||
## Datum
|
||||
|
||||
|
||||
## Teilnehmer
|
||||
|
||||
- Annette Halbhuber
|
||||
- Bernd Klebl
|
||||
- Bing Shi
|
||||
- Christian Meins
|
||||
- Christian Seltsam
|
||||
- Daniel Brügmann
|
||||
- Diego Da-Costa-Souza
|
||||
- Dong-Won Han
|
||||
- Emmanuel Kontcheu-Tagne
|
||||
- Nicole Bechtold
|
||||
- Thorsten Volland
|
||||
## Diskussionspunkte
|
||||
|
||||
## Koordiniertes Release auf Kundentestumgebung
|
||||
|
||||
- nach Sprintende ausführliche Tests auf SIT
|
||||
- Deployment im Anschluss zusammen und koordiniert mit IFP und neXt auf die E2E-Kundentestumgebung
|
||||
- Teams-Kanal zur Koordination (Kundentestumgebung)
|
||||
- Dokumentation der Releaseinhalte in Confluence
|
||||
- Konsequenzen:
|
||||
- SIT-Umgebung steht nicht durchgängig für Deployments zur Verfügung (Freeze zwischen Sprintende und Deployment auf E2E-Kundentestumgebung)
|
||||
- Unterbrechung in der aktuellen Pipeline: SIT ist die Vorstufe zur EVU-Test
|
||||
- Unterbrechung des Flows â kürzerer Zeitraum zwischen Sprintende + Deployment
|
||||
- Starke Abhängigkeit zu IFP/neXt â Deployment unabhängig von IFP/neXt, aber vorab auf SIT getestet
|
||||
- Schnittstellenänderungen konsequenter betrachten
|
||||
- MaÃnahmen:
|
||||
- Vorgehen zwischen Iteration 2 und 3 (PI 28) einmal verproben
|
||||
- Erstellung Releasedokumentation (nach Template )Â
|
||||
- SIT ab Mittwoch EOB unverändert
|
||||
- Wenn Tests grün, dann Deployment Donnerstagnachmittag auf E2E-Kundentestumgebung
|
||||
- Erkenntnisse aus dem Vorgehen analysieren
|
||||
- Offene Fragen:
|
||||
- Zuständigkeit übergreifende Tests
|
||||
- Wer macht das eigentliche Deployment auf Zielumgebung?
|
||||
- Befüllung Releasedokumentation-Template für Bestellsystem?
|
||||
## Diskussionspunkte für Folgetermine
|
||||
|
||||
## Wie ist der Release Scope des Bestellsystems (Gesamtsystem vs. Einzelanwendungen)?
|
||||
|
||||
- Feature-Releases/Reguläre Releases
|
||||
- Hotfix-Releases
|
||||
- Versionierung
|
||||
## Wie ist der Release-Zyklus? Wann findet ein Release statt?
|
||||
|
||||
|
||||
|
||||
## Welche Release-Dokumentation wird benötigt?
|
||||
|
||||
- Scope des jeweiligen Releases (Versionen der Anwendungen)
|
||||
- Changelog/Release-Notes
|
||||
- Deployment-Infos (Reihenfolge aufgrund von Abhängigkeiten, zusätzliche Deployment-Tasks)
|
||||
- Releasefreigabe (ggf. Anforderung von Betriebsteam)
|
||||
|
||||
|
||||
## Werden Checklisten zur Release-Vorbereitung eingesetzt?
|
||||
|
||||
- siehe z.B. bei APN:
|
||||
## Technische Fragen
|
||||
|
||||
- Scope von Changelogs (falls nicht oben geklärt)
|
||||
- Arbeiten mit Release Candidates/Feature-Branch?
|
||||
- Feature-Toggles?
|
||||
+35
@@ -0,0 +1,35 @@
|
||||
# 2023-04-12 Releaseprozess für Kundentestumgebung
|
||||
|
||||
> Confluence Page ID: 253591653
|
||||
> Version: 2
|
||||
> Pfad: /pathOS/Kommunikationskanäle, Termine, Besprechungsnotizen pathOS/Besprechungsnotizen/Sonstige Termine/2023-04-12 Releaseprozess für Kundentestumgebung
|
||||
> Labels:
|
||||
|
||||
---
|
||||
|
||||
## Datum
|
||||
|
||||
|
||||
## Teilnehmer
|
||||
|
||||
## Diskussionspunkte
|
||||
|
||||
- Releasedokumentation:
|
||||
-
|
||||
neues Feld "Lösungsansatz" in Jira-Tickets für erläuternde Texte zu den einzelnen Tickets
|
||||
- Vorschlag für erstes Deployment zur Vereinfachung: eine Release-Version für alle Anwendungen, später eine Version pro Anwendung
|
||||
- Release Anwendung/Microservice vs. Bestellsystem-Release
|
||||
- Release Anwendung/Microservice bei Fertigstellung der benötigten Features und Bugfixes inkl. anschlieÃender QA
|
||||
- Release Bestellsystem: aus der Sicht des Nutzers/EVU (Release = Bereitstellung/Deployment)
|
||||
- Vorschlag zum vorübergehenden Vorgehen bei Release:
|
||||
- Alle Apps mergen ihre Features wie bisher in den Master-Branch
|
||||
- Ist der Master-Branch Feature-Complete für ein Release,
|
||||
- wird in Git ein Release-Tag angelegt
|
||||
- wird sichergestellt, dass SIT erfolgreich durchgeführt wurde
|
||||
- sit_update/sit_trigger werden am Mittwoch vor einem BS-Release nicht automatisch ausgeführt
|
||||
- bei Nachlieferung für Release müssen die Jobs manuell gestartet werden
|
||||
- ggf. scheduled Trigger für Donnerstagmorgen?
|
||||
- Ist die Staging-Pipeline im passenden Status (post SIT) für das Release, wird die Pipeline-Instanz in der Release-Dokumentation verlinkt
|
||||
- vorhandener Eintrag in Release-Dokumentation wird überschrieben
|
||||
- letzte eingetragene Pipeline enthält alle für das Release relevanten App-Versionen â Deployments nach EVU-E2E und EVU-Test werden auf dieser Pipeline-Instanz ausgelöst
|
||||
- Neue Umgebung für E2E-Tests (ohne EVU-Zugriff) für die Releasevorbereitung ist in Planung
|
||||
+61
@@ -0,0 +1,61 @@
|
||||
# Einführung von Xray im Testworkflow von ART O2C
|
||||
|
||||
> Confluence Page ID: 259257571
|
||||
> Version: 25
|
||||
> Pfad: /pathOS/Kommunikationskanäle, Termine, Besprechungsnotizen pathOS/Besprechungsnotizen/QA Themen/Einführung von Xray im Testworkflow von ART O2C
|
||||
> Labels:
|
||||
|
||||
---
|
||||
|
||||
Diese Seite wurde erstellt, um die Koordination der Xray-Einrichtung im neuen Bestellsystem nachvollziehbar zu machen.
|
||||
Bitte um Updaten dieser Seite beim Fortschritt/Ãnderungen. Â
|
||||
|
||||
|
||||
- PI 27 - S4 - O2CCIBÂ truedas I.NVI IT Lifecycle Management Toold1143f0d-33c0-3f1c-b44b-7720150f306eO2CCIB-2693
|
||||
- PI 27 - S4 - O2CZEROÂ das I.NVI IT Lifecycle Management Toold1143f0d-33c0-3f1c-b44b-7720150f306eO2CZERO-1588
|
||||
- PI 28 - S4 - O2CZERO das I.NVI IT Lifecycle Management Toold1143f0d-33c0-3f1c-b44b-7720150f306eO2CZERO-1785
|
||||
- PI 27 - S6 - O2C404Â das I.NVI IT Lifecycle Management Toold1143f0d-33c0-3f1c-b44b-7720150f306eO2C404-1911
|
||||
- PI 27 - S6 - O2CCIBÂ das I.NVI IT Lifecycle Management Toold1143f0d-33c0-3f1c-b44b-7720150f306eO2CCIB-2876: Einleitun zu Xray:Â
|
||||
- PI 28 - S1 - O2CCIBÂ das I.NVI IT Lifecycle Management Toold1143f0d-33c0-3f1c-b44b-7720150f306eO2CCIB-2942:
|
||||
|
||||
|
||||
- Einrichten einer Jira-Testumgebung für alle Tester auf https://nvi-tst.jaas.service.deutschebahn.com/secure/Dashboard.jspa:
|
||||
|
||||
12
|
||||
complete
|
||||
Ticket zur Support-Anfrage an Jira-Team: https://arija.jaas.service.deutschebahn.com/servicedesk/customer/portal/9/SATS-563
|
||||
|
||||
|
||||
|
||||
|
||||
|
||||
|
||||
Info: Laut Bing macht Team Zero die ersten Vorbereitungen für die GitLab Integration mit Xray. Die Tester sollen die Basis nutzen, um die
|
||||
Integration weiter zu erweitern.
|
||||
Tickets von System-Team für die Vorbereitung der GitLab Pipelines zweck Exportieren der Testergebnisse nach Jira in einem Testplan
|
||||
- PI 28 - S2 - O2CSYS das I.NVI IT Lifecycle Management Toold1143f0d-33c0-3f1c-b44b-7720150f306eO2CSYS-663
|
||||
- PI 28 - S5 - O2CSYSÂ das I.NVI IT Lifecycle Management Toold1143f0d-33c0-3f1c-b44b-7720150f306eO2CSYS-672
|
||||
|
||||
|
||||
|
||||
|
||||
Offene TODOs:
|
||||
|
||||
3
|
||||
complete
|
||||
Stauts der Einrichtung von Xray auf Jira-Testumgebung folgen (am 4.5.2023 wurde Xray auf Testumgebung in den Projekten O2C ART und O2C System freigeschaltet)
|
||||
|
||||
|
||||
4
|
||||
incomplete
|
||||
Wunsch von Bing: Die Anforderungen in der Story das I.NVI IT Lifecycle Management Toold1143f0d-33c0-3f1c-b44b-7720150f306eO2CSYS-672 erweitern und konkretisieren und mit Jira-Board Zuständige ( Nicki, Ellena) Absprache halten, da der Import der Testergebnisse Einfluss auf Jira-Oberfläche haben wird (evtl. neue Test-Vorgänge werden automatisch erzeugt. Dies muss überprüft werden)
|
||||
|
||||
|
||||
7
|
||||
incomplete
|
||||
Nach der Einrichtung von Xray auf Testumgebung die API ausprobieren und schauen, ob Importieren der Testergebnisse ohne Erstellung neuer Test-Vorgänge in Jira möglich ist?
|
||||
|
||||
|
||||
10
|
||||
incomplete
|
||||
Xray Integration mit neuen Anforderungen für nächste PI vorbereiten. Laut Nicki hat System-Team aktuell wenig Kapazität für die Unterstüzung.
|
||||
+11
@@ -0,0 +1,11 @@
|
||||
# Kommunikationskanäle, Termine, Besprechungsnotizen pathOS
|
||||
|
||||
> Confluence Page ID: 267687097
|
||||
> Version: 8
|
||||
> Pfad: /pathOS/Kommunikationskanäle, Termine, Besprechungsnotizen pathOS
|
||||
> Labels:
|
||||
|
||||
---
|
||||
|
||||
Dieser Abschnitt bietet eine Zusammenfassung aller regelmäÃig stattfindenden Termine im ART pathOS â auf Team-, teamübergreifender und ART-Ebene â sowie eine Ãbersicht der etablierten Kommunikationskanäle in pathOS.
|
||||
Weiterhin werden hier die Besprechungsnotizen zentraler, übergreifender Termine wie der Architekturrunde, der CI/CD-Runde und der DevOps-Runde dokumentiert. Notizen zu weiteren Terminen werden zentral im OneNote abgelegt.
|
||||
+13
@@ -0,0 +1,13 @@
|
||||
# Architektur Bestellsystem
|
||||
|
||||
> Confluence Page ID: 267687106
|
||||
> Version: 13
|
||||
> Pfad: /pathOS/Architektur Bestellsystem
|
||||
> Labels:
|
||||
|
||||
---
|
||||
|
||||
Architektur-Dokumentation
|
||||
pathOS pflegt und aktualisiert seine Architekturbeschreibung im Runbook. Sie ist über den Link für jeden einsehbar.Â
|
||||
  Architektur-Runde
|
||||
Im zweiwöchentlichen Rhythmus findet die Architektur-Runde von pathOS mit Teilnehmern aus jedem Team statt. Die Protokollierung findet sich hier. Auch im Confluence dokumentiert werden alle betriebliche Themen, die die Architektur betreffen. Diese können unter der Kategorie Betrieb eingesehen werden. Â
|
||||
@@ -0,0 +1,10 @@
|
||||
# Roadmap Bestellsystem
|
||||
|
||||
> Confluence Page ID: 267687109
|
||||
> Version: 1
|
||||
> Pfad: /pathOS/Roadmap Bestellsystem
|
||||
> Labels:
|
||||
|
||||
---
|
||||
|
||||
Yellowi.A.
|
||||
+10
@@ -0,0 +1,10 @@
|
||||
# Start / Vorstudie Bestellsystem
|
||||
|
||||
> Confluence Page ID: 267687115
|
||||
> Version: 2
|
||||
> Pfad: /pathOS/Start / Vorstudie Bestellsystem
|
||||
> Labels:
|
||||
|
||||
---
|
||||
|
||||
|
||||
+426
@@ -0,0 +1,426 @@
|
||||
# 4.4.5 Anbindung an Verwaltungsunterstützende Services (KDV & eBRS)
|
||||
|
||||
> Confluence Page ID: 27525683
|
||||
> Version: 135
|
||||
> Pfad: /pathOS/Start / Vorstudie Bestellsystem/00_Vorstudie Bestellsystem/4 Anforderungen an das neue Bestellsystem der DB Netz/4.4 Soll-Schnittstellen Bestellsystem (Consumer oder Provider)/4.4.5 Anbindung an Verwaltungsunterstützende Services (KDV & eBRS)
|
||||
> Labels:
|
||||
|
||||
---
|
||||
|
||||
## Einleitung
|
||||
|
||||
DB Netz interne Mitarbeiter (DB Netz Vertriebsmitarbeiter, Kundenbetreuer, fachliche sowie technische Betriebsführung) sowie DB Netz externe Benutzer (Mitarbeiter der EVUs) sind die zwei unterschiedlichen Benutzergruppen, die sich im Bestellportal anmelden. Für die externen Benutzer wird die Funktionalität zur Authentifizierung und Autorisierung über das vorhandene Verfahren eBRS genutzt, interne Nutzer sollen sich dagegen mit ihrem BKU-Account am System anmelden können. Der Service Kundendatenverwaltung (KDV) liefert die Kundenstammdaten zu einer gegebenen Kundennummer.
|
||||
Im CRM System gibt es neben der KaufmännischenSperre auch ein Stop-Kennzeichen für den Kunden. Wenn dieses gesetzt ist, wird dieser Kunde nicht über den Service KDV übertragen, d.h. er kann sich dann auch nicht am Bestellsystem anmelden.Â
|
||||
Hinweis: alle DB-internen EVUs (z.B. DB Cargo - EVU Sachbearbeiter) gelten als externe Benutzer.
|
||||
Hinweis: Es wird keine Stellvertreter-Regelung wie in TPN unterstützt, d.h. dass es keine exklusiven Vorgänge gibt, für die man andere Benutzer (Stellvertreter) berechtigen muss. Stattdessen sollen Nutzer bei Bedarf die für sie irrelevanten Vorgänge ausblenden können.
|
||||
## Registrierung und Verwaltung der Bestellportal-Benutzer
|
||||
|
||||
Alle externen Benutzer (DB Netz extern) müssen sich im Vorfeld für die Nutzung des Bestellportals registrieren. Dies geschieht über eine entsprechende Funktionalität im Kundenportal der DB Netz (ehemals myNet), das eine entsprechende Anbindung an eBRS besitzt. Ãber das Kundenportal können alle Nutzer kundenseitig durch Selbstadministration verwaltet werden. Die Verwaltung der Benutzer erfolgt durch EVU-PowerUser.
|
||||
Die initiale Pflege der PowerUser pro Kunde, die dann selbst die Verwaltung und Berechtigungszuordnung der weiteren Nutzer dieses Kunden übernehmen, ist nicht Teil des Projekts und ist durch I.NMK sicherzustellen.
|
||||
|
||||
Für die Administration der DB Netz internen BKU-Benutzer zur Zugriffsberechtigung auf das Bestellportal ist das konzerninterne Benutzermanagementsystem iMan zu verwenden.
|
||||
## Authentifizierung
|
||||
|
||||
Damit nur zugangsberechtigte Benutzer das Bestellportal verwenden können, erfolgt die Authentifizierung (Prüfung von Benutzername und Passwort) für beide Benutzergruppen (DB Netz intern und extern) über eine Login-Seite des Bestellportals. Das Bestellportal prüft die Authentifizierung im Hintergrund mithilfe von LDAP im entsprechenden Active Directory. Für DB Netz interne Benutzer wird das BKU-Active Directory abgefragt, für DB Netz externe User wird das konzernweite DS-Active Directory abgefragt. (Active Directory Domain Services AD DS). Wegen der Trust-Beziehung von DS-AD zu BKU-AD, kann die Anmeldung auch in einem Aufruf erfolgen.
|
||||
Die Anmelde-Maske wird im Bestellportal umgesetzt. Die Anmeldung am Bestellportal muss im Rahmen einer 2 Faktor-Authentifizierung möglich sein. Diese Funktionalität muss im Rahmen des Bestellportals umgesetzt werden, da eBRS dies aktuell nicht unterstützt.
|
||||
## Autorisierung
|
||||
|
||||
Die zugeordneten generischen Rollen eines Benutzers (z.B. DB Netz Vertriebsmitarbeiter oder EVU-Trassenbesteller) werden durch einen LDAP-Zugriff auf das jeweils entsprechende Active Directory abgefragt. Für DB Netz interne BKU-User erfolgt die Abfrage gegen das BKU-Active Directory, wohin gegen für DB Netz externe Benutzer die Abfrage gegen das DS-Active Directory erfolgt.
|
||||
Für DB Netz externe Benutzer kommt nach Ermittlung der generischen Rolle zusätzlich die Notwendigkeit hinzu, über den Service BenutzerBerechtigungZuordnung (BBZ) und dessen Operation leseBenutzerKontoBerechtigungZuordnungen mit dem Rückgabewert "Zugeordnete Kundennummern", die berechtigten Kundennummern abzufragen, wobei einem externen Benutzer pro Rolle (z.B. "Trassenanmeldung") mehrere Kundennummern zugeordnet sein können. Der Service BBZ kann nur eine Ebene von Berechtigungen parametrisieren, in diesem Fall sind dies die Kundennummern. Derzeit wird davon ausgegangen, dass diese Berechtigungsgranularität ausreichend für die Rechtevergabe im Bestellportal ist. Falls sich im Laufe des Projekts weitere Anforderungen hinsichtlich Berechtigungen ergeben sollten, so muss entweder der Service BBZ angepasst werden oder im Bestellportal eine eigene Berechtigungsverwaltung implementiert werden.
|
||||
DB Netz interne Benutzer sind für alle Kundennummern lese- und schreibberechtigt. (vgl. - Akteure Bestellportal).
|
||||
## Kundenstammdaten
|
||||
|
||||
Die Abfrage der Kundenstammdaten aus dem CRM-System erfolgt gestaffelt in zwei Operationen mit dem Service Kundendatenverwaltung (KDV).Â
|
||||
Die Operation leseKunde liefert zu einer Kundennummer den entsprechenden Kunden (Geschäftseinheit). Das Bestellsystem nutzt insbesondere folgende Felder: Name des Kunden, CompanyID, kaufmännischeSperre, Telefonnummer+E-Mail+Faxnummer des zentralen Ansprechpartners beim Kunden. Alle Berechtigungen liegen im Verfahren eBRS (siehe oben) ab.
|
||||
|
||||
Relevant für das Bestellsystem sind neben dem Kundenname und der Adressinformationen insbesondere die Sperrvermerke (Kunde ist kaufmännisch gesperrt oder inaktiv). Um die Kundenstammdaten zu ermitteln, wird die Operation leseKunde nach einer erfolgreichen Anmeldung aufgerufen, die durch Ãbergabe einer Kundennummer die entsprechenden Kundenstammdaten zurück gibt.Â
|
||||
Das Bestellsystem muss ermöglichen, dass auch für kaufmännisch gesperrte Kunden Aufträge an die DB Netz AG übermittelt werden können. Das Bestellportal muss dem Bearbeiter vor Ãbergabe einer Bestellung an die DB Netz AG eine konfigurierbare Warnmeldung anzeigen:
|
||||
- Die Warnmeldung könnte wie folgt ausgegeben werden: "Diese Kundennummer ist kaufmännisch gesperrt. Bitte beachten Sie, dass Sie für die Dauer der Sperre kein Angebot erhalten und Trassenbestellungen nicht bearbeitet werden."
|
||||
- Kundensperre "Inaktiver Kunde" für inaktiv gesetzte Kunden: es können keine Aufträge an DB Netz gesandt werden. Â
|
||||
|
||||
|
||||
| | Service / Komponente | Beschreibung | Kommentar
|
||||
| |
|
||||
BBZ
|
||||
leseBenutzerKontoBerechtigungZuordnungen |
|
||||
Liefert alle Zuordnungen für einen Benutzer eines Mandanten. | optional kann auch nach einer bestimmten Rolle gefiltert werden
|
||||
| |
|
||||
KDV
|
||||
leseKunde
|
||||
leseAlleKunden |
|
||||
|
||||
Liefert zu einer gegebenen Kundennummer detaillierte Kundendaten zurück
|
||||
Liefert eine Liste aller Kunden |
|
||||
|
||||
|
||||
leseAlleKunden ist relevant, falls sämtliche Kundendaten im Bestellsystem gecacht werden müssen. Ansonsten können einzelne Kunden-Sätze mit leseKunde abgefragt werden.
|
||||
|
||||
|
||||
Kundendaten
|
||||
Mehrere Kundennummer /Geschäftspartner referenzieren auf eine Hauptnummer (z.B. DB Regio). Die TAF/TAP Company_ID muss noch entsprechend in den Stammdaten eingepflegt werden.Â
|
||||
Annahme: im neu zu startenden Projekt "Neues CRM System" werden diese Daten erfasst und über den Service KDV zur Verfügung gestellt.
|
||||
## KundennummerÂ
|
||||
|
||||
Die Kunden-Nr. ist Ausdruck dafür, welcher Regionalbereich (Kundenmanagement) für die Betreuung der Kunden zuständig ist. Die Zuordnung von Kunden zu Benutzern wird vom Service KundenDatenVerwaltung (KDV) übernommen. Die Kundenstammdaten liegen im CRM-Systems der DB Netz, der Service KDV ermöglicht den Zugriff auf die Kundenstammdaten für andere Systeme (siehe Schnittstellenbeschreibung). Â
|
||||
Die Buchstaben der Kunden-Nr. sind nicht durchgehend belegt. Die Verwendung der Buchstaben der Kunden-Nr. erfolgt nach dem Sitz des jeweiligen Regionalbereiches
|
||||
-
|
||||
- BXXXX: Berlin, RB Ost
|
||||
- DXXXX: Duisburg, RB West
|
||||
- FXXXX: Frankfurt, RB Mitte
|
||||
- HXXXX: Hannover, RB Nord
|
||||
- KXXXX: Karlsruhe, RB Südwest
|
||||
- LXXXX: Leipzig, RB Südost
|
||||
- MXXXX: München, RB Süd
|
||||
- ZXXXX: Zentrale
|
||||
- CXXXX: besondere Kundengruppe "SCHWEIZ"
|
||||
- RXXXX: RV-Kunden
|
||||
## Kundendatenverwaltung (KDV) und BenutzerBerechtigungsZuordnungen (BBZ)
|
||||
|
||||
 Â
|
||||
## Datenmodell                                                                     Â
|
||||
|
||||
Das CRM System wird alle für TAF/TAP- TSI benötigten kundenspezifische Stammdaten zukünftig enthalten. Die Kundendaten werden in jeder TAF/TAP Nachricht im Element "AdministrativeContactInformation" übertragen.
|
||||
Es gibt bereits EU-weit standardisierte Bezeichner für das jeweilige EVU/EIU, die sogenannte CompanyID :
|
||||
- Jedes EVU bzw. EIU muss über eine eigene CompanyID verfügen. Sofern das noch nicht der Fall ist, muss das EVU / EIU diese beantragen
|
||||
- Die jeweils erforderliche CompanyIDÂ wird als bekannt vorausgesetzt
|
||||
(nicht in der untenstehenden Ausprägungsliste enthalten)
|
||||
- Die gültigen Ausprägungen sind in der "RNE Reference Database" hinterlegt und können per Service oder per Dateidownload abgeglichen werden
|
||||
Die CompanyIDÂ ist wie folgt strukturiert:
|
||||
- CompanyID Kodierung: 4 digits (UIC id of the owner of the path, RU UIC code in the RU Path, IM UIC code in the IM Path)
|
||||
- Die DB Netz hat die CompanyIDÂ 0080
|
||||
|
||||
|
||||
| |
|
||||
I....AdministrativeContactInformation |
|
||||
 |
|
||||
Administrative
|
||||
ContactInformation |
|
||||
Kontaktinformationen des Absenders |
|
||||
Hinweis: Die EVU-Organisationseinheit ist als nationaler Parameter auf Messageebene definiert
|
||||
| |
|
||||
I....I....Name |
|
||||
AdministrativeContactInformation |
|
||||
Name |
|
||||
EVU / EIU: Name des Kunden
|
||||
EVU / EIU: Name des geschäftsführenden Koordinators |
|
||||
Muss immer angegeben werden
|
||||
| |
|
||||
I....I....Address |
|
||||
AdministrativeContactInformation |
|
||||
Address |
|
||||
Postadresse des Absenders |
|
||||
wird nicht verwendet
|
||||
| |
|
||||
I....I....eMail |
|
||||
AdministrativeContactInformation |
|
||||
eMail |
|
||||
EVU / EIU:Â Email-Adresse des Kunden
|
||||
EVU / EIU: Email-Adresse des geschäftsführenden Koordinators |
|
||||
Muss immer angegeben werden
|
||||
| |
|
||||
I....I....PhoneNumber |
|
||||
AdministrativeContactInformation |
|
||||
PhoneNumber |
|
||||
EVU / EIU:Â Telefonnummer des Kunden
|
||||
EVU / EIU: Telefonnummer des geschäftsführenden Koordinators |
|
||||
Muss immer angegeben werden
|
||||
| |
|
||||
I....I....FaxNumber |
|
||||
AdministrativeContactInformation |
|
||||
FaxNumber |
|
||||
EVU / EIU:Â Faxnummer des Kunden
|
||||
EVU / EIU: Faxnummer des geschäftsführenden Koordinators |
|
||||
Muss immer angegeben werden
|
||||
| |
|
||||
I....I....FreeTextField |
|
||||
AdministrativeContactInformation |
|
||||
FreeTextField |
|
||||
Frei definierbarer Text |
|
||||
Â
|
||||
|
||||
|
||||
## Verortung der Kundennummer
|
||||
|
||||
| |
|
||||
kundenummerBestellendesEvu (NSP) |
|
||||
Kundennummer des bestellenden EVU (im ResponsibleApplicant steht die zugehörige CompanyID)
|
||||
| |
|
||||
kundennummerDurchfuerendesEvu (NSP) |
|
||||
Kundennummer des durchführenden EVU (ResponsibleRU steht die zugehörige CompanyID)
|
||||
Eine Ãnderung der Kundennummer in nachfolgenden Bezugsgeschäftsvorfällen ist nur durch "Abmeldung" bzw. "Stornierung" und anschlieÃender erneuerter "Erstanmeldung" mit geänderter Kundennummer möglich. Die Kundennummer ist in einem Feld NSP "Kundennummer bestellendes EVU" bzw. "Kundennummer durchführendes EVU", das sich in der TAF/TAP Messagestruktur auf Ebene PathInformation->PlannedJourneyLocation befindet, pro Zuglaufpunkt anzugeben (siehe TAF/TAP TSI Kundendaten).
|
||||
## Nichtfunktionale Aspekte BBZ
|
||||
|
||||
|
||||
|
||||
| |
|
||||
Vertraulichkeit |
|
||||
|
||||
11
|
||||
incomplete
|
||||
 sehr hoch
|
||||
|
||||
|
||||
12
|
||||
incomplete
|
||||
 hoch
|
||||
|
||||
|
||||
13
|
||||
complete
|
||||
 mittel
|
||||
|
||||
|
||||
14
|
||||
incomplete
|
||||
 niedrig
|
||||
|
||||
|
||||
| |
|
||||
Integrität |
|
||||
|
||||
15
|
||||
incomplete
|
||||
 sehr hoch
|
||||
|
||||
|
||||
16
|
||||
incomplete
|
||||
 hoch
|
||||
|
||||
|
||||
17
|
||||
complete
|
||||
 mittel
|
||||
|
||||
|
||||
18
|
||||
incomplete
|
||||
 niedrig
|
||||
|
||||
|
||||
Â
|
||||
Â
|
||||
| |
|
||||
Verfügbarkeit
|
||||
| |
|
||||
Servicelevel* |
|
||||
|
||||
31
|
||||
incomplete
|
||||
 SL 1 Plus
|
||||
|
||||
|
||||
32
|
||||
incomplete
|
||||
 SL 1
|
||||
|
||||
|
||||
33
|
||||
incomplete
|
||||
 SL 1 Basic
|
||||
|
||||
|
||||
34
|
||||
incomplete
|
||||
 SL 2
|
||||
|
||||
|
||||
35
|
||||
incomplete
|
||||
 SL 3 Plus
|
||||
|
||||
|
||||
36
|
||||
complete
|
||||
 SL 3
|
||||
|
||||
|
|
||||
Aktueller Service Level der BBZ: SL3, eine Erhöhung des Service Levels ist anzustreben
|
||||
 |
|
||||
| |
|
||||
Logging
|
||||
| |
|
||||
Anforderung an Logging* |
|
||||
Nicht bekannt
|
||||
 |
|
||||
| |
|
||||
Ãbertragungsverfahren
|
||||
| |
|
||||
Schnittstellenart* |
|
||||
|
||||
37
|
||||
incomplete
|
||||
 Datenablage in Datei, Pfad: manuelle Festlegung
|
||||
|
||||
|
||||
38
|
||||
complete
|
||||
 Webservice:Â
|
||||
|
||||
|
||||
39
|
||||
incomplete
|
||||
 SMS-Nachricht, Nummer:
|
||||
|
||||
|
||||
48
|
||||
incomplete
|
||||
 gemeinsame Datenbank:
|
||||
|
||||
|
||||
41
|
||||
incomplete
|
||||
 Online-Transaktion:
|
||||
|
||||
|
||||
42
|
||||
incomplete
|
||||
 Andere: Dateiversand via Email
|
||||
|
||||
|
||||
| |
|
||||
Transaktionssicherheit* |
|
||||
 Keine Anforderungen.
|
||||
 Folgende Anforderungen:
|
||||
| |
|
||||
Art der Datenübertragung |
|
||||
 HTTP(S)
|
||||
## Nichtfunktionale Aspekte KDV
|
||||
|
||||
|
||||
|
||||
| |
|
||||
Vertraulichkeit |
|
||||
|
||||
97
|
||||
incomplete
|
||||
 sehr hoch
|
||||
|
||||
|
||||
98
|
||||
complete
|
||||
 hoch
|
||||
|
||||
|
||||
99
|
||||
incomplete
|
||||
 mittel
|
||||
|
||||
|
||||
100
|
||||
incomplete
|
||||
 niedrig
|
||||
|
||||
|
||||
| |
|
||||
Integrität |
|
||||
|
||||
101
|
||||
incomplete
|
||||
 sehr hoch
|
||||
|
||||
|
||||
102
|
||||
incomplete
|
||||
 hoch
|
||||
|
||||
|
||||
103
|
||||
complete
|
||||
 mittel
|
||||
|
||||
|
||||
104
|
||||
incomplete
|
||||
 niedrig
|
||||
|
||||
|
||||
Â
|
||||
Â
|
||||
| |
|
||||
Verfügbarkeit
|
||||
| |
|
||||
Servicelevel* |
|
||||
|
||||
105
|
||||
incomplete
|
||||
 SL 1 Plus
|
||||
|
||||
|
||||
106
|
||||
incomplete
|
||||
 SL 1
|
||||
|
||||
|
||||
107
|
||||
incomplete
|
||||
 SL 1 Basic
|
||||
|
||||
|
||||
108
|
||||
incomplete
|
||||
 SL 2
|
||||
|
||||
|
||||
109
|
||||
incomplete
|
||||
 SL 3 Plus
|
||||
|
||||
|
||||
110
|
||||
complete
|
||||
 SL 3
|
||||
|
||||
|
|
||||
Aktueller Servicelevel des KDV: SL3, von daher ist ein Caching der Daten über die KDV-Operation leseAlleKunden im Bestellsystem zu empfehlen.
|
||||
- Antwortzeiten für leseKunde < 1 Sekunde (Datenvolumen GröÃenordnung < 50k)
|
||||
- Antwortzeiten für leseAlleKunden < 5 Sekunden (ca. 3 MB Datenvolumen)
|
||||
 |
|
||||
| |
|
||||
Logging
|
||||
| |
|
||||
Anforderung an Logging* |
|
||||
 Ein Monitoring der kaufmännisch relevanten Vorgänge ist erforderlich
|
||||
 |
|
||||
| |
|
||||
Ãbertragungsverfahren
|
||||
| |
|
||||
Schnittstellenart* |
|
||||
|
||||
111
|
||||
incomplete
|
||||
 Datenablage in Datei, Pfad: manuelle Festlegung
|
||||
|
||||
|
||||
112
|
||||
complete
|
||||
 Webservice:Â
|
||||
|
||||
|
||||
113
|
||||
incomplete
|
||||
 SMS-Nachricht, Nummer:
|
||||
|
||||
|
||||
114
|
||||
incomplete
|
||||
 gemeinsame Datenbank:
|
||||
|
||||
|
||||
115
|
||||
incomplete
|
||||
 Online-Transaktion:
|
||||
|
||||
|
||||
116
|
||||
incomplete
|
||||
 Andere: Dateiversand via Email
|
||||
|
||||
|
||||
| |
|
||||
Transaktionssicherheit* |
|
||||
 Keine Anforderungen.
|
||||
 Folgende Anforderungen:
|
||||
| |
|
||||
Art der Datenübertragung |
|
||||
 HTTP(S)
|
||||
+38
@@ -0,0 +1,38 @@
|
||||
# 6.7 SAPBINe und Netzmonitor (Nemo)
|
||||
|
||||
> Confluence Page ID: 27525686
|
||||
> Version: 25
|
||||
> Pfad: /pathOS/Start / Vorstudie Bestellsystem/00_Vorstudie Bestellsystem/6 IT Ist-Analyse/6.7 SAPBINe und Netzmonitor (Nemo)
|
||||
> Labels:
|
||||
|
||||
---
|
||||
|
||||
TPN stellt dem System Netzmonitor (Nemo) und SAPBine über zwei verschiedene Schnittstellen täglich ein aktuelles Datendelta aus der TPN-Datenbasis zur Verfügung.Â
|
||||
|
||||
|
|
||||
| |
|
||||
Bereitstellendes System
|
||||
| |
|
||||
Name* |
|
||||
TPN
|
||||
| |
|
||||
Anwendungs-ID (lt. BEAM) |
|
||||
A-101 488
|
||||
| |
|
||||
Einführung mit Version |
|
||||
TPN Release 8.9.5 / August 2018 Release - Netzmonitor
|
||||
TPN Release 8.3.0 - SAPBine
|
||||
| |
|
||||
Organisatorische Verantwortung* |
|
||||
Fachliche Betriebsführung TPN
|
||||
| |
|
||||
Neu oder Ersatz für/durch* |
|
||||
Neue Schnittstelle
|
||||
| |
|
||||
Technische Betriebsführung |
|
||||
Verfahrensbetriebsführung TPN
|
||||
Â
|
||||
Die beiden nachfolgenden Schnittstellenkontextdiagramme zeigen die miteinander interagierenden Systeme TPN - SAPBI und TPN- NEMo sowie den Akteur.Â
|
||||
Â
|
||||
Â
|
||||
Die aktuelle Schnittstellenbeschreibung TPN - SAPBI und TPN- Netzmonitor befindet sich im Sharepoint.
|
||||
+118
@@ -0,0 +1,118 @@
|
||||
# 2019-03-11 Fachliche Klärung zum Thema Common Interface TAF/TAP
|
||||
|
||||
> Confluence Page ID: 27525688
|
||||
> Version: 1
|
||||
> Pfad: /pathOS/Start / Vorstudie Bestellsystem/00_Vorstudie Bestellsystem/14 Besprechungsnotizen Vorstudie/2019-03-11 Fachliche Klärung zum Thema Common Interface TAF/TAP
|
||||
> Labels:
|
||||
|
||||
---
|
||||
|
||||
 Besprechungsprotokoll vom 11.03.19
|
||||
|
||||
Abstimmung über die Technische TAF/TAP Schnittstelle für Fahrplan (/Vertrieb) und Betrieb
|
||||
Â
|
||||
| | Teilnehmer:
|
||||
| |
|
||||
Wolfgang Kuzaj, NMF 11
|
||||
Benjamin Schmücker, NMK 3(I)
|
||||
Jens Miehlnickel, NMK 3(I)
|
||||
Richard Berger, NVI 2Â
|
||||
Jürgen Sievers, NVI 2(A)Â
|
||||
Bettina Kranz, NVI 2(A)
|
||||
Dr. Patrick Breun, NMF 11Andreas Haase, IPI
|
||||
|
||||
|
||||
| |
|
||||
Verteiler:
|
||||
TeilnehmerInnen, sowieAndreas A Schumann, NPB 3(P)Ralph Grassel, NMKÂ Â Â
|
||||
Holger Duis, NVI 2(A)Â Â Â
|
||||
Bernd Völlmeke, NPB 3(Z)
|
||||
Lydia Weitershagen, NVI 2(A)Â Â
|
||||
Holm Zickermann, FIB VS
|
||||
Martin Kiderle, NPB 3(P)Â Â Â
|
||||
Lars Ladouceur, NPB 3(P)Â Â Â
|
||||
Julian Holzner, NMF 11Â Â Â
|
||||
Henning Henke,NMF 2Â Â Â
|
||||
Sebastian Hassemer, NVI 31Â
|
||||
Erstellt von: Bettina Kranz
|
||||
| | Ort/Zeit:
|
||||
| |
|
||||
Frankfurt, Weilburger Str. 22
|
||||
11.03.19, 10.00 â 12:00Uhr
|
||||
|
||||
|
|
||||
| | Nr. | Inhalte/MaÃnahmen | Zuständig | Termin | Status
|
||||
| | Agendapunkt: Fachliche Gründe, die für eine gemeinsame Schnittstelle sprechen
|
||||
| |  1.         |  Die Teilnehmergruppen stellen jeweils aus ihrer Sicht die Vorteile eines Common Interface dar. |  Alle |
|
||||
| I
|
||||
| | Agendapunkt: Fachliche Gründe, die gegen eine gemeinsame Schnittstelle sprechen
|
||||
| |  2.      Â
|
||||
 |  Die Teilnehmergruppen stellen jeweils aus ihrer Sicht die Nachteile eines Common Interface dar. | Alle |
|
||||
| I
|
||||
Â
|
||||
| | Agendapunkt: Sicht der Enterprise Architektur
|
||||
| |  3.      Â
|
||||
|
||||
  |  Die Sicht der Enterprise Architektur ist, dass alle Zielgruppen des Kunden konsistent mit den benötigten Geschäftsobjekten über alle Prozesse hinweg von der DB Netz beauskunftet werden sollen (360° Sicht auf den Kunden). | Sievers |
|
||||
| I
|
||||
| | Agendapunkt: Diskussion
|
||||
| |  4.      Â
|
||||
|
||||
  | Es ist zu ermittelt, in welchem Umfang es der Wunsch der EVU ist, eine Schnittstelle zu haben, und ob die Kunden dieses Vorhaben der DB Netz unterstützen. Dabei sind insbesondere die entstehenden Kosten und Aufwände auf der Kundenseite sowie die Vor- und Nachteile für den Kunden zu ermitteln und zu bewerten. | Kuzaj
|
||||
 |
|
||||
 | I
|
||||
Â
|
||||
| |  5.      Â
|
||||
|
||||
  | Es istaktuell nicht geklärt, welcher Aufwand inklusive Kosten einem eventuellen, noch nicht ermittelten und erkennbaren Nutzen für die Bereiche Fahrplan und Betrieb gegenübergestellt werden kann. Diese Aufwands-/Nutzenbetrachtung mussaber Basis für die Entscheidung sein. | Kuzaj
|
||||
 |
|
||||
Â
|
||||
 | I
|
||||
Â
|
||||
| |  6.      Â
|
||||
|
||||
  | Es besteht ein Problem der Dateninkonsistenz, welches nicht über eine gemeinsame Schnittstelle gelöst werden kann.  Die fachliche Inkonsistenz resultiert aus den Prozessen und muss aufgrund der Betriebslage auch so sein. Die Datensicht kann sich mehrfach im Prozessverlauf ändern. | Kuzaj
|
||||
 |
|
||||
|
||||
 | I
|
||||
| |  7.        | Aus Sicht der Fachbereiche müsste an Stelle einer gemeinsamen Schnittstelle eher an den Prozessen oder an der Transparenz in Richtung Kunde gearbeitet werden. | Fachbereiche
|
||||
 |
|
||||
| I
|
||||
| |  8.       | Die Herstellung der internen Datenkonsistenz ist aktuell bereits im Scope von FIB. |
|
||||
|
|
||||
| I
|
||||
| |  9.      Â
|
||||
|
||||
  | Es gibt keine Nachrichten/Meldungen auf Kundenseite, bei denen der Kunde nicht weiÃ, an wen er diese adressieren soll. Daher wird aktuell keine Notwendigkeit gesehen, nur eine fachliche Schnittstelle anzubieten.  Es ist im Gegenteil sogar wünschenswert, dass der Kunde entscheiden kann, an wen er die Nachricht senden möchte. | Fachbereiche
|
||||
 |
|
||||
 | I
|
||||
| |  10.    Â
|
||||
 |
|
||||
Fachlich bleiben es zwei getrennte Kanäle, technisch kann zu einem späteren Zeitpunkt noch entschieden werden, ob diese zusammengeführt werden können um nach auÃen eine oder zwei Schnittstellen anbieten zu können.
|
||||
Es muss noch entschieden werden, ob und unter welchen Anforderungen diese zusammengeführt werden soll. |  Alle
|
||||
 |
|
||||
Â
|
||||
Â
|
||||
 | B
|
||||
Â
|
||||
| |  11.    Â
|
||||
 | Die einzelnen Projekte werden nun zunächst jeweils ihre eigenen Schnittstellen nach den TAF/TAP Vorgaben und NfA spezifizieren und umsetzen. | Fachbereiche |  | A
|
||||
| |  12.    Â
|
||||
 | Aus Sicht der Enterprise Architektur soll das Ziel weiterverfolgt werden, eine gemeinsame technische Schnittstelle zu bauen, welche eine URL für den Kunden anbietet und zum Beispiel über einen Proxy die Nachrichtenverteilung steuert.
|
||||
Der Vorschlag ist, zunächst mit zwei getrennten fachlichen Schnittstellen zu starten und ggf. später an einer gemeinsamen Schnittstelle zu arbeiten. | Sievers
|
||||
 |
|
||||
Â
|
||||
  | I
|
||||
Â
|
||||
| | 13.      | Es muss nun evaluiert werden, wo die Entscheidungspunkte eine oder zwei technische Schnittstellen liegen. Hierbei muss sichergestellt sein, dass keine negativen Wechselwirkungen aus nicht koordinierbaren Lastspitzen der beiden Kanäle resultieren. | Sievers
|
||||
 |
|
||||
 |
|
||||
A
|
||||
| |  14.    Â
|
||||
 | Falls in Punkt 11 die Umsetzung einer gemeinsamen Schnittstelle beschlossen wird, muss geklärt werden, welches Projekt die Kosten für die technische Schnittstelle trägt. | Sievers
|
||||
 |
|
||||
 | A
|
||||
|
||||
|
||||
Anhang: Protokoll mit Workshop-Präsentation
|
||||
250
|
||||
+14
@@ -0,0 +1,14 @@
|
||||
# 6.2.1.1 Technische Schnittstellenspezifikation TPPuE
|
||||
|
||||
> Confluence Page ID: 27525692
|
||||
> Version: 26
|
||||
> Pfad: /pathOS/Start / Vorstudie Bestellsystem/00_Vorstudie Bestellsystem/6 IT Ist-Analyse/6.2 M13 neXt Gesamtfahrplan/6.2.1 Business Service TrassenProduktPruefenUndErgaenzen (BEP) und Routensuche/6.2.1.1 Technische Schnittstellenspezifikation TPPuE
|
||||
> Labels:
|
||||
|
||||
---
|
||||
|
||||
Der Service "Trassenprodukt prüfen und ergänzen" ist der fachlichen Domäne: âKapazitäts-und Fahrplanmanagementâ zugeordnet und dort in der Komponente âTrassenmanagementâ verortet.Â
|
||||
## Die Technische Schnittstellenspezifikation TPPuEÂ
|
||||
|
||||
Link
|
||||
https://wiki.intranet.deutschebahn.com/wiki/display/neXtlab/Operationen+des+BEP+SOAP+Service oder Technische Schnittstellenbeschreibung TPPuE
|
||||
+339
@@ -0,0 +1,339 @@
|
||||
# 4.4.1 Anbindung Abrechnungssysteme an das Bestellsystem
|
||||
|
||||
> Confluence Page ID: 27525694
|
||||
> Version: 105
|
||||
> Pfad: /pathOS/Start / Vorstudie Bestellsystem/00_Vorstudie Bestellsystem/4 Anforderungen an das neue Bestellsystem der DB Netz/4.4 Soll-Schnittstellen Bestellsystem (Consumer oder Provider)/4.4.1 Anbindung Abrechnungssysteme an das Bestellsystem
|
||||
> Labels:
|
||||
|
||||
---
|
||||
|
||||
## EinleitungÂ
|
||||
|
||||
Im Verkaufsprozess von Trassenprodukten muss sowohl eine Anbindung an das dem Vertrieb zugeordnete Preissystem, als auch an die kaufmännische Abrechnung erfolgen. Um dies zu ermöglichen werden die notwendigen Schnittstellen, welche im parallel laufenden Projekt AbrechnungsCookpit (AC) Trasse umgesetzt werden, angebunden. Das Projekt AC Trasse soll in 2021 produktiv gehen.
|
||||
## Ausschnitt aus dem Systemkontext des Bestellsystems
|
||||
|
||||
Die Anbindung der kaufmännischen Systeme- Abrechnung an das Bestellsystem bildet eine umfangreiche Schnittstellensammlung. Im Folgenden zur Ãbersicht ein Ausschnitt aus dem Systemkontext des im EAM hinterlegten Architekturartefakts Â
|
||||
|
||||
|
||||
|
||||
|
||||
|
||||
|
||||
|
||||
## Prozessuale und dynamische Sicht auf die Schnittstelle Bestellsystem und AbrechnungsCockpit
|
||||
|
||||
Im Folgenden eine vereinfachte Darstellung des gesamten Prozesses, der über das Bestellsystem abgewickelt wird. In dieser Darstellung ist dokumentiert, in welchem Prozessschritt welche Funktionalität der Abrechnungs- und Preissysteme aufgerufen werden sollen.
|
||||
Verständnis des Prozessablaufs vor dem Hintergrund Abrechnung und zukünftige Anbindung von BP mit AC
|
||||
|
||||
|
||||
|
|
||||
| |
|
||||
##  Service/Komponente Â
|
||||
|
|
||||
## Â Â Kurzbeschreibung
|
||||
|
|
||||
## Kommentar
|
||||
|
||||
| |
|
||||
Service PreisVerwaltungTrasse
|
||||
ermittleTrassenPreis
|
||||
|
||||
|
|
||||
Es wird zu einer vom Fahrplan zurückgelieferten FahrplanKapazität (TAF/TAP TSI: PathDetailsMessage) eine verbindlicher Angebotspreis ermittelt.
|
||||
Das zurückgegebene Objekt Preisauskunft liefert den Preis für eine Trasse und auch den Link zu einer generierte Leistungsbeschreibung (LB) im PDF Format welche im LB Portal abliegt.
|
||||
Die Serviceoperation wird aus der Komponente SteuerungVertriebsablauf des Bestellsystems heraus aufgerufen. | Die in der Schnittstelle definierte Zugtrasse muss durch das Bestellsystem über die Fahrplankapazität befüllt werden
|
||||
| |
|
||||
Service PreisVerwaltungTrasse
|
||||
ermittleTrassenPreisInfo |
|
||||
In diesem Kontext fragt das Bestellsystem unverbindliche Preisanfragen ab, um im Planungsprozess dem Kunden bei der Suche einer geeigneten Route als Information einen unverbindlichen Preis anzuzeigen.
|
||||
Das zurückgegebene Objekt Preisauskunft liefert den Preis für die übergebene Trasse.
|
||||
Die Serviceoperation wird aus der Komponente SteuerungVertriebsablauf des Bestellsystems heraus aufgerufen. | Die in der Schnittstelle definierte Zugtrasse muss durch das Bestellsystem über die Fahrplankapazität befüllt werden
|
||||
|
||||
| |
|
||||
Service AufbereitungAbrechnungsInformationenTrassen
|
||||
abrechneVertragsAenderung |
|
||||
Ãnderungen einer Bestellung nach Abschluss eines Trassenvertrags müssen im Abrechnungssystem nachgehalten werden. Dies geschieht über den Service abrechneVertragsAenderung.
|
||||
Ãnderungen können vom Kunden oder von der DB Netz ausgelöst worden sein. In jedem Fall muss sichergestellt werden, dass dieser Service vom Bestellsystem aufgerufen wird.
|
||||
Auch bei Gewährung von Rabatten (NeuverkehrsRabatte) wird dieser Service nach der Genehmigung im OrderDiscountOrderSystem aufgerufen.
|
||||
Der Rabatt wird nachträglich auf den bereits zum Listenpreis abgeschlossenen Vertrag gewährt. Dieser Service erstellt erzeugt eine aktualisierte LB und liefert einen entsprechenden Link zurück.
|
||||
Die Serviceoperation wird aus der Komponente SteuerungVertriebsablauf des Bestellsystems heraus aufgerufen. |
|
||||
Die in der Schnittstelle definierte Zugtrasse muss durch das Bestellsystem über die Fahrplankapazität befüllt werden
|
||||
LB = Leistungsbeschreibung
|
||||
| |
|
||||
Service
|
||||
KaufmaennischeAuftragsverwaltung
|
||||
erstelleAngebotsAnfrage
|
||||
erstelleVertragsAngebot
|
||||
erstelleProduktVertrag |
|
||||
Der Service  bildet die Schnittstelle zu SAP R/3 Netz. Der Service erwartet einen Beleg, der Belegpositionen enthält (ITOM).
|
||||
Eine Belegposition kann eine AngebotsAnfrage, VertragsAngebot oder ProduktVertrag enthalten.
|
||||
Die Belegposition benötigt eine Beschreibung (Text) und den dazugehörigen Preis.
|
||||
Zurückgeliefert wird im Erfolgsfall wieder ein Beleg. Im Erfolgsfall werden BelegAnhänge generiert, die über den Service BelegAnhangArchiv ausgelesen werden können.
|
||||
Bei den "Erstellen" Operationen ist die BelegID bei Ãbergabe an die Operation noch nicht gefüllt, erst bei Rückgabe des Belegs durch die ausgeführte Operation wird dieser zurückgesendet.
|
||||
Die Serviceoperation wird aus der Komponente SteuerungVertriebsablauf des Bestellsystems heraus aufgerufen. |
|
||||
Das im Beleg referenzierte eigentliche Trassenprodukt wird im Service nicht verwendet,
|
||||
insofern kann hier ohne Change Request auch ein TAF/TAP Objekt mit übergeben werden (Any Tag).
|
||||
| |
|
||||
Service
|
||||
KaufmaennischeAuftragsverwaltung
|
||||
aendereAngebotsAnfrage
|
||||
aendereVertragsAngebot
|
||||
aendereProduktVertrag |
|
||||
Der Service  bildet die Schnittstelle zu SAP R/3 Netz. Der Service erwartet einen Beleg, der Belegpositionen enthält (ITOM).
|
||||
Eine Belegposition kann eine AngebotsAnfrage, VertragsAngebot oder ProduktVertrag enthalten. Die Belegposition benötigt eine Beschreibung (Text) und den dazugehörigen Preis.
|
||||
Zurückgeliefert wird im Erfolgsfall wieder ein Beleg.
|
||||
Im Erfolgsfall werden BelegAnhänge generiert, die über den Service BelegAnhangArchiv ausgelesen werden können.
|
||||
Bei den "Aendere" Operationen muss die BelegID bei Ãbergabe an die Operation gefüllt werden, erst bei Rückgabe des Belegs durch die ausgeführte Operation wird dieser zurückgesendet.
|
||||
Die Serviceoperation wird aus der Komponente SteuerungVertriebsablauf des Bestellsystems heraus aufgerufen.
|
||||
|
|
||||
Das im Beleg referenzierte eigentliche Trassenprodukt wird im Service nicht verwendet,
|
||||
insofern kann hier ohne Change Request auch ein TAF/TAP Objekt mit übergeben werden (Any Tag).
|
||||
| |
|
||||
Service
|
||||
KaufmaennischeAuftragsverwaltung
|
||||
beendeBeleg |
|
||||
Der Service  bildet die Schnittstelle zu SAP R/3 Netz. Der Service erwartet eine BelegID. Fachlich bedeutet dies, dass ein Beleg storniert wird.
|
||||
Die Serviceoperation wird aus der Komponente SteuerungVertriebsablauf des Bestellsystems heraus aufgerufen.
|
||||
|
|
||||
|
||||
| |
|
||||
Service BelegAnhangArchiv
|
||||
leseBelegAnhang
|
||||
erstelleBelegAnhang |
|
||||
Der Basic Service archiviert Dokumente der KundenAuftragsVerwaltung im Archiv (DoxIs/BCM).Â
|
||||
Der Link auf das Archiv wird im eigentlichen Beleg aus der kaufmännischen Auftragsverwaltung hinterlegt.
|
||||
Das Speichern von BelegAnhängen muss vom Bestellsystem ausgehen.
|
||||
Das Bestellsystem erstellt ein PDF jeder Anfrage, jeden Angebots und jeden Vertrags und speichert dieses über erstelleBelegAnhang.
|
||||
|
||||
Die Serviceoperationen werden aus der Komponente SteuerungVertriebsablauf des Bestellsystems heraus aufgerufen.
|
||||
|
|
||||
|
||||
| | Schnittstelle DiscountOrderSystem |
|
||||
Das Discount Order System ist eine Webapplikation, welche in das Abrechnungscockpit integriert ist und Anträge zur Neuverkehrsrabatten verwaltet.
|
||||
Ein Kunde kann Neuverkehrsrabatte geltend machen. Eine Entsprechende Anfrage auf Genehmigung wird an das Discount Order System (DOS) übertragen.
|
||||
Nach der Genehmigung muss es eine Rückmeldung an das Bestellsystem geben und die Ãnderungsbepreisung muss an den Service AufbereitungAbrechnungsInformationenTrassen
|
||||
der Abrechnung übermittelt werden. | Schnittstelle ist seitens AbrechnungsCockpit noch nicht definiert.
|
||||
| |
|
||||
SteuerungVertriebsAblauf
|
||||
(KundenauftragsVerwaltung) |
|
||||
Die Komponente SteuerungVertriebsAblauf (ehemals KundenauftragsVerwaltung) steuert zukünftig den vertrieblichen Prozess für Trassen, Serviceeinrichtungen und Stationshalten.
|
||||
Von hier werden die entsprechenden Produktspezifischen Services des Fahrplans, S&S etc aufgerufen und auch die kaufmännische Abwicklung angestoÃen. |
|
||||
|
||||
| |
|
||||
SAP R/3 Netz  |
|
||||
Kaufmännisches Back-End System SAP R/3 Netz, das zur Abrechnung und revisionssicheren Archivierung verwendet wird. Â
|
||||
Abrechnung und revisionssichere Archivierung, SAP Hybris Billing in der Abbildung und hier SAP R3/Netz |
|
||||
|
||||
|
||||
| | Link auf Rechnungsportal |
|
||||
Sharepointanwendung zur Ablage der detaillierten Rechnung zu Trassenverträgen als PDF |
|
||||
|
||||
| | Link auf LB (Leistungsbeschreibung) |
|
||||
Sharepointanwendung zur Ablage der detaillierten Preisaufstellung zu Trassenangeboten als PDF
|
||||
Diskriminierungsfreie Veröffentlichung (Hinweis: Bei der Ablehnung bleibt die LB im Portal. Die Preisberechnung erfolgt zeitlich mit dem Angebotsversand.
|
||||
Folglich können alle LBs auf dem LB-Portal Veröffentlicht werden. Im GelV- nach der Konstruktion wird LB freigegeben.
|
||||
Im Netzfahrplan- Vorläufig VNP; Entgültig ENP - in beiden Fällen wird LB freigegeben.
|
||||
Die im LB-Portal abgelegte Leistungsbeschreibung zum Trassenangebot darf erst sichtbar werden, wenn das Angebot an den Kunden versendet wird! |
|
||||
|
||||
|
||||
| | Veröffentlichung der LB | ein Service wird bei der AC Trasse benötigt, um die Veröffentlichung von Leistungsbeschreibungen zu Netzfahrplanangeboten zu triggern  | noch nicht spezifiziert durch AC Trasse
|
||||
| | AC Service Zuordnung in die Trassenproduktsegmenten -------------- |
|
||||
Anhand der relevanten Anmeldekriterien im Bestellsystem wird eine Zuordnung in die Trassenproduktsegmenten
|
||||
selbst in der AC Trasse (Trassenpreissystem) des dann geltenden Trassenpreissystems angezeigt ()
|
||||
- Anhand der relevanten Anmeldekriterien wird eine Zuordnung in die Trassenproduktsegmente des dann geltenden Trassenpreissystems angezeigt
|
||||
- Das Preissystem unterscheidet grundsätzlich zwischen Güterverkehr und Personenverkehr
|
||||
- Weitere Merkmale sind aktuell beispielsweise Zuggewicht, Zuglänge, (konstruierte) Durchschnittsgeschwindigkeit, Regionalität (Stichwort Metropolverkehre) und weitere Determinanten
|
||||
- Die Produktdeterminaten können sich bis zur Produktivsetzung noch ändern > Grundsätzlich müssen die Produktzuordnungen
|
||||
soweit wie möglich konfigurierbar und erweiterbar sein, um auf periodische Anpassungen der Produktgestaltung reagieren zu können
|
||||
(die nächste Definition wird für das FplJ 2023 vorgenommen) | noch nicht spezifiziert durch AC Trasse
|
||||
| | Neue Anforderung wird noch durch AC Trasse spezifiziert |
|
||||
Bei neuen Kunden oder bei Kunden mit Zahlungsausfällen bzw. drohender Insolvenz muss der Kunde Vorkasse leisten.
|
||||
Aktuell gibt es keine Integration zwischen dem Vorkasse-Prozess und dem Abschluss eines Vertrags. Angedacht ist
|
||||
bspw. das dem Kunden ein Angebot unterbreitet wird, aber der Vertrag erst dann abgeschlossen wird, wenn Vorkasse-Zahlungen eingegangen sind. | (P0) Pe Null Projekt: To Do: AC Trasse
|
||||
|
||||
|
||||
## Sicht auf die Schnittstellen im Verkaufsprozesses (inklusive Preisauskunft und Preisinformation)
|
||||
|
||||
Nachfolgend eine Zusammenfassung der Services und deren Operationen, die aus der Komponente SteuerungVertriebsablauf des neuen Bestellsystems heraus aufgerufen werden.
|
||||
                               Â
|
||||
## Nichtfunktionale Aspekte
|
||||
|
||||
|
||||
|
||||
| |
|
||||
Vertraulichkeit |
|
||||
|
||||
11
|
||||
incomplete
|
||||
 sehr hoch
|
||||
|
||||
|
||||
12
|
||||
complete
|
||||
 hoch
|
||||
|
||||
|
||||
13
|
||||
incomplete
|
||||
 mittel
|
||||
|
||||
|
||||
14
|
||||
incomplete
|
||||
 niedrig
|
||||
|
||||
|
||||
| |
|
||||
Integrität |
|
||||
|
||||
15
|
||||
incomplete
|
||||
 sehr hoch
|
||||
|
||||
|
||||
16
|
||||
complete
|
||||
 hoch
|
||||
|
||||
|
||||
17
|
||||
incomplete
|
||||
 mittel
|
||||
|
||||
|
||||
18
|
||||
incomplete
|
||||
 niedrig
|
||||
|
||||
|
||||
Â
|
||||
Â
|
||||
| |
|
||||
Verfügbarkeit
|
||||
| |
|
||||
Servicelevel |
|
||||
|
||||
31
|
||||
incomplete
|
||||
 SL 1 Plus
|
||||
|
||||
|
||||
32
|
||||
incomplete
|
||||
 SL 1
|
||||
|
||||
|
||||
33
|
||||
complete
|
||||
 SL 1 Basic
|
||||
|
||||
|
||||
34
|
||||
incomplete
|
||||
 SL 2
|
||||
|
||||
|
||||
35
|
||||
incomplete
|
||||
 SL 3 Plus
|
||||
|
||||
|
||||
36
|
||||
incomplete
|
||||
 SL 3
|
||||
|
||||
|
|
||||
die Verfügbarkeit des AC-Services PreisVerwaltungTrasse mit SL3 ist nicht ausreichend
|
||||
JP: Antwortzeiten werden unter 2 Sekunden sein, perspektivisch auch schneller. Durch das Auto-Scaling sollten AC überhaupt kein Problem mit den Peak-Lasten haben.
|
||||
Bzgl. der Verfügbarkeit der Services hat der Fachbereich SL 3 angefordert.
|
||||
 |
|
||||
| |
|
||||
Logging
|
||||
| |
|
||||
Anforderung an Logging |
|
||||
 Ein Monitoring der kaufmännisch relevanten Vorgänge ist erforderlich
|
||||
 |
|
||||
| |
|
||||
Ãbertragungsverfahren
|
||||
| |
|
||||
Schnittstellenart |
|
||||
|
||||
37
|
||||
incomplete
|
||||
 Datenablage in Datei, Pfad: manuelle Festlegung
|
||||
|
||||
|
||||
38
|
||||
complete
|
||||
 Webservice:Â
|
||||
|
||||
|
||||
39
|
||||
incomplete
|
||||
 SMS-Nachricht, Nummer:
|
||||
|
||||
|
||||
40
|
||||
incomplete
|
||||
 gemeinsame Datenbank:
|
||||
|
||||
|
||||
41
|
||||
incomplete
|
||||
 Online-Transaktion:
|
||||
|
||||
|
||||
42
|
||||
incomplete
|
||||
 Andere: Dateiversand via Email
|
||||
|
||||
|
||||
| |
|
||||
Transaktionssicherheit |
|
||||
 Keine Anforderungen.
|
||||
 Folgende Anforderungen:
|
||||
| |
|
||||
Art der Datenübertragung |
|
||||
 HTTP(S)
|
||||
                 Â
|
||||
## Datenmodell
|
||||
|
||||
Für die Preisberechnung/Abrechnung werden folgende Informationen aus dem Bestellsystem benötigen. Datenfelder AC-Bestellsystem TAF. Das vorhandene Datenmodell des AC Trasse beinhaltet ein ITOM nahes Modell vom Objekt ZugTrasse (siehe aktuelle Servicebeschreibungen). Ein Mapping des TAF/TAP Modells auf die ZugTrasse ist geplant.
|
||||
Hinweis: Die Preise werden im TAF/TAP Objekt in den Attributen NetworkSpecificParameters hinterlegt, da diese keine TAF/TAP Standarddatenfelder darstellen.
|
||||
## Attribute der Struktur âNetworkSpecificParameterâ auf Message-Ebene
|
||||
|
||||
(Extrahiert aus der Anlage 1 der EVU-SST)
|
||||
Â
|
||||
| | Trassenpreis | Trassenpreis in Euro [â¬] |
|
||||
|
|
||||
1. Das Feld enthält den Gesamtpreis der Trasse in Euro.
|
||||
2. Der Preis wird mit zwei Nachkommastellen geliefert.
|
||||
3. Wird nicht bei den Ausprägungen des Feldes <geschaeftsvorfallTyp> 19 (Zurückweisung), 35 (nicht konstruierbare Trasse) und bei RV-Kapazitätsangeboten und Ergebnissen der Produkte FZB und FPS geliefert.
|
||||
| |
|
||||
| PreisInformationen |
|
||||
|
|
||||
|
||||
| |
|
||||
 |
|
||||
PreisInformationenZLP |
|
||||
 |
|
||||
Â
|
||||
| |
|
||||
NV_IM |
|
||||
Intermodal gewonnener Neuverkehr |
|
||||
I....I....I....nvIm |
|
||||
NetworkSpecificParameter
|
||||
| |
|
||||
NV_BIS |
|
||||
Neuverkehr (ab ZLP) bis ZLP |
|
||||
I....I....I....nvBis |
|
||||
NetworkSpecificParameter
|
||||
| |
|
||||
NV_NUMMER |
|
||||
Von DB Netz vergebene Nummer für bestätigten Neuverkehr |
|
||||
Siehe |
|
||||
https://ciodbn.noncd.rz.db.de/websites/MMO/Projekte/neXt_APluS/Value%20Stream/02%20Workshops/TAF%20TAP%20TSI/02%20Termine/Austausch%20M31%20Bestellportal/20181203%20NetworkSpecificParameter_%C3%9Cbersicht%20v06.xlsx
|
||||
|
||||
|
||||
|
||||
   Â
|
||||
+116
@@ -0,0 +1,116 @@
|
||||
# 6.8 Verwaltungsunterstützende Services (KDV & eBRS)
|
||||
|
||||
> Confluence Page ID: 27525695
|
||||
> Version: 25
|
||||
> Pfad: /pathOS/Start / Vorstudie Bestellsystem/00_Vorstudie Bestellsystem/6 IT Ist-Analyse/6.8 Verwaltungsunterstützende Services (KDV & eBRS)
|
||||
> Labels:
|
||||
|
||||
---
|
||||
|
||||
6.8.1 Externe Benutzerverwaltung (eBRS)
|
||||
eBRS steht als System für "externer Benutzer und Rollen Service" mit dem Funktionsumfang einer Benutzerverwaltung, die über ein PowerUser-Konzept von den EVU-Usern selbst bedient wird.
|
||||
Die manuelle und verfahrensspezifische Pflege von Benutzern im Active Directory ist mühsam. Das Verfahren eBRS erleichtert dies durch automatische Prozesse. Auch der administrative Aufwand für DB Netz Mitarbeiter wird dadurch erleichtert, dass die Pflege der eigenen Mitarbeiter an die EVUs und EIUs selbst ausgelagert wird.
|
||||
Pro EVU gibt es so genannte "PowerUser", die das Benutzermanagement für ihr eigenes EVU übernehmen. Neue Benutzer werden von ihren PowerUsern eingeladen, sich für eBRS bzw. myNet zu registrieren. Der PowerUser gibt hierfür lediglich eine E-Mailadresse ein.
|
||||
Der Benutzer erhält dann einen Registrierungslink und kann sich registrieren. Hier wird er aufgefordert, folgende Informationen auszufüllen:
|
||||
- Pflichtfelder
|
||||
- Anrede (Herr/Frau)
|
||||
- Vorname
|
||||
- Nachname
|
||||
- Passwort
|
||||
- Optionale Felder
|
||||
- Titel (Prof. / Dr.)
|
||||
- StraÃe und Hausnummer
|
||||
- PLZ
|
||||
- Ort
|
||||
- Land
|
||||
- Telefonnummer
|
||||
Weitere Felder (etwa Fax, Initialen) sind derzeit nicht in eBRS vorgesehen und werden zur Zeit daher nicht im AD gespeichert.
|
||||
Folgende Namenskonvention wird für Benutzernamen im DS-AD verwendet: DS\[Erste Buchstabe des Vornamen].[Nachname][ggf. Nummer]
|
||||
Zum Beispiel würde Johann-Wolfgang Goethe folgenden Benutzernamen bekommen: j.goethe
|
||||
Zusätzlich sind folgende Regeln zu beachten:
|
||||
- Die Sonderzeichen ä, ö, ü und à werden in ae, ou, ue, ss konvertiert.
|
||||
- Andere Sonderzeichen (wie è, à , â¦) werden bei der Eingabe blockiert.
|
||||
- Nur folgende Zeichen sind bei der Eingabe des Vor- und Nachnamens auf der UI zulässig:
|
||||
-
|
||||
- a-z
|
||||
- A-Z
|
||||
- üÃöÃäÃ
|
||||
- -
|
||||
- à (groà und klein)
|
||||
- Leerzeichen
|
||||
Bindestriche und Leerzeichen werden bei der Berechnung des Benutzernamens ignoriert (entfernt), sowohl bei Vor- als auch bei Nachnamen. Bei der Generierung der Benutzernamen werden nur Kleinbuchstaben verwendet.
|
||||
Â
|
||||
Wenn ein Benutzerkonto mit dem gleichen Namen bereits besteht, dann wird hochgezählt. Das heiÃt zum Beispiel:
|
||||
- Johann-Wolfgang Goethe bekommt den Benutzernamen j.goethe
|
||||
- Johannes Goethe bekommt dann den Benutzernamen j.goethe1
|
||||
Die maximale Anzahl von Buchstaben für Vornamenbuchstaben + . + Nachname beträgt 20 Zeichen. Denn aus Kompatibilitätsgründen erlaubt das AD maximal 20 Zeichen für den âSamAccountNameâ.
|
||||
Sollte der Nachname zu lange sein, wird dieser automatisch gekürzt, zum Beispiel: Johannes Mustermannbeispielname wird zu j.mustermannbeispiel
|
||||
Die Hochzählung funktioniert folgendermaÃen:
|
||||
Der erste Benutzer bekommt seinen Benutzernamen mit maximal 20 Zeichen zugeteilt. Der nächste, der den gleichen Benutzernamen bekommen würde, bekommt diesen Namen mit einer 1 im Anschluss. Der nächste bekommt eine 2 usw. Es werden keine redundanten Nullen verwendet, das heiÃt 1,2,3,4,5,6,7,8,9,10,11, 12⦠und nicht 01,02,03,04,05,06,07,08,09,10,â¦
|
||||
Die Höchstmögliche Zahl beträgt 9999.
|
||||
Sollte der Benutzername mit Zahl länger als 20 Zeichen sein, wird der Nachname um die entsprechende Zeichenzahl gekürzt.
|
||||
Beispiele:
|
||||
- j.mustermannbeispiel
|
||||
- j.mustermannbeispie1
|
||||
- j.mustermannbeispie#
|
||||
- j.mustermannbeispi10
|
||||
- j.mustermannbeispi##
|
||||
- j.mustermannbeisp100
|
||||
- j.mustermannbeisp###
|
||||
- j.mustermannbeis1000
|
||||
- j.mustermannbeis####
|
||||
- j.mustermannbeis9999
|
||||
|
||||
|
||||
Nachfolgendes Systemkontext-Diagramm beschreibt das eBRS-System aus architektonischer Sicht:
|
||||
|
||||
Die eBRS-Oberfläche (erreichbar über F5 und in der oberen Hälfte des Diagramms abgebildet) ist lediglich für die Pflege der Berechtigungen durch berechtigte Anwender (u.a. PowerUser) bestimmt. Die Anwendungen im Backend (z.B. Bestellsystem, Click&Ride) können direkt mit dem AD bzw. dem Service BBZ kommunizieren, um die Benutzerkonten bzw. die relevanten Rechte abzufragen.
|
||||
Die externen Benutzerkonten liegen in der Active Directory Domäne ds.db.de. Hier besteht ein einseitiger Trust zur BKU-Domäne (DS vertraut BKU, aber BKU vertraut DS nicht).
|
||||
Folgende Informationen sind für die Anbindung an das Active Directory wichtig:
|
||||
- Host: ds.db.de
|
||||
- Port: 389
|
||||
- LDAP Root-Pfad: OU=MyNet,OU=Verfahren,DC=ds,DC=db,DC=de
|
||||
- Darunter gibt es umgebungsspezifische OUs, worunter wiederum die Benutzer liegen. Die Struktur sieht folgendermaÃen aus:
|
||||
- MyNet (OU, siehe Root-Pfad oben)
|
||||
- TU (OU)
|
||||
- User (OU)
|
||||
- Groups (OU)
|
||||
- AU (OU)
|
||||
- User (OU)
|
||||
- Groups (OU)
|
||||
- PU (OU)
|
||||
- User (OU)
|
||||
- Groups (OU)
|
||||
- Zugriff: Da es sich um Active Directory handelt, braucht man für den lesenden Zugriff keine besonderen Rechte. Jeder Benutzer, der sich in dem AD authentifizieren kann, kann auch dort lesen.
|
||||
- Sofern einem Benutzer eine bestimmte Rolle zugewiesen wird, wird er in der entsprechenden AD-Gruppe aufgenommen.
|
||||
- Dabei ist die Zuordnung an Kundennummern nicht abgedeckt, da dies in der BBZ geregelt wird. Die AD-Gruppenzugehörigkeit kann aber insofern hilfreich sein, damit jeder, der überhaupt eine Rolle besitzt (z.B. Trassenbestellung), sich in einer Anwendung anmelden kann und die Startseite sieht. So ist die Erstanmeldung performanter und die Zuordnung zu Kundennummern kann später abgefragt werden.
|
||||
- Folgende AD-Gruppen wurden definiert. Hier ist das "XX" entsprechend durch TU, AU oder PU zu ersetzen. Die Gruppen können in der o.g. OU-Struktur gefunden werden.
|
||||
- gm-eBRS-XX-PowerUser
|
||||
- gm-eBRS-XX-Trassenbestellung
|
||||
- gm-eBRS-XX-Anlagenbestellung
|
||||
- gm-eBRS-XX-BetriebDisposition
|
||||
- gm-eBRS-XX-InfrastrukturBauplanung
|
||||
- gm-eBRS-XX-Abrechnung
|
||||
- gm-eBRS-XX-Vertrag
|
||||
- gm-eBRS-XX-NebenleistungenKlein
|
||||
- gm-eBRS-XX-NebenleistungenGross
|
||||
- gm-eBRS-XX-Zusatzleistungen
|
||||
- gm-eBRS-XX-Aufgabentraeger
|
||||
- gm-eBRS-XX-AlleRollen (Parent-Gruppe: enthält alle o.g. Rollen)
|
||||
- Zertifikate
|
||||
- Für .NET Anwendungen sollten die Zertifikate automatisch gezogen werden. Für andere Anwendungen wurden folgende Kenntnisse aus dem Projekt Click&Ride (CnR) gesammelt:
|
||||
- Die AD Server (Berlin/Frankfurt) haben PK-Zertifikate, welche mit einem der DB Root CA Zertifikaten (DB Root CA 1, âSonntag, â21. âNovember â2027 17:21:47) signiert wurden.
|
||||
- In der Regel werden DB Zertifikate mit einem der DB Trust Center Zertifikaten signiert.
|
||||
- Das entsprechende DB Root CA Zertifikat war - zumindest in der aktuellen - SDE/SDC Installation (=Zertifikate in security/cacerts der Entwickler- JVM) nicht enthalten. In den Browsern etc. werden die z.B. aber schon verteilt.
|
||||
- In CnR wurde nun ein eigener Truststore angelegt (hat aber vor Allem mit Spring/Docker/AWS zu tun) und das entsprechende DB Root CA Zertifikat dort zur Verifizierung der AD Zertifikate hinterlegt.
|
||||
- Das DB Root CA bekommt man aus dem Browser oder per Open SSL
|
||||
- Username und Passwort (Credentials, die gegen das AD verifiziert werden sollen) müssen nicht codiert werden; dies erfolgt mit SSL/TLS. Das jeweilige Kryptoverfahren handeln Client und Server immer vor Beginn der Ãbertragung aus.
|
||||
|
||||
|
||||
Ãber den Service BBZ werden die Zuordnung von Benutzerdaten (Benutzername) zu Kundennummern und berechtigte Rolle (für Bestellsystem: "Trassenbestellung") bezogen. Dieser Service ist mittels SOAP anzusprechen.Â
|
||||
Detaillierte technische Informationen können der technischen Komponentenspezifikation entnommen werden. Diese ist unter folgendem Link im SharePoint abgelegt.Â
|
||||
## 6.8.2 Kundendatenverwaltung (KDV)
|
||||
|
||||
Das Arbeitsdokument befindet sich im Share Point Link.
|
||||
| | KDV/ KuDav | SOAP, https | Kundendatenverwaltung. Enthält Informationen wie 'Sperrvermerk' auf Kundennummer-Ebene.
|
||||
##
|
||||
+64
@@ -0,0 +1,64 @@
|
||||
# 6.10 GFD-Z IST-Zustand und Analyse
|
||||
|
||||
> Confluence Page ID: 27525700
|
||||
> Version: 55
|
||||
> Pfad: /pathOS/Start / Vorstudie Bestellsystem/00_Vorstudie Bestellsystem/6 IT Ist-Analyse/6.10 GFD-Z IST-Zustand und Analyse
|
||||
> Labels:
|
||||
|
||||
---
|
||||
|
||||
Schnittstelle zwischen Trassenportal (TPN) und GFD-Z
|
||||
TPN übergibt Trassenanmeldungen und andere Aufträge in Form von âTPN-Anforderungenâ an GFD-Z. GFD-Z bereitet die Aufträge für die Konstruktion auf und stellt für TPN Informationen über den Status der Verarbeitung (âAnforderungsstatusâ) zur Verfügung. Die aus dem Konstruktionssystem RUT-K an GFD-Z übergebenen Konstruktionsergebnisse werden von GFD-Z zusammengestellt und für die Veröffentlichung bereitgestellt sowie als Angebote (âTPN-Antwortâ) an TPN zurückgegeben. Die beiden Datenflussrichtungen sind technisch als Datenbankschnittstellen implementiert.Â
|
||||
## Annahme Bestellsystem:
|
||||
|
||||
Eine Anbindung des Bestellsystems an das bestehende System GFD-Z ist nicht geplant. Angebotsdaten werden direkt über die neue RUT-K Schnittstelle (SteuerungKonstruktionsablauf) an die neue Bestellsystem-Schnittstelle (SteuerungVertrieb) übertragen. Weitere Spezifikationen (erhaltene Operationen, verwendete Schnittstellenobjekte) werden in der Schnittstellenbeschreibung Bestellsystem - BaDiFa (RUK-K) neu beschrieben.Â
|
||||
Systemkontextdiagramm vom heutigen System GFD-Z:Â
|
||||
|
||||
| |
|
||||
Kurzbeschreibung der Schnittstelle GFD-Z  - TPN
|
||||
TPN - GFD-Z |
|
||||
GFD-Z stellt an der Schnittstelle folgende Daten zur Abholung durch TPN bereit:
|
||||
- Informationen über den Bearbeitungsstatus einer TPN-Anforderung
|
||||
- Angebote zu Fahrlagen, die aus einer TPN-Anforderung erzeugt oder verändert worden sind
|
||||
- Daten zur Trassenanmeldung werden von TPN an GFD-Z übergeben
|
||||
-Â GFD-Z quittiert den Empfang der Anforderung mit einer eindeutigen Anforderungsnummer
|
||||
| |
|
||||
Verwendete Schnittstellenobjekte |
|
||||
-Â Â Â Â TPN-Antwort
|
||||
-Â Â Â Â Anforderungsstatus
|
||||
| |
|
||||
Enthaltene Operationen |
|
||||
-    Angebotsdaten an TPN übertragen
|
||||
-Â Â Â Â TPN-Abfrage (Status einer Anforderung vom GFD-Z abfragen)
|
||||
-Â Â Â Â Angebot abholen (durch TPN)
|
||||
##
|
||||
Schnittstelle zwischen GFD-Z â BIP
|
||||
|
||||
Als Nebenleistung kann ein EVU eine Trassengrafik bestellen, siehe https://fahrweg.dbnetze.com/fahrweg-de/kunden/leistungen/neben_und_zusatzleistungen/preise-1392066. Diese wird mit BIP erstellt. Es handelt sich hier um den gleichen Bestellvorgang wie für gedruckte Buchfahrpläne, bei dem ein Produktionsauftrag direkt in Richtung der âVeröffentlichungâ geht. Im Zielbild würde BIP wegfallen und seine gesamte Funktionalität in der neuen Veröffentlichungsplattform aufgehen.
|
||||
Die Bestellungen von Nebenleistungen sollten langfristig über das Bestellportal abgewickelt werden, das damit eine Schnittstelle zu einer weiteren Produktionsplattform hätte. Dies ist im Rahmen des MVPs jedoch nicht berücksichtigt.
|
||||
## Schnittstelle zwischen GFD-Z und dem Abrechnungscockpit
|
||||
|
||||
Ãber GFD-Z wird die Verwaltung der Trassen und unter anderem die Datenversorgung der NSS und von EBuLa realisiert sowie die Angebote zur Weitergabe an den Kunden (EVU) vorbereitet. Da in diesen Angeboten auch Preisangaben vorhanden sind, muss GFD-Z diese über einen neuen Service des Abrechnungscockpits beziehen.
|
||||
Ãber diese Schnittstelle werden von GFD-Z Trassenpreisanfragen an das Abrechnungscockpit gestellt und die jeweiligen Ergebnisse entgegengenommen. Weiterhin wird das Abrechnungscockpit über diese Schnittstelle bei Vertragsänderungen informiert und mit den Trassendaten des alten und neuen Vertragsstandes versorgt.Â
|
||||
## Annahme Bestellsystem:
|
||||
|
||||
Ãber die Schnittstelle Bestellsystem - AC werden zukünftig die Trassenpreisanfragen/Vertragsänderungen an AC gestellt und die Ergebnisse entgegengenommen.Â
|
||||
## Schnittstelle zwischen GFD-Z - NSSÂ
|
||||
|
||||
Die NSS Schnittstelle wird weiter über Fahrplan (Badifa) versorgt.
|
||||
- Badifa berücksichtigt durch den Zugtrassenbereitstellungsservice die Versorgung unmittelbar umliegender DB Netz-interner Systeme mit Zugtrasseninformationen.
|
||||
- Aktuell wird eine Vorstudie zur Integration der betrieblichen Fahrplanbearbeitung (BFB) in Badifa bzw. IKS (Integriertes Konstruktionssystem) durchgeführt
|
||||
- Es existiert eine Analyse (âSynopseâ), die den Informationsgehalt von TAF/TAP Path Details Messages des Betriebs mit dem Informationsgehalt des aktuellen Betriebszugs der NSS verglichen hat.
|
||||
- Es ist nicht erwünscht neben den geplanten Services einen weiteren provisorischen Service zu entwickeln, um bspw. ein Releasedatum zu retten. (âkein zweites ISAâ)
|
||||
Zur Ablösung der NSS herrscht bilateraler Konsens zwischen Fahrplan und Betrieb.Â
|
||||
 Die Anforderungen der historischen Abnehmer (NSS) werden an Badifa übergeben ggf. den Zugtrassenbereitstellungsservice von Badifa um weitere Services erweitert sofern die TAF/ TAP TSI konformen Daten vom Bestellsystem oder aus dem Betrieb nicht ausreichend oder inkompatibel sind.Â
|
||||
## Experten Schätzung für die weitere GFD-Z Schnittstellen:Â
|
||||
|
||||
GFD-Z â OSB: Entfällt zusammen mit OSB, wenn die Workflowsteuerung des unterjährigen Baufahrplans zur Fahrplankonstruktion wandert. Das hängt aber davon ab, ob die Prozessanpassungen und IT-Unterstützung aus M13 und M31 im unterjährigen Baufahrplan dazu führen, dass alle baubedingt geänderten Trassen auskonstruiert werden können, sodass QAP in GFD-Z entfallen kann. Wenn das nicht der Fall sein sollte, könnte die Schnittstelle evtl. noch etwas länger bis zur Ablösung OSB leben.
|
||||
GFD-Z â PAULA: Wurde implementiert, aber nie produktiv genutzt, und diente nur zur Weitergabe von La-Daten aus PAULA nach EBuLa, ohne dass GFD-Z etwas damit getan hat. Falls irgendwann die La-Daten in die Buchfahrplan-Darstellung auf den Bordgeräten integriert werden soll, könnte sich das ändern. Vermutlich wird weder das neue Trassenkonstruktionssystem, noch die Trassen- bzw. Trassenfahrplan-Verwaltung, noch die zukünftige Veröffentlichungsplattform, eine Schnittstelle zu PAULA haben.
|
||||
GFD-Z â BuMV: Eigentlich ist das keine Schnittstelle. GFD-Z erzeugt für gedruckte Buchfahrpläne RTF-Dateien. Die âBuchmacherâ (in den LN-Prozessen: âFahrplandatenbereitstellerâ) öffnen diese mit MS Word und verwenden einen Satz Makros zur Nachbearbeitung der Dokumente, wenn nötig. Diese Makros heiÃen âBuMVâ (âBuchMacher-Verfahrenâ).Â
|
||||
## Annahmen aus der FIB 2 VeröffentlichungsplattformÂ
|
||||
|
||||
- Schnittstelle zwischen GFD-Z - Ebula: die Schnittstelle wird weiter über GFD-Z versorgt.
|
||||
- GFD-Z - Ebula Editor: die Schnittstelle wird weiter über GFD-Z versorgt.
|
||||
- GDF-Z - Leporello: die Schnittstelle wird weiter über GFD-Z versorgt.
|
||||
+74
@@ -0,0 +1,74 @@
|
||||
# 7.1.3 Einzelkomponenten und Funktionen
|
||||
|
||||
> Confluence Page ID: 27525710
|
||||
> Version: 21
|
||||
> Pfad: /pathOS/Start / Vorstudie Bestellsystem/00_Vorstudie Bestellsystem/7 Umsetzungsalternativen und Bewertung/7.1 make-, buy, re-use-Entscheidungen/7.1.3 Einzelkomponenten und Funktionen
|
||||
> Labels:
|
||||
|
||||
---
|
||||
|
||||
In diesem Kapitel werden die Kernfunktionen des neuen Bestellprozesses betrachtet und die Umsetzungsalternativen vorgestellt. Eine Kauflösung bzw. Wiederverwendung wird vorgestellt, soweit diese bekannt ist. Dabei wird auf die Vorstellung von TPN verzichtet, da diese bereits in der IST-Analyse sowie als separate Wiederverwendungsoption diskutiert wurde.
|
||||
## Kernfunkionen
|
||||
|
||||
## TAF-TAP-TSI-konforme Bestellschnittstelle
|
||||
|
||||
Neben einer Eigenentwicklung kommt hierfür das unter Kapitel  beschriebene Produkt - eine Referenzimplementierung der TAF TAP-TSI-Bestellschnittstelle in Betracht.Â
|
||||
Dieses Produkt könnte als Integrationskomponente zwischen den externen EVUs und der Komponente SteuerungVertriebsAblauf eingesetzt werden.
|
||||
Eine Bewertung dieser Alternative ist in Architekturentscheidung RNE CI zu finden.
|
||||
## Planung einer Zugfahrt (UI)
|
||||
|
||||
Hierbei handelt es sich um die Planungsfunktionalität in einer Bestelloberfläche. Die Wiederverwendung der entsprechenden Einfachbahn Produkte wird im Kapitel beschrieben.
|
||||
## Anmeldung einer Zugfahrt (UI)
|
||||
|
||||
Für die Anmeldung sowie Ãnderung oder Stornierung einer Zugfahrt kommen neben einer Neuentwicklung die bisherigen Systeme TPN und Click&Ride in Frage.
|
||||
## Vorgangsverwaltung Trasse
|
||||
|
||||
Die Vorgangsverwaltung umfasst die Speicherung sowie den Abruf und die Darstellung der Anmelde-Vorgänge. Diese Funktionalität wird sowohl für die Bestellschnittstelle als auch auch für die Anmeldung-UI benötigt.
|
||||
Hierfür ist eine Neuentwicklung vorgesehen, die das TAF-TAP-TSI-konforme Datenmodell und spezifische Zugriffsszenarien effizient unterstützen kann. So können zum Beispiel die Trassen-Anfragen und -Angebote als unveränderliche Dokumente abgelegt werden und eine einfache Darstellung der Vorgänge ermöglichen.
|
||||
Eine Umsetzung als eigenständige Komponente (getrennt von der Prozesssteuerung) ermöglicht eine Trennung der trassenspezifischen Vorgänge vom produktübergreifenden Vertriebsprozess (siehe unten).
|
||||
## Prozesssteuerung des Vertriebsablaufs
|
||||
|
||||
Die Steuerung des Vertriebsablaufs umfasst zum einen die Integration mit den Umsystemen aus dem Bereich Abrechnung und Fahrplankonstruktion. Zum anderen ist hier zukünftig die Integration mit den anderen Produkten (Anlagen bzw. Stationen) vorgesehen.
|
||||
Hier kommt neben einer Neuentwicklung auch die Wiederverwendung der Prozesssteuerung (siehe Kapitel ) in Betracht. Allerdings läuft die bisherige Lösung auf der EIP und enthält Fahrplan- und Vertriebs-Komponenten. Eine Migration auf eine Camunda-basierte Lösung und eine Aufteilung in Vertriebs- und Fahrplan-Kompontenten ist in neXt gestartet. Eine Wiederverwendung kann geprüft werden, sobald die Migration abgeschlossen ist. Auf der anderen Seite ist eine integrierte Camunda-Funktionalität der einzusetzenden Entwicklungsplattform eine sinnvolle Alternative.
|
||||
## Abrechnungsfunktionen
|
||||
|
||||
Für die Abrechnung werden im Rahmen der Trassenbestellungen folgende Funktionen benötigt:
|
||||
- Preisauskunft
|
||||
- Beleg-Verwaltung
|
||||
- Beleg-Archivierung
|
||||
- Ãnderungsabrechnung
|
||||
- Rabatte
|
||||
- Leistungsbeschreibungen
|
||||
Diese Funktionen werden im Rahmen des Projekts Abrechnungscockpits neu- bzw. weiterentwickelt. Es handelt sich also um eine Wiederverwendung, wobei die zusätzlichen Anforderungen vom Bestellsystem berücksichtigt werden (siehe ).
|
||||
## Fahrplan- und Infrastruktur-Funktionen
|
||||
|
||||
## Stammdaten
|
||||
|
||||
Es kann zwischen betrieblichen, fahrplanerischen und vertrieblichen Stammdaten unterschieden werden. Diese werden zur Zeit vom System GFD-I (siehe ) bereitgestellt. Als die künftige Quelle ist das System InfrastrukturManager anvisiert, welches durch das Projekt M15 aufzubauen ist.
|
||||
## Konstruktion-Steuerung
|
||||
|
||||
Bisher erfolgt die Steuerung des Konstruktionsablaufs in TPN sowie die eigentliche Konstruktion in RUT-K (angebunden in TPN über GFD-Z). Künftig soll dieser Ablauf durch die im Projekt BaDiFa zu entwickelnde Systeme abgelöst werden.
|
||||
Eine Alternative wäre die Wiederverwendung der bisherigen Kette: Konstruktion-Steuerung in TPN, GFD-Z, Konstruktion in RUT-K. Hier ist vor allem die Konvertierung zwischen den bisherigen Datenmodellen und Prozessen sowie deren Entsprechungen in der TAF/TAP Welt problematisch.
|
||||
## Routensuche
|
||||
|
||||
Im Bestellportal soll die Routensuche die Planung einer Zugfahrt unterstützen, ähnlich zum Trassenfinder, bzw. die angebotene Trasse visualisieren, wie in der Click&Ride App. Dafür bietet (im Gegensatz zum Trassenfinder) einen dedizierten Service. Dieser soll im Bestellportal genutzt und entsprechend der neuen Anforderungen erweitert werden.
|
||||
## Zugnummer- bzw. OTN-Generator
|
||||
|
||||
Zukünftig sollen die OTN (Operational Train Number, entspricht in etwa der bisherigen Zugnummer) von einem vom Fahrplan angebotenen Service umgesetzt werden. Dieser wird im BaDiFa Projekt entwickelt, bzw. aus dem bisherigen Zugnummern-Generator von TPN weiterentwickelt.
|
||||
## Bestelleingangsprüfung
|
||||
|
||||
Die fahrplanerische Prüfung der Trassenbestellungen erfolgt aktuell im vom entwickelten Service TrassenProduktPruefenUndErgaenzen. Dieser kann wiederverwendet werden. Die vertrieblichen Prüfungen hingegen sollen direkt im Bestellportal umgesetzt werden, um eine saubere Trennung von Fahrplan und Vertrieb zu erreichen.
|
||||
## Sonstige Funktionen
|
||||
|
||||
## Integration Kundenportal
|
||||
|
||||
Das Bestellportal-Frontend soll in ein Kundenportal der Netz integriert werden, um eine zentrale Anlaufstelle zu ermöglichen. Eine leichtgewichtige Integration (Verlinkung aus dem Portal) ist prinzipiell mit jeder verfügbaren Portal-Lösung, wie MyNet, NetzCockpit oder dem DB Kundenportal möglich.
|
||||
## Benutzerverwaltung
|
||||
|
||||
Die Benutzerverwaltung deckt vor allem die Authentifizierung und Autorisierung der Benutzer ab. Das Letztere umfasst insbesondere die Rollen und die Kundennummer-Zuordnungen. Hierfür kann die bestehende eBRS Lösung aus MyNet/BBZ/LDAP wiederverwendet werden. Alternativ könnte, analog zu TPN, eine eigene Benutzerverwaltung umgesetzt werden.
|
||||
## Kundenstammdaten
|
||||
|
||||
Die Kundenstammdaten werden aktuell vom Service KDV angeboten. Dieser soll wiederverwendet werden.
|
||||
## Geschäftsanalytik (BI)
|
||||
|
||||
Für die Analyse der Geschäftsdaten sollen bestehende Systeme wiederverwendet werden: . Aufgrund der mit TAF-TAP-TSI geänderten Datenstrukturen und Prozesse wird dafür ein geeigneter Service angeboten.
|
||||
+40
@@ -0,0 +1,40 @@
|
||||
# 4.3 Geschäftsobjekte Bestellsystem
|
||||
|
||||
> Confluence Page ID: 27525716
|
||||
> Version: 47
|
||||
> Pfad: /pathOS/Start / Vorstudie Bestellsystem/00_Vorstudie Bestellsystem/4 Anforderungen an das neue Bestellsystem der DB Netz/4.3 Geschäftsobjekte Bestellsystem
|
||||
> Labels:
|
||||
|
||||
---
|
||||
|
||||
Das im Bestellsystem verwendete Objektmodell leitet sich aus dem fachlichen Objektmodell der DB Netz AG (FOM) ab (). Für die IT-technische Modellierung innerhalb des Bestellsystems orientiert sich das Projekt sehr nahe am TAF/TAP TSI Standard. Die neuen Fachklassen und Geschäftsobjekte sind im TAF/TAP TSI Modell (Anlage 3, 4 und 5 des TAF/TAP Fachkonzepts) beschrieben. Bei Schnittstellen im DB Netz-IT Kontext zu Komponenten auÃerhalb des Bestellsystems, findet eine bilaterale Abstimmung zwischen beiden Partnern statt, es wird insbesondere bei bestehenden Services eine am IT Objektmodell der DB Netz (ITOM) ausgerichtete Struktur verwendet werden, alternativ das intern genutzte TAF/TAP TSI nahe Modell.
|
||||
Die folgende Abbildung zeigt die Beziehung von Objekten aus Sicht des Fahrplans zu Objekten aus Sicht des Vertriebs vorgenommen unter Berücksichtigung der TAF/TAP Nachrichten als Grundlage.
|
||||
|
||||
Im Rahmen der Vorstudie wurde das Objektmodell für die Schnittstellen mit den Verantwortlichen der externen Schnittstellen und der IT Architektur im CIO-Bereich der DB Netz AG abgestimmt und eine erste Kostenindikation erstellt. Eine finale Abstimmung des geänderten bzw. ergänzten Objektmodells auf Attributebene ist für den Start des Projektes Anfang 2020 geplant.Â
|
||||
## 4.3.1 Objektverwendungen und Identifier
|
||||
|
||||
Die unternehmensextern orientierte Schnittstelle TAF/TAP TSI Common Interface benutzt selbstverständlich TAF/TAP TSI im Sinne der Schnittstellenbeschreibung der DB Netz AG. Die zentralen Objekte der neuen TAF/TAP-TSI-Struktur sind die vier Objekte Train (âZugâ), PathRequest (âFahrlageâ), Path (âZugtrassenvarianteâ), sowie CaseReference (keine direkte ITOM-Entschprechung vorhanden) für spezielle Ausprägungen bzw. ergänzende Anmeldeinformationen.Â
|
||||
## Train-Objekt und PathRequestMessage
|
||||
|
||||
Das Train-Objekt bildet im Bestellsystem das grundlegende Objekt für die Kundensicht. Es kann ausschlieÃlich vom Kunden erstellt werden. Der Train repräsentiert dabei den vom Kunden umrissenen, aus Kundensicht beschriebenen Geschäftsvorfall. Durch die TrainID wird das Objekt fachlich eindeutig identifizierbar. Das Train-Objekt ist in der Planungsphase beim Kunden das entscheidende Objekt, unter dem Entwurfsstände gefunden werden und so Planungsvorgänge wieder aufgenommen werden können. Ein Train kann in der Anmeldung in multiple PathRequests aufgesplittet werden. Jede maÃgeblich Anpassung am Objekt PathRequest erfordert die Generierung eines neuen PathRequests. MaÃgebliche Anpassung sind beispielsweise Unterscheidungen in den Anmeldungen für Werktage und Wochenenden. Eine präzise Definition, wann eine Differenzierung zu einem neuen PathRequest führt gibt es nicht. These ist, dass jede bestellte Attribut-Abweichung die Bildung eines neuen PathRequests erfordert. Bis zum Vertragsschluss, kann das Train-Objekt relativ beliebig durch den Anmelder angepasst werden. Mit Vertragsschluss führen wesentliche Ãnderungen am Objekt aber unbedingt zur Schaffung eines neuen TrainObjektes und ggf. zum Ende des Lebenszyklus des Ausgangsobjekts. So lässt sich beispielsweise nach Vertragsschluss der PlannedCalendar des Train-Objekts nicht mehr erweitern. Eine zeitliche Verlängerung kann nur durch Schaffung eines entsprechenden neuen Train-Objekts abgebildet werden.
|
||||
## Path-Objekt und PathDetailsMessage
|
||||
|
||||
Das Path-Objekt wird im Gegensatz zum Train-Objekt durch den Infrastructure Manager (IM) gebildet und über eine eindeutige PathID fachlich identifizierbar gemacht. Das Path-Objekt beschreibt eine Zeit-Wege-Linie durch das Netz des erstellenden IM. Vereinfacht gesagt entsteht durch die Verknüpfung zwischen Train-Objekt und Path-Objekt ein Fahrplan. Ein Path-Objekt kann losgelöst von einem Train-Objekt existieren, etwa im Fall von Systemtrassen. Diese Zuordnung wird über eine PathDetailsMessage bekannt gegeben. Auf ein PathRequest hin, kann ein IM mit multiplen PathDetailsMessages eine 1:n Zuordnung herstellen. Bezogen auf den Train besteht also eine Mehrfachzuordnung auf PathRequest-Ebene und danach ebenfalls auf PathDetailsEbene. Durch Referenzierung auf die ensprechenden IDs ist aber jederzeit eine Nachvollziehbarkeit der Zuordnung gegeben.
|
||||
## CaseReference
|
||||
|
||||
Das Objekt CaseReference ist derzeit noch in der fachlichen Klärung. Grundsätzlich können Verwendungen des Objekts "bilateral" zwischen IM und Responsible Applicant (RA) definiert werden, so dass Ersteller und Empfänger das Objekt verstehen können. Eine europaweite Abstimmung ist nicht erforderlich. Die Verwendung des Objekts wird mit der Schnittstellenbeschreibung bekannt gegeben.
|
||||
|
||||
Ideen zu Verwendung des CaseReference-Objekts sind:
|
||||
- Zusammenfassung von Taktverkehren
|
||||
- Zusammenfassung von Verkehrskonzepten (wahrscheinlich sehr ähnlich zu oben, ggf. mit anderen Ausprägungen)
|
||||
- Beschreibung von BaumaÃnahmen und Bündelung betroffener Path-Objekte mit Calendar-Objekten
|
||||
- Grundsätzlich sachverhaltliche Bündelung einer Menge von Path-Objekten
|
||||
CaseReference-Objekt Framework der RNEÂ
|
||||
## Aufbau Identifier
|
||||
|
||||
Die Identifier in TAF/TAP sind alle grundsätzlich identisch aufgebaut. Der identifizierte Objekttyp selbst ist in den ersten beiden Stellen gekennzeichnet. Identifier in der Planungsphase bilden die Grundlage für die abgeleiteten tagesscharfen Objekte der Betriebsphase. Der Absender einer Nachricht an den Betrieb muss demnach bei Erstellung einer Nachricht darauf achten, auf das korrekte Tagesobjekt zu verweisen.Â
|
||||
|
||||
Das Design von TAF/TAP TSI zeigt, dass die TrainID ein rein fachlich zu verstehender Identifier ist. Ungeachtet der Verwendung von TAF/TAP IDs, wird also auch das Handling technischer Identifier notwendig sein.
|
||||
|
||||
|
||||
Â
|
||||
+74
@@ -0,0 +1,74 @@
|
||||
# 2019-02-27 Abstimmung RuT-Kneu <-> Bestellportal Zeitschiene
|
||||
|
||||
> Confluence Page ID: 27525725
|
||||
> Version: 3
|
||||
> Pfad: /pathOS/Start / Vorstudie Bestellsystem/00_Vorstudie Bestellsystem/14 Besprechungsnotizen Vorstudie/2019-02-27 Abstimmung RuT-Kneu <-> Bestellportal Zeitschiene
|
||||
> Labels: meeting-notes
|
||||
|
||||
---
|
||||
|
||||
##
|
||||
|
||||
## Teilnehmer
|
||||
|
||||
-
|
||||
Sebastian Hassemer
|
||||
-
|
||||
Alicia Schäfer
|
||||
- Daniel Görich
|
||||
- Joachim Geidel
|
||||
- Benjamin Schmücker
|
||||
- Ana Cvitkovic
|
||||
- Sebastian Leisner
|
||||
-
|
||||
Konstantin Pussep
|
||||
## Was ist im Scope von RUT-K Neu bis 2023?
|
||||
|
||||
- RV-Kapazitäten
|
||||
- Konstruktion GelV September 2023
|
||||
- Konstruktion NetzV April 2023
|
||||
- Datenmigration NetzV 2022 -> Netzfahrplan 2023
|
||||
- Workflowsteuerung NetzV und GelV (im Scope RUT-K Neu; Workflowsteuerung Bau nicht RUT-K Neu)
|
||||
- Inkl. BEP für automatisch vs. manuelle Konstruktion/Bestellportal fragt BEP, ob fahrbar oder nicht
|
||||
Die BEP müsste fachlich gesehen in eine vertriebliche und eine fahrplantechnische Prüfung aufgeteilt werden, auÃerdem müsste die Bestelleingangsprüfung von der Prüfung auf Eignung für die automatische Konstruktion getrennt werden. Die vertriebliche Prüfung gehört eigentlich in die Domäne Vertrieb und nicht in die Domäne Fahrplan. Da eine Ablösung des aktuellen BEP-Services nicht im Scope der beiden M31-Teilprojekte ist, gehen wir zunächst davon aus, dass sie unverändert bleibt und in der Domäne Fahrplan angesiedelt wird.
|
||||
- Veröffentlichung ansteuern
|
||||
- Fristen kommen aus Vertrieb, Fahrplan teilt diese auf RBn auf
|
||||
Es gibt für den Vertriebsprozess und die Steuerung der Konstruktionsprozesse unterschiedliche Fristen und daher auch unterschiedliche Fristenrechnungen. Korrekterweise müsste man von noch zwischen Fristen (Zeitdauern, um etwas zu tun) und Terminen (Stichtage wie letzter Termin für die Abgabe von Trassenanmeldungen zum Netzfahrplan) unterscheiden.
|
||||
Fristenrechnung für Vertriebsprozesse gehört zur Domäne Vertrieb und damit in das Teilprojekt Bestellportal. Fristenrechnung für die Fahrplankonstruktion benötigt als EingangsgröÃen die Fristen bzw. Termine der Vertriebsprozesse, wenn es um eine aus einem Vertriebsprozess ausgelöste Konstruktion geht. Diese Fristenrechnung gehört zur âSteuerung Konstruktionsablaufâ und ins Teilprojekt RUT-K neu.
|
||||
Trassenverwaltung
|
||||
- Trassenverwaltung
|
||||
- "Front-End um Bestellungen zu sehen" (KK-Client) inkl. Fahrlagenverwaltung
|
||||
- Zugnummernvergabe (wird mitgenommen/kann sein, dass es weitergegeben wird)
|
||||
- Heben auf neue Infrastruktur
|
||||
Â
|
||||
## Change-Requests:
|
||||
|
||||
- Lärmschutz (Ana schickt CR)
|
||||
Â
|
||||
## Nicht Scope RUT-K Neu
|
||||
|
||||
- Preis nicht Teil RUT-K Neu sonder im Rahmen des Bestellportals
|
||||
- Abbildung TTR
|
||||
- SAPBine Schnittstelle
|
||||
Â
|
||||
## Einbindung BEP
|
||||
|
||||
- Ãberprüfung in Bestellportal (Fahrplan- und Vertriebs-BEP)
|
||||
Â
|
||||
## Relevant für Meilensteine/Fertige Inkremente
|
||||
|
||||
- Schulungen für Konstrukteure müssen gewährleistet werden (erster Stand muss früher fertig sein)
|
||||
- Dummy für Schnittstelle recht früh (gewünscht von Bestellportal)
|
||||
- Aus feiner Fahrplan wird Kapazität ist Fahrplan Domäne (-> RUT macht aus Feinplanung Kapazitätszusage)
|
||||
Â
|
||||
## Offen:
|
||||
|
||||
- Beratung bei abgelehnten Trassen kein LN-Prozess (Beratungsprozess). Im Scope oder nicht? -> Bestellportal über Marco
|
||||
- Termin zur Abstimmung über Objektmodelle
|
||||
Â
|
||||
## Fazit:
|
||||
|
||||
- Ohne äuÃeren Einfluss ist Scope bis Jfpl 2024 umzusetzen
|
||||
- Aktuell Ziel
|
||||
- Schätzung hat noch nicht stattgefunden
|
||||
- Trotzdem Fallbacklösung vorbereiten im Rahmen des Risikomanagements, und in beiden Teilprojekten für den Fall, dass es Verzögerungen im jeweils anderen Teilprojekt gibt
|
||||
+42
@@ -0,0 +1,42 @@
|
||||
# 6.2.1 Business Service TrassenProduktPruefenUndErgaenzen (BEP) und Routensuche
|
||||
|
||||
> Confluence Page ID: 27525729
|
||||
> Version: 36
|
||||
> Pfad: /pathOS/Start / Vorstudie Bestellsystem/00_Vorstudie Bestellsystem/6 IT Ist-Analyse/6.2 M13 neXt Gesamtfahrplan/6.2.1 Business Service TrassenProduktPruefenUndErgaenzen (BEP) und Routensuche
|
||||
> Labels:
|
||||
|
||||
---
|
||||
|
||||
## Einführung
|
||||
|
||||
Der Service "Trassenprodukt prüfen und ergänzen" ist der fachlichen Domäne: âKapazitäts-und Fahrplanmanagementâ zugeordnet und dort in der Komponente âTrassenmanagementâ verortet. Welche Funktionalitäten von den Komponenten aktuell unterstützt werden ist nur rudimentär in der Dokumentation abgelegt und muss aktuell noch zu groÃen Teilen den User Stories entnommen werden. Es wird daran gearbeitet, die Dokumentation auszuweiten.
|
||||
Um dem Kunden schnellstmöglich eine Rückmeldung zu geben, ob seine Angaben valide sind, wird jeder Vorgang (beispielsweise nach dem Speichern oder Senden) automatisch an den Business Service TrassenProduktPruefenUndErgaenzen (kurz: TPPuE) geschickt. Da es sich bei diesem Service um eine Art Bestelleingangsprüfung (kurz BEP) handelt, wird dieser Begriff sehr häufig verwendet und auch in diesem Dokument benutzt.
|
||||
Auf den folgenden Seiten wird dieser Service näher beschrieben.
|
||||
## Ziele und Inhalt des Service
|
||||
|
||||
Der Service führt umfangreiche Prüfungen auf einer Fahrlage durch um festzustellen, ob der Kundenwunsch formal korrekt ist und die Fahrlage technisch theoretisch konstruierbar ist.
|
||||
Kurze Beschreibung der funktionalen Anforderungen der Service TrassenProduktPruefenUndErgaenzen liegt
|
||||
|
||||
|
||||
|
||||
Â
|
||||
## Serviceübersicht RoutensucheÂ
|
||||
|
||||
| | Serviceprofil
|
||||
| |
|
||||
Tags |
|
||||
Routensuche, Route, Kosten, Graph, schnellste Verbindung, Mehrwegsuche
|
||||
| |
|
||||
Verbindung zu Anwendungssystemen | Fahrzeiten- und Belegungszeitenrechner (FBZe) Service über FBZe-Connector
|
||||
| |
|
||||
Muster des Nachrichtenaustauschs
|
||||
 (Message Exchange Pattern) |
|
||||
synchrones Request/Response
|
||||
| |
|
||||
Fehlerbehandlung |
|
||||
Siehe 2.6 Ausnahmebehandlung
|
||||
- Es wird nicht die günstigste Route (Variante) gefunden (zurzeit wird eine leere Route dem Aufrufer zurückgeliefert)
|
||||
- Die zu Grunde liegende Infrastruktur ist nicht korrekt
|
||||
- Unabhängig von der Anzahl der geforderten Routen werden zu viele Routen ausgegeben
|
||||
| | Servicebeschreibung | Servicebeschreibung Routensuche M13 NeXt Gesamtfahrplan befindet sich .Â
|
||||
Tabelle 1: Serviceübersicht RoutensucheÂ
|
||||
+14
@@ -0,0 +1,14 @@
|
||||
# 6.2.2 Fahrzeitberechnung (FBZE)
|
||||
|
||||
> Confluence Page ID: 27525735
|
||||
> Version: 7
|
||||
> Pfad: /pathOS/Start / Vorstudie Bestellsystem/00_Vorstudie Bestellsystem/6 IT Ist-Analyse/6.2 M13 neXt Gesamtfahrplan/6.2.2 Fahrzeitberechnung (FBZE)
|
||||
> Labels:
|
||||
|
||||
---
|
||||
|
||||
- Fahrzeitberechnung (FBZE) ist kein BusinessService, sondern wird derzeit nur als Bibliothek intern eingebunden.Â
|
||||
- Bibliothek FBZE ist nicht für das Produkt Fahrzeitrechnung geeignet, da dieser nur die Fahrzeiten für bereits existierende, mikroskopische Routen berechnen kann, selbst aber nicht in der Lage ist, ein Routing durchzuführen.
|
||||
- Für den Zweck der Fahrzeitrechnung eignet sich der Kern der automatischen Einzelbelegung hinter C&R besser, wenn dieser ohne den gesetzten Verkehr initialisiert wird. In diesem Fall sucht der Algorithmus eine ideale Strecke und konstruiert diese inkl. Fahrzeiten aus. Für diese Trasse kann dann auch über den Service zur Preisermittlung ein Preis ermittelt werden
|
||||
-
|
||||
WSDL
|
||||
+37
@@ -0,0 +1,37 @@
|
||||
# 7.1.2 Komplettlösung basierend auf Bestandssystemen
|
||||
|
||||
> Confluence Page ID: 27525737
|
||||
> Version: 10
|
||||
> Pfad: /pathOS/Start / Vorstudie Bestellsystem/00_Vorstudie Bestellsystem/7 Umsetzungsalternativen und Bewertung/7.1 make-, buy, re-use-Entscheidungen/7.1.2 Komplettlösung basierend auf Bestandssystemen
|
||||
> Labels:
|
||||
|
||||
---
|
||||
|
||||
Bisher erfolgt die Trassen-Bestellung über  (Trassenfinder und Click-und-Ride App unterstützen nur einige Teilaspekte als Alternative zu TPN). Wie in der folgenden Abbildung vorgestellt, beinhaltet TPN sowohl vertriebliche als auch fahrplanerische Komponenten.
|
||||
|
||||
Durch die Trennung von Fahrplan und Vertrieb könnte die Wiederverwendung, also entweder im Fahrplan oder im Vertrieb, erfolgen. Nachfolgend wird eine Wiederverwendung im Vertrieb betrachtet.
|
||||
Neben der technologischen Aktualisierung von TPN müssen folgende fachliche Anpassungen an TPN vorgenommen werden:
|
||||
- Umsetzung wichtigster Anforderungen im bestehenden Internet Client (Angular Client) und TPN Backend
|
||||
- Anpassungen der Datenmodelle der TPN-UI (z.B. homogene Fahrlagen in TAF/TAP TSI, keine Ergänzungsfahrpläne mehr, netzausgelöste Angebote)
|
||||
- Erheblicher Ausbau der Planungs-Komponenten
|
||||
- Ausbau der Konstruktionsfunktionalitäten
|
||||
- Integration TAF/TAP-TSI in TPN
|
||||
|
||||
-
|
||||
EVU XML und die neue TAF/TAP passen nicht zusammen. 120 Felder aus EVU XML gibt es nicht mehr in TAF/TAP (z.B. VZR und Lokstellungen sind anders).
|
||||
- Die neue Verkehrstageregelung kann nicht ohne Weiteres zurück in eine TPN VZR transformiert werden
|
||||
-
|
||||
Mapping TPN- TAF/TAP- TSI -EVU 4.0 - Evu 2x. oder 3.xÂ
|
||||
- Trennung Vertrieb vom Fahrplan
|
||||
- Anbindung an die neue Konstruktionsschnittstelle
|
||||
|
||||
- Trennung Trasse Zug
|
||||
- Trennung der Prozess-Schritte für Vertrieb und Fahrplan
|
||||
## Bewertung
|
||||
|
||||
Folgende Argumente sprechen gegen die Wiederverwendung von TPN:
|
||||
-
|
||||
Bestellprozess für Trassenprodukte tief integriert mit Produktionssteuerung: Keine Bündelprodukte mit Nicht-Trassenprodukten möglich
|
||||
-
|
||||
Monolithisches System TPN erlaubt keine eigene Governance für die Weiterentwicklung von Prozessen und Systemen in den Domänen Vertrieb respektive Fahrplan
|
||||
Aus diesem Grund findet keine Schätzung dieser Umsetzungsvariante statt.Â
|
||||
+31
@@ -0,0 +1,31 @@
|
||||
# 7.1.1 Komplettlösung - Ergebnisse von APluS
|
||||
|
||||
> Confluence Page ID: 27525741
|
||||
> Version: 18
|
||||
> Pfad: /pathOS/Start / Vorstudie Bestellsystem/00_Vorstudie Bestellsystem/7 Umsetzungsalternativen und Bewertung/7.1 make-, buy, re-use-Entscheidungen/7.1.1 Komplettlösung - Ergebnisse von APluS
|
||||
> Labels:
|
||||
|
||||
---
|
||||
|
||||
Für die Auswahl und die Bewertung der BUY-Umsetzungsalternativen werden zunächst die Ergebnisse des Projekts APluS (siehe unten) betrachtet.Â
|
||||
## Projektauftrag EU-Ausschreibung Kaufsoftware für Planungs- und Steuerungssysteme (APluS)
|
||||
|
||||
Im Zeitraum von 09/2015 bis 08/2016 wurde das Projekt APluS zur âVorbereitung einer EU-Ausschreibung zum Abschluss eines Rahmenvertrages mit den Leistungsfeldern Lizensierung, Wartung, Weiterentwicklung und optional den Betrieb einer Standard-IT-Plattformâ beauftragt (Quelle: BV aus VS 16/2015).
|
||||
Fokus war hierbei: Ausrichtung der IT im Bereich Fahrplan und Betrieb auf einen europäischen Standard âum dem Ziel einer strategischen Weiterentwicklung der DB Netz AG zu einem europäischen Fahrplanersteller und damit Dienstleister von EIU näher zu kommenâ (Quelle: BV aus VS 16/2015) Perspektivische Weiterentwicklung des Standards zu einer releasefähigen, europäischen Plattform für Fahrplan- und Betriebs IT.
|
||||
Der Projektauftrag APluS kann, aufgrund der geringen Abdeckung der Anforderungen am Markt (Ergebnis RFI), nicht erfüllt werden. Daher wurde im 2. Lenkungskreis der Auftrag zur Zerlegung des Scopes in separate Umsetzungspakete und die Erarbeitung von bedarfsgerechten Umsetzungsstrategien erteilt (Rightsizing APluS). Im Rahmen von âRightsizingâ wurden Umsetzungspakete erarbeitet und vom APluS LK am 20.6.2016 beschlossen (vgl. Abbildung).
|
||||
|
||||
|
||||
Bewertungskriterien K-Komplexität der Schnittstelle, R-Risiko, F-Funktionale Ãberlappung: Vorhanden
|
||||
|
||||
Das Umsetzungspaket 2 umfasst die Module der Trassenbestellung (und entspricht im Wesentlichen dem Umfang dieser Vorstudie):
|
||||
- Bestellportal- Browserbasierte Kundenschnittstelle für EVUs zur Anmeldung von Trassen
|
||||
- Bestellschnittstellen -TAF/TAP-TSI-konforme EVU-Schnittstelle und PCS-Schnittstelle
|
||||
- Steuerung Vertriebsablauf - Komponenten zur Steuerung der Vertriebsaktivitäten: AnstoÃen der Produktionsprozesse, Steuerung der Angebotskommunikation, Anbindung der kaufmännischen Systeme und des Archivsystems
|
||||
|
||||
 Der Scope des Projekts Bestellsystem ist eine Untermenge von Bestellportal /Bestellschnittstelle.
|
||||
## Ergebnis APluS
|
||||
|
||||
Unter Punkt 2. Bestellportal/Bestellschnittstelle wurde eine Individualentwicklung empfohlen:
|
||||
- Keine der am Markt verfügbaren Kaufsoftwarelösungen erfüllt die notwendigen Anforderungen der DB Netz
|
||||
-
|
||||
Die Eigenentwicklung- Individualentwicklung einer Lösung für das Bestellsystem und die entsprechenden Schnittstellen nach agilem Vorgehen (SAFe) wurde zwischen I.NM und I.NVI am 07.04.16 beschlossen (4.te Lenkungskreis).
|
||||
+102
@@ -0,0 +1,102 @@
|
||||
# 7.1.4 Technologie- und Plattform-Auswahl
|
||||
|
||||
> Confluence Page ID: 27525745
|
||||
> Version: 18
|
||||
> Pfad: /pathOS/Start / Vorstudie Bestellsystem/00_Vorstudie Bestellsystem/7 Umsetzungsalternativen und Bewertung/7.1 make-, buy, re-use-Entscheidungen/7.1.4 Technologie- und Plattform-Auswahl
|
||||
> Labels:
|
||||
|
||||
---
|
||||
|
||||
Die Eigenentwicklung der Bestellsystem-Services soll im Rahmen einer Microservice-Architektur erfolgen. Die geplanten Microservices sind in der folgenden Grafik dargestellt.
|
||||
|
||||
Die Technologie-Auswahl basiert auf den Empfehlungen des DB Systel Technologie-Radars und ist nachfolgend skizziert:
|
||||
|
||||
Die Auswahl einer geeigneten Plattform für die zu entwickelnden Systeme stellt in diesem Zusammenhang eine kritische Entscheidung dar. Hierfür werden die nachfolgenden Optionen betrachtet:
|
||||
## Plattform-Alternativen
|
||||
|
||||
## AWS
|
||||
|
||||
Amazon Web Services (AWS) ist die Standard-Cloud-Plattform des DB Konzern (vgl. https://db-planet.deutschebahn.com/pages/value-it/apps/content/cloud-db). Das AWS-Angebot enthält zahlreiche Services aus den Bereichen Infrastructure-as-a-Service (IaaS) und Plattform-as-a-Service (PaaS). Diese können flexibel gebucht, kombiniert und konfiguriert werden.
|
||||
So können praktisch alle benötigten Ressourcen, Technologien und Produkte als vorgefertigte bzw. konfigurierbare Dienste in AWS genutzt werden.
|
||||
## Analyse
|
||||
|
||||
Aufgrund des sehr umfangreichen Angebots steigt die Komplexität und für einige Services, auch die Gefahr des Vendor-Lock-Ins bei der Nutzung der AWS-only Features, wie z.B. AWS Lambdas. Ein sicherer, Konzern-Richtlinien konformer, Betrieb ist nur mit viel AWS Know-How, Erfahrung und Aufwand zu bewerkstelligen.
|
||||
Daher ist der reine Betrieb in AWS als aufwendig und riskant anzusehen. Diese Option wird somit nicht weiter in Betracht gezogen. Stattdessen ist der Betrieb in einer vorbereiteten DB-konformen AWS-Umgebung zu bevorzugen. Die dazugehörigen Angebote im DB Konzern werden nachfolgend vorgestellt.
|
||||
## DB Modular Cloud
|
||||
|
||||
Mit der DB Modular Cloud wird ein Infrastructure-as-a-Service Angebot für den Self-Service Cloud-Betrieb angeboten. Dieser umfasst aktuell:
|
||||
- Server-Varianten (Windows 2016, AWS Linux, AWS Linux 2, RedHat Enterprise Linux) in verschiedenen Leistungsklassen
|
||||
- Datenbank-Varianten (PostgreSQL, MariaDB, Oracle SE Two, Microsoft SQL Server SE) in verschiedenen Leistungsklassen
|
||||
- Supportlevel Bronze
|
||||
- Support on Demand
|
||||
|
||||
## Analyse
|
||||
|
||||
DB Modular Cloud bietet lediglich den Service Level Bronze und ist aktuell nicht für den Produktivbetrieb vorgesehen.
|
||||
## DB Container Services
|
||||
|
||||
DB Container Services (DBCS) ist die Containerumgebung der DB Systel. Ein besonderer Schwerpunkt liegt dabei auf der PaaS Platform OpenShift, Buildpipelines und DevOps. DB Container Services setzt auf RedHat OpenShift (RHEL7, Kubernetes, Docker) und beinhaltet die virtuelle Infrastruktur, die OpenShift Console/API und eine Vielzahl von gemanagten Middleware Produkten (Beispielsweise Apache, Tomcat, Jboss, .NET, Javascript, Node.js, Datenbanken, Messaging, etc.).
|
||||
Der Funktionsumfang enthält:
|
||||
|
||||
|
||||
- Einfaches Deployment durch Verwendung von Basistemplates (Apache, Tomcat, Jboss, PHP, etc.) im Self-Service, auf Wunsch werden diese automatisiert gepflegt
|
||||
- Integrierte, standardisierte DevOps Mechanismen
|
||||
- Bedarfsgerechte automatische Skalierung in Sekunden
|
||||
- Eingebaute Hochverfügbarkeit über drei Availibility-Zones für jeden Container
|
||||
- Integriertes zentrales Logfile-Management und Monitoring
|
||||
Die Container Services werden in verschiedenen Varianten angeboten: Shared, Dedicated, Dedicated-Private. Die Unterschiede liegen in der Isolationsebene der OpenShift Installation und der zugehörigen Infrastruktur sowie in den Preismodellen (per-use vs. fix&per-use).
|
||||
Als Service Level wird in der Variante Dedicated neben Bronze auch Gold angeboten.
|
||||
## Analyse
|
||||
|
||||
CTO Container Strategie besagt:Â
|
||||
CTO-Beschluss
|
||||
Neben der im DBCS-Team betriebenen PaaS-Lösung auf Basis von Kubernetes/OpenShift werden weitere PaaS-Lösungen für containerisierte Applikationen nur in Abstimmung mit Portfoliomanagement und der Architekturgilde aufgebaut.
|
||||
Somit ist DBCS (bzw. Business Hub als Aufsatz) die Hauptoption für die Umsetzungsplattform. Allerdings werden einige Zusatzdienste (wie Datenbanken, WorkflowEngines) aktuell nicht von DBCS als Service angeboten.
|
||||
## Business Hub
|
||||
|
||||
Der Business Hub dient als digitale Integrationsplattform des DB Konzerns (siehe https://db-planet.deutschebahn.com/pages/business-hub/apps/content/was-ist-der-business-hub-2):
|
||||
## Eine Plattform für alleÂ
|
||||
|
||||
Durch den Business Hub werden sowohl geschäftsfeldübergreifende, bahninterne APIs, als auch APIs auÃerhalb des Bahnkonzerns miteinander verknüpft, um Ihre Geschäftsprozesse bestmöglich zu unterstützen. Die zentrale Plattformlösung stellt alle Werkzeuge, Bausteine und Services bereit, damit Sie Ihren Weg in digitale Transformation beschreiten können.
|
||||
Auf Basis einer modularen Entwicklung im Baukastenprinzip können Konzernkunden die Plattform zur Erstellung verschiedener Services nutzen, sowie eigene Services am Markt für andere Konzernunternehmen und den externen Markt zur Verfügung stellen. Durch die Nutzung existierender Services profitieren Sie von bestehenden Lösungen anderer Konzerngesellschaften, die auf dem integrierten Marktplatz angeboten werden.
|
||||
Der Business Hub ist der Marktplatz für die Nutzung und den Vertrieb von Daten und Services im Konzern.
|
||||
Es werden unterschiedliche Varianten angeboten:
|
||||
## Business Hub Service Factory
|
||||
|
||||
Die Business Hub Service Factory wird als betriebsfertiger Integrations- und Infrastrukturdienst in der DB Enterprise Cloud zur Verfügung gestellt.
|
||||
Die in der Business Hub Service Factory enthaltenen Top-Features:
|
||||
|
||||
|
||||
- Integration von internen und externen Services auf Basis unterschiedlicher Technologien (REST/SOAP/Streaming)
|
||||
- BPM-Engine zur Orchestrierung mehrerer Services zu einem Service-Bundle
|
||||
- Service-Monetarisierung auf Basis fachlicher Mengen oder Service Contents mit Ãbergabe der Abrechnungsdaten an die DB Konzernsysteme
|
||||
- Identity- & Access-Management (Identity Broker), mit der Möglichkeit auch externe Identity Provider zu integrieren
|
||||
- Deployment Pipeline mit Service Test Management für beliebig automatisierbare Testverfahren (z.B. Integration Tests, Compliance Tests)
|
||||
- Datenbank- und Storage-Services
|
||||
- Hochverfügbare Laufzeitumgebungen inkl. Monitoring
|
||||
Der Service wird wahlweise als SL3-Bronze und SL1-Gold (geplant) angeboten. Die Preise orientieren sich an den darunterliegenden DB Container Services.
|
||||
## Business Hub Connect
|
||||
|
||||
Zur Bereitstellung oder Integration von internen und externen digitalen Produkten und Services (APIs) innerhalb des Konzerns, stellt Business Hub Connect alle dazu benötigten Fähigkeiten in Form einer umfangreichen API-Konnektivitätslösung zur Verfügung.
|
||||
|
||||
|
||||
Das API-Management unterstützt die Veröffentlichung und Monetarisierung von APIs - unabhängig davon, auf welcher Plattform die jeweilige API entwickelt wurde. Die API Management-Fähigkeiten von Business Hub Connect stellen hierfür umfangreiche Funktionen für das Veröffentlichen, Verwalten, Kontrollieren und Auffinden von APIs zur Verfügung.
|
||||
|
||||
|
||||
Die Veröffentlichung der APIs im API-Portal als zentralem Marktplatz für Services ist Bestandteil von Business Hub Connect.Â
|
||||
|
||||
|
||||
Business Hub Connect ist zur Zeit noch in der Betaphase. Die Fähigkeiten sind noch im Aufbau und werden kontinuierlich weiterentwickelt.Â
|
||||
Die wichtigsten Features des API-Managements:Â
|
||||
- API Creation & Delivery Management.
|
||||
- API Lifecycle Management.
|
||||
- API Discovery.
|
||||
- API Analytics.
|
||||
- API Monetization.
|
||||
- API Test Management.
|
||||
- API Support & Community Management.
|
||||
Der Service wird wahlweise als SL3-Bronze und SL1-Gold angeboten.
|
||||
## Analyse
|
||||
|
||||
Prinzipiell bietet Business Hub zusätzliche Dienste zum Angebot der DB Container Services. Die meisten dieser Dienste (BPM-Engine, Identity Management, etc.) werden bereits mit dem Angebot der Service Factory abgedeckt.
|
||||
Zielplattform-abhängige Lieferobjekte (z.B. Dokumentation, Testfälle, o.ä.) oder spezielle Anforderungen an Lieferobjekte (z.B. hinsichtlich Form, Inhalt, Erstellungsprozess), sind im Rahmen des Umsetzungsprojekts vorrangig durch die technischen Architekten zu ermitteln und auszuarbeiten.
|
||||
+49
@@ -0,0 +1,49 @@
|
||||
# 4.4.2 Anbindung von Betriebsstellen/Fahrplanvertrieblicher Stammdaten
|
||||
|
||||
> Confluence Page ID: 27525760
|
||||
> Version: 87
|
||||
> Pfad: /pathOS/Start / Vorstudie Bestellsystem/00_Vorstudie Bestellsystem/4 Anforderungen an das neue Bestellsystem der DB Netz/4.4 Soll-Schnittstellen Bestellsystem (Consumer oder Provider)/4.4.2 Anbindung von Betriebsstellen/Fahrplanvertrieblicher Stammdaten
|
||||
> Labels:
|
||||
|
||||
---
|
||||
|
||||
## Einführung
|
||||
|
||||
Das System zur Bereitstellung von fachlichen Stammdaten, wie etwa Betriebsstellen, Streckenklassen oder Produktmerkmale ist heute die GFD-I, deren Ablösung bis Mitte 2024 geplant ist. Der M15 Infrastrukturmanager wird hier das Nachfolgesystem sein, dass die Daten hält. Die Daten werden domänenspezifisch gepflegt.Â
|
||||
Das Bestellsystem hat unter anderem die Aufgabe, die DB Netz Stammdaten aus Betrieb, Fahrplan und Vertrieb den Schnittstellenkunden bereitzustellen. Hierfür wird es am M15 Infrastrukturmanager eine Schnittstelle geben müssen, die den gesamthaften Datenexport erlaubt und das Bestellsystem in die Lage versetzt, die Daten als xml unseren Kunden zur Verfügung zu stellen.
|
||||
Für den Bestellprozess im Bestellportal werden zunächst vor allem die neuen, europaweit harmonisierten Primary Location Codes (PLC) zu verwenden sein. Diese werden in der Central Reference File Database (CRD) der RNE vorgehalten und sind jeweils durch die National Contact Points für die Einführung der TAF/TAP TSI verwaltet und gepflegt. Das Bestellportal wird für die Eingabe in der grafischen Benutzeroberfläche die Angabe dieser PLC auf Daten der CRD zurückgreifen. Die heutigen RIL100 Codes der DB Netz AG behalten parallel ihre Gültigkeit. Eine Zuordnung zwischen PLC und RIL100-Codes muss durch die Datenhaltung im M15 Infrastrukturmanager geleistet werden. Für die Abkürzungen der Ãrtlichkeiten und Betriebsstellen ist die Ril 100 respektive das AG 850 zuständig (Liegt bei I.NMN). Das Bestellportal muss neben den DB Netz eigenen oder verwalteten Betriebsstellen auch die Eingabe von Betriebsstellen aus Fremdinfrastrukturen im In- und Ausland unterstützen, da diese im Rahmen der Train-Information abgebildet werden müssen.Â
|
||||
## Stammdaten aus dem Infrastrukturmanager M15 sind:
|
||||
|
||||
BetriebsstellenListeÂ
|
||||
- Diese Auflistung enthält alle Betriebsstellen der DB Netz, die in ausgetauschten Nachrichten unter Beachtung der jeweils aktuell gültigen Schnittstellendokumentation enthalten sein dürfen. Die Betriebsstellen sind als PrimaryLocationCode (TAF/TAP Format) hinterlegt, bei Konstruktion auf fremder Infrastruktur ggf. auch nicht DB Netz eigene Betriebsstellen. Teilweise müssen Betriebsstellen auch als SubsidiaryCodes (TAF/TAP Format) vorliegen, dies ist bei Betriebsstellen der Fall, die z.B. eine Fahrplanbearbeitungsgrenze darstellen oder Bahnhofsteile einer groÃen Betriebsstelle (Mutterbahnhof) sind.
|
||||
StreckenListeÂ
|
||||
- Diese Auflistung enthält streckenweise (gleiche Zahl in Spalte "Strecke") in aufsteigender Kilometrierungsrichtung alle der Strecke zugeordneten Betriebsstellen (PrimaryLocationCodes, SubsidiaryCodes). Die versetzte Darstellung von Betriebsstellen bei zweigleisigen Strecken gesondert für die Hin- und Gegenrichtung entsprechend der Kilometrierungsrichtung sowie für das Richtungs- und Gegenrichtungsgleis ergibt sich aus der Wirkrichtung von Signalstandorten bzw. Halteplätzen.Â
|
||||
Für die Angabe in der Trassenbestellung bzw. im Angebot ist diese Unterscheidung nicht relevant, die Betriebsstelle selbst existiert unabhängig von der angegebenen Wirkrichtung in beiden Richtungen.
|
||||
StreckenklassenListeÂ
|
||||
- Diese Auflistung enthält alle aktuell bestellbaren Streckenklassen.
|
||||
ZuggattungsListeÂ
|
||||
- enthält alle aktuellen Zuggattungen.
|
||||
ZugausruestungsListeÂ
|
||||
- enthält Angaben für Attribute zur Beschreibung der technischen Ausrüstung des Zuges.
|
||||
Verkehrstageschlüssel
|
||||
- Evtl. für Anbindung als Schnelleingabefunktion; grundsätzlich werden in der fachlichen Kommunikation keine Verkehrstageschlüssel mehr verwendet
|
||||
(Funktionsweise Bitleiste https://wiki.intranet.deutschebahn.com/wiki/display/neXtlab/Umrechnung+TPN+Verkehrszeitregelung+in+diskrete+Verkehrstageregelung)
|
||||
TriebfahrzeugListe
|
||||
- enthält die Baureihen und -varianten sowie deren Beschreibung für alle aktuellen Triebfahrzeuge.  Fachliche Betriebsführer und Ansprechpartner: Andreas Hahn.Â
|
||||
Tfz Leerfahrt
|
||||
- Diese Tabelle enthält die Angaben zur Unterscheidung bei der Durchführung einer Zugfahrt bzw. eines Zugfahrtabschnittes als Tfzfahrt bzw. als Leerreisezug. (Tfzf und Leer_Rz)
|
||||
Betriebstellendaten, DB Netz-eigen
|
||||
- Verortung und Festlegung der Handoverpoints (zwischen zwei EIU vereinbarter Ãbergabepunkt hinsichtlich der Zuständigkeit für die Trassierung und Betriebsdurchführung) und Netzgrenze auf der Infrastruktur
|
||||
- Das AbrechnungsCockpit-Trasse und RuT-K neu müssen erkennen können, ob Abschnitte zwischen Handoverpoint und Netzgrenze konstruktionsrelevant, abrechnungsrelevant und Veröffentlichungsrelevant relevant ist. Die entsprechenden Informationen müssen im Infrastrukturdatenmodell bei den Streckenabschnitten hinterlegt sein und bei der Infrastrukturdatenpflege (Infrastrukturmanger (IM)) erfasst werden.Â
|
||||
|
||||
|
||||
Verkehrsart Kunde Zusatz (enthält die Attribute der gewählten Produktart)
|
||||
- Charterverkehr (nur für Züge mit maximal 30 Verkehrstagen bestellbar; nur im Gelegenheitsverkehr für Züge des SPV; Zuglaufpunkte mit bestelltem Verkehrshalt müssen mit einem erfassbaren Haltegrund bestellt werden)
|
||||
- Nostalgieverkehr (nur für Züge mit maximal 30 Verkehrstagen bestellbar; nur im Gelegenheitsverkehr für Züge des SPV)
|
||||
- Punkt-zu-Punkt-Verkehr (nur in Kombination mit einer Flexibilität = âZF 30â bestellbar; Bestellung ist dann sowohl zum Netzfahrplan als auch im Gelegenheitsverkehr für den SPV erlaubt â unter âWeitere Angabenâ dürfen keine AnschluÃbeziehungen bestellt sein â max. 130 km/h Durchschnittsgeschwindigkeit)
|
||||
Verkehrsart KundeÂ
|
||||
- Diese Tabelle enthält die Angaben zur Unterscheidung der Verkehre gemäà Trassenpreissystem 2017. Die Angaben sind Schienengüterverkehr (SGV), Schienenpersonennahverkehr (SPNV), Schienepersonenfernverkehr (SPFV). Â
|
||||
Betriebliche Priorisierung
|
||||
- Diese Tabelle enthält die Angaben; sehr hohe Prio SPFV- Express, erhöhte Prio SGV-Schnell und sehr hohe Prio SGV-Express zur Unterscheidung der Priorität in der betrieblichen Disposition der Zugtrassen.
|
||||
Flexibilität
|
||||
- enthält die Attribute der vom Kunden gewünschten Flexibilität für die Konstruktion.  Zur Steigerung der Flexibilität in der Trassenkonstruktion für den Netzfahrplan im Güterverkehr (also nicht im Gelegenheitsverkehr) kann der Kunde die Option âräumliche Flexibilitätâ (RF 120) bestellen. Flexibilität gilt für den gesamten Zuglauf innerhalb des Konstruktionsbereiches der DB Netz. Räumliche Flexibilität darf nicht bestellt werden wenn der gesamte Zuglauf eine Tfz-Fahrt ist â in Zusammenhang mit der Bestellung von Pre-arranged Paths (PaPs) über PCS (gilt auch für âNebenprodukteâ der PaPs wie Feeder/Outflow oder Tailormade-Trassen) â wenn die Trassenbestellung auf eine RV-Kapazität referenziertReferenziert eine Schienengüterverkehr-Anmeldung zum Netzfahrplan auf eine RV-Kapazität, muss der mit der bestellten räumlichen Flexibilität gewählte zeitliche Konstruktionsspielraum kleiner oder gleich der Bandbreite der referenzierten RV-Kapazität sein
|
||||
+28
@@ -0,0 +1,28 @@
|
||||
# 4.4.3 Anbindung EVUs an DB Netz TSI konforme Bestellschnittstelle
|
||||
|
||||
> Confluence Page ID: 27525769
|
||||
> Version: 14
|
||||
> Pfad: /pathOS/Start / Vorstudie Bestellsystem/00_Vorstudie Bestellsystem/4 Anforderungen an das neue Bestellsystem der DB Netz/4.4 Soll-Schnittstellen Bestellsystem (Consumer oder Provider)/4.4.3 Anbindung EVUs an DB Netz TSI konforme Bestellschnittstelle
|
||||
> Labels:
|
||||
|
||||
---
|
||||
|
||||
Es wird eine technische Schnittstelle in Form eines WebService (âCI_Planning_DBNetzâ genannt) zum Austausch von Nachrichten im Kontext von Vorgängen zur Trassenanmeldung zwischen dem EVU-System und dem Bestellsystem der DB Netz implementiert werden. Diese Schnittstelle ersetzt die bisherige EVU-Schnittstelle der DB Netz und wird den zukünftigen TAF/TAP-TSI konformen Nachrichtenaustausch zwischen den beteiligten Bahngesellschaften realisieren.
|
||||
Die Implementierung der Schnittstelle (TAF/TAP TSI Common Interface) erfolgt gemäà der CI-Spec der RNE (RailNetEurope) und ist über den Link http://ccs.rne.eu/common-interface/ abrufbar.
|
||||
Das TAF/TAP TSI Common Interface der DB Netz ("CI_Planning_DBNetz") kann nur die für das EVU und für den Trassenbestell- und Zuweisungsprozess erforderlichen TAF/TAP-TSI Nachrichten verarbeiten. Konkret sind dies die folgenden TAF/TAP TSI standarisierten Nachrichtentypen:
|
||||
- PathRequestMessage
|
||||
- PathConfirmedMessage
|
||||
- PathDetailsRefusedMessage
|
||||
- PathCanceledMessage
|
||||
- ReceiptConfirmationMessage
|
||||
- ErrorMessage
|
||||
- ObjectInfoMessage
|
||||
- UpdateLinkMessage
|
||||
Umgekehrt erfordert eine peer-to-peer Kommunikation per WebService, dass jedes EVU, welches über CI_Planning_DBNetz mit dem Bestellsystem der DB Netz kommunizieren möchte, ebenfalls einen WebService bereitstellt. Dieser WebService muss sich ebenfalls nach der TAF/TAP-TSI Spezifikation richten. Er muss die notwendigen Aspekte der CI-Spec implementieren. Die DB Netz sieht eine Versendung der nachfolgenden Nachrichtentypen an die EVU vor.
|
||||
- PathDetailsMessage
|
||||
- PathNotAvailableMessage
|
||||
- ReceiptConfirmationMessage
|
||||
- ErrorMessage
|
||||
- ObjectInfoMessage
|
||||
- UpdateLinkMessage
|
||||
## Systemkontext
|
||||
+30
@@ -0,0 +1,30 @@
|
||||
# 4.4.4.2 M13 Click&Ride Integration und Anbindung
|
||||
|
||||
> Confluence Page ID: 27525778
|
||||
> Version: 36
|
||||
> Pfad: /pathOS/Start / Vorstudie Bestellsystem/00_Vorstudie Bestellsystem/4 Anforderungen an das neue Bestellsystem der DB Netz/4.4 Soll-Schnittstellen Bestellsystem (Consumer oder Provider)/4.4.4 Anbindung an den Fahrplan und das Kapazitätsmanagement/4.4.4.2 M13 Click&Ride Integration und Anbindung
|
||||
> Labels:
|
||||
|
||||
---
|
||||
|
||||
## Einführung
|
||||
|
||||
Grundsätzlich muss hier in der Begrifflichkeit zwischen dem Verfahren Click&Ride und dem gleichnamigen Produkt differenziert werden.Â
|
||||
## Das Verfahren Click&Ride
|
||||
|
||||
Die Integration des Verfahrens Click&Ride beschäftigt sich mit der technischen wie prozessualen Integration der Click&Ride App mit ihren Funktionalitäten in das neue Bestellsystem. Heute arbeitet Click&Ride mit einer eigenständigen Middleware, die aus Objekten im Click&Ride-Objektmodell (CROM) Objekte in ITOM erzeugt und diese an der neXt Schnittstelle zur technischen Prozessteuerung direkt in den Prozess zur automatischen Konstruktion einkippt.Â
|
||||
Mit Integration in das neue Bestellsystem wird Click&Ride künftig Aufträge, die aus der App erzeugt werden, an die Komponente SteuerungVertriebsAblauf übergeben. Dazu muss die Objektumwandlung von CROM zu ITOM auf CROM zu TAF/TAP-nah erfolgen. Das Messaging-Konzept aus TAF/TAP kann für die App-Version von Click&Ride vernachlässigt werden, da die Nachrichtenabfolge in Click&Ride fachlich ausreichend ist und keine Drittsysteme integriert werden müssen.
|
||||
|
||||
Durch die prozessuale Integration von Click&Ride in die Komponente SteuerungVertriebsAblauf wird künftig eine Statusüberwachung über das Bestellportal auch für Vorgänge möglich sein, die in der Click&Ride App ausgelöst wurden. Eine Annahme von Click&Ride-Angeboten, die über die Click&Ride-App angefragt wurden soll dabei im ersten Schritt aber nicht implementiert werden. Die Vertragsverwaltung von aus der Click&Ride-App bestellten Vorgängen wird aber nahtlos gemäà TAF/TAP TSI-Prozessen über das Bestellportal und die TAF/TAP-Schnittstelle möglich sein.
|
||||
## Das Produkt Click&Ride
|
||||
|
||||
Das Produkt Click&Ride wird neben dem Auslösen von Anfragen über die Click&Ride-App, zukünftig auch aus dem Bestellportal heraus und über das Common Interface auslösbar sein. Hierzu wurde der Prozess "Kurzfristige Trassenberatung mit Buchungsoption" definiert und in der Schnittstellenbeschreibung für die neue TAF/TAP TSI Schnittstele dokumentiert. Der gesonderte Prozess ist erforderlich, um dem juristischen Charakter einer Click&Ride-Anfrage gerecht zu werden. Anfragen in Click&Ride gelten als eine Form der Trassenberatung, die im Einzelfall zur Buchung führen kann. Hierfür wird das Konstruktionsergebnis aus der Trassenberatung mit Click&Ride für 10 Minuten als belegte Trasse reserviert und ist für den Kunden, der die Trassenberatung angefordert hat mit Annahmeverzicht buchbar. Um dieses Produkt möglichst breitgefächert zur Nutzung zu bringen, wurde ein Prozess mit TAF/TAP-konformen Messages definiert, der dies bewusst auch Schnittstellenkunden ermöglicht.
|
||||
## Die Kapazitätsabfrage (Nicht MVP)
|
||||
|
||||
Die Fähigkeiten hinter Click&Ride sollen auÃerdem in einem weiteren Feature einem Kundennutzen zugeführt werden: die Kapazitätsabfrage. Diese ermöglicht dem Kunden im Bestellportal, eine beliebige Anmeldung testweise in den Fahrplankonstruktionskern zu senden, ohne dass dies einen Anmeldungscharackter hat. Im Unterschied zur Fahrzeitberechnung erhält der Kunde auf seine Anfrage dann eine konkrete Trassenkonstruktion unter Berücksichtigung der bekannten Infrastrukturauslastung. Technisch ist eine Kapazitätsabfrage kaum von einer Click&Ride-Anfrage zu unterscheiden, es gibt aber erhebliche fachliche Unterschiede:
|
||||
- Eine Kapa-Abfrage kann auch erfolgen, wenn eine automatische Veröffentlichung nicht erfolgen kann
|
||||
- Eine Kapa-Anfrage ist nicht an die Beschränkung der Fristigkeit von Click&Ride gebunden, sondern kann auch mit mehreren Tagen oder Wochen Vorlauf erfolgen
|
||||
- Eine Kapa-Abfrage kann ggf. auch dann erfolgen, wenn technische Sachverhalte eine automatische Konstruktion eigentlich nicht zulassen (z.B. aktuell: KV-Profil)
|
||||
- Eine Kapa-Abfrage erzeugt keine persistente Trassierung bzw. Reservierung, sondern gibt ausschlieÃlich Auskunft über eine individual nutzbare Kapazität für den angefragten Sachverhalt zum Zeitpunkt der Anfrage
|
||||
Kunden bekommen so eine Einschätzung für die zu erwartende Netzauslastung zum gewünschten Fahrtzeitpunkt und können Ihren Kunden wiederum entsprechend angepasste Angebote unterbreiten. Die Kapazitätsauskunft gibt dabei keine Auskunft darüber, welche Kapazitäten durch wen belegt sind, sondern eine unverbindliche Positivauskunft darüber, wie eine Trassierung eines konkreten Zuges aussähe/aussehen könnte, wenn diese aktuell angefragt würde. Da eine Kapazitätsabfrage keinen Vertriebsprozess darstellt, ist angedacht diese zwischen Bestellportal und Click&Ride Belegungskern direkt, ohne Umweg über die Komponente SteuerungVertriebsAblauf, anzubinden. Die Informationsauskunft wird zunächst ausschlieÃlich über das Bestellportal abrufbar sein.
|
||||
Der Prozess für die kurzfristige Fahrplagenberatung mit Buchungsoption (KFB) ist im EVU SST Hauptdokument (Abbildung 12: Geschäftsvorfallfolgen â Kurzfristige Fahrlagenberatung mit Buchungsoption) einsehbar.
|
||||
+19
@@ -0,0 +1,19 @@
|
||||
# 4.4.4 Anbindung an den Fahrplan und das Kapazitätsmanagement
|
||||
|
||||
> Confluence Page ID: 27525780
|
||||
> Version: 93
|
||||
> Pfad: /pathOS/Start / Vorstudie Bestellsystem/00_Vorstudie Bestellsystem/4 Anforderungen an das neue Bestellsystem der DB Netz/4.4 Soll-Schnittstellen Bestellsystem (Consumer oder Provider)/4.4.4 Anbindung an den Fahrplan und das Kapazitätsmanagement
|
||||
> Labels:
|
||||
|
||||
---
|
||||
|
||||
## EinleitungÂ
|
||||
|
||||
Folgende Schnittstellen (Services/Komponeten) aus der fachlichen Domäne: âKapazitäts-und Fahrplanmanagementâ werden an das neue System angebunden oder mit integriert.Â
|
||||
Die Schnittstellenbeschreibung bzw. Servicebeschreibungen sind Bestandteil der funktionalen Systemdokumentation und stellt allen Betroffenen die fachlichen Informationen zur Verfügung.
|
||||
## Ausschnitt aus dem Systemkontext des Bestellsystems
|
||||
|
||||
|
||||
|
||||
|
||||
In den folgenden Unterkapiteln sind zu den primären Soll-Schnittstellen noch weiterführende Informationen dokumentiert.
|
||||
+230
@@ -0,0 +1,230 @@
|
||||
# 4.4.4.1 Neues Konstruktionssystem (Projekt BaDiFa)
|
||||
|
||||
> Confluence Page ID: 27525784
|
||||
> Version: 42
|
||||
> Pfad: /pathOS/Start / Vorstudie Bestellsystem/00_Vorstudie Bestellsystem/4 Anforderungen an das neue Bestellsystem der DB Netz/4.4 Soll-Schnittstellen Bestellsystem (Consumer oder Provider)/4.4.4 Anbindung an den Fahrplan und das Kapazitätsmanagement/4.4.4.1 Neues Konstruktionssystem (Projekt BaDiFa)
|
||||
> Labels:
|
||||
|
||||
---
|
||||
|
||||
## EinführungÂ
|
||||
|
||||
Durch die Trennung Fahrplan <> Vertrieb wird das Verhältnis zwischen Kundenauftrag und Konstruktionsauftrag stärker formalisiert () Heute ist beides in einer Datenbank in TPN integriert und wird nicht weiter differenziert.
|
||||
Die Bestellsystem-Komponente SteuerungVertriebsAblauf verwaltet den Kundenauftrag und übergibt die Produktionsaufträge an die Fahrplan-Schnittstelle mit der dahinter stehenden Komponente SteuerungKonstruktionsAblauf. Dort werden fahrplanintern Arbeitsaufträge an die manuelle oder die automatische Fahrplankonstruktion geschnitten. Nach Fertigstellung der Konstruktion übergibt SteuerungKonstruktionsAblauf die Konstruktionsergebnisse über die Vertriebsschnittstelle zurück an SteuerungVertriebsAblauf. Der Produktionsauftrag ist damit abgeschlossen.Â
|
||||
SteuerungVertriebsAblauf bereitet nun die vom Kunden erwartete Nachricht für den Versand vor und gibt diese über das DB Netz Common Interface oder das Bestellportal an den Kunden. Ebenso werden Buchungsbestätigungen, Stornierungen und Ãnderungen über SteuerungVertriebsAblauf aus dem Vertrieb an den Fahrplan übergeben und dort verarbeitet. Der Abschluss der Verarbeitung wird in TAF/TAP TSI auch wieder zurück an den Kunden gespiegelt, so dass Kunde, Vertrieb und Fahrplan jeweils den aktuellen Status aller Vorgänge bestätigt vorliegen haben. Der Vertrieb hält dabei die Hoheit an den Daten zum Vertriebsvorgang, während dem Fahrplan die Datenhoheit über die Trassenverwaltung obliegt. Die veränderte systemische Abbildung zwischen Vertrieb und Fahrplan verändert dabei grundsätzlich nicht die Geschäftsprozesse zum Kapazitätsmanagement.Â
|
||||
Das neue Bestellsystem wird keine Schnittstelle zur Veröffentlichung enthalten, da die Veröffentlichung von Fahrplanunterlagen unmittelbar aus der Trassenverwaltung heraus auszulösen ist.
|
||||
## SchnittstellenkontextÂ
|
||||
|
||||
|
||||
|
||||
|
||||
|
||||
|
||||
## Schnittstellenspezifikation (Operationen)
|
||||
|
||||
| |
|
||||
## Service/Komponente
|
||||
|
|
||||
## Â Â Kurzbeschreibung
|
||||
| Bild aus EAM |
|
||||
## Kommentar
|
||||
|
||||
| |
|
||||
FahrplanSchnittstelle
|
||||
erteileFahrplanKonstruktionsAuftrag
|
||||
bucheFahrplanKapazität
|
||||
freigabeFahrplanKapazität
|
||||
aendereFahrplanKonstruktionsAuftrag
|
||||
zurückziehenFahrplanKonstruktionsAuftrag
|
||||
verarbeiteFehlerNachricht
|
||||
verarbeiteteAngebotsAnfrageStornierung
|
||||
|
||||
|
||||
|
||||
|
|
||||
Fahrplan Schnittstelle - Angebotsdaten ( Angebotsanfragen) werden direkt über die neue RUT-K Schnittstelle (SteuerungKonstruktionsablauf) an die SteuerungVertrieb übertragen. Weitere Spezifikationen (Erhaltene Operationen, Verwendete Schnittstellenobjekte) werden in der Schnittstellenbeschreibung Bestellsystem- RUT-K neu beschrieben. |
|
||||
|
|
||||
|
||||
|
||||
|
||||
|
||||
| |
|
||||
Vertriebsschnittstelle
|
||||
verarbeiteVertragsAngebot
|
||||
verarbeiteBuchungsbestaetigung
|
||||
verarbeiteNetzausgeloestesVertragsAngebot
|
||||
verarbeiteGebuchteTrasseNichtVerfuegbar
|
||||
verarbeiteFehlerNachricht |
|
||||
Vertriebsschnittstelle - VertragsAngebote, Buchungsbestätigungen und Netz-ausgelöste Vertragsänderungen werden von Seiten des Fahrplans über diese Schnittstelle an den Vertrieb (Bestellsystem) übergeben. |
|
||||
|
|
||||
ErrorMessage
|
||||
AngebotsAnfrage
|
||||
Buchungsbestätigung
|
||||
NetzausgelösteAenderung
|
||||
| |
|
||||
OTN-Generator
|
||||
pruefeOperationalTrainNumber
|
||||
pruefeKundennummermitEigenemOTNKontingent
|
||||
erzeugeOperationalTrainNumber
|
||||
|
||||
|
||||
|
||||
|
||||
|
||||
|
||||
|
||||
|
|
||||
Prüfe ob ein Kunde ein Zugnummernkontingent besitzt, prüfe ob die vom Kunden angegebene Zugnummern zu seinem Kontingent gehört und frei ist.
|
||||
|
||||
|
|
||||
|
|
||||
OTN und parallel Betrieb Zugnummerngenerator (TPN) Hinweis: Für eine gewisse Zeit wird es 2023 zu einem parallel Betrieb Zugnummerngenerator (Fahrplanjahr 2023) und OTN-Generator (Fahrplanjahr 2024) geben.
|
||||
|
||||
|
||||
|
||||
|
||||
## Datenmodell Schnittstelle Bestellsystem- BaDiFa
|
||||
|
||||
Als Grundlage wird das Objektmodell TAF-TAP- TSI verwendet (Anlage 1 der EVU SST und das TAF/TAP TSI Konzept). Das fachliche Objektmodell des Vertriebs mit AngebotsAnfrage, VertragsAngebot und ProduktVertrag wird annähernd auf die TAF/TAP Objekte PathRequestMessage und PathDetailsMessage abgebildet. Steuernde Informationen für den Fahrplan werden in den übergreifenden Objekten modelliert. Das fachliche Objektmodell des Fahrplans mit den Objekten FahrplanKonstruktionsAuftrag und FahrplanKapazität wird ebenfalls annähernd auf die TAF/TAP Objekte PathRequestMessage und PathDetailsMessage abgebildet.
|
||||
Die noch auszudetaillierenden Objekte und deren Befüllungsregeln werden zu Beginn des Implementierungsprojekts bestimmt und umgesetzt.
|
||||
|
||||
## Nichtfunktionale Aspekte
|
||||
|
||||
| |
|
||||
Vertraulichkeit |
|
||||
|
||||
11
|
||||
incomplete
|
||||
 sehr hoch
|
||||
|
||||
|
||||
12
|
||||
complete
|
||||
 hoch
|
||||
|
||||
|
||||
13
|
||||
incomplete
|
||||
 mittel
|
||||
|
||||
|
||||
14
|
||||
incomplete
|
||||
 niedrig
|
||||
|
||||
|
||||
| |
|
||||
Integrität |
|
||||
|
||||
15
|
||||
incomplete
|
||||
 sehr hoch
|
||||
|
||||
|
||||
16
|
||||
complete
|
||||
 hoch
|
||||
|
||||
|
||||
17
|
||||
complete
|
||||
 mittel
|
||||
|
||||
|
||||
18
|
||||
incomplete
|
||||
 niedrig
|
||||
|
||||
|
||||
Â
|
||||
| |
|
||||
Verfügbarkeit
|
||||
| |
|
||||
Robustheit der Schnittstelle |
|
||||
 Keine Anforderungen.
|
||||
 Folgende Anforderungen: | Kommentar
|
||||
| |
|
||||
Servicelevel |
|
||||
|
||||
31
|
||||
incomplete
|
||||
 SL 1 Plus
|
||||
|
||||
|
||||
32
|
||||
incomplete
|
||||
 SL 1
|
||||
|
||||
|
||||
33
|
||||
complete
|
||||
 SL 1 Basic
|
||||
|
||||
|
||||
34
|
||||
incomplete
|
||||
 SL 2
|
||||
|
||||
|
||||
35
|
||||
incomplete
|
||||
 SL 3 Plus
|
||||
|
||||
|
||||
36
|
||||
incomplete
|
||||
 SL 3
|
||||
|
||||
|
|
||||
|
||||
|
||||
 |
|
||||
| |
|
||||
Logging
|
||||
| |
|
||||
Anforderung an Logging |
|
||||
alle anmelderelevanten Vorgänge sind zu loggenÂ
|
||||
 |
|
||||
| |
|
||||
Ãbertragungsverfahren
|
||||
| |
|
||||
Schnittstellenart |
|
||||
|
||||
37
|
||||
incomplete
|
||||
 Datenablage in Datei, Pfad: manuelle Festlegung
|
||||
|
||||
|
||||
38
|
||||
complete
|
||||
 Webservice/Rest-API:Â
|
||||
|
||||
|
||||
39
|
||||
incomplete
|
||||
 SMS-Nachricht, Nummer:
|
||||
|
||||
|
||||
40
|
||||
incomplete
|
||||
 gemeinsame Datenbank:
|
||||
|
||||
|
||||
41
|
||||
incomplete
|
||||
 Online-Transaktion:
|
||||
|
||||
|
||||
42
|
||||
incomplete
|
||||
 Andere: Dateiversand via Email
|
||||
|
||||
|
||||
| |
|
||||
Transaktionssicherheit |
|
||||
 Keine Anforderungen.
|
||||
 Folgende Anforderungen:
|
||||
| |
|
||||
Art der Datenübertragung |
|
||||
HTTP
|
||||
 Â
|
||||
+1661
File diff suppressed because it is too large
Load Diff
+64
@@ -0,0 +1,64 @@
|
||||
# 6.3 Initiative Einfachbahn
|
||||
|
||||
> Confluence Page ID: 27525791
|
||||
> Version: 28
|
||||
> Pfad: /pathOS/Start / Vorstudie Bestellsystem/00_Vorstudie Bestellsystem/6 IT Ist-Analyse/6.3 Initiative Einfachbahn
|
||||
> Labels:
|
||||
|
||||
---
|
||||
|
||||
6.3.1 Initiative Einfachbahn
|
||||
Im Rahmen der Initiative Einfachbahn hat der Vertrieb der DB Netz AG verschiedene Angebote entwickelt, die durch prototyphafte Umsetzung schnell unseren Kunden und Partnern zur Verfügung gestellt werden konnten. Einige dieser Angebote/Produkte unterstützen auch mittelbar das Thema Zugfahrt bzw. Planung einer Zugfahrt. Hier gilt zu prüfen, inwieweit IT-Lösungen der Einfachbahn als integriertes Angebot im Bestellportal Mehrwert schaffen können. Dabei besteht keine Möglichkeit, Komponenten des Trassenfinder direkt zu übernehmen: Die fachlichen Komponenten des Trassenfinder werden nicht durch die Fachbereiche selbst bereitgestellt, sondern sind parallel durch Fachexperten der Einfachbahn kuratiert. Die IT ist auÃerdem ohne Abstimmung des CIO-Bereichs entstanden - eine bewusste Strategie, um schnell prototypische Lösungen entwickeln zu können. Das führt aber im Umkehrschluss dazu, dass die Lösungen nicht im produktiven Einsatz verwendet werden können. Die Konzepte der Einfachbahn-Angebote wären daher im Rahmen des Bestellportals unter Einbeziehung des CIO-Bereichs und Anbindung von Services der fachlichen Owner nachzubauen.
|
||||
Die Produkte, die dafür zu betrachten sind, sind im Einzelnen:
|
||||
- Trassenfinder
|
||||
- Strecken.info
|
||||
- GreTa
|
||||
- MaTeo
|
||||
## 6.3.1.1 Trassenfinder
|
||||
|
||||
## Funktionen
|
||||
|
||||
Der Trassenfinder ermöglicht die Routenplanung im Netz der DB. Der Nutzer kann unter Auswahl des Fahrplanjahrs, Angabe von Start, Ziel und Zugeigenschaften Routenvorschläge erhalten, die für die Anmeldung eines Zuges herangezogen werden können. Es besteht auÃerdem die Möglichkeit, durch Ausschluss einzelner Streckenabschnitte die Ergebnisse nutzerseitig zu beeinflussen. Neben Laufwegen in mehreren Varianten gibt der Trassenfinder auÃerdem Prognosen zum Trassenentgelt, zum Energieverbrauch und zur Fahrzeit ab.
|
||||
Im nachfolgenden Dokument ist die Funktionalität des heute verfügbaren Trassenfinders detailliert beschrieben: ; Ein öffentlich zugänglicher Link zur Anwendung befindet sich im Internet unter folgender Adresse: www.Trassenfinder.deÂ
|
||||
## Bewertung
|
||||
|
||||
Der Mehrwert für die Zugplanung ist unbestreitbar. Die angebotenen Informationen unterstützen den Kunden in jeder Zugplanung unmittelbar. Eine Integration der Kernfunktionen ist im Bestellportal daher bereits im Rahmen des Minimal Viable Product (MVP) zu sehen.
|
||||
## Konzeptansatz
|
||||
|
||||
Die fachliche Abbildung mit Services der Fachabteilung ist in diesem Fall einfach konzipierbar, da im Rahmen des Projekts neXt Digitale Kapazitätssteigerung mit der Routensuche und dem Fahrt- und BelegungsZeitErmittlungsservice (FBZE) die wesentlichen Kernkomponenten für Routing und Fahrzeitberechnung bereits vorliegen. Die erforderliche Eingabe von Planungsinformationen ist in der Trassenplanung und -anmeldung sowieso teil des Bestellportals, so dass sich die Routensuchfunktionen nahtlos in den Nutzerprozess einbinden lassen.
|
||||
Für die Prognose von Trassenentgelten werden Services des Abrechnungscockpit (AC Trasse) angebunden, die neben der reinen Entgeltprognose auch eine Produktzuordnung zurückliefern werden. Somit kann der Nutzer auch erkennen, wie sich das prognostizierte Trassenentgelt zusammensetzt und inwieweit die Zugplanung im beabsichtigten Produktsegment einordnungsfähig ist.
|
||||
## 6.3.1.2 Strecken.info
|
||||
|
||||
## Funktionen
|
||||
|
||||
Die DB Netz AG ist bestrebt seine Zugangsberechtigte kontinuierlich über aktuelle Einschränkungen der Infrastruktur zu informieren. Dazu werden dazu die unterjährigen BaumaÃnahmen der nächsten 70 Tage dem Kunden als pdf-Datei in Form der 12-Wochen-Vorschau (http://fahrweg.dbnetze.com/fahrweg-de/technik/baustelleninformation/bauschwerpunkte.html) zur Verfügung gestellt. Diese wird durch Strecken.Info durch eine interaktive Karte im Internet ergänzt, wobei die Granularität und der Inhalt der Informationen der 12-Wochen-Vorschau beibehalten wird. Strecken.Info bietet auÃerdem über einen Login eine Anbindung an den kostenpflichtigen Service LiveMaps.
|
||||
## Bewertung
|
||||
|
||||
Eine Integration der Funktionen von Strecken.Info und ggf. LiveMaps ist stark erstrebenswert. Für die Planung von Zugfahrten im Gelegenheitsverkehr können die Informationen dem Kunden einen erheblichen Mehrwert bieten. Kunden im Netzfahrplan können die Informationen hingegen nicht nutzen. Aufgrund der Begrenzung der Anwendbarkeit und der erwarteten Komplexität der Einbindung der beiden Angebote Strecken.Info und LiveMaps, wird eine Integration im Rahmen des MVP nicht angestrebt.
|
||||
## Konzeptansatz
|
||||
|
||||
 - keine Umsetzung im Rahmen des MVP -
|
||||
## 6.3.1.3 GreTa
|
||||
|
||||
## Funktionen
|
||||
|
||||
GreTa ermöglicht dem Nutzer, unter Angaben von Traktion und Laufweg, die Anzeige von Regelgrenzlasten. Dabei bietet GreTa einen Lookup-Service, der die statischen Regelgrenzlasttabellen durchforstet und die Regelgrenzlast sowie die grundsätzliche Machbarkeit einer gesicherten Durchfahrt Streckenabschnittsweise ausgibt. Die begrenzende und jeweils nächste limitierende Grenzlast werden dabei farblich Hervorgehoben. GreTa bietet für angemeldete Nutzer auÃerdem die Möglichkeit der Beantragung einer Einzelgrenzlastberechnung.
|
||||
## Bewertung
|
||||
|
||||
Eine Einbindung von GreTa in den Prozess der Planung einer Zugfahrt wäre im Wesentlichen für Güterverkehrskunden wünschenswert, wird aber nicht zwingend als MVP bewertet.
|
||||
## Konzeptansatz
|
||||
|
||||
Die grundsätzliche Prüfung und Einhaltung von Grenzlasten erfolgt auch in der neXt Routensuche. Der dahinter stehende Service (Grenzlastbereitstellung) gibt zu allen Streckenabschnitten die gültige Grenzlast zurück. Das Mapping auf die Infrastruktur wird derzeit aufwändig in der neXt Routensuche vorgenommen. Eine Nutzung für das Bestellportal ist zwar grundsätzlich vorstellbar, erscheint aber sehr aufwändig. Parallel wurde durch das Projekt BaDiFa bei I.NMN 1 angestoÃen, die Einrichtung eines echten Grenzlastberechnungsservice zu avisieren, da die heutige Praxis der Grenzlastermittlung in den Regionalbereichen hohe Ineffizienzen aufweist.Â
|
||||
Aufgrund der Kann-Bewertung der Integration von GreTa, wird die fachliche Anbindung hier zunächst nicht näher spezifiziert, da hier ggf. der Leistungsfähigste Service mit den besten Ergebnissen zu gegebener Zeit ausgewählt wird. Der Verzicht auf eine Integration stellt ebenfalls im Rahmen des MVP einen möglichen Ausgang dar, wenn beispielsweise auf die Produktivsetzung eines neuen Services gewartet werden sollte. Für Kunden besteht damit lediglich ein Komfortverlust, da die Grenzlastauskunft weiterhin in einem Bestellportal-externen Tool einzuholen wäre.
|
||||
## 6.3.1.4 MaTeo
|
||||
|
||||
## Funktionen
|
||||
|
||||
MaTeo ist ein webbasiertes IT-Tool zur Beauftragung einer Machbarkeitsstudie auÃergewöhnliche Transporte (MaT). Die Machbarkeitsstudie ist Voraussetzung für die Bearbeitung von Trassenanmeldungen zu auÃergewöhnlichen Transporten. Im Rahmen der Machbarkeitsstudie wird eine BZA-Nr. vergeben, die in der Trassenanmeldung anzugeben ist. Andernfalls erfolgt solange keine Bearbeitung der Anmeldung, bis die BZA-Nr. vorliegt.
|
||||
Die entsprechende Bestellannahme der MaT sowie die Interaktion zwischen den Kunden und der DB Netz AG wird durch MaTeo digital unterstützt.Â
|
||||
## Bewertung
|
||||
|
||||
Die Prozessunterstützung, die MaTeo Kunden im Segment auÃergewöhnliche Transporte bietet, sollte mittelfristig in das Bestellportal integriert werden. Da MaTeo auf eine abgrenzbare Menge Kunden wirkt und heute bereits eine digitale Prozessunterstützung bietet, wird auf eine Integration im Rahmen des MVP aber verzichtet.
|
||||
## Konzeptansatz
|
||||
|
||||
- keine Umsetzung im Rahmen des MVP -
|
||||
+10
@@ -0,0 +1,10 @@
|
||||
# 6.11 Rechner unterstützte Trassenkonstruktion (RuT-K)
|
||||
|
||||
> Confluence Page ID: 27525801
|
||||
> Version: 10
|
||||
> Pfad: /pathOS/Start / Vorstudie Bestellsystem/00_Vorstudie Bestellsystem/6 IT Ist-Analyse/6.11 Rechner unterstützte Trassenkonstruktion (RuT-K)
|
||||
> Labels:
|
||||
|
||||
---
|
||||
|
||||
Zum Zeitpunkt der Konzeptionsphase - Vorprojekt läuft ein paralleles Projekt BaDiFa zur Erstellung von RuT-Kneu. Die Beschreibung vom heutigen System RuT-K ist der Vorstudie BaDiFa zu entnehmen.
|
||||
+56
@@ -0,0 +1,56 @@
|
||||
# 2019-04-17 Abstimmung RuT-Kneu <-> Bestellportal Roadmap
|
||||
|
||||
> Confluence Page ID: 27525802
|
||||
> Version: 3
|
||||
> Pfad: /pathOS/Start / Vorstudie Bestellsystem/00_Vorstudie Bestellsystem/14 Besprechungsnotizen Vorstudie/2019-04-17 Abstimmung RuT-Kneu <-> Bestellportal Roadmap
|
||||
> Labels: meeting-notes
|
||||
|
||||
---
|
||||
|
||||
## Datum
|
||||
|
||||
|
||||
|
||||
|
||||
## Kurze Zusammenfassung unseres Termins mit RuT-K zum aus unserer Sicht risikominimierenden Ansatz âTemporäre Wiederverwendung von Bestandssystemenâ:
|
||||
|
||||
## Diskussionspunkte
|
||||
|
||||
| | Zeit | Eintrag | Wer | Notizen
|
||||
| | 5min | Agenda Eintrag | Name |
|
||||
BaDiFa sieht derzeit keinen Anlass, dass es grundsätzliche Schwierigkeiten geben könnte gemeinsam bis 2022 produktiv zu gehen. Der Tenor ist âWir schaffen dasâ¦â.
|
||||
| | Â | Â | Â | RuT-K Neu glaubt nicht an ein Mapping der verschiedenen Datenmodelle (EVU, TAF/TAP) in einem vertretbaren Aufwand insbesondere wegen:
|
||||
- Stamm-, Ergänzer
|
||||
- Mehrere Angebote auf eine Anfrage
|
||||
- Netzausgelöster Ergänzungsfahrplan
|
||||
- 20 Stunden Züge
|
||||
| |
|
||||
|
|
||||
|
|
||||
| Man sieht zusätzlich in unserer Roadmap folgende Schwierigkeit: Zum Testen mit den EVUs wird man keine Fach-Ressourcen (Fahrplaner) bekommen können, es muss âallesâ automatisch funktionieren.
|
||||
| |
|
||||
|
|
||||
|
|
||||
|
|
||||
Wir haben folgende Vereinbarung getroffen, der Plan A sollte in etwa so aussehen: wir legen unter der Annahme los, dass alle abhängigen neu gestarteten Projekte insoweit rechtzeitig liefern können, dass der Produktivtermin für das Bestellportal und nachgelagerte Systeme Ende 2022 gehalten werden kann. Die Integration mit dem neuen Konstruktionssystem muss in jedem Fall sehr frühzeitig und wirklich E2E - zumindest mit einfachen Anmeldungen â funktionieren, das sieht RuT-K genauso. Das bedeutet, eine erste für uns nutzbare Version von BaDiFa liegt Ende 2020 vor. Dazu muss es in FIB einen Eintrag im Risikomanagement geben.
|
||||
Falls zum Zeitpunkt Ende 2020 BaDiFa nicht soweit sein sollte, wollen wir den Plan B ausrufen, bzw. aus Risikogesichtspunkten dem FIB Board zur Entscheidung vorschlagen: Implementierung TAF/TAP CI, Neue (TAF/TAP) Benutzeroberfläche für EVUs, Adapter TPN mit Mapping TAF/TAP->EVU, Headless TPN, Ertüchtigung TAF/TAP für das TPN Backend, Ertüchtigung TAF/TAP für RuT-K alt, Ertüchtigung TAF/TAP für GFD-Z.
|
||||
Für Plan B benötigen wir eine Einschätzung der Dauer und Kosten einer Ertüchtigung der Bestandssysteme, falls das mehrere Jahre dauern würde wäre es wohl kein Notfallplan. Den Plan B definieren wir als eine der Umsetzungsalternativen unserer Vorstudie, und zwar als diejenige, die wir erstmal nicht als erste Empfehlung angeben werden, sondern eben erst zu dem gegebenem Zeitpunkt weiterverfolgen werden, falls obiges Szenario eintritt.
|
||||
Information: RuT-K Neu plant als noch nicht näher abgestimmte eigene Roadmap die folgenden Haupt-Stränge: Fahrplaner UI und Konstruktionskern sowie Anbindung von Bestellportal und VÃ. Man will mit einfachen Use-Cases starten. Fahrplaner UI ist am Anfang nur readonly, Bearbeitung kommt dann später, â¦
|
||||
## Handlungspunkte
|
||||
|
||||
|
||||
13
|
||||
incomplete
|
||||
Sinnvollerweise sollte nach Ansicht RuT-K in unserer Roadmap auch nach Produkten unterschieden werden, also beispielsweise Fertigstellung GelV oder Netzfahrplan, Studienâ¦
|
||||
|
||||
|
||||
1
|
||||
incomplete
|
||||
|
||||
|
||||
|
||||
|
||||
|
||||
14
|
||||
incomplete
|
||||
Â
|
||||
+261
@@ -0,0 +1,261 @@
|
||||
# 4.4.4.3 Fahrplanerische Bestelleingangsprüfungen (BEP), TrassenPrüfenUndErgänzen (TTPUE), Routensuche und Fahrzeitberechnung (FBZE) - M13
|
||||
|
||||
> Confluence Page ID: 27525810
|
||||
> Version: 53
|
||||
> Pfad: /pathOS/Start / Vorstudie Bestellsystem/00_Vorstudie Bestellsystem/4 Anforderungen an das neue Bestellsystem der DB Netz/4.4 Soll-Schnittstellen Bestellsystem (Consumer oder Provider)/4.4.4 Anbindung an den Fahrplan und das Kapazitätsmanagement/4.4.4.3 Fahrplanerische Bestelleingangsprüfungen (BEP), TrassenPrüfenUndErgänzen (TTPUE), Routensuche und Fahrzeitberechnung (FBZE) - M13
|
||||
> Labels:
|
||||
|
||||
---
|
||||
|
||||
## Anforderungen an die Bestelleingangsprüfung (BEP) und Routensuche
|
||||
|
||||
 Die Funktionsweise der Bestelleingangsprüfung (BEP) und der Routensuche wird in Kapitel 6.2.1 exakter erläutert. Im Folgenden wird lediglich eine kurze Beschreibung des Ablaufs gegeben sowie die zusätzlichen Anforderungen, die das Projekt Bestellsystem an die beiden Anwendungen hat, beschrieben.
|
||||
Aktuell kann die BEP nur in Verbindung mit der Routensuche genutzt werden. Die Routensuche kann wiederum als eigener Webservice unabhängig von der BEP aufgerufen werden, allerdings unterstützt die Routensuche (wie auch die BEP) derzeit nur eine Infrastruktur, die des aktuell gültigen Fahrplanjahres. Die Fahrtzeitberechnung (FBZE) muss nicht direkt angesprochen werden. Es genügt, wenn diese nur durch die Routensuche angesprochen wird. Ãber die Routensuche bekommt das Bestellportal die FZBE Ergebnisse.
|
||||
Ziel ist es, beide Anwendungen unabhängig voneinander aufzurufen sowie diese auf mehreren Infrastrukturversionen nutzen zu können.
|
||||
## Arbeitsweise BEP / Routensuche (Route, RoutenVariante, Durchfahrt, Laufpunkt)Â
|
||||
|
||||
Der Ablauf erfolgt in 4 Phasen:
|
||||
1 Phase: Plausibilitätsprüfung und Formelle Prüfungen
|
||||
Sind alle Pflichtfelder gefüllt?
|
||||
2 Phase: Fachliche Prüfungen, die unabhängig von der Routensuche sind
|
||||
Beispiel: Existiert die vorhandene Streckenklasse?
|
||||
3 Phase: Routensuche
|
||||
Ist eine Route zu den vorgegebenen Zuglaufpunkten vorhanden?
|
||||
Berechnung der Fahrzeiten.
|
||||
4 Phase: Keine Route gefunden? Ursachencheck.
|
||||
Es werden verschiedene Relaxierungsparameter (siehe Anhang) geprüft. Das bedeutet, dass aktuell eine Prüfung erfolgt, welche untersucht, ob generell, unter Berücksichtigung der Via-Punkte oder bedingt durch die Zugcharakteristik keine Route gefunden wird.Â
|
||||
|
||||
|
||||
## Anpassungsbedarf durch ein neues (Trassen-)Bestellsystem
|
||||
|
||||
 Folgende Ãnderungen/Erweiterungen sind im Projekt neXt für die Anbindung des Bestellsystems notwendig:
|
||||
- Die Streckennummern müssen angezeigt bzw. zurückgegeben werden.
|
||||
- Das Servicelevel muss angepasst werden, Ziel SL1 Basic.
|
||||
- Ggf. Nutzungskosten für die beiden Services im Betrieb (z.B. in der Anmeldephase Netzfahrplan mindestens 80000 Aufrufe).
|
||||
- Die Routensuche muss Verfügbarkeitseinschränkungen zurückliefern können.
|
||||
- Beide Anwendungen (BEP / Routensuche) müssen unabhängig voneinander aufrufbar sein.
|
||||
- Die Routensuche soll verschiedene Kriterien berücksichtigen, wie z.B. die verkehrsgünstigste Route.
|
||||
- Die BEP / Routensuche muss in einem TAF/TAP nahen Objektmodell kommunizieren können.
|
||||
- Es sollten alle BEP Prüfungen bzw. Prüfungsschritte durchlaufen werden und eventuelle Probleme in der Rückmeldung bereits benannt werden, sodass Kunden dies nicht mehrmals prüfen lassen müssen, um mehrere Fehler zu finden.Â
|
||||
- Konfigurationsmöglichkeiten, welche Prüfungen durchlaufen werden sollen.
|
||||
Das entsprechende Dokument zum Change Request ist unter CR_neXt_Bestellsystem zu finden.
|
||||
## Anhang
|
||||
|
||||
## Â Aktuelle Relaxierungsparameter
|
||||
|
||||
<v01:E-TraktionVerboten>false</v01:E-TraktionVerboten>
|
||||
<v01:AusschlussVerkehrsart>false</v01:AusschlussVerkehrsart>
|
||||
<v01:Zuggattungszusaetze>false</v01:Zuggattungszusaetze>
|
||||
<v01:Steilstrecken>false</v01:Steilstrecken>
|
||||
<v01:NotbremsUeberbrueckung>false</v01:NotbremsUeberbrueckung>
|
||||
<v01:Bahnsteiglaengen>false</v01:Bahnsteiglaengen>
|
||||
<v01:Halteplatzlaenge>false</v01:Halteplatzlaenge>
|
||||
<v01:EingleisigeSperrung>false</v01:EingleisigeSperrung>
|
||||
<v01:KombinierterVerkehr>false</v01:KombinierterVerkehr>
|
||||
<v01:StreckenKlasse>false</v01:StreckenKlasse>
|
||||
<v01:Zuglaenge>false</v01:Zuglaenge>
|
||||
<v01:ETCS>false</v01:ETCS>
|
||||
<v01:E-TraktionErforderlich>false</v01:E-TraktionErforderlich>
|
||||
<v01:KesselwagenVerboten>false</v01:KesselwagenVerboten>
|
||||
<v01:RichtungswechselhaekchenFehlt>false</v01:RichtungswechselhaekchenFehlt>
|
||||
<v01:Streckenoeffnungszeiten>false</v01:Streckenoeffnungszeiten>
|
||||
<v01:UeberlasteterSchienenwegVorgaben>false</v01:UeberlasteterSchienenwegVorgaben>
|
||||
<v01:Totalsperrung>false</v01:Totalsperrung>
|
||||
<v01:Grenzlast>true</v01:Grenzlast>
|
||||
<v01:Zughakengrenzlast>false</v01:Zughakengrenzlast>
|
||||
|
||||
|
||||
## Anforderungen des Projekts Bestellsystem an die Fahrtzeitberechnung (FBZE)
|
||||
|
||||
FBZE ist kein BusinessService, sondern wird derzeit nur als Bibliothek intern eingebunden. Die Bibliothek FBZE ist nicht für das Produkt Fahrzeitrechnung geeignet, da diese nur die Fahrzeiten für bereits existierende, mikroskopische Routen berechnen kann, selbst aber nicht in der Lage ist, ein Routing durchzuführen. Für den Zweck der Fahrzeitrechnung eignet sich der Kern der automatischen Einzelbelegung hinter C&R besser, wenn dieser ohne den gesetzten Verkehr initialisiert wird.
|
||||
In diesem Fall sucht der Algorithmus eine ideale Strecke und konstruiert diese inkl. Fahrzeiten aus. (EINE VARIANTE in C&R). Ãber die Routensuche bekommt das Bestellportal die FZBE Ergebnisse.Â
|
||||
Anforderungen bei Fahrzeitberechnungen aus TAF/TAP- TSI
|
||||
In einer Anmeldung für  eine Fahrzeitberechnung ist immer eine Zugnummer anzugeben. Sie hat unter fachlich-rechtlichen Aspekten keine Bedeutung, dient aber neben den Identifikatoren Train-ID, PathRequest-ID und Path-ID als zusätzliches, den Geschäftsvorfall identifizierendes Ordnungsmerkmal. Sie unterstützt mit ihrer fachlichen Eindeutigkeit die praktische Arbeit mit den Geschäftsvorfällen für Fahrzeitberechnungen. Gesonderte Zugnummernzuweisungen für Fahrzeitberechnungen durch die DB Netz erfolgen nicht. Es können vorzugsweise Zugnummern des aktuellen Netzfahrplans, die vom EVU benutzt wurden, verwendet werden. Das bestellende EVU hat die Eindeutigkeit der Zugnummern für die Gesamtheit seiner Anmeldungen je Produkt Fahrzeitberechnung gewährleisten.
|
||||
|
||||
|
||||
SchnittstellenkontextÂ
|
||||
|
||||
|
||||
|
||||
|
||||
Die öffentliche Schnittstelle "Routensuche Web Service" bietet verschiedene Operationen für unterschiedliche Zwecke. Folgende Serviceoperationen werden durch den "Routensuche Web Service" bereitgestellt. SucheRoute - Das Ermitteln einer oder mehrerer Routen mit den Daten der Start- und Zielbetriebsstelle
|
||||
|
||||
|
||||
 Â
|
||||
|
||||
## DatenmodellÂ
|
||||
|
||||
Routensuche ist grundsätzlich ein Webservice, der ITOM âsprichtâ und über SOAP/http kommuniziert. Allerdings hat M13 die Antwortobjekte der Routensuche eigenhändig ITOM-nah modelliert, was dazu geführt hat, dass der CIO Bereich die Routensuche zum heutigen Stand nicht als Business Service betrachtet. Die Routensuche unterstützt keine Erkennung der korrekten Infrastruktur und keine Funktionen aus dem SPV. Diese fehlenden Funktionen werden sukzessive im Kontext Baufahrplan nachgeliefert.Â
|
||||
Problem: Datengrundlage bzw. Infrastrukturdaten in einer Version sind nicht vorhanden.
|
||||
Datenmodell TAF/TAP-TSI
|
||||
|
||||
|
||||
| |
|
||||
marktProdukt |
|
||||
Produkt, welches von DB Netz angeboten wird |
|
||||
1. In diesem Feld ist eines der über das Bestellsystem bestellbaren Produkte der DB Netz anzugeben. Produkte sind aktuell: Trasse, KFB (kurzfristige Fahrlagenberatung mit Buchungsoption), FZB (Fahrzeitberechnung), FPS (Fahrplanstudie/Betriebsprogrammstudie)
|
||||
2. Das Feld ist unter Berücksichtigung der für die Produkte möglichen Geschäftsvorfälle zu verwenden (siehe Kap. 2.1  "Geschäftsvorfälle und TAF-TSI/TAP-TSI- Nachrichtentypen") |
|
||||
1 |
|
||||
string |
|
||||
TR = Trasse
|
||||
FZB = Fahrzeitberechnung
|
||||
FPS = Fahrplan- und Betriebsprogrammstudie
|
||||
|
||||
|
||||
|
||||
|
||||
## Nichtfunktionale Aspekte
|
||||
|
||||
| |
|
||||
Vertraulichkeit |
|
||||
|
||||
11
|
||||
incomplete
|
||||
 sehr hoch
|
||||
|
||||
|
||||
12
|
||||
incomplete
|
||||
 hoch
|
||||
|
||||
|
||||
13
|
||||
incomplete
|
||||
 mittel
|
||||
|
||||
|
||||
14
|
||||
incomplete
|
||||
 niedrig
|
||||
|
||||
|
||||
| |
|
||||
Integrität |
|
||||
|
||||
15
|
||||
incomplete
|
||||
 sehr hoch
|
||||
|
||||
|
||||
16
|
||||
incomplete
|
||||
 hoch
|
||||
|
||||
|
||||
17
|
||||
incomplete
|
||||
 mittel
|
||||
|
||||
|
||||
18
|
||||
incomplete
|
||||
 niedrig
|
||||
|
||||
|
||||
| |
|
||||
IT-Sicherheit |
|
||||
n/a
|
||||
| |
|
||||
Nachvollziehbarkeit |
|
||||
n/a
|
||||
Â
|
||||
Â
|
||||
| |
|
||||
Verfügbarkeit
|
||||
| |
|
||||
Robustheit der Schnittstelle |
|
||||
 Keine Anforderungen.
|
||||
 Folgende Anforderungen: | Kommentar
|
||||
| |
|
||||
Servicelevel* |
|
||||
|
||||
31
|
||||
incomplete
|
||||
 SL 1 Plus
|
||||
|
||||
|
||||
32
|
||||
incomplete
|
||||
 SL 1
|
||||
|
||||
|
||||
33
|
||||
complete
|
||||
 SL 1 Basic
|
||||
|
||||
|
||||
34
|
||||
incomplete
|
||||
 SL 2
|
||||
|
||||
|
||||
35
|
||||
incomplete
|
||||
 SL 3 Plus
|
||||
|
||||
|
||||
36
|
||||
incomplete
|
||||
 SL 3
|
||||
|
||||
|
|
||||
|
||||
|
||||
 |
|
||||
| |
|
||||
Logging
|
||||
| |
|
||||
Anforderung an Logging* |
|
||||
Â
|
||||
 |
|
||||
| |
|
||||
Ãbertragungsverfahren
|
||||
| |
|
||||
Schnittstellenart* |
|
||||
|
||||
37
|
||||
incomplete
|
||||
 Datenablage in Datei, Pfad: manuelle Festlegung
|
||||
|
||||
|
||||
38
|
||||
complete
|
||||
 Webservice:Â
|
||||
|
||||
|
||||
39
|
||||
incomplete
|
||||
 SMS-Nachricht, Nummer:
|
||||
|
||||
|
||||
40
|
||||
incomplete
|
||||
 gemeinsame Datenbank:
|
||||
|
||||
|
||||
41
|
||||
incomplete
|
||||
 Online-Transaktion:
|
||||
|
||||
|
||||
42
|
||||
incomplete
|
||||
 Andere: Dateiversand via Email
|
||||
|
||||
|
||||
| |
|
||||
Transaktionssicherheit* |
|
||||
 Keine Anforderungen.
|
||||
 Folgende Anforderungen:
|
||||
| |
|
||||
Anforderung an Logging* |
|
||||
n/a
|
||||
| |
|
||||
Art der Datenübertragung |
|
||||
 ftp
|
||||
 SMS
|
||||
 HTTP
|
||||
 ESB
|
||||
 Andere: manuelle Ãbertragung
|
||||
Â
|
||||
 Â
|
||||
@@ -0,0 +1,40 @@
|
||||
# 6.4 Abrechnungssysteme
|
||||
|
||||
> Confluence Page ID: 27525811
|
||||
> Version: 82
|
||||
> Pfad: /pathOS/Start / Vorstudie Bestellsystem/00_Vorstudie Bestellsystem/6 IT Ist-Analyse/6.4 Abrechnungssysteme
|
||||
> Labels:
|
||||
|
||||
---
|
||||
|
||||
## Ist Zustand
|
||||
|
||||
Das System Trassenpreissystem (TPS) ist abgängig und wird aktuell durch das Projekt AbrechnungsCockpit (AC) ersetzt. Die Preisberechnung wird bereits über das AC gekapselt und wird über entsprechende Adaptoren in TPN (Neuverkehrsrabatte) und GFD-Z (Angebotspreise) oder Click&Ride (Angebotspreise) an die Bestellsysteme übermittelt. |
|
||||
| | Â Â
|
||||
Service/Komponente  |  Â
|
||||
Kurzbeschreibung  |
|
||||
|
||||
|
||||
Kommentar
|
||||
 Â
|
||||
| |
|
||||
Trassenportal Netze (TPN) |
|
||||
Ãber TPN werden Trassenanmeldungen und Trassenangebote zwischen der DB Netz und den Eisenbahnverkehrsunternehmen auf elektronischem Weg übermittelt. Die Kommunikation mit GFDâZ geschieht über eine elektronische Schnittstelle. Trassenanmeldungen mit einer Anfrage für Neuverkehrsrabatte (NVR) werden über den TPNAdapter weitergegeben. |
|
||||
Die Schnittstellenbeschreibung kann unter folgendem Link nachgelesen werden.
|
||||
| |
|
||||
Service TPNAdapter |
|
||||
Der Adapter dient der Anbindung des Altsystems TPN (Trassenportal Netze). Ãber diesen Adapter werden Anfragen für Neuverkehrsrabatte (NVR) an das Discount Order System (DOS) übertragen. Die Erstellung bzw. Aktualisierung von NVR Anträgen wird über den Adapter Service initiiert und die Belege werden revionssicher gespeichert. Darüber hinaus kann TPN über diesen Service Ãnderungsbepreisungen an die Abrechnung übermitteln. |
|
||||
Die Schnittstellenbeschreibung kann über folgenden Link nachgelesen werden.
|
||||
Die Anbindung des AC an TPN erfolgt indirekt über GFD-Z. Der Service AufbereitungsAbrechnungsInformationTrassen ist implementiert, wird jedoch noch nicht produktiv genutzt (Umsetzung erfolgt aufgrund Architekturweiche). Die Anbindung GFD-Z erfolgt für die Preisberechnung und Abrechnung über den Service GFD-ZAdapter.
|
||||
| |
|
||||
Discount Order System |
|
||||
Das Discount Order System ist eine Webapplikation, welche in das Abrechnungscockpit integriert ist und Anträge zur Neuverkehrsrabatten verwaltet. |
|
||||
Die Anbindung ist über GFD-Z vorgesehen, derzeit aber noch nicht implementiert. Die Schnittstellenbeschreibung kann unter folgendem Link nachgelesen werden.
|
||||
| | GFD-ZAdapter | Der GFD-Z Adapter empfängt die Preisanfrage und transformiert den Request in ZugTrassenVarianten. | Die Schnittstellenbeschreibung kann unter folgendem Link nachgelesen werden.
|
||||
| | GFD-Z: Preisanfrage für  Angebotserstellung | In diesem Kontext sendet GFD-Z Preisanfragen, um die Angebote zu vervollständigen. | Die Schnittstellenbeschreibung kann unter folgendem Link nachgelesen werden.
|
||||
| | Click&Ride | AC- PreisVerwaltungTrasse.ermittleTrassenpreis |
|
||||
Die Click&Ride â App nutzt die aktuelle Serviceoperation PreisverwaltungTrasse.ermittleTrassenpreis, als Datenmodell wird aktuell ITOM verwendet. Zukünftig wird für das Bestellsystem diese Schnittstelle verwenden. Die Ãnderung an dem AC Service werden zu einem Change Request führen.
|
||||
Prozessschritt "Trassenpreis ermitteln pro Zugtrasse" (siehe Prozess-Schritt 71):
|
||||
Ermitteln der einzelnen Trassenpreise durch Aufruf eines Webservices des Abrechnungscockpits.
|
||||
Implementierter Service: com_dbnetz_neXt_PSS_g_V01._01.pub.angebotsAnfrageMain:ermittleTrassenpreise
|
||||
https://wiki.intranet.deutschebahn.com/wiki/display/neXtlab/ProzessSteuerung.PhaseG
|
||||
+20
@@ -0,0 +1,20 @@
|
||||
# 6.5 Bereitstellung von Stammdaten IST Zustand
|
||||
|
||||
> Confluence Page ID: 27525816
|
||||
> Version: 30
|
||||
> Pfad: /pathOS/Start / Vorstudie Bestellsystem/00_Vorstudie Bestellsystem/6 IT Ist-Analyse/6.5 Bereitstellung von Stammdaten IST Zustand
|
||||
> Labels:
|
||||
|
||||
---
|
||||
|
||||
GFD-I ist eine Anwendung zur Erfassung und Pflege von Daten zur Gleis- und Streckeninfrastruktur der DB Netz AG. In GFD-I werden im Ist-Zustand auÃerdem weitere Stammdaten von DaViT gepflegt (Geschäftspartner, Triebfahrzeug-Stammdaten und weitere sog. âSchlüsselwerteâ).
|
||||
|
||||
|
||||
| |
|
||||
Rahmendatenzugriff |
|
||||
GFD-I FahrplandatenhaltungInfrastruktur |
|
||||
Abruf bestimmter Stammdaten (sog. Schlüsselwerte), z.B. Betriebsstellen, Fahrplanperioden, Geschäftspartner, Triebfahrzeugbaureihen und deren Eigenschaften.
|
||||
|
||||
|
||||
Aktuell werden die Stammdaten über eine Excel Liste an TPN bzw. die EVU SST übermittelt. Folgende Stammdaten aus GFD- I werden für TPN bereitgestellt: Stammdaten_2017_08_TPNÂ
|
||||
 Stammdaten 2019
|
||||
+193
@@ -0,0 +1,193 @@
|
||||
# 4.4.4.4 Netzmonitor und SAPBIne
|
||||
|
||||
> Confluence Page ID: 27525834
|
||||
> Version: 42
|
||||
> Pfad: /pathOS/Start / Vorstudie Bestellsystem/00_Vorstudie Bestellsystem/4 Anforderungen an das neue Bestellsystem der DB Netz/4.4 Soll-Schnittstellen Bestellsystem (Consumer oder Provider)/4.4.4 Anbindung an den Fahrplan und das Kapazitätsmanagement/4.4.4.4 Netzmonitor und SAPBIne
|
||||
> Labels:
|
||||
|
||||
---
|
||||
|
||||
## EinführungÂ
|
||||
|
||||
Im Rahmen des neuen Bestellsystems ist geplant, eine API anzubieten, die es ermöglicht, den Datenbestand für nachfolgende Business Intelligence Systeme (Drittsysteme) bereitzustellen. Diese API soll die bereitgestellten Daten jedoch nicht systemspezifisch aufbereiten, sondern die Daten in einer standardisierten Objektmodell-Struktur zur Verfügung stellen.
|
||||
Hierzu wird es über einen Service AuftragsDatenBereitstellung (Pull) möglich sein, durch Angabe von Zeiträumen dedizierte Datensätze abzufragen. Das Datenformat wird das vom Bestellsystem verwendete Objektmodell beinhalten (TAF/TAP Objektmodell). Der Service soll mit SLA 3 betrieben werden.
|
||||
Die abnehmenden Systeme können sich an diese Schnittstelle anbinden, um die Auftragsdaten des Bestellsystems zu beziehen. Die Aufbereitung und Auswertung dieser Daten für definierte Business Intelligence Auswertungen (Reports) ist nicht Bestandteil der angebotenen Schnittstelle vom Bestellsystem.
|
||||
Im Folgenden ist ein Systemkontext des Services, über den beliebige BI Systeme angebunden werden können, abgebildet. Derzeit sind zwei Systeme vorgesehen.
|
||||
Hinweis: Das Projekt Bestellsystem stellt die entsprechenden Daten zur Auswertung den jeweiligen Nutzern zur Verfügung. Anpassungen an den BI Systemen Netzmonitor und SAPBine sind nicht Teil des Projekts Bestellsystem.
|
||||
|
||||
|
||||
|
||||
## NetzmonitorÂ
|
||||
|
||||
- Das Bestellsystem stellt eine Schnittstelle im TAF/TAP Format zur Verfügung. Diese stellt die vertrieblichen Auftragsdaten in einem festgelegten Format (TAF/TAP-TSI-nah) bereit, von den fachlichen Inhalten angelehnt an die bisherige Schnittstelle.Â
|
||||
- Netzmonitor wird auch nach 2023 bestehen bleiben.Â
|
||||
- Ungeklärt ist im Rahmen der Konzeptionsphase des Bestellsystem, ob Netzmonitor die vom Bestellsystem geplante API nutzt und/ oder die Daten aus der Komponente Trassenverwaltung von BaDiFa beziehen wird.
|
||||
- Arbeitsannahme vom Projekt Bestellsystem:
|
||||
- Die Kosten zur Anpassung bei Netzmonitor werden nicht vom Projektbudget Bestellsystem finanziert.
|
||||
## SAPBIneÂ
|
||||
|
||||
- Das Bestellsystem stellt eine Schnittstelle im TAF/TAP Format zur Verfügung. Diese stellt die vertrieblichen Auftragsdaten in einem festgelegten Format (TAF/TAP-TSI-nah) bereit, von den fachlichen Inhalten angelehnt an die bisherige Schnittstelle.Â
|
||||
- SAPBine wird nach 2023 bestehen bleiben. Derzeit nutzen 3000 User das System, ein Hauptnutzer ist z.B. Station&Service. SAPBine ist auch für den Vertrieb ein versorgendes System, es bedient die Schnittstelle IBL (Informationssystem Betriebsleistung). Die IT-Anwendung IBL ist in SAP BI integriert und dient der Ermittlung und Bereitstellung der Betriebsleistungsstatistik für die Abrechnung.Â
|
||||
- ab dem Zeitpunkt März 2023 müssen Reports über SAPBINe bereitgestellt werdenÂ
|
||||
- eine Anpassung muss bei SAPBINe erfolgen.
|
||||
- Im Rahmen der Konzeptionsphase des Bestellsystems ist ungeklärt:
|
||||
- Ob und welche Reports hinsichtlich Fahrplandaten über SAPBINe ab März 2023 bereitgestellt werden sollen.
|
||||
- Ob SAPBINe die vom Bestellsystem geplante Schnittstelle nutzt und/ oder die Daten aus der Komponente Trassenverwaltung von BaDiFa beziehen wird.
|
||||
- Wer die Kosten für die notwendigen Anpassungen von SAPBINe (und ggf. der Folgesysteme) finanziert, sofern vertriebliche Reports auf dem neuen Datenmodell von TAF/TAP-TSI erstellt werden müssen.Â
|
||||
- Arbeitsannahme vom Projekt Bestellsystem:
|
||||
- Die Kosten zur Anpassung bei SAPBINe werden nicht vom Projektbudget Bestellsystem finanziert.
|
||||
Â
|
||||
## Nichtfunktionale Aspekte
|
||||
|
||||
| |
|
||||
Vertraulichkeit |
|
||||
|
||||
11
|
||||
incomplete
|
||||
 sehr hoch
|
||||
|
||||
|
||||
12
|
||||
incomplete
|
||||
 hoch
|
||||
|
||||
|
||||
13
|
||||
incomplete
|
||||
 mittel
|
||||
|
||||
|
||||
14
|
||||
incomplete
|
||||
 niedrig
|
||||
|
||||
|
||||
| |
|
||||
Integrität |
|
||||
|
||||
15
|
||||
incomplete
|
||||
 sehr hoch
|
||||
|
||||
|
||||
16
|
||||
incomplete
|
||||
 hoch
|
||||
|
||||
|
||||
17
|
||||
incomplete
|
||||
 mittel
|
||||
|
||||
|
||||
18
|
||||
incomplete
|
||||
 niedrig
|
||||
|
||||
|
||||
| |
|
||||
IT-Sicherheit |
|
||||
n/a
|
||||
| |
|
||||
Nachvollziehbarkeit |
|
||||
n/a
|
||||
Â
|
||||
Â
|
||||
| |
|
||||
Verfügbarkeit
|
||||
| |
|
||||
Robustheit der Schnittstelle |
|
||||
 Keine Anforderungen.
|
||||
 Folgende Anforderungen: | Kommentar
|
||||
| |
|
||||
Servicelevel* |
|
||||
|
||||
31
|
||||
incomplete
|
||||
 SL 1 Plus
|
||||
|
||||
|
||||
32
|
||||
incomplete
|
||||
 SL 1
|
||||
|
||||
|
||||
33
|
||||
incomplete
|
||||
 SL 1 Basic
|
||||
|
||||
|
||||
34
|
||||
incomplete
|
||||
 SL 2
|
||||
|
||||
|
||||
35
|
||||
complete
|
||||
 SL 3 Plus
|
||||
|
||||
|
||||
36
|
||||
incomplete
|
||||
 SL 3
|
||||
|
||||
|
|
||||
|
||||
|
||||
 |
|
||||
| |
|
||||
Logging
|
||||
| |
|
||||
Anforderung an Logging* |
|
||||
Â
|
||||
 |
|
||||
| |
|
||||
Ãbertragungsverfahren
|
||||
| |
|
||||
Schnittstellenart* |
|
||||
|
||||
37
|
||||
incomplete
|
||||
 Datenablage in Datei, Pfad: manuelle Festlegung
|
||||
|
||||
|
||||
38
|
||||
complete
|
||||
 Webservice:Â
|
||||
|
||||
|
||||
39
|
||||
incomplete
|
||||
 SMS-Nachricht, Nummer:
|
||||
|
||||
|
||||
40
|
||||
incomplete
|
||||
 gemeinsame Datenbank:
|
||||
|
||||
|
||||
41
|
||||
incomplete
|
||||
 Online-Transaktion:
|
||||
|
||||
|
||||
42
|
||||
incomplete
|
||||
 Andere: Dateiversand via Email
|
||||
|
||||
|
||||
| |
|
||||
Transaktionssicherheit* |
|
||||
 Keine Anforderungen.
|
||||
 Folgende Anforderungen:
|
||||
| |
|
||||
Anforderung an Logging* |
|
||||
n/a
|
||||
| |
|
||||
Art der Datenübertragung |
|
||||
 ftp
|
||||
 SMS
|
||||
 HTTP
|
||||
 ESB
|
||||
 Andere: manuelle Ãbertragung
|
||||
Â
|
||||
@@ -0,0 +1,124 @@
|
||||
# 6.9 RNE Common Interface
|
||||
|
||||
> Confluence Page ID: 27525836
|
||||
> Version: 29
|
||||
> Pfad: /pathOS/Start / Vorstudie Bestellsystem/00_Vorstudie Bestellsystem/6 IT Ist-Analyse/6.9 RNE Common Interface
|
||||
> Labels:
|
||||
|
||||
---
|
||||
|
||||
 Für den Austausch von TAF/TAP-TSI-konformen Nachrichten zur Unterstützung der europaweiten Interoperabilität muss das neue Bestellsystem bestimmte Schnittstellen anbieten, bzw. anbinden. Die Schnittstellen-Spezifikation wird nachfolgend beschrieben. AnschlieÃend wird die RNE-Referenzimplementierung vorgestellt und bewertet.Â
|
||||
## Technische Spezifikation Common Interface (CI)
|
||||
|
||||
Die TAF-TSI-Verordnung (Siehe TAF-TSI-Verordnung, Commission Regulation 1305/2014) beschreibt im Abschnitt 4.2.12. Vernetzung und Kommunikation eine gemeinsame Architektur für den TSI-konformen Datenaustausch der beteiligten Eisenbahnunternehmen (EVUs und EIUs).
|
||||
Die dort beschriebene Architektur adressiert die Aspekte:
|
||||
- Vernetzung der Akteure mittels eines hybriden Peer-to-Peer Kommunikationsmodells und einer Nachrichten-Schnittstelle (ausführlich beschrieben in TAF TSI â Anhang D.2: Anlage F â Modell für TAF-TSI-Daten und -Meldungen)
|
||||
- Sicherheit des Datenaustauschs (Verschlüsselung und Signatur für ausgetauschte Nachrichten)
|
||||
- Zentralspeicher für Metadaten und Verwaltung der öffentlichen Schlüsseln (Publik-Key-Infrasktruktur und Zertifizierungsbehörde).
|
||||
- (verbindliche) Gemeinsame Schnittstelle zur Unterstützung der Interoperabilität. Dadurch wird anderen Akteuren ein einheitlicher Zugang zu allen TSI-Daten gewährleistet.Â
|
||||
Vor allem die Gemeinsame Schnittstelle liegt im Fokus des Projekts Bestellsystem. Laut TAF-TSI-Verordnung gilt:
|
||||
Eine gemeinsame Schnittstelle muss Folgendes verarbeiten können:
|
||||
- Formatierung abgehender Meldungen anhand der Metadaten,
|
||||
- Signatur und Verschlüsselung abgehender Meldungen,
|
||||
- Adressierung abgehender Meldungen,
|
||||
- Ãberprüfung der Authentizität eingehender Meldungen,
|
||||
- Entschlüsselung eingehender Meldungen,
|
||||
- Konformitätsprüfungen eingehender Meldungen anhand der Metadaten,
|
||||
-
|
||||
Behandlung des gemeinsamen Zugangs zu den verschiedenen Datenbanken.
|
||||
Die technische Spezifikation der Schnittstelle erfolgt im TAF-TSI - ANNEX D.2: APPENDIX E - COMMON INTERFACE (zusätzlich zum Nachrichtenformat im Apendix F).
|
||||
Es wird eine mehrstufige Architektur für die Verarbeitung der TSI-Nachrichten vorgeschlagen (Nummern verweisen auf Abschnitte der TAF-TSI Verordnung):
|
||||
|
||||
Die Architektur behandelt folgende Funktionalitäten:
|
||||
- API Adaptors
|
||||
- Translation and Validation
|
||||
- Metadata System
|
||||
- Security and Transport
|
||||
- XML (Messages)
|
||||
- Generic API
|
||||
- Message Queueing
|
||||
- Data Compression
|
||||
- Admin UI
|
||||
Es werden folgende nicht-funktionale Anforderungen adressiert:
|
||||
- Capacity: up to 1000 partners
|
||||
- Stress: 100 (nominal) â 200 (peak) msgs/sec, with delay of 500 (90 ) - 2000 (max) ms
|
||||
- Availability: 99,9
|
||||
- Internet resource utilization: 600 kb/s (~ 30 msgs/s)
|
||||
- Computer resource utilization: <50Â CPU load for 5 legacy applications
|
||||
Die eigentliche Kommunikation zwischen den einzelnen TSI-Teilnehmern (also EVUs und EIUs) erfolgt über einen Web Service.
|
||||
Der Web Service basiert auf SOAP (Simple Object Access Protocol) mit XML als Datenaustauschformat.
|
||||
Weitere Informationen zum Common Interface beschreibt das TAP-TSI and TAF-TSI - Sector Handbook for the Communication between Railway Undertakings and Infrastructure Managers (RU/IM Telematics Sector Handbook). Hier wird zum einen die übergreifende RU/IM Architektur skizziert:
|
||||
|
||||
Es kann entweder die von der RNE zu entwickelnde Referenzimplementierung eingesetzt werden oder eine Eigenentwicklung vorgenommen werden. Eine Eigenentwicklung empfiehlt sich für neu entwickelte TAF/TAP-TSI-konforme Systeme, während Alt-Systeme mittels Referenzimplementierung angebunden werden könnten (siehe auch die Bewertung der Referenzimplementierung weiter unten).
|
||||
Analyse:
|
||||
Die Kommunikation erfolgt im Push-Verfahren, d.h. dass jeder Netzwerkteilnehmer jeden potentiellen Netzwerkteilnehmer kennen muss, um ihm Nachrichten zustellen zu können. Im Falle der DB Netze müssen der CI Endpunkt von jedem EVU bekannt sein, um dessen Trassenanfragen beantworten zu können.Â
|
||||
Die TAF/TAP-TSI-Architektur verwaltet die Liste der registrierten Eisenbahnunternehmen (Company Codes), verzichtet aber auf eine gemeinsame Registry der zugehörigen CI Endpunkte. Stattdessen werden ausdrücklich bilaterale Abstimmungen über die Endpunkte zwischen den einzelnen Teilnehmern gefordert. Dies können ca. 1000 Partner pro Teilnehmer sein (vgl. nicht-funktionale Anforderungen oben und die mehr als 400 EVUs in Deutschland).
|
||||
## RNE CCS - Common Components System
|
||||
|
||||
Die TAF-TSI-Common Components Group bietet (mit RNE als Auftragnehmer) eine Referenzimplementierung für das Common Interface an. Diese kann, muss aber nicht, von den einzelnen Eisenbahnunternehmen eingesetzt werden. Im letzteren Fall muss eine kompatible Implementierung seitens des Eisenbahnunternehmens eingesetzt werden.
|
||||
Die Referenzimplementierung wird zusammen mit weiteren Komponenten als Common Components System bezeichnet. Das sind im Einzelnen:
|
||||
- Common Reference Files Database (auch CRD für Central Repository Domain) für den Austausch der Stammdaten,
|
||||
- Common Interface (CI) Implementierung inkl. Adapter für Bestandssysteme,
|
||||
- Certification Authority (CA) für die Ausstellung und Verifikation der Zertifikate, wodurch TSI-Nachrichten verschlüsselt und verifiziert werden können.
|
||||
|
||||
Dabei werden die CRD und CA zentral von RNE betrieben, die konkrete von RNE erstellte CI-Implementierung wird wiederum sowohl von RNE selbst (z.B. im Falle von PCS bzw. dessen Nachfolger) als auch von EVUs und EIUs, die kein eigenes CI implementieren, genutzt.Â
|
||||
CI-Implementierungen kommunizieren mit (relevanten) anderen CI-Implementierungen sowie mit der CA (Zertifikat-Validierung) und ggf. mit dem CRD zur länderübergreifenden Stammdaten-Synchronisation.
|
||||
Die von der CA ausgestellten Zertifikate werden manuell beantragt und in der jeweiligen CI-Implementierung hinterlegt.
|
||||
|
||||
## CRD - Common Reference File Database
|
||||
|
||||
Folgende Daten werden vom CRD verwaltet und verteilt, entweder per manuellem Download oder über einen Webservice:
|
||||
- Location Reference Files (stations, customer sidings, loading, places)
|
||||
- Partner Reference files (company codes)
|
||||
- TAF-TSI-Metadata (XML Schemas für Nachrichtenaustauch)
|
||||
|
||||
|
||||
## Annahmen:
|
||||
|
||||
-
|
||||
## Der Upload der nationalen (deutschen) Daten zum CRD ist nicht im Scope des Projekts Bestellsystem.
|
||||
|
||||
- Der Abgleich der XML Schemas erfolgt manuell, da diese in der Regel nur bei der Weiterentwicklung des TSI-Standards notwendig werden und somit ohnehin eine Anpassung des Bestellsystems erfordern.
|
||||
- Ein automatisierter Abgleich der Referenz-Daten, vom CRD zum Bestellsystem, ist nur bedingt sinnvoll, da sich diese vermutlich selten ändern werden und zum anderen eine Qualitätssicherung gewünscht sein kann. Es wäre denkbar diese automatisiert abzuholen, um dann nach manueller Prüfung (ggf. auf Testumgebungen) in die Produktion einzuspielen, dies wird aber nicht Teil des MVPs des Bestellsystems sein.
|
||||
|
||||
## CA - Certification Authority
|
||||
|
||||
Die sichere Kommunikation zwischen den TSI-Teilnehmern wird mithilfe von digitalen Zertifikaten sichergestellt (X.509, vgl. https://docs.microsoft.com/en-us/previous-versions/tn-archive/bb123848(v=exchg.65)). Diese werden zentral von RNE CA vergeben, die wiederum von teilnehmenden IT-Systemen als "Trusted Authority" anerkannt werden müssen.
|
||||
Die Zertifikate dienen der SSL/TLS Kommunikation zwischen den einzelnen CI's und CRD. Sie erlauben auch eine (optionale) Verschlüsselung und Signierung der Nachrichteninhalte.
|
||||
Es sollen ausschlieÃlich die von der RNE ausgestellten Zertifikate zum Einsatz kommen.
|
||||
## Analyse:
|
||||
|
||||
Bei X.509-Zertifikaten und deren Einsatz in SSL/TLS sowie zur Verschlüsselung von Nachrichten handelt es sich um Industrie-Standards, die von der eingesetzten Software unterstützt werden müssen. Eine Verschlüsselung auf Transportebene gewährleistet eine sichere Ãbertragung, eine separate Verschlüsselung auf Nachrichtenebene über PKI Verfahren ist aufwendig, verlangsamt die Kommunikation und ist nicht empfehlenswert.
|
||||
Aus technischer Sicht ist es unerheblich, ob Zertifikate nur von RNE oder auch von anderen Quellen CAs kommen, solange diese als Trusted Authority in der Software (z.B. Java Keystore) registriert werden.
|
||||
## CI - Common Interface Implementation
|
||||
|
||||
Die von der RNE entwickelte und (mit Lizenz) verfügbare Referenzimplementierung ist im folgenden beschrieben.
|
||||
|
||||
Das Software-Paket kann von EVU bzw. EIU lokal installiert und konfiguriert werden. RNE CI agiert als Adapter (Local Instance) zwischen den Bestandssystemen (Legacy Systems) und anderen TSI-Teilnehmern (Remote CI). Die letzteren können die CI Referenzimplementierung oder eine eigene Implementierung des CI sein.
|
||||
Das RNE CI enthält folgende Komponenten:
|
||||
- CI Web Service für eingehende und ausgehende Nachrichten inkl. Verschlüsselung, Signieren, Kompression
|
||||
- Verwaltung der Metadaten (Schemas und Referenzdaten) sowie der Zertifikate und zusätzliche privater Stammdaten
|
||||
- Konnektoren für Bestandssysteme (FTP, Dateien, JMS, SMTP, WebServices)
|
||||
- Routing-Regeln für die Weiterleitung zwischen den internen und externen Systemen
|
||||
- Mapping der TAF-TSI-Daten auf interne Datenformate (z.B. UIC 407-1) sowie manuelle (graphische) Mappings auf andere XML Datenformate
|
||||
Analyse:
|
||||
Die RNE CI Implementierung liegt aktuell in Version 2.1 vor.
|
||||
Das RNE CI unterstützt aktuell noch nicht den redundanten skalierbaren Betrieb mehrerer Instanzen mit Ausfallsicherheit, siehe auch das Dokument Common Interface Performance & Hardware Recommendation, Version 1.3, Kapitel 5.4. RNE Common Component Normal Deployment with Load Balancer and Failover:
|
||||
This deployment option is not yet practically implemented and tested yet.Â
|
||||
Das RNE CI erlaubt den Betrieb und Konfiguration verschiedener CI-Instanzen pro Kommunikationspartner. Diese statische Zuordnung ist allerdings inflexibel verglichen mit der längst üblichen dynamischen Lastverteilung mittels Load Balancer.
|
||||
Analyse:
|
||||
Die fehlende Unterstützung der oben genannten nicht-funktionalen Anforderungen stellt ein erhebliches Risiko dar.
|
||||
Der Technologiestack von RNE CI umfasst unter anderem Wildfly 14.0.1 und MySQL 5.7. Der letztere wird nur bis 2023 unterstützt (vgl. https://endoflife.software/applications/databases/mysql). Für Wildfly 14.0.1 endet der reguläre Support im Februar 2023 (vgl. https://access.redhat.com/support/policy/updates/jboss_notes).
|
||||
Der Hauptanwendungsfall des RNE CI liegt auf der Integration der (unveränderten) Bestandssysteme in die TSI-Kommunikation. Dies erfolgt mithilfe der Konnektoren, Datenmappings und Routing-Regeln. Dies unterscheidet sich grundlegend vom Scope des Bestellsystems, das eine TAF/TAP-TSI-konforme Integration vom Vertrieb über den Fahrplan bis in den Betrieb ausgeht.
|
||||
Der Einsatz des RNE CI stellt ein hohes Risiko bzgl. der Flexibilität und Time-To-Market dar, da eine Unterstützung der neuen Funktionen und Fehlerbehebung stets seitens RNE erfolgen muss. Ein kritisches Bespiel hier ist die Unterstützung, der noch nicht final verabschiedeten CaseReference-Objekte, die für nationale Erweiterungen des TSI-Standards von entscheidender Bedeutung sind.
|
||||
Entscheidung:
|
||||
Für erste Tests mit Kommunikationspartnern kann das RNE CI für das neue Bestellsystem initial verwendet werden, um eine TSI-konforme Implementierung der Bestellsystem-CI sicherzustellen. Eine eigene DB Netz Implementierung sollte jedoch durch das Projekt sichergestellt werden.
|
||||
Begriffsdefinitionen:
|
||||
- TSI - Technical Specification for Interoperability
|
||||
- CRD - Common Repository Domain: Europa-weite Metadaten, die im Central Reference Files Database des RNE verwaltet werden. Der letztere wird häufig ebenfalls als CRD bezeichnet.
|
||||
- CA - Certification Authority: Service zur Ausgabe und Verifikation von digitalen Zertifikaten
|
||||
- CI - Common Interface: Spezifikation einer gemeinsamen Schnittstelle für den Austausch von TSI Nachrichten
|
||||
- RNE CI - Common Interface Reference Implementation: die von RNE entwickelte Integrationslösung für TAF/TAP TSI
|
||||
- CCS - Common Components System:Â
|
||||
- LI - Local Instance: eine konkrete Installation des RNE CI
|
||||
- UIC-Common Component: Synonym für RNE CI
|
||||
+27
@@ -0,0 +1,27 @@
|
||||
# 6.6 Anlagenportal Netz (APN+)
|
||||
|
||||
> Confluence Page ID: 27525850
|
||||
> Version: 11
|
||||
> Pfad: /pathOS/Start / Vorstudie Bestellsystem/00_Vorstudie Bestellsystem/6 IT Ist-Analyse/6.6 Anlagenportal Netz (APN+)
|
||||
> Labels:
|
||||
|
||||
---
|
||||
|
||||
Die Nutzung des Anlagenportal-Netz ist ein kostenloser Service, den die DB Netz AG allen Zugangsberechtigten anbietet. Diese beinhalten Abstell- und Zugbildungsanlagen, Zusatzausstattungen, Ladestellen und Dispositionsgleise. Diese können sowohl für das kommende Netzfahrplanjahr als auch im aktuellen und zukünftigen Gelegenheitsverkehr angemeldet bzw. bestellt werden.
|
||||
Anbei eine Ãbersicht über die Serviceeinrichtungen der DB Netz AG: Serviceeinrichtungen
|
||||
Die Suche nach Serviceeinrichtungen bietet einen Ãberblick über das gesamte Angebot an Serviceeinrichtungen. Als Nutzer hat man Einblick, in welcher Betriebsstelle welche Serviceeinrichtungen vorhanden sind, welche Ausstattungsmerkmale sie aufweisen und was ihre Nutzung kostet.
|
||||
Angebote
|
||||
In der Angebotsphase werden alle Angebote aus Anmeldungen zum Netzfahrplan je Kundennummer aufgelistet. Alle Serviceeinrichtungen können in der Detailsicht gesamthaft oder einzeln angenommen oder abgelehnt werden.
|
||||
Warenkorb
|
||||
In der Anmeldephase zum Netzfahrplan kann man Serviceeinrichtungen in den Warenkorb schieben, um sie dann gesammelt zu überprüfen, bevor sie final anmeldet werden. In der Navigation kann man direkt über den persönlichen Bereich zum Warenkorb gelangen oder nach Spezifikation der Anmeldedetails. Ãber die Ãnderungsfunktion im Warenkorb gelangt man zurück in die Anmeldedetails, um sie dort zu bearbeiten.
|
||||
|
||||
|
||||
## Ãberblick - Nutzungswünsche für Serviceeinrichtungen online anfragen
|
||||
|
||||
https://fahrweg.dbnetze.com/fahrweg-de/kunden/leistungen/anlagen/anlagenbestellung/anlagenportal_netz-1369304
|
||||
|
||||
|
||||
|
||||
|
||||
|
||||
Die Bestellung von Serviceeinrichtungen soll perspektivisch in das Bestellsystem übernommen werden, wird jedoch nicht Teil des MVPs sein.
|
||||
@@ -0,0 +1,22 @@
|
||||
# 9.2 Projekttools
|
||||
|
||||
> Confluence Page ID: 27525865
|
||||
> Version: 10
|
||||
> Pfad: /pathOS/Start / Vorstudie Bestellsystem/00_Vorstudie Bestellsystem/9 Weiteres Vorgehen und Kostenindikation/9.2 Projekttools
|
||||
> Labels:
|
||||
|
||||
---
|
||||
|
||||
In M31 werden folgende Tools verwendet:
|
||||
Â
|
||||
- SharePoint zur zentralen Dokumentenablage und zur gemeinsamen Dokumentenbearbeitung. Darüber hinaus Projektkalender und kurzfristige Ankündigungen sowie Linksammlung.
|
||||
- Jira als Sammlung des Product Backlogs mit Epics, Capabilities, Features/Enabler und Storys/Enabler. Darüber hinaus Erfassung von einzelnen Aufgaben, Bugs, Risiken und Impediments.
|
||||
- Zentrales Mail-Funktionspostfach mit diversen E-Mail-Verteilern je Team M31; dient u. A. zur Verteilung von regelmäÃigen Projekt-Statusmails an das Gesamtteam.
|
||||
- DB Planet für das Projektmarketing. In Zukunft ist geplant, hier auch eine eigene Bestellportal-Anwendergruppe zwecks Informationsaustausch und Diskussion zu etablieren.
|
||||
- TMT In Zukunft ist geplant für die Erfassung von Defects aus dem System- und Abnahmetest.
|
||||
- Ontrack als vom Konzern vorgegebenes neues Projektmanagementtool.
|
||||
- Wiki ConfluenceÂ
|
||||
|
||||
|
||||
|
||||
Eine Fortschrittsmessung erfolgt über Jira (Velocity, Story Points, Hit Rate etc.). Jira bietet dazu folgende Berichtsmöglichkeiten je Umsetzungsteam an, die z. T. in M31 auch genutzt werden: Burndown-Diagramm, Epic-Bericht, Epic-Burndown, Versionsbericht, Release-Burndown, Geschwindigkeits-Diagramm, Kontroll-Diagramm, Kumuliertes Flussdiagramm.
|
||||
@@ -0,0 +1,49 @@
|
||||
# 9.3 Mitarbeiter
|
||||
|
||||
> Confluence Page ID: 27525867
|
||||
> Version: 25
|
||||
> Pfad: /pathOS/Start / Vorstudie Bestellsystem/00_Vorstudie Bestellsystem/9 Weiteres Vorgehen und Kostenindikation/9.3 Mitarbeiter
|
||||
> Labels:
|
||||
|
||||
---
|
||||
|
||||
Mit Vereinbarung des Projektauftrags stehen alle anbei genannten Rollen im definierten Umfang für die gesamte Projektlaufzeit dem Projekt zur Verfügung. Der VzP-Anteil ist mit der operativen Planung der jeweiligen OEn abgestimmt. Berücksichtigt sind hierbei nur Ressourcen, die aus Projektsicht mindestens mit 20% VzP benötigt werden.Â
|
||||
Bei Ressourcenwechsel ist eine adäquate Vertretung mit gleichem VzP-Anteil zu benennen, so dass alle Rollen im genannten Projektzeitraum durchgängig besetzt sind.
|
||||
Die anbei aufgelisteten Ressourcen beziehen sich lediglich auf das Vorhaben zur Erstellung eines neuen Bestellsystems. Ggf. werden durch die Einrichtung eines neuen Release Trains "Vertrieb" nach der SAFe-Methodik, weitere Ressourcen notwendig. Diese sind in der nachfolgenden Abschätzung allerdings nicht enthalten, da zum Zeitpunkt der Abstimmung unklar ist, welchen Scope ein möglicher neuer Release Train abdecken soll.
|
||||
| | Bereich | Rolle | (Initiale) Besetzung | OrgE | Auslastung (VzP) | Kommentar
|
||||
| | Vertrieb | Product Manager | B. Schmücker | I.NMK 3 | 50% |
|
||||
|
||||
| | Vertrieb | Product Owner | B. Schmücker, N.N. | I.NMK 3 | 300% | 3 Umsetzungsteams
|
||||
| | Vertrieb | Mentor/Experte | diverse (Kundenbetreuer, Fahrplan-Mitarbeiter in den Regionen, u.ä.) | diverse | 50% | 0,5 VZP = 5 Pers. zu je 1 Tag/Monat
|
||||
| | Vertrieb | Change Manager | N.N. | I.NMK 3 | 50% |
|
||||
|
||||
| | Vertrieb | Fachliche BF | N.N. | I.NMK 3 | 20% |
|
||||
|
||||
| | CIO | Release Train Engineer | Holger Wiese | I.NVI 3 | 100% |
|
||||
|
||||
| | CIO | Scrum Master/PMO | A. Schäfer, (DBS/Extern) | I.NVI 31, extern | 200% | Jeder ScM übernimmt auch PMO-Aufgaben
|
||||
| | CIO | Anwendungsmanager (Projektbegleitung durch I.NVI 4) | extern | I.NVI 4 | 50% |
|
||||
|
||||
| | CIO | Solution Architect | H. Duis | I.NVI 2 | 20% |
|
||||
|
||||
Darüber hinaus steht eine Entscheidung bzgl. der Budgetierung des Projekts UGA (Umsetzung gesetzlicher Anforderungen) im Rahmen des aktuellen Planungsprozesses von I.NMK 3 noch aus. Es wird davon ausgegangen, dass mit diesem Projekt das Budget für 3 VZP von I.NMK bereitgestellt werden kann:
|
||||
- 0,5 VZP Product Manager
|
||||
- 2 VZP Product Owner
|
||||
- 0,5 VZP Change Manager
|
||||
Weitere Ressourcen sind demzufolge im Rahmen der BV zu berücksichtigen und zu beantragen.Â
|
||||
|
||||
|
||||
Darüber hinaus werden folgende Ressourcen im Bedarfsfall hinzugezogen:Â
|
||||
- Testmanager Automatisierung (I.NVI 3, ca. 10%)
|
||||
- Kostenstellenmanager (I.NVI 1, ca. 10%)
|
||||
|
||||
|
||||
Weitere Experten werden bedarfsabhängig hinzugezogen. Dies umfasst beispielsweise die Themengebiete:
|
||||
- Mitarbeiter aus den Regionalbereichen (insbesondere Kundenbetreuer)
|
||||
- Recht- und Regulierung
|
||||
- Fachbetriebsführung und Anwendungsmanagement weiterer Verfahren (TPN, APN,  etc.)
|
||||
- Fach- und IT-Architektur.
|
||||
Mit erfolgreichem Abschluss des Projekts und Ãberführung der Projektergebnisse in den produktiven Betrieb sind folgende Rollen entsprechend dem genannten VZP-Anteil in den jeweiligen Bereichen aufzubauen. Dieser Aufbau ist im Rahmen der Beschlussvorlage vor dem Projektbeginn berücksichtigt.
|
||||
| | Bereich | Rolle | (Initiale) Besetzung | OrgE | VZP-Anteil | Kommentar
|
||||
| | Vertrieb | Fachliche Betriebsführung | N.N. | I.NMK 3 | 100% | Productowner Bestellsystem
|
||||
| | CIO | Anwendungsmanager | N.N. | I.NVI 4 | 20% |
|
||||
+174
@@ -0,0 +1,174 @@
|
||||
# 9.4 Aufwands- und Kostenschätzung für das neue Bestellsystem
|
||||
|
||||
> Confluence Page ID: 27525869
|
||||
> Version: 65
|
||||
> Pfad: /pathOS/Start / Vorstudie Bestellsystem/00_Vorstudie Bestellsystem/9 Weiteres Vorgehen und Kostenindikation/9.4 Aufwands- und Kostenschätzung für das neue Bestellsystem
|
||||
> Labels:
|
||||
|
||||
---
|
||||
|
||||
## 9.4.1 Kostenindikation im Rahmen von Magic Estimation für das neue BestellsystemÂ
|
||||
|
||||
Am 20. und 21. August 2019 wurde im Rahmen eines zweitägigen Workshops mit der agilen Schätzmethodik Magic Estimation eine Kostenindikation für die voraussichtlichen Projektumsetzungs- und anschlieÃenden Betriebsführungskosten hergeleitet, die als Expertenschätzung zu bewerten ist. Als Baseline für die Schätzung wurde der zu diesem Zeitpunkt existierende Stand des Product Backlogs herangezogen, in dem sich zu dieser Zeit 75 Features befunden haben. Die Baseline der geschätzten Features lässt sich in einem entsprechenden Excel-Dokument nachvollziehen.
|
||||
Das Team, welches die Schätzung durchgeführt hat, bestand insgesamt aus 6 Personen (davon 4 projektexterne Personen), die unterschiedliche Kompetenzen aufweisen. Vertreten waren die Kompetenzen von Entwicklern, technischen Architekten sowie ein UX-Experte. Begleitet wurde die Schätzung vom Product Owner und den im Vorprojekt mitwirkenden Business Analysten, die insbesondere durch die Klärung von Verständnisfragen und Festlegung von fachlichen Annahmen, Unklarheiten im Rahmen der Schätzworkshops direkt auflösen konnten.
|
||||
Aufwände, die im Rahmen der Umsetzung eines Features enthalten sind und pro Feature ausgewiesen werden umfassen Tätigkeiten von
|
||||
- Scrum Master
|
||||
- Business Engineers
|
||||
- Technischen Architekten
|
||||
- EntwicklernÂ
|
||||
- Tester
|
||||
Der Aufwand und die Komplexität eines Features für die genannten Tätigkeiten wird anhand von T-Shirt-GröÃen eingeschätzt, die anschlieÃend in Story Points umgerechnet werden:
|
||||
| | T-Shirt-GröÃe | Story Points
|
||||
| | XS | 10
|
||||
| | S | 15
|
||||
| | M- | 35
|
||||
| | M | 60
|
||||
| | M+ | 90
|
||||
| | L | 115
|
||||
| | XL | 300
|
||||
|
||||
Um eine Abschätzung zu erhalten, wie viel Personentage sich ungefähr hinter einem Story Point verbergen, wurden 4 Referenz-Features aus einem TPN-Projekt vom Expertenteam geschätzt. Da für diese Referenz-Features die tatsächlichen Umsetzungskosten bekannt sind, lässt sich hierdurch eine Umrechnung herleiten. Es ergibt sich ein Umrechnungsfaktor von 2,27 PT pro Story Point. Die vollständige Herleitung und Umrechnung lässt sich im Dokument FeatureListeBestellSystem_Schätzung sowie im Begleitdokument Bestellsystem - Magic Estimation Ergebnisse nachvollziehen.
|
||||
Darüber hinaus wurde ein durchschnittlicher Tagessatz pro PT hergleitet, indem die aktuellen Ressourcen-Kosten eines Scrum Masters, Business Engineers, technischer Architekt, Entwickler und Tester, entsprechend der DB Systel Tagessätze gemittelt wurden. Es ergibt sich ein Kostensatz in Höhe von 952 EUR pro PT. Auch diese Herleitung kann in den zuvor genannten Dokumenten nachvollzogen werden.
|
||||
Darüber hinaus wurden Aufwände ermittelt, die als Aufschlag in der Kostenindikation ausgewiesen werden. Diese umfassen
|
||||
- Release-Kosten (Annahme: 4 Releases)
|
||||
- LuP Test (Annahme: Durchführung pro Release)
|
||||
- Pentest (Annahme: Durchführung pro Release)
|
||||
- Umgebungskosten (während der Projektlaufzeit)
|
||||
- technische Betriebsführung (von 11/ 2022 - 04/ 2023)
|
||||
- SAFe Organisation (Aufwände für Ressourcen auf Release Train Ebene, 2 Systemarchitekten, 1 Projektleiter, 1 Testmanager, durchschnittlicher Tagessatz 1.213,50 EUR)
|
||||
- Einheitsaufschlag DB Systel / Querschnittskosten (Annahme: 10% der Features, Onboarding und SAFe Organisation)
|
||||
- Aufwände für On- und Offboarding von Mitarbeitern während der Projektlaufzeit (Annahme: 10% der Feature-Kosten)
|
||||
- Umsetzungspuffer (Annahme: 15 % der Feature-Kosten)
|
||||
- Risikoaufschlag (Annahme: 10% der Gesamtkosten)
|
||||
|
||||
|
||||
In Summe ergeben sich durch diese Kostenindikation Gesamtkosten in Höhe von ca. 24.035.000 EUR*, die sich wie folgt aufgliedern:
|
||||
| | Position | Betrag | Annahmen
|
||||
| | Umsetzungskosten (Features) Bestellsystem | 12.020.485 EUR | Features enthalten die Aufwände für Umsetzung und Test, inkl. BE, TA, SM, Tester
|
||||
| | Release-Kosten | 120.000 EUR | Pro Release, Annahme - Defekt und Analyseunterstützung durch Entwicklung
|
||||
| | Lup Test, Pen-Test | 400.000 EUR |
|
||||
LuP Test enthält Personalkosten zur Vorbereitung, durchführung und Betreuung pro Release;
|
||||
Pentest erfolgt im Rahmen von Releases und enthält die Sicherheitsanalyse sowie externe Diensteistungen für die Durchführung
|
||||
| | Umgebungskosten | 1.038.000 EUR | bis einschl. Ende 2023
|
||||
| | Technische Betriebsführungskosten (von 11/ 2022 - 04/ 2023) | 125.000 EUR | 6 Monaten - Nur für Produktionsumgebung
|
||||
| | Ressourcen für SAFe Organisation | 3.300.720 EUR | Safe Organisation 40 Monaten - 01.2020-04.2023Â
|
||||
| | Einheitsaufschlag DB Systel | 1.652.000 EUR |
|
||||
|
||||
| | Puffer (Onboarding/ Offboarding + Umsetzungspuffer) | 3.194.000 EUR |
|
||||
|
||||
| | Risikoaufschlag | 2.185.000 EUR |
|
||||
|
||||
| | Summe Kostenindikation Gesamtkosten | 24.035.000 EUR* |
|
||||
|
||||
*) Keine Erhöhungen der Tagessätze in Folge der Projektlaufzeit berücksichtigt
|
||||
## 9.4.2 Team-Zusammenstellung-Personalkosten
|
||||
|
||||
Entsprechend der vorangegangenen methodischen Kostenindikation unter 9.4.1 kann die nachfolgende Team-Zusammenstellung für die Projektumsetzungsphase empfohlen werden. Durch diese Team-Zusammenstellung konnte eine alternative, grobe Kostenindikation angenähert werden, die die oben genannte Indikation plausibilisieren konnte. Â
|
||||
Hieraus lässt sich im Zeitraum 01/ 2020 - 04/ 2023 eine Gesamtsumme von 25,1 Mio. EURO für Personalkosten herleiten. Die detaillierte Herleitung kann im Dokument Kalkulation_Ressourcen_Bestellsystem nachvollzogen werden.
|
||||
Team 1Â
|
||||
| | Ressource | Einsatz ab | Einsatz bis | VzP
|
||||
| | Business Analyst | 15.01.2020 | 30.04.2023 | 1
|
||||
| | Technischer Architekt | 15.01.2020 | 30.04.2023 | 1
|
||||
| | Backend-Entwickler | 15.01.2020 | 30.04.2023 | 1
|
||||
| | Backend-Entwickler | 15.01.2020 | 30.04.2023 | 1
|
||||
| | Backend-Entwickler | 15.01.2020 | 30.04.2023 | 1
|
||||
| | Backend-Entwickler | 15.01.2020 | 30.04.2023 | 1
|
||||
| | Backend-Entwickler | 15.01.2020 | 30.04.2023 | 1
|
||||
| | Tester | 15.01.2020 | 30.04.2023 | 1
|
||||
| | Scrum Master | 15.01.2020 | 30.04.2023 | 1
|
||||
Team 2
|
||||
| | Ressource | Einsatz ab | Einsatz bis | VzP
|
||||
| | Business Analyst | 15.01.2020 | 30.04.2023 | 1
|
||||
| | Technischer Architekt | 15.01.2020 | 30.04.2023 | 1
|
||||
| | UI-Entwickler | 15.01.2020 | 30.04.2023 | 1
|
||||
| | UI-Entwickler | 15.01.2020 | 30.04.2023 | 1
|
||||
| | UI-Entwickler | 15.01.2020 | 30.04.2023 | 1
|
||||
| | Backend-Entwickler | 15.01.2020 | 30.04.2023 | 1
|
||||
| | Tester | 15.01.2020 | 30.04.2023 | 1
|
||||
| | Scrum Master | 15.01.2020 | 30.04.2023 | 1
|
||||
|
||||
|
||||
|
||||
Team 3
|
||||
| | Ressource | Einsatz ab | Einsatz bis | VzP
|
||||
| | Business Analyst | 01.09.2020 | 30.04.2023 | 1
|
||||
| | Technischer Architekt | 01.09.2020 | 30.04.2023 | 1
|
||||
| | UI-Entwickler | 01.09.2020 | 30.04.2023 | 1
|
||||
| | UI-Entwickler | 01.09.2020 | 30.04.2023 | 1
|
||||
| | Backend-Entwickler | 01.09.2020 | 30.04.2023 | 1
|
||||
| | Backend-Entwickler | 01.09.2020 | 30.04.2023 | 1
|
||||
| | Tester | 01.09.2020 | 30.04.2023 | 1
|
||||
| | Scrum Master | 01.09.2020 | 30.04.2023 | 1
|
||||
|
||||
|
||||
Querschnitt-Ressourcen
|
||||
| | Ressource | Einsatz ab | Einsatz bis | VzP
|
||||
| | UX-Designer | 15.01.2020 | 30.04.2023 | 1
|
||||
| | Solution Architect | 15.01.2020 | 30.04.2023 | 1
|
||||
| | Change Manager | 15.01.2021 | 30.04.2023 | 0,75
|
||||
| | Anwendungsmanager
|
||||
(Projektbegleitung durch I.NVI 4) | 15.01.2020 | 30.04.2023 | 0,5
|
||||
##
|
||||
9.4.3 Aktivierbarkeit
|
||||
|
||||
In Zusammenarbeit mit der Anlagenbuchhaltung (I.NPB) wurde im Rahmen der Konzeptionsphase festgestellt, dass die gesamte Projektumsetzungsphase (Januar 2020 - einschlieÃlich März 2023) zur Erstellung eines Bestellsystems als aktivierbar eingestuft wird. Von den in diesem Zeitraum anfallenden Aufwänden sind keine Teile ausgenommen.
|
||||
DB Netz interne Ressourcen sind aus diesem Grund in der Projektkalkulation zu berücksichtigen und als GWU-erhöhende Positionen im Rahmen der Beschlussvorlage einzubringen. Notwendig werdende Folgeaktivitäten sind im Rahmen des Umsetzungsprojekts durchzuführen, hierzu zählen u.a. AIB-Nr. beantragen, aktivierungsfähige Kostenstellen beantrage, Tool FAA einrichten und Mitarbeitern zur Verfügung stellen.
|
||||
Die Bewertung wurde auf Basis einer Checkliste zur Bewertung von Aktivierbaren Eigenleistungen durchgeführt, die von der Anlagenbuchhaltung zur Verfügung und abschlieÃend bewertet wurde. Diese ist zu Dokumentationszwecken auf dem Sharepoint abgelegt.
|
||||
Es sind daher für folgende Ressourcen die zu berücksichtigenden Kosten zu berechnen. Diese belaufen sich im Zeitraum 01/ 2020 - 04/ 2023 auf insgesamt etwa 2.770.000 EUR, die detaillierte Herleitung kann im Dokument Kalkulation_Ressourcen_Bestellsystem nachvollzogen werden.
|
||||
|
||||
|
||||
| | Ressouce | Organisationseinheit | Einsatz ab | Einsatz bis | VzP
|
||||
| | Release Train Engineer | I.NVI | 01.01.2020 |
|
||||
30.04.2023 |
|
||||
1
|
||||
| | Scrum Master | I.NVI | 01.01.2020 |
|
||||
30.04.2023 |
|
||||
1
|
||||
| | Product Owner | I.NMK | 01.01.2020 | 30.04.2023 | 1
|
||||
| | Product Owner | I.NMK | 01.01.2020 | 30.04.2023 | 1
|
||||
| | Product Owner | I.NMK | 01.01.2020 | 30.04.2023 | 1
|
||||
| | Product Manager | I.NMK | 01.01.2020 | 30.04.2023 | 0,5
|
||||
| | Change Manager | I.NMK | 01.01.2020 | 30.04.2023 |
|
||||
0,5
|
||||
|
||||
|
||||
## 9.4.4 Ermittlung der Gesamtkosten für das Umsetzungsprojekt von 01/ 2020 - 04/ 2023
|
||||
|
||||
|
||||
|
||||
| | Position | Betrag
|
||||
| | Umsetzungskosten im Zeitraum 01/ 2020 - 04/ 2023 | 18.695.000 EUR*
|
||||
| | Einheitsaufschlag DB Systel (Annahme: 6%) | 1.122.000 EUR
|
||||
| | Puffer (Annahme: 15 % der Umsetzungskosten) | 2.804.000 EUR
|
||||
| | Release-Kosten (inkl. LuP + Pentest) | 520.000 EUR
|
||||
| | Umgebungskosten | 1.038.000 EUR
|
||||
| | Technische Betriebsführungskosten (von 11/ 2022 - 04/ 2023) | 125.000 EUR
|
||||
| |
|
||||
Zulieferung von Projekt M13 | 1.000.000 EUR
|
||||
| |
|
||||
Zulieferung von Projekt AC-Trasse | 260.000 EUR
|
||||
| | Zulieferung von CST (KDV + BBZ) | 70.000 EUR
|
||||
| | PGM (Annahme: 150 TEUR/ Jahr) | 500.000 EUR
|
||||
| | Miete (Annahme: 150 TEUR/ Jahr) | 500.000 EUR
|
||||
| | Schulung |
|
||||
-*
|
||||
| | Aktivierbare Eigenleistungen | 2.770.000 EUR*
|
||||
| |
|
||||
SUMME |
|
||||
29.405.034 EUR*
|
||||
*) Aus Projektsicht keine Anwenderschulungen notwendig. Keine Erhöhungen der Tagessätze in Folge der Projektlaufzeit berücksichtigt.
|
||||
## 9.4.5. Kosten für den Betrieb ab 05/ 2023Â
|
||||
|
||||
Eine detaillierte Herleitung der ab 05/ 2023 jährlich anfallenden Wartungs- und Betriebsführungskosten kann im Dokument Kalkulation_Sheet RUN-Kosten nachvollzogen werden. Nicht-Produktivumgebungen werden nach anteiliger Bedarfsabschätzung nicht durchgängig bereitgestellt.Â
|
||||
|
||||
| | Position | ab 05/2023 | Betrag 2024 | Betrag 2025
|
||||
| | Technische Betriebsführung Bestellsystem |
|
||||
| 670.000,00 EUR | 670.000,00 EUR
|
||||
| | Wartungskosten Bestellsystem |
|
||||
| 3.406.241EUR | 2.806.669 EUR
|
||||
| | Betreuungsaufwand I.NVI 4 |
|
||||
| 2 VZP (240.000 EUR) |
|
||||
|
||||
|
||||
Basiswert Wartungskosten Bestellportal
|
||||
[Annahme: Steigerung um 3% pro Jahr - Verlagerung aus Basiswert]
|
||||
@@ -0,0 +1,114 @@
|
||||
# 12 Anhang
|
||||
|
||||
> Confluence Page ID: 27525871
|
||||
> Version: 40
|
||||
> Pfad: /pathOS/Start / Vorstudie Bestellsystem/00_Vorstudie Bestellsystem/12 Anhang
|
||||
> Labels:
|
||||
|
||||
---
|
||||
|
||||
## 12.1 Referenzdokumente
|
||||
|
||||
Liste aller referenzierten Dokumente wie fachliche Anforderungen oder Schätzdokument, aus dem Kosten und Zeiten für Bewertung übernommen wurde. Quellenangabe der verwendeten Gesetze, Normen und Richtlinien
|
||||
Alle referenzierten Dokumente sind mit der Vorstudie bereit zu stellen â bei umfangreichen DoÂkumenten die relevanten Ausschnitte oder Verlinkungen.
|
||||
Es gibt 3 wesentliche Quellen:
|
||||
-     Die Vorstudie wird in Confluence (Kürzel âWikiâ) beschrieben: LINK WIKI
|
||||
-     Weitere Dokumente liegen im Sharepoint (Kürzel âSPâ): LINK SP
|
||||
-     Die Modellierung erfolgt im Enterprise-Architekt - Kürzel âEAMâ) unter âProjekte\Plan- Phase\Bestellsystemâ. LINK EAM
|
||||
Â
|
||||
| |
|
||||
Nr. |
|
||||
Inhalt |
|
||||
Dateiname/Link
|
||||
| |
|
||||
1 |
|
||||
Anforderungen Bestellsystem: |
|
||||
Baseline_Anforderungen Export aus JIRAÂ
|
||||
| |
|
||||
2 |
|
||||
Nichtfunktionale Anforderungen an das Bestellsystem: |
|
||||
Nichtfunktionale Anforderungen Bestellsystem
|
||||
| |
|
||||
3 |
|
||||
Schutzbedarfsfeststellung und Restrisikodeklaration- BS-Z: |
|
||||
Link zu risk2valueÂ
|
||||
| |
|
||||
4 |
|
||||
Aufwand und Kostenschätzung für das neue Bestellsystem:Â
|
||||
 |
|
||||
Kalkulation_Ressourcen_BestellsystemÂ
|
||||
FeatureListeBestellSystem_Schätzung
|
||||
Bestellsystem - Magic Estimation Ergebnisse;Â
|
||||
Kalkulation_Sheet RUN-Kosten.
|
||||
Â
|
||||
| |
|
||||
5 |
|
||||
Schnittstellen Bestellsystem:Â |
|
||||
Excel Datei "Schnittstellendokumentation Vorprojekt Bestellsystem"Â
|
||||
Â
|
||||
| |
|
||||
6 |
|
||||
EAM Bestellsystem:Â Â
|
||||
 |
|
||||
Neues Bestellsystem Systemkontext.pdf,Â
|
||||
Neues Bestellsystem Architektur in EAM;Â
|
||||
Â
|
||||
| |
|
||||
7 |
|
||||
Architekturweiche:Â Â |
|
||||
LinkÂ
|
||||
| |
|
||||
8 |
|
||||
TAF/TAP TSI : |
|
||||
Link
|
||||
Schnittstellendokumentation zu TAF/TAP TSIÂ Â
|
||||
Anlage 1 der EVU SST und das TAF/TAP TSI Konzept
|
||||
Annex_8.4-TrainID-CaseReferenceFramework_
|
||||
Â
|
||||
| |
|
||||
Â
|
||||
9
|
||||
Â
|
||||
Â
|
||||
 |
|
||||
EAM Die IT Bebauung wird in einem EAM-Modell |
|
||||
(EAM.eap)Â :
|
||||
Domänenmodell,Â
|
||||
2-DB Netz IT Anwendungen Primärverortung.pdfÂ
|
||||
IST Bebauungspläne -Kapazität und Fahrplanmanagement.pdf
|
||||
Bebauungspläne -Kudeninteraktion - Vertrieb.pdf
|
||||
| |
|
||||
10 |
|
||||
Ãbergreifendes Fachliches Objektmodell (FOM)
|
||||
 |
|
||||
Objektlandkarte - Ãbersicht.pdfÂ
|
||||
Â
|
||||
| |
|
||||
11 |
|
||||
Prozessportal DB Netz: |
|
||||
 Prozessportal der DB Netz AG
|
||||
| |
|
||||
12 |
|
||||
IT IST Analyse:
|
||||
TPN Architekturbeschreibung
|
||||
TPN Schnittstellenbeschreibungen
|
||||
Kaufmännische Systeme, Trassenpreissystem, Schmerzpunkte TPN-GFD-Z |
|
||||
Link Sharepoint.
|
||||
Â
|
||||
| |
|
||||
13 |
|
||||
Fachkonzept Value Stream FIB
|
||||
 |
|
||||
 Value Stream FIB_Fachkonzept.doc;
|
||||
Â
|
||||
Â
|
||||
| |
|
||||
14 |
|
||||
Weitere Konzepte |
|
||||
DB Systel Technologie-RadarsÂ
|
||||
Agiles Testkonzept.docx
|
||||
Â
|
||||
|
||||
|
||||
Â
|
||||
Â
|
||||
@@ -0,0 +1,74 @@
|
||||
# 13 Abnahmeerklärungen
|
||||
|
||||
> Confluence Page ID: 27525874
|
||||
> Version: 3
|
||||
> Pfad: /pathOS/Start / Vorstudie Bestellsystem/00_Vorstudie Bestellsystem/13 Abnahmeerklärungen
|
||||
> Labels:
|
||||
|
||||
---
|
||||
|
||||
| |
|
||||
Besteller/Auftraggeber |
|
||||
 |
|
||||
 |
|
||||
 |
|
||||
 |
|
||||
 |
|
||||
Â
|
||||
| |
|
||||
 |
|
||||
 |
|
||||
OE |
|
||||
 |
|
||||
Datum |
|
||||
 |
|
||||
Unterschrift (zwingend erforderlich)
|
||||
| |
|
||||
CIO |
|
||||
 |
|
||||
 |
|
||||
 |
|
||||
 |
|
||||
 |
|
||||
Â
|
||||
| |
|
||||
 |
|
||||
 |
|
||||
OE |
|
||||
 |
|
||||
Datum |
|
||||
 |
|
||||
Unterschrift (zwingend erforderlich)
|
||||
| |
|
||||
Stakeholder gem. 2.1 |
|
||||
 |
|
||||
 |
|
||||
 |
|
||||
 |
|
||||
 |
|
||||
Â
|
||||
| |
|
||||
 |
|
||||
 |
|
||||
OE |
|
||||
 |
|
||||
Datum |
|
||||
 |
|
||||
Unterschrift
|
||||
| |
|
||||
Stakeholder gem. 2.1 |
|
||||
 |
|
||||
 |
|
||||
 |
|
||||
 |
|
||||
 |
|
||||
Â
|
||||
| |
|
||||
 |
|
||||
 |
|
||||
OE |
|
||||
 |
|
||||
Datum |
|
||||
 |
|
||||
Unterschrift
|
||||
## Â
|
||||
+70
@@ -0,0 +1,70 @@
|
||||
# 2018-12-06 Besprechungsnotizen
|
||||
|
||||
> Confluence Page ID: 27525877
|
||||
> Version: 2
|
||||
> Pfad: /pathOS/Start / Vorstudie Bestellsystem/00_Vorstudie Bestellsystem/14 Besprechungsnotizen Vorstudie/2018-12-06 Besprechungsnotizen
|
||||
> Labels: meeting-notes
|
||||
|
||||
---
|
||||
|
||||
## Datum
|
||||
|
||||
|
||||
## Teilnehmer
|
||||
|
||||
-
|
||||
 Â
|
||||
-
|
||||
Patrick Breun, Jürgen Sievers
|
||||
## Ziele
|
||||
|
||||
-
|
||||
- Methode im Vorgehen: IT Phasenmodell und Vorgehen im FIB (Feature-Readyness)
|
||||
- Verantwortungen
|
||||
- Einsatz Coach Hr. Buse
|
||||
- Termine
|
||||
- Optional: Multi-Kanal Architektur
|
||||
- Gemeinsame Schnittstelle mit dem Betrieb
|
||||
## Diskussionspunkte
|
||||
|
||||
## Methode im Vorgehen
|
||||
|
||||
Das Bestellportal läuft unter der Betreuung im FIB
|
||||
Als Vorgehen soll die Methode des  Agiles Vorprojektes, mit Workshops und dem typischen Ablauf im IT-Phasenmodell, angewendet werden.
|
||||
QG Idee ist noch nicht durchschritten. Dieses soll Anfang März durschritten werden.
|
||||
## Verantwortungen
|
||||
|
||||
PO soll Benjamin Schmücker sein.
|
||||
|
||||
5
|
||||
complete
|
||||
Von Analtol Scholz erfolgt eine Zulieferung zu Ansprechpartnern zu den Geschäftsobjekten (darunter verstehe ich einen Ansprechpartner für die Themen Fahrlagen-/Trassenverwaltung und Auftragssteuerung) -> In dem Thema Geschäftsobjekte ist I.NMF1 in der Verantwortung; Todo: Patrick Breun à Stand: Anatol hat die Suche angestoÃen, Rückmeldung noch offen
|
||||
|
||||
|
||||
6
|
||||
incomplete
|
||||
Hierzu ist auch die I.NVI5 mit einzubinden um die Zuarbeit zu konkretisieren -> ToDo: Patrick Breun bitte auf Rüdiger Wenig zugehen à ehrlicherweise kann ich mit diesem ToDo gerade wenig anfangen. Was genau ist damit gemeint?
|
||||
|
||||
|
||||
## Einsatz Coach Hr. Buse
|
||||
|
||||
An einer Beauftragung von Herrn Buse besteht kein Interesse und leider auch kein Budget. Das Vorhaben ist eng geplant und daher ist die Beauftragung eines Coaches schwierig in der Umsetzung.
|
||||
## Gemeinsame Schnittstelle TAF/TAP/TSI
|
||||
|
||||
Zuerst als eine fachliche Schnittstelle betrachten und im laufe des Vorprojektes die konkrete Umsetzung und den Schnitt Vertrieb/Produktion betrachten.
|
||||
|
||||
7
|
||||
incomplete
|
||||
Termin zur EU Vorab-Kommunikation in den Terminplan aufnehmen. Detailtiefe der Vorab-Kommunikation muss bestimmt werden. Todo: Patrik Breun
|
||||
|
||||
|
||||
Es ist auch der Ergebnistyp der Vorab-Kommunikation zu bestimmen.
|
||||
Da der Termin aktuell grob mit Anfang/Mitte Q2/2019 abgegeben ist und damit noch vor QG Plan liegt ist dieses bitte als Abhängigkeit/Risiko gesondert im FIB zu betrachten und im Backlog des PO eintragen sein.
|
||||
Die Vorab-Kommunikation muss über den I.NMK als Anforderung eingereicht werden.
|
||||
## Multi-Kanal Architektur
|
||||
|
||||
Multikanal- Architektur bitte mit einplanen. Im Rahmen der Vorstudie sollen die zu bedienen den Kanäle genauer betrachtet werden.
|
||||
|
||||
## Sonstiges
|
||||
|
||||
Für die BusinessAnalyse und EnterpriseArchitektur stellt I.NVI 2 jeweils Mitarbeiter zu 40PT (= insgesamt 80 PT in 2019 für die Restarbeiten Idee und agiles Vorprojekt) bereit.
|
||||
@@ -0,0 +1,10 @@
|
||||
# QualityGates
|
||||
|
||||
> Confluence Page ID: 27525880
|
||||
> Version: 4
|
||||
> Pfad: /pathOS/Start / Vorstudie Bestellsystem/QualityGates
|
||||
> Labels:
|
||||
|
||||
---
|
||||
|
||||
|
||||
+46
@@ -0,0 +1,46 @@
|
||||
# 2018-11-27 Besprechungsnotizen
|
||||
|
||||
> Confluence Page ID: 27525893
|
||||
> Version: 2
|
||||
> Pfad: /pathOS/Start / Vorstudie Bestellsystem/00_Vorstudie Bestellsystem/14 Besprechungsnotizen Vorstudie/2018-11-27 Besprechungsnotizen
|
||||
> Labels: meeting-notes
|
||||
|
||||
---
|
||||
|
||||
## Datum
|
||||
|
||||
|
||||
## Teilnehmer
|
||||
|
||||
-
|
||||
|
||||
-
|
||||
|
||||
-
|
||||
-
|
||||
## Ziele
|
||||
|
||||
- Durchsprache der Inhalte QG Idee
|
||||
- Einigung auf Tooling
|
||||
- Nächste Schritte festlegen
|
||||
## Handlungspunkte
|
||||
|
||||
|
||||
1
|
||||
complete
|
||||
Confluence einrichten und Berechtigungen verteilen
|
||||
|
||||
|
||||
8
|
||||
complete
|
||||
Kurzbeschreibung für GBR erstellen
|
||||
|
||||
|
||||
9
|
||||
complete
|
||||
Ideenportaleintrag einrichten (Name Projekt und Verantwortlichkeiten)
|
||||
|
||||
|
||||
|
||||
|
||||
Mit Erstellen der Inhalte für QG Idee wird ab sofort begonnen.
|
||||
@@ -0,0 +1,11 @@
|
||||
# Besprechungsnotizen
|
||||
|
||||
> Confluence Page ID: 27525896
|
||||
> Version: 4
|
||||
> Pfad: /pathOS/Kommunikationskanäle, Termine, Besprechungsnotizen pathOS/Besprechungsnotizen
|
||||
> Labels:
|
||||
|
||||
---
|
||||
|
||||
Alle Besprechungsnotizen
|
||||
com.atlassian.confluence.plugins.confluence-business-blueprints:meeting-notes-blueprinte2019063-378a-47e1-8eeb-120824c6d610meeting-notesPlan your meetings and share notes and actions with your team.Meeting notesCreate meeting notemeeting-notes
|
||||
+10
@@ -0,0 +1,10 @@
|
||||
# 00_Vorstudie Bestellsystem
|
||||
|
||||
> Confluence Page ID: 27525916
|
||||
> Version: 5
|
||||
> Pfad: /pathOS/Start / Vorstudie Bestellsystem/00_Vorstudie Bestellsystem
|
||||
> Labels:
|
||||
|
||||
---
|
||||
|
||||
|
||||
@@ -0,0 +1,10 @@
|
||||
# 2 Rahmenbedingungen
|
||||
|
||||
> Confluence Page ID: 27525932
|
||||
> Version: 2
|
||||
> Pfad: /pathOS/Start / Vorstudie Bestellsystem/00_Vorstudie Bestellsystem/2 Rahmenbedingungen
|
||||
> Labels:
|
||||
|
||||
---
|
||||
|
||||
|
||||
+42
@@ -0,0 +1,42 @@
|
||||
# 1.6 Roadmap und Meilensteine
|
||||
|
||||
> Confluence Page ID: 27525934
|
||||
> Version: 34
|
||||
> Pfad: /pathOS/Start / Vorstudie Bestellsystem/00_Vorstudie Bestellsystem/1 Ziele des Projekts/1.6 Roadmap und Meilensteine
|
||||
> Labels:
|
||||
|
||||
---
|
||||
|
||||
## 1.6.1 Roadmap Umsetzungsprojekt 2020 - 2023
|
||||
|
||||
Die Umsetzungsphase für das Projekt zur Erstellung eines neuen Bestellsystems, sowie die Implementierung einer TAF/TAP-TSI konformen EVU-Schnittstelle ("EVU Schnittstelle 4.0") soll ab Januar 2020 beginnen.
|
||||
Es sind folgende fachliche Meilensteine definiert:
|
||||
- März 2023: Mit Beginn der Anmeldephase für den Netzfahrplan 2024 müssen das Bestellportal und die EVU-Schnittstelle TAF/TAP-konform produktiv zur Verfügung stehen zur Unterstützung des Geschäftsprozesses für den Netzfahrplan.Â
|
||||
- April 2023: Die Funktionsmodule für die Anmeldungen im Gelegenheitsverkehr müssen ab Ende der Anmeldephase des Netzfahrplans 2024 im April 2023 produktiv sein.
|
||||
- Juli 2023: Die Funktionalitäten zur Anmeldung von Fahrplanstudien für den Netzfahrplan 2025 müssen ab Juli 2023 produktiv zur Verfügung stehen.
|
||||
Die Umsetzung des neuen Bestellsystems bis März 2023 erfolgt nach SAFe-Methodik im Rahmen von 13 Program Increments (PIs) mit einer Dauer von jeweils 3 Monaten. Die Umsetzungsdauer der 4 Sprints pro PI beträgt drei Wochen. Es wird von einem Start der Umsetzung Anfang Januar 2020 ausgegangen:
|
||||
- PI 1:Â Â Â 01/ 2020 â 03/ 2020
|
||||
- PI 2:Â Â Â 04/ 2020 â 06/ 2020
|
||||
- PI 3:Â Â Â 07/ 2020 - 09/ 2020
|
||||
- PI 4:Â Â Â 10/ 2020 â 12/ 2020
|
||||
- PI 5:Â Â Â 01/ 2021 â 03/ 2021
|
||||
- PI 6:Â Â Â 04/ 2021 â 06/ 2021
|
||||
- PI 7:Â Â Â 07/ 2021 - 09/ 2021
|
||||
- PI 8:Â Â Â 10/ 2021 â 12/ 2021
|
||||
- PI 9:Â Â Â 01/ 2022 â 03/ 2022
|
||||
- PI 10:Â 04/ 2022 â 06/ 2022
|
||||
- PI 11:Â 07/ 2022 - 09/ 2022
|
||||
- PI 12:Â 10/ 2022 â 12/ 2022
|
||||
- PI 13:Â 01/ 2023 â 03/ 2023
|
||||
Die datumsscharfe PI-Planung ist im Rahmen des Umsetzungsprojekt ab 2020 zu terminieren.
|
||||
Für die Umsetzung des Vorhabens zur Erstellung eines neuen (Trassen-)Bestellsystems können folgende Produkt-Inkrement auf die PI-Sprints aufgeteilt werden. Diese Planung im Rahmen der PI-Plannings mit dem Projekt BaDiFa abzustimmen.
|
||||
Anhand der im Product Backlog definierten Capabilites wird folgende Gesamt-Projektplanung angestrebt:
|
||||
|
||||
|
||||
## 1.6.2 Roadmap Vorstudie 2019
|
||||
|
||||
Für den Zeitraum des Vorprojekt von Januar - Oktober 2019 wurde folgende aggregierte Zeitplanung aufgestellt. Diese leitet sich aus der detaillierten Roadmap ab, die hier aufgerufen werden kann.Â
|
||||
|
||||
|
||||
|
||||
Für die Erstellung der Beschlussvorlage wird zudem folgende Zeitplanung zugrunde gelegt:Â
|
||||
@@ -0,0 +1,93 @@
|
||||
# 2.1 Stakeholderanalyse
|
||||
|
||||
> Confluence Page ID: 27525936
|
||||
> Version: 39
|
||||
> Pfad: /pathOS/Start / Vorstudie Bestellsystem/00_Vorstudie Bestellsystem/2 Rahmenbedingungen/2.1 Stakeholderanalyse
|
||||
> Labels:
|
||||
|
||||
---
|
||||
|
||||
Im folgenden eine Auflistung der für das Projekt zur Erstellung eines neuen Bestellsystems relevanten Stakeholder, aufgeschlüsselt nach den Kategorien Leitungsebene, Anwendergruppe und Sonstige. In der Spalte Kommunikation im Projekt wird die angedachte Kommunikation mit dem jeweiligen Stakeholder beschrieben, teilweise startet diese Kommunikation erst nach dem Vorprojekt, also erst im eigentlichen Umsetzungsprojekt.
|
||||
|
||||
|
||||
| | OE | Stakeholder (Beschreibung/ Rolle) | Stakeholder in Person | Kategorie | Einfluà | Interesse | Typ |
|
||||
Einbindung in Projekt
|
||||
| | I.NM | Leiter Vertrieb & Fahrplan | Dr. Thomas Schaffer | Leitungsebene | hoch | mittel | Topmanagement | Einbindung über Value Stream FIB-Programmstrukturen (FIB-Leitungsboard)
|
||||
| | I.NMF | Leiter Fahrplan und Kapazitätsmanagement | Dr. Michael Beck | Leitungsebene | hoch | gering | Topmanagement | Einbindung über Value Stream FIB-Programmstrukturen (FIB-Leitungsboard)
|
||||
|
||||
| | I.NMK | Leiterin Marketing und Vertrieb | Marion Brückmann | Leitungsebene | hoch | hoch | Topmanagement | Einbindung über Value Stream FIB-Programmstrukturen (FIB-Leitungsboard)
|
||||
| | I.NVI | CIO DB Netz AG | Dr. Jürgen Antes | Leitungsebene | hoch | mittel | Topmanagement |
|
||||
Quality Gate Board, Freigabe Konzernanmeldung
|
||||
Einbindung über Value Stream FIB-Programmstrukturen (FIB-Leitungsboard)
|
||||
| | TO | CIO DB Konzern | Christa Koenen | Leitungsebene | hoch | gering | Topmanagement | Einbindung über Konzernanmeldung des Projekts bei TO (im Anschluss an QG Plan)
|
||||
| | I.NMN | Leiter Netzzugangsrecht und Regulierung | Dr. Johannes Berg | Leitungsebene | hoch | mittel | Topmanagement | Einbindung über gezielte Informationsveranstaltung
|
||||
| | I.NMK 3 | Leiter Vertriebssysteme DB Netz (FB) | Ralph Grassel | Leitungsebene | hoch | hoch | Entscheider |
|
||||
Einbindung über Value Stream FIB-Programmstrukturen (FIB-Leitungsboard)
|
||||
Einbindung über PI-Sprint Planning, PI-Sprint Review
|
||||
| | I.NMK 3 (I) | Leiter Anforderungsmanagement DB Netz Vertrieb | Jens Miehlnickel | Leitungsebene | mittel | hoch | Entscheider |
|
||||
Einbindung über Value Stream FIB-Programmstrukturen (FIB-Leitungsboard)
|
||||
Einbindung über PI-Sprint Planning, PI-Sprint Review
|
||||
Einbindung über Rolle Product Manager nach SAFe
|
||||
| | I.NVI 3 | Leiter IT-Projektportfoliomanagement, Projektleiterpool, Build | Matthias Karbstein | Leitungsebene | hoch | hoch | Entscheider | Einbindung über Value Stream FIB-Programmstrukturen (FIB-Leitungsboard)
|
||||
| | I.NVI 31 | Leiter IT-Projekte Vertrieb und Fahrplan | N.N. | Leitungsebene | hoch | hoch | Entscheider | Einbindung über Value Stream FIB-Programmstrukturen (FIB-Leitungsboard)
|
||||
| | I.NMF 1 | Leiter Regelwerke Programme Verf Fahrplan | Anatol Scholz | Leitungsebene | hoch | mittel | Influencer | Einbindung über Value Stream FIB-Programmstrukturen (FIB-Leitungsboard)
|
||||
|
||||
| | I.NMF 11 | Leiter Fachliche Architektur Fahrplan | Dr. Patrick Breun | Leitungsebene | mittel | mittel | Influencer | dreiwöchentliches "Eskalationsmeeting"
|
||||
| | I.NMF 13 | Leiterin Anforderungsmanagement Fahrplan | Dr. Bettina Birkmeier | Leitungsebene | mittel | mittel | Influencer | Ãber den Mitarbeiter Marco Krannich, der zu 0,2 PT im Projekt verankert ist
|
||||
| | I.NMF 32 | Leiter neXt Gesamtfahrplan | Dr. Daniel Pöhle | Leitungsebene | mittel | mittel | Influencer | Einbindung M13/FaPü über Mitarbeiter und direkte Einbindung bei BEdarf
|
||||
| | I.NVI 2 | Leiter IT-Beratung, Enterprise Architecture Management, Plan | N.N. | Leitungsebene | mittel | mittel | Influencer | Einbindung über Value Stream FIB-Programmstrukturen (FIB-Leitungsboard)
|
||||
|
||||
| | I.NVI 1 (S) | ITK Sicherheitsmanager | Drazen Morog | Leitungsebene | mittel | gering | Influencer |
|
||||
Informationsbereitstellung (Beschreibung Projektvorhaben)
|
||||
| | I.N | Datenschutzbeauftragter | Dietrich Zundel
|
||||
|
|
||||
| mittel | gering | Influencer | Informationsbereitstellung (Beschreibung Projektvorhaben)
|
||||
| | I.NM-X | Regionalleiter Vertrieb und Fahrplan | diverse | Leitungsebene | mittel | hoch | Influencer |
|
||||
Kontinuierliche Einbindung im Rahmen des Change Managements im Projekt (Verantwortlichkeit im Projekt: Rolle Change Manager)
|
||||
Durchführung regelmäÃiger Informationsveranstaltungen
|
||||
| | I.NM-X-K | Vertriebsleiter in den Regionen | diverse | Leitungsebene | mittel | hoch | Influencer |
|
||||
Kontinuierliche Einbindung im Rahmen des Change Managements im Projekt (Verantwortlichkeit im Projekt: Rolle Change Manager)
|
||||
Durchführung regelmäÃiger Informationsveranstaltungen
|
||||
| | I.NM-X-F | Fahrplanleiter in den Regionen | diverse | Leitungsebene | gering | mittel | Influencer |
|
||||
Kontinuierliche Einbindung im Rahmen des Change Managements im Projekt (Verantwortlichkeit im Projekt: Rolle Change Manager)
|
||||
Durchführung regelmäÃiger Informationsveranstaltungen (Federführung liegt beim Projekt BaDiFa)
|
||||
| | GBR Netz | Leiter Gesamtbetriebsrat DB Netz AG | Veit Sobek | Gesamtbetriebsrat | hoch | mittel | Influencer |
|
||||
Einbindung durch I.NMK 3 (I) vor Beginn des Umsetzungsprojekts (nach QG Plan)
|
||||
| | I.NHB | Digitalisierungsbeauftragter | N.N. | Sonstige | mittel | mittel | Influencer |
|
||||
Einbindung durch I.NMK 3 (I) ab Beginn der Umsetzungsphase (nach QG Plan)
|
||||
| | I.NHD (K) | Kommunikation DB Netz AG | Madeleine Schmitt | Sonstige | mittel | mittel | Influencer | Einbindung durch Change Management im Projekt, insbesondere mit der Klärung, inwiefern eine Betroffenheit durch die Kommunikationsabteilung der DB Netz AG bzw. sogar ggf. durch die Konzernkommunikation vorliegt.
|
||||
(Verantwortlich im Projekt: Rolle Change Manager)
|
||||
| | I.NPB 2 | Leiter Betriebliches Infrastrukturmanagement | Dr. Michael Kettner | Leitungsebene | gering | gering | Influencer | Betroffenheit wegen Schnittstellenbezug M15; Einbindung bedarfsbezogen, Kommunikation direkt mit Projektteam M15
|
||||
| |
|
||||
|
|
||||
|
|
||||
|
|
||||
|
|
||||
|
|
||||
|
|
||||
|
|
||||
|
||||
| | DB Netz | Kundenbetreuer DB Netz | diverse | Anwender | hoch | hoch | Influencer |
|
||||
Kontinuierliche Einbindung im Rahmen des Change Managements im Projekt (Verantwortlichkeit im Projekt: Rolle Change Manager)
|
||||
Durchführung regelmäÃiger Informationsveranstaltungen
|
||||
| | I.NM-X-F | Fahrplan-Konstrukteure | diverse | Sonstige | gering | mittel | Influencer |
|
||||
Kontinuierliche Einbindung im Rahmen des Change Managements im Projekt (Verantwortlichkeit im Projekt: Rolle Change Manager)
|
||||
Durchführung von Informationsveranstaltungen (Federführung liegt beim Projekt BaDiFa)
|
||||
| | DB Systel | Technische BF | diverse | Anwender | gering | mittel | Influencer | Einbindung durch Kommunikationsweg über IT-Entwicklungs-/Umsetzungsteam (Verantwortlich: Technischer Architekt)
|
||||
| | DB Netz | Fachliche BF | N.N. | Anwender | gering | mittel | Influencer | Einbindung durch Mitarbeit der Ressource im Projekt Team
|
||||
| |
|
||||
|
|
||||
|
|
||||
|
|
||||
|
|
||||
|
|
||||
|
|
||||
|
|
||||
|
||||
| | ext. | EVU-Kunden | diverse | Anwender | hoch | hoch | Influencer |
|
||||
Aufbau einer Online-Community zum Austausch mit den EVU-Kunden (Entgegennahme von Anforderungen und Impulsen, Bereitstellung von Informationen zum aktuellen Entwicklungsstand)
|
||||
Durchführung regelmäÃiger Informationsveranstaltungen (z.B. WebEx, Kundenworkshops vor Ort) (Verantwortlichkeit im Projekt: Rolle Change Manager)
|
||||
EVU Interessenverbände, gesteuert über I.NMK 4 (in Abstimmung mit Change Manager aus dem Projekt)
|
||||
| | ext. | BNetzA | diverse | Sonstige | mittel | mittel |
|
||||
Influencer | Einbindung über I.NMN (Netzzugang)
|
||||
| | ext. | EBA | diverse | Sonstige | gering | gering | Influencer | Einbindung über I.NMN (Netzzugang)
|
||||
@@ -0,0 +1,29 @@
|
||||
# 2.3 Projektrisiken
|
||||
|
||||
> Confluence Page ID: 27525939
|
||||
> Version: 51
|
||||
> Pfad: /pathOS/Start / Vorstudie Bestellsystem/00_Vorstudie Bestellsystem/2 Rahmenbedingungen/2.3 Projektrisiken
|
||||
> Labels:
|
||||
|
||||
---
|
||||
|
||||
Folgende initiale Risiken wurden im Rahmen des Vorprojekts und bei der Erstellung der Vorstudie identifiziert. Diese sind mit detaillierten Infos als Baseline bis zum Ende der Konzeptionsphase in einem Excel- Dokument festgehalten und werden anschlieÃend während des fortlaufenden Risiko-Managements im Projekt weiterverfolgt und aktualisiert. Dies erfolgt im Rahmen des zentralen Risiko-Managements vom Projekt M31 in JIRA.
|
||||
| | Risiko | Auswirkung | Eintrittswahrscheinlichkeit
|
||||
| | M31-247: Verzögerung der FIB 2 Umsetzung, wenn OP TAF/TAP-TSI nicht rechtzeitig geklärt sind | 4 - Kritisch | C - Möglich
|
||||
| | M31-472: Einsatzfähigkeit und Nutzbarkeit Bestellsystem abhängig von Projektvorhaben RuT-K neu | 4 - Kritisch | C - Möglich
|
||||
| | M31-474: Veröffentlichungssysteme nicht TAF/TAP-TSI konform | 3 - Wesentlich | B - Wahrscheinlich
|
||||
| | M31-481: Anmeldeprozess und Fahrplanerstellungsprozess auf Grund nicht migrierbarer Altdaten erschwert | 2 - Moderat | C - Möglich
|
||||
| | M31-482: Anforderungen an Rahmenverträge ändern sich | 1 - Geringfügig | D - Unwahrscheinlich
|
||||
| | M31-634:Â Fehlende Informationen bzgl. Roadmap zur Bereitstellung von Infrastrukturstammdaten (M15) | 3 - Wesentlich | B - Wahrscheinlich
|
||||
| | M31-485: Fehlende Bereitstellung TAF/TAP-TSI konformer Infrastrukturdaten | 1 - Geringfügig | B - Wahrscheinlich
|
||||
Die Risiken werden entsprechend folgender Metrik bewertet:
|
||||
Auswirkung:
|
||||
1 - Gering: <0,5 Mio. Euro Erhöhung oder <1 Monat Verzug;Â
|
||||
2 - Moderat: 0,5â <1 Mio. Euro Erhöhung oder 1â <3 Monate Verzug;
|
||||
3 - Wesentlich: 1â <5 Mio. Euro Erhöhung oder 3 â <6 Monate Verzug;  Â
|
||||
4 - Kritisch: >5 Mio. Euro Erhöhung oder >6 Monate Verzug;
|
||||
Eintrittswahrscheinlichkeit:
|
||||
A â Nahezu sicher (>80%);Â
|
||||
B â Wahrscheinlich (50-79%);
|
||||
C â Möglich (20-49%);
|
||||
D â Unwahrscheinlich (<20%);Â
|
||||
+37
@@ -0,0 +1,37 @@
|
||||
# 2.2 Bebauungsplan IST und SOLL Zustand
|
||||
|
||||
> Confluence Page ID: 27525941
|
||||
> Version: 82
|
||||
> Pfad: /pathOS/Start / Vorstudie Bestellsystem/00_Vorstudie Bestellsystem/2 Rahmenbedingungen/2.2 Bebauungsplan IST und SOLL Zustand
|
||||
> Labels:
|
||||
|
||||
---
|
||||
|
||||
## EinführungÂ
|
||||
|
||||
Die IT Bebauung basiert auf einem Domänenmodell der DB Netz AG.
|
||||
- Das Domänenmodell wird durch die IT Architektur im CIO-Bereich der DB Netz AG gepflegt und weiter entwickelt.Â
|
||||
- Die IT Soll- und Zielbebauung wird anhand der IT Anforderungen durch die IT Architekten des CIO-Bereichs überprüft, abgestimmt und fortgeschrieben.
|
||||
- Die IT Bebauung wird in einem EAM-Modell gepflegt (). Die IT Bebauung ist Teil des Architekturmanagements der DB Netz AG.
|
||||
Im Rahmen der Vorstudie werden im ersten Schritt die Bebauungspläne IST - Zustand analysiert:Â
|
||||
- Das Domänenmodell Kundeninteraktion, VertriebÂ
|
||||
- Das Domänennmodellund Kapazitäts- und FahrplanmanagementÂ
|
||||
|
||||
|
||||
## 2.2.1 Bebauungsplan aktuell IST -ZustandÂ
|
||||
|
||||
Die Verortung aller bestehenden Anwendungen der DB Netz ist in folgendem Dokument hinterlegt:Â Â
|
||||
Der Ausschnitt der Bebauungspläne, der für das Projekt Relevanz hat wird im folgenden erläutert. Die aktuellen Bebauungspläne für die Domänen Kundeninteraktion- Vertrieb, Kapazitäts- und Fahrplan und Infrastrukturdaten sind im EAM Werkzeug der DB Netz, dem , hinterlegt und werden in diesem Dokument als PDF dargestellt.
|
||||
## 2.2.1.3. Das Domänenmodell Kapazitäts und Fahrplanmanagement -Â
|
||||
|
||||
EAM.Bebauungspläne.IST-Zustand.Kapazitäts- und FahrplanmanagementÂ
|
||||
## 2.2.1.2 Das Domänenmodell Kundeninteraktion - Vertrieb
|
||||
|
||||
EAM.Bebauungspläne.IST-Zustand.Kundeninteraktion.Vertrieb Â
|
||||
## 2.2.2 IT Bebauungsplan SOLL -ZustandÂ
|
||||
|
||||
Bezogen auf das Projekt zur Erstellung eines neuen Bestellsystems wird folgende Vision/ Soll-Bebauung angestrebt:Â
|
||||
## Bebauungsplan langfristig ("Vision FIB 2")Â
|
||||
|
||||
|
||||
Â
|
||||
+53
@@ -0,0 +1,53 @@
|
||||
# 2.4 weitere Rahmenbedingungen
|
||||
|
||||
> Confluence Page ID: 27525943
|
||||
> Version: 23
|
||||
> Pfad: /pathOS/Start / Vorstudie Bestellsystem/00_Vorstudie Bestellsystem/2 Rahmenbedingungen/2.4 weitere Rahmenbedingungen
|
||||
> Labels:
|
||||
|
||||
---
|
||||
|
||||
Das Projekt zur Konzeption und Erstellung eines neuen Bestellsystems ist im agilen Release Train (ART) "M31 - Digitaler Fahrplan" des Value Streams FIB eingebettet. Im Zielbild von FIB werden unter anderem folgende zwei "Schmerzpunkte" benannt, die es durch das Vorhaben zur Erstellung eines neuen Bestellsystems aufzulösen gilt:
|
||||
- Manufaktur-Architektur mit enger Verdrahtung zwischen Trasse und Zug
|
||||
- Keine TAF/TAP-TSI Konformität (Erfüllung externer Vorgaben)Â
|
||||
Die Zielsetzung, Leitlinien und Inhalte des Value Streams FIB können im Fachkonzept FIB eingesehen werden. Die Finanzierung des Projekts zur Erstellung eines neuen Bestellsystems erfolgt daher durch Beantragung von Mittelfreigaben im Kontext des ART M31.
|
||||
Das Projekt M31 hat zum Ziel, die Basis für eine digitalisierte Fahrplanerstellung mit einer leistungsstarken und zukunftsträchtigen Architektur zu entwickeln. Gemeinsam mit dem Projekt neXt (M13) hinterlegt damit M31 das Element âDigitaler Fahrplanâ aus Zukunft Bahn, Teil der Digitalisierungsstrategie von Fahrplan und Betrieb. In neXt wird die Automatisierung der Fahrplanung umgesetzt.
|
||||
|
||||
|
||||
|
||||
|
||||
|
||||
Im Rahmen des Unternehmensprogramms Zukunft Bahn wurde ein Zielbild für die integrative Fahrplanungs- und Betriebsdurchführung und Verfügbarkeitssteuerung mit dem Fokus Zugfahrt entworfen. Die MaÃnahmen M15 âDigitalisierung Betrieb I (Infrastrukturrepräsentanz)â, M16 âDigitalisierung Betrieb I (bauliche InfrastruktureinschränÂkung)â und M31 âDigitalisierung Fahrplanâ mit M13 âneXt Gesamtfahrplanâ stellen eine logische Kette von der Bereitstellung von Infrastruktur und deren Daten (M15), die Information über deren Verfügbarkeit bzw. den baubetrieblichen Einschränkungen (M16) sowie die Vermarktung dieser Kapazitäten über den Netzfahrplan und den Gelegenheitsverkehr (M31) dar.
|
||||
Programmtechnisch werden M13, M15 und M31 über den Value Stream âFIB â Fahrplan und Infrastrukturbasisâ übergreifend im Rahmen eines agilen Organisationsmodells SAFe (Scaled Agile Framework) gesteuert.
|
||||
M31 ist auf einen Umsetzungszeitraum von acht Jahren angelegt (2017-2024). Um die Vorgaben des DB Konzerns hinsichtlich IT-Projekten (âGoldene Regeln für IT-Projekteâ) in Ansätzen einhalten zu können (kleinere Projekte mit geringerem Umfang), wurde M31 auf zwei Stufen aufgeteilt:
|
||||
- M31 Stufe 1 (2017-2020) hat den Fokus, die Zielerreichung von M13 bezüglich Einzel-Finanzierungsvereinbarung mit dem Bund sowie dem Business Case (produktive Nutzung ab 2019) zu ermöglichen. Hierzu zählen z. B. die Integration des unterjährigen Baufahrplans ins Fahrplankonstruktionssystem RUT-K sowie die Ermöglichung des Arbeitens mit baulichen Verfügbarkeitseinschränkungen.
|
||||
- M31 Stufe 2 (2020-2024) hat den Fokus, die notwendigen Voraussetzungen für die weitere Automatisierung, Digitalisierung und Optimierung im Fahrplan- und Kapazitätsmanagement zu schaffen. Hierzu zählen z. B. die technische Modernisierung von RUT-K sowie die Realisierung eines neuen Bestellsystems inkl. EVU-Schnittstelle.
|
||||
Im Rahmen der zwei Vorprojekte âRUT-K neuâ und âneues Bestellportal/EVU-Schnittstelleâ werden zwei Vorstudien in 2019 angefertigt. Diese beiden Teilprojekte decken hinsichtlich des in 2016 ehemals geplanten Budgetumfangs von M31 bereits ca. 80 % der Stufe 2 ab. Das im Herbst 2019 geplante Durchschreiten des Quality Gates Planung dient dann als Grundlage der BV für M31 Stufe 2 2020 (anschlieÃend jährliche Budgetfreigaben weiterhin geplant).
|
||||
Die verbleibenden 20 % umfassen Themen wie Effizienzsteigerungen in der Fahrplankonstruktion, Integration des Systems KSB-S (Fahrplansystem der S-Bahn Berlin) und aus M31 Stufe 1 verschobene Epics (Integration FfZ, frühe Bauphasen und minutengenaue Infrastruktur). Letztere sind in der Vorstudie M31 Stufe 1 beschrieben; die übrigen Themen werden genauer analysiert, sofern die Umsetzung in absehbare Nähe gerückt ist (ab ca. 2021).
|
||||
|
||||
|
||||
Im Rahmen der Konzeptionsphase des neuen Bestellsystems wurde insbesondere die direkte Abhängigkeit zum separaten IT-Vorhaben zur Erstellung eines neuen Fahrplan-Konstruktionssystems identifiziert, von dem die Einsatzfähigkeit und Nutzbarkeit des neuen Bestellsystems abhängig ist. Mit dem Ziel zur Trennung der Funktionalitäten von Vertrieb und Fahrplan in unterschiedliche IT-Systeme, werden die in einem neuen Bestellsystem zukünftig angebotenen Funktionalitäten im Vergleich zu den derzeit in TPN angebotenen Funktionalitäten geringer ausfallen.
|
||||
In einem neu zu schaffenden Konstruktionssystem müssen deshalb insbesondere folgende Funktionalitäten voraussichtlich zeitgleich mit der Produktivsetzung des neuen Bestellsystems bereitgestellt werden:
|
||||
- Steuerung des Konstruktionsablaufs für Fahrplanerstellung
|
||||
- Komponente zur Verwaltung von Trassen
|
||||
- TAF/TAP-TSI Konformität im Konstruktionssystem
|
||||
- Schnittstelle zur Ãbergabe von veröffentlichungsrelevanten Informationen an die Veröffentlichungssysteme, in dem von den Veröffentlichungssystemenen vorausgesetzten Datenformat
|
||||
Das Vorhaben zur Erstellung eines neuen Fahrplan-Konstruktionssystems ist ebenfalls in den ART M31 innerhalb des Value Stream FIB eingebettet. Zu diesem Vorhaben ist eine sehr enge Verzahnung sicherzustellen, mit der Berücksichtigung folgender Schwerpunkte:Â
|
||||
- Abstimmung und Verwendung des gleichen Objektmodells
|
||||
- Definition und Vereinbarung von konkreten Schnittstellen
|
||||
- Zeitgleiche Rollout- & Einführungsplanung
|
||||
Darüber hinaus existieren folgende weitere Rahmenbedingungen, die es zu berücksichtigen gilt. Die Verantwortung zur Umsetzung dieser Themen liegt nicht im Projekt zur Erstellung des Bestellsystems, Entscheidungen zum Umgang mit diesen Themen beeinflusst aber unter Umständen den Inhalt und die Planung des Projekts zur Erstellung eines Bestellsystems:
|
||||
- TAF/TAP-TSI Befähigung der restlichen IT-Systemlandschaft, insbesondere:
|
||||
- Bereitstellung von TAF/TAP-TSI konformenen Infrastukturstammdaten (GFD-I oder Nachfolgesystem)
|
||||
- Schnittstelle zum Nachrichtenaustausch zwischen Fahrplan und Betrieb (NSS)
|
||||
- ggf. Abrechnungssysteme
|
||||
- ggf. Veröffentlichungssysteme
|
||||
|
||||
|
||||
Zu Beginn des Vorprojekts zur Konzeption eines neuen Bestellsystems wurden Lessons-Learned aus Vorgänger-Projekten mit ähnlichen Inhalten durchgeführt. Die Vorgängerprojekte WIN, IngriT und APluS hatten teilweise einen ähnlichen Scope. Im Rahmen der Lessons-Learned konnten u.a. folgende Fehlerquellen identifiziert werden, die es in einem neuen Projektvorhaben zu vermeiden gilt:Â
|
||||
- Projekt-Scope zu groÃ, dadurch nicht mehr managebare Komplexität erzeugt
|
||||
- zu viele externe Projektbeteiligte, insbesondere ohne Bahn-Know-How
|
||||
- falsche Technologie-Entscheidung
|
||||
|
||||
|
||||
Sonstige organisatorische Rahmenbedingungen, wie zum Beispiel personelle Reorganisation, Aufbau oder Höherqualifizierung von Personal, Anpassung von Richtlinien, oder ähnliches wurde zum Zeitpunkt der Erstellung der Vorstudie nicht identifiziert. Neben der EU Verordnung 62/2006, die den rechtlichen Rahmen zur Erreichung der Ziele von TAF/TAP-TSI vorgibt, wurden darüber hinaus im Rahmen des Vorprojekts keine interne oder externe Richtlinien, Normen bzw. Standards identifiziert, die aus fachlicher oder technischer Sicht besonderer Berücksichtigung bedürfen. Die Verantwortung zur Sicherstellung fachlicher Richtlinien obliegt dem zuständigen Fachbereich, die Verantwortung zur Sicherstellung technischer Richtlinien obliegt dem umsetzungsverantwortlichen Dienstleister.
|
||||
+97
@@ -0,0 +1,97 @@
|
||||
# 1.1 Beschreibung der Aufgabenstellung des Projektes
|
||||
|
||||
> Confluence Page ID: 27525948
|
||||
> Version: 67
|
||||
> Pfad: /pathOS/Start / Vorstudie Bestellsystem/00_Vorstudie Bestellsystem/1 Ziele des Projekts/1.1 Beschreibung der Aufgabenstellung des Projektes
|
||||
> Labels:
|
||||
|
||||
---
|
||||
|
||||
## Problemstellung
|
||||
|
||||
## Problem 1: Verpflichtende Erfüllung der TAF/TAP TSI im Altsystem nicht umsetzbar
|
||||
|
||||
Die DB Netz AG ist verpflichtet, die Vorgaben der EU Komission zur Umsetzung der Technical Specifications for Interoparability (TSI) im Personen- und Güterverkehr umzusetzen. Dabei werden grundlegenden Ãnderungen in der Struktur fachlicher Objekte umgesetzt, die mit dem bislang in TPN zugrunde gelegten Objektmodell nicht vollumfänglich kompatibel sind. Da eine Umwandlung der TAF/TAP-Objekte in TPN-Objekte nicht verlustfrei in beide Richtungen durchführbar ist, ist eine reine Anpassung der bisherigen Systemwelt nicht durchgängig darstellbar.
|
||||
## Problem 2: Kein kundenorientiertes Bestellportal zur Trassenanmeldung vorhanden
|
||||
|
||||
Mit TPN bzw. dem Anita-Client hat die DB Netz AG aktuell ein Anmeldeinterface im Angebot, das - neben anderen Funktionalitäten - dem Kunden das Erstellen und Senden seiner Zugfahrtanmeldung gegenüber der DB Netz AG ermöglicht. Im Wesentlichen ist TPN aber das System zur internen Konstruktionssteuerung im Bereich Fahrplan der DB Netz AG und enthält Datenbankelemente, wie etwa ein Auftragsmanagement und eine eigene Kundendatenverwaltung. Der Anita-Client gibt dem Kunden keinerlei Unterstützung, die Planung seiner Zugfahrt im Systemvorzunehmen, weshalb sich über die Initiative Einfachbahn eine Vielzahl unterstützender Produkte etabliert hat, die den Kunden in einzelnen Planungsapekten unterstützen. Dazu müssen allerdings mehrere Tools gesondert aufgerufen werden und redundante Planungsinformationen mehrfach eingegeben werden. Hinzu kommt, dass die Produkte der Einfachbahn vielfach ohne Gewährleistung über die Richtigkeit der angezeigten Daten arbeiten, da es sich hierbei aus Sicht des CIO-Bereichs um nicht-abgestimmte "Schatten-IT" handelt.
|
||||
Aufgrund der Tatsache, dass TPN nicht ausschlieÃlich ein System für den Kunden darstellt, sondern sich das grundlegende Prozessmodell und die Eingabemasken an den internen Prozessen und dem Objektmodell der DB Netz orientieren und die Verantwortung für die Weiterentwicklung dem Bereich Fahrplan obliegt, ist insbesondere der Aspekt der kundenfreundlichen und intuitiven Bedienung erheblich vernachlässigt. Eine unabhängige Weiterentwicklung des Programmteils "Kundenportal" ist aufgrund der engen Verzahnung des Kundenclients mit den internen Funktionen der Konstruktionssteuerung in der Vergangenheit nicht möglich gewesen. Interne und juristische Anforderungen bei der Weiterentwicklung wurden meist stärker gewertet als der Benutzerkomfort in den Bedienkonzepten, weshalb Weiterentwicklungen für den Kunden selten spürbare Qualitätsverbesserungen erzeugen konnten.
|
||||
## Lösungsansatz
|
||||
|
||||
## Schaffen eines TAF/TAP TSI kompatiblen BestellsystemsÂ
|
||||
|
||||
Der Aufbau eines neuen, integrierten Bestellsystems (in diesem Projekt beschrieben) und eines neuen Konstruktionssystems (Projekt BaDiFa/Ablöse RuT-K) gewährleistet, dass TAF/TAP TSI in vollem Umfang unterstützt werden kann und wir als DB NEtz AG von den Neuerungen, die mit TAF/TAP TSI Einzug erhalten, profitieren können. Diese Vorteile sind unter anderem:
|
||||
- Auf eine einzelne Trassenanmeldung kann künftig mit beliebig vielen, verkehrstagebezogen vollständigen Trassenangeboten geantwortet werden. Bisher haben wir ein 1:1-Verhältnis, dass dazu führt, dass Kunden vom Fahrplankonstrukteur Zeitscheiben für die Anmeldung vorgegeben bekommen, und ggf. entsprechend nachanmelden müssen, nur dass wir ein Angebot erstellen können
|
||||
- Der Kunde erhält eigene, durchgängige Identifier für Vorgänge und Züge, die die Nachvollziehbarkeit von Vorgängen für uns und Kunden erhöhen und die Bedeutungsüberladung der Zugnummern (künftig: OperationalTrainNumber) reduzieren
|
||||
- Die DB Netz AG wird als Infrastructure Manager in die Lage versetzt, wahrhaftig netzausgelöst Trassen zu ändern oder zu stornieren
|
||||
Das Bestellsystem besteht in der Kundenwahrnehmung im Wesentlichen aus einem Bestellportal, dass dem Kunden TAF/TAP-kompatible Trassenanmeldungen ermöglicht sowie einer Bestellschnittstelle, aufgebaut als Common Interface im Sinne der RNE, mit dem der TAF/TAP-konforme Nachrichtenaustausch zur Planung von Zugfahrten zwischen EVU und EIU unterstützt wird.
|
||||
## Trennung der Systemverantwortungen Fahrplan <> Vertrieb
|
||||
|
||||
Im Fachkonzept FIB ist unter Kapitel 3.2.4 als Element der künftigen IT-Landschaft die zukünftige Verantwortungstrennung zwischen Vertrieb und Fahrplan neu definiert. MaÃgeblich ist, dass Vertriebskanäle klar von Fahrplanung und Auftragsmanagement getrennt existieren sollen. Dies ermöglicht künftig das Kundensystem weitgehend unabhängig von den halbjährlichen Releasezyklen der DaViT-Systemwelt weiterzuentwickeln und auf Anforderungen der Nutzer zügig reagieren zu können. Fachliche Weiterentwicklungen sind zwar weiterhin nicht Fahrplan-unabhängig zu realisieren, die Weiterentwicklung der Benutzeroberflächen, Bedienkonzepte, Einbindung neuer, planungsunterstützender Services und ähnliche Anforderungen können aber in agilen Produktinkrementen nachgepflegt und verbessert werden. Der Kunde nimmt das System damit als zeitgemäÃes IT-System war, das ihn maÃgeblich in der Erledigung seiner eigenen Aufgaben unterstützt.
|
||||
Die enge Verzahnung in TPN zwischen Kundenclient und Konstrukteursclient, also externem und internem System, macht eine solche zeitgemäÃe Weiterentwicklung unmöglich. Durch Auflösung von TPN in seine wesentlichen Kernelemente, kann die Trennung zwischen Vertrieb und Fahrplan aber systemisch realisiert werden. Die Elemente Konstruktionssteuerung und Fahrplan-Auftragsmanagement verbleiben dabei in der Verantwortung des Fahrplans und können dort weiterentwickelt werden. Das Kundendatenmanagement kann bereits heute durch das CRM-Tool bzw. die Schnittstelle KundenDatenVerwaltung des Vertriebs abgebildet werden. Das neue Trassenbestellportal (im Nachfolgenden analog verwendeter Begriff "Bestellportal") ersetzt künftig die Funktionalität "Anita-Client" bzw. "Kundenportal" aus TPN.
|
||||
Das neue Bestellportal kann, dank der Auslösung aus TPN, entsprechend der Anforderung der Kunden gestaltet und entwickelt werden und so ein zeitgemäÃes Interface mit für Kunden effizienten Workflows vereinen. Somit wird der Vorgang der Trassenanmeldung für Kunden maÃgeblich effizienter und einfacher, mit dem Ziel auf Kundenseite zu höherer Zufriedenheit und besserer Wirtschaftlichkeit zu führen.
|
||||
## In Scope
|
||||
|
||||
Das Projekt zur Erstellung eines neuen Bestellsystems
|
||||
- löst die TPN Funktionalität "Anita-Client" bzw. "Kundenportal" ab und stellt hierfür ein neues Bestellportal als Webfrontend bereit.
|
||||
- löst die bestehenden EVU XML Schnittstellen in den Version 2.0 und 3.0 ab und stellt hierfür ein DB Netz spezifisches Common Interface ("XML-Schnittstelle 4.0") bereit (nicht abwärtskompatibel zu XML Schnittstelle 2.0 und 3.0).
|
||||
- implementiert das TAF/TAP-TSI-Datenmodell zur Entgegennahme von Trassenanmeldungen in diesem Format.
|
||||
- implementiert eine Komponente "SteuerungVertriebsAblauf", die unter anderem die Schnittstelle zum Konstruktionssystem bildet ("Trennung Systemverantwortung Fahrplan <> Vertrieb").
|
||||
- integriert den bestehenden Kanal "Click&Ride", so dass Trassenanmeldungen über diesen Kanal dem zentralen Bestellsystem zugeführt werden.
|
||||
- bindet die Komponenten des Abrechnungscockpits zur Preisermittlung eines Trassenangebots, sowie die Komponente BelegAnhangArchiv zur Archivierung der Geschäftsbelege über die Komponente "SteuerungVertriebsAblauf" an.
|
||||
- erstellt eine Komponente, die die Bereitstellung der Trassenanmeldungs-bezogenen Stammdaten für die EVUs ermöglicht.
|
||||
- implementiert eine API zur Bereitstellung der Bestellsystem-Vorgangsdaten für Reporting-Systeme.
|
||||
Dieser Scope stellt das Minimal Viable Product (MVP) dar.
|
||||
|
||||
|
||||
|
||||
|
||||
## Out of Scope:
|
||||
|
||||
Das Projekt zur Erstellung des neuen Bestellsystems löst nicht das vollständige System TPN ab, sondern lediglich die Teilfunktionalität "B2B-Bestellsystem" (Anita-Client/Kundenportal). Aus diesem Grund liegt die Verantwortlichkeit zur AuÃerbetriebnahme von TPN nicht im Scope des Projekts. Das Projekt beschäftigt sich zudem auch nicht mit den Funktionen und der Ablösung des Systems GFD-Z.
|
||||
Das heiÃt im Einzelnen:
|
||||
- Das neue Bestellsystem beinhaltet nicht die TPN Funktionalität "KK-Client", also die Funktionalitäten für die Benutzerrollen "Konstrukteur" und "Koordinator". Hierüber wird federführend der Produktionsprozess im Bereich Fahrplan (Konstruktion von Trassen durch Fahrplaner) gesteuert.
|
||||
Die Verantwortung über die Konstruktionssteuerung/Produktionssteuerung liegt in der Domäne Kapazitätsmanagement.
|
||||
|
||||
|
||||
- Das neue Bestellsystem baut kein neues und eigenständiges Kundendatenmanagement auf.
|
||||
Die erforderlichen Capabilities sind im CRM/KDV im Vertrieb bereits in Produktion.
|
||||
|
||||
|
||||
- Das neue Bestellsystem baut keine eigenständige Trassenverwaltung auf.
|
||||
Die Verantwortung über die Trassenverwaltung liegt in der Domäne Kapazitätsmanagement.
|
||||
|
||||
|
||||
- Das neue Bestellsystem baut keinen Service für die Veröffentlichung von Fahrplandokumenten auf.
|
||||
Die Verantwortung für die Veröffentlichung wird in der Domäne Kundenkommunikation und Information in der integrierten Veröffentlichung behandelt, die Verantwortung verbleibt organisatorisch beim Fahrplan.
|
||||
|
||||
|
||||
- Das neue Bestellsystem baut keine eigenständige Benutzerverwaltung auf.
|
||||
Die erforderlichen Capabilities sind in Form von eBRS und iMan bereits produktiv.
|
||||
|
||||
|
||||
- Das neue Bestellsystem baut keine Zugnummernverwaltung/-generator auf.
|
||||
Die Verantwortung über die Zugnummernverwaltung liegt in der Domäne Kapazitätsmanagement.
|
||||
|
||||
|
||||
- Das neue Bestellsystem berücksichtigt zunächst noch keine neuen Produkte aus TTR.Â
|
||||
Die neue Prozess- und IT-Landschaft zu TTR ist zurzeit nicht hinreichend spezifiziert und kann daher im Rahmen der Konzeptionsphase und Vorstudie und der Kostenschätzung keine Berücksichtigung finden.
|
||||
|
||||
|
||||
- Das neue Bestellsystem berücksichtigt zunächst keine Trassenbestellungen, die auÃerhalb der Infrastruktur der DB Netz AG liegen.
|
||||
Im neuen Bestellsystem werden zunächst nur Trassenbestellungen für die Infrastruktur der DB Netz AG ermöglicht. Internationale Trassenbestellungen sind weiterhin über das System PCS durchzuführen bzw. beim jeweilig national-verantwortlichen EIU zu bestellen.
|
||||
|
||||
|
||||
- Das neue Bestellsystem lässt eine Referenz auf bestehende Rahmenverträge zu, die Neuanmeldung von Rahmenverträgen wird nicht abgedeckt.
|
||||
Neue Rahmenvertragsanmeldungen sind nicht vorgesehen. Es bestehen aber langlaufende Rahmenverträge mit Gültigkeit bis 2031, die weiterhin für Kunden in der Anmeldung zum Netzfahrplan referenzierbar bleiben müssen. Es wird für Kunden keine systemisch unterstützten Funktionen zur Ãnderung von Rahmenverträgen geben.
|
||||
|
||||
|
||||
- Das neue Bestellsystem verantwortet und finanziert keine Anpassungen an bestehenden Business Intelligence (BI) Systemen wie z.B. SAPBINe oder Netzmonitor.
|
||||
Das neue Bestellsystem wird eine API Schnittstelle anbieten, um den Datenbestand des Bestellsystems exportieren zu können. Die Weiterverarbeitung dieser Daten und Aufbereitung in entsprechende Reports durch BI-Systeme liegt nicht in der Verantwortung des Projekts Bestellsystem.
|
||||
|
||||
|
||||
- Das neue Bestellsystem verantwortet nicht die grundsätzliche Analyse und Umsetzung von TAF/TAP-TSI-Anforderungen in der IT-Landschaft der DB Netz AG.
|
||||
Anforderungen durch TAF/TAP-TSI werden durch ein Konzeptionsteam des Ressortbereichs Fahrplan (I.NMF) in das Projekt zur Erstellung eines neuen Bestellsystems eingesteuert. Anzupassende Schnittstellen werden im Rahmen des Projekts identifiziert und im Abhängigkeitsmanagement berücksichtigt. Die Verantwortung zur Berücksichtigung sonstiger TAF/TAP-TSI spezifischer Attribute in der restlichen IT-Landschaft der DB Netz AG, zum Beispiel TAF/TAP-TSI spezifische Anpassung der Abrechnungssysteme oder der Veröffentlichungssysteme, liegen nicht im Scope des Projekts zur Entwicklung eines neuen Bestellsystems.
|
||||
|
||||
|
||||
- Der Aufbau eines Dispatchers zum Routen von Betriebs- und Vertriebsnachrichten zu den jeweiligen Fachbereichen ist nicht Bestandteil des Projekts zur Erstellung eines Bestellsystems.
|
||||
@@ -0,0 +1,12 @@
|
||||
# 1 Ziele des Projekts
|
||||
|
||||
> Confluence Page ID: 27525953
|
||||
> Version: 10
|
||||
> Pfad: /pathOS/Start / Vorstudie Bestellsystem/00_Vorstudie Bestellsystem/1 Ziele des Projekts
|
||||
> Labels:
|
||||
|
||||
---
|
||||
|
||||
## Allgemeine Zielformulierung:
|
||||
|
||||
Ziel ist der Aufbau eines kundenfreundlichen Bestellsystems, dass den Kunden TAF/TAP-TSI kompatibel bei der Planung aller Zugfahrten weitgehend unterstützt, die Anmeldung dieser ermöglicht sowie Informationen über Anmeldestatus und bestehende Trassenverträge und deren Verwaltung bereithält. Das Bestellsystem beinhaltet ein webbasiertes Bestellportal sowie eine Datenaustauschschnittstelle zum Anbinden von Trassenbestellsystemen von Drittherstellern.
|
||||
+28
@@ -0,0 +1,28 @@
|
||||
# 1.3 Anwender des Projektergebnisses/ITK-Systems
|
||||
|
||||
> Confluence Page ID: 27525957
|
||||
> Version: 28
|
||||
> Pfad: /pathOS/Start / Vorstudie Bestellsystem/00_Vorstudie Bestellsystem/1 Ziele des Projekts/1.3 Anwender des Projektergebnisses/ITK-Systems
|
||||
> Labels:
|
||||
|
||||
---
|
||||
|
||||
## Nutzerkennzahlen eines neuen Bestellsystems
|
||||
|
||||
Annahme:
|
||||
Die wesentlichen Hauptanwender eines neuen Bestellportals und einer Datenaustauschschnittstelle ("EVU-Schnittstelle 4.0") sind alle Zugangsberechtigten, die mit der DB Netz AG einen Infrastrukturnutzungsvertrag geschlossen haben. Es handelt sich hierbei im Wesentlichen um Eisenbahnverkehrsunternehmen, die ihre Zugfahrten anmelden. Insgesamt werden über das Bestellportal und die neue TAF/TAP-konforme EVU-Schnittstelle alle der bei der DB Netz AG registrierten Eisenbahnverkehrsunternehmen erreicht.Â
|
||||
## Auswertung Benutzer TPN WebClient (von I.NMF 13)
|
||||
|
||||
|
||||
Für den TPN-Internetclient können folgende Zahlen festgestellt werden:
|
||||
- 58 %, also 364, der bei DB Netz registrierten Kunden nutzen aktuell das Verfahren TPN zur Trassenanmeldung
|
||||
- 1.189 Kundennummern ( 73% der vergebenen Kundennummern) werden bei Anmeldungen über TPN genutzt
|
||||
-
|
||||
Hierfür bestehen 4.146 gültige Kundenzugänge mit der Rollenzuordnung "EVU-Sachbearbeiter"
|
||||
|
||||
Die EVU-Schnittstelle wird darüber hinaus von jenen EVU genutzt, die Anmeldungen über Software von Drittanbietern übermitteln. Hierbei handelt es sich nach aktuellem Kenntnisstand um 75 Kunden mit insgesamt 101 Verfahrens-Usern. Grundsätzlich stehen allen Nutzern beide Verfahren zur Anmeldung offen, einige unserer Kunden nutzen auch beide Verfahren gleichwertig nebeneinander.Â
|
||||
243 der registrierten Unternehmen melden über beide Anmeldeverfahren sowohl Personen- als auch Güterverkehre an. 68 Unternehmen melden ausschlieÃlich Personenverkehre und 138 ausschlieÃlich Güterverkehre an. Insgesamt sind 449 registrierte Kunden erfasst.
|
||||
Darüber hinaus wird das System auch von internen Nutzer verwendet. Diese Anwender sind in diesem Abschnitt nicht berücksichtigt worden, da der Fokus zunächst auf die wesentlichen Hauptanwender gelegt wird. Detaillierungen zu den DB Netz internen Anwendern finden sich in Kapitel .
|
||||
Quellen:
|
||||
-
|
||||
Auswertung von I.NMF 13
|
||||
+18
@@ -0,0 +1,18 @@
|
||||
# 1.2 Besteller des Projektes
|
||||
|
||||
> Confluence Page ID: 27525961
|
||||
> Version: 3
|
||||
> Pfad: /pathOS/Start / Vorstudie Bestellsystem/00_Vorstudie Bestellsystem/1 Ziele des Projekts/1.2 Besteller des Projektes
|
||||
> Labels:
|
||||
|
||||
---
|
||||
|
||||
| |
|
||||
Bedarfsträger bzw. anfordernde OE |
|
||||
I.NMK 3 (Ralph Grassel)
|
||||
| |
|
||||
Bestellende OE |
|
||||
I.NVI 31 (N.N.)
|
||||
| |
|
||||
Bereich |
|
||||
DB Netze Fahrweg, I.NMK
|
||||
+45
@@ -0,0 +1,45 @@
|
||||
# 6.2 M13 neXt Gesamtfahrplan
|
||||
|
||||
> Confluence Page ID: 27525966
|
||||
> Version: 116
|
||||
> Pfad: /pathOS/Start / Vorstudie Bestellsystem/00_Vorstudie Bestellsystem/6 IT Ist-Analyse/6.2 M13 neXt Gesamtfahrplan
|
||||
> Labels:
|
||||
|
||||
---
|
||||
|
||||
## M13 Click&RideÂ
|
||||
|
||||
## Einleitung
|
||||
|
||||
Im Rahmen von neXt Gesamtfahrplan ist TPN aktuell über die Prozesssteuerung angebunden und wird u.a. verwendet, um Zugnummern für Click&Ride Bestellungen zu erzeugen und Folgeworkflows in angeschlossenen Systemen von neXt Gesamtfahrplan auszulösen.
|
||||
- Click&Ride ist seit 06/2019 produktiv.Â
|
||||
- Technische Migration von Click&Ride im Zeitraum 04/2019 - spätestens Ende Q3/2019 geplant:
|
||||
- Migration KAM von SAG auf Spring Boot
|
||||
- Migration technische ProzessSteuerung von BPMN Webmethods auf Camunda
|
||||
- Migration der genutzten Services (u.a. BEP, TrassenService, etc.) von TIBCO auf Spring Boot
|
||||
|
||||
|
||||
## Schnittstellenkontext C&R
|
||||
|
||||
|
||||
|
||||
|
||||
|
||||
|
||||
|
||||
|
||||
## Schnittstellenspezifikation C&R
|
||||
|
||||
Aufträge, die über die Click & Ride App bestellt werden, sind in TPN abgebildet (Auftragstyp 1C und 2C) (EmpfangeVertragsanname, sende Vertragsbestätigung). Bei der weiteren Bearbeitung eines bestätigten Auftrags aus Click&Ride sind nur Stornierungen erlaubt (Auftragstyp 7).
|
||||
Der bestehende TPN Zugnummerngenerator ist um den WebService TPNKonBelZugNummernService für Click&Ride im Projekt neXt um zwei Operationen erweitert.Â
|
||||
Die Annahme und Bearbeitung von C&R Bestellanfragen (inkl. AkzeptierteReservierungID) und Aufruf von Process Phase G heraus für Bearbeitung einer C&R Anfrage in KonBelTPNAdapter ist im Sequenzdiagramm dargestellt. Â
|
||||
|
||||
|
||||
|
||||
|
||||
|
||||
## Phase G:Â Optimierung GelV (Click&Ride)
|
||||
|
||||
Zum Zeitpunkt Juni 2019 sind die Prozesse Phase G und Phase E noch nicht im Prozessportal und der LN-Prozesslandschaft der DB Netz AG übernommen worden.Â
|
||||
Verknüpfung im Wiki: Wiki NeXt GesamtfahrplanÂ
|
||||
Optimierung Gelegenheitsverkehr SGVÂ befindet sich unter:Â Â NeXt EAM
|
||||
+103
@@ -0,0 +1,103 @@
|
||||
# 1.4 Projektziele und -nutzen des Minimal Viable Product
|
||||
|
||||
> Confluence Page ID: 27525967
|
||||
> Version: 57
|
||||
> Pfad: /pathOS/Start / Vorstudie Bestellsystem/00_Vorstudie Bestellsystem/1 Ziele des Projekts/1.4 Projektziele und -nutzen des Minimal Viable Product
|
||||
> Labels:
|
||||
|
||||
---
|
||||
|
||||
Die im Nachfolgenden definierten Ziele, die Einordnung dieser in die Geschäfts- und Konzernziele, sowie die Projektnutzen-Betrachtung beziehen sich auf das zu erstellende Minimal Viable Product (MVP). Eine Abgrenzung zur grundsätzlichen Vision findet sich in Kapitel .
|
||||
## 1.4.1 Projektziele
|
||||
|
||||
Projektziel (Kriterien, nach denen das Projekt bei Abschluss als erfolgreich bewertet wird)
|
||||
- Es besteht eine TAF/TAP-TSI konformes Common Interface ("XML-Schnittstelle 4.0") zum Datenaustausch zwischen Zugangsberechtigten und der DB Netz AG im Sinne des TAF/TAP Sectors "Planning".
|
||||
- Die Schnittstelle berücksichtigt den Datenaustausch für Trassenameldung, -änderung und -stornierung im Netzfahrplan und Gelegenheitsverkehr.
|
||||
|
||||
- Bereitstellung und produktiver Einsatz der Schnittstelle ab März 2023 für Anmeldephase Netzfahrplan 2024 inkl. Berücksichtigung von Verweisen auf bestehende Rahmenverträge
|
||||
- Bereitstellung und produktiver Einsatz der Schnittstelle ab April 2023 (Ende Anmeldephase Netzfahrplan) für Anmeldungen im Gelegenheitsverkehr für das Fahrplanjahr 2024
|
||||
|
||||
- Es besteht ein TAF/TAP-TSI konformes Trassenbestellportal als Front-End zur Nutzung durch EVUs für alle relevanten Geschäftsvorfälle der Trassenanmeldung, -änderung und -stornierung.
|
||||
- Als relevante Geschäftsvorfällen gelten Planen, Anmelden und Verwalten (Ãndern, Stornieren) von Trassen im Netzfahrplan und Gelegenheitsverkehr.
|
||||
- Bereitstellung und produktiver Einsatz des Front-Ends für EVUs ab März 2023 für Netzfahrplan 2024
|
||||
- Bereitstellung und produktiver Einsatz des Front-Ends für EVUs ab April 2023 (Ende Anmeldephase Netzfahrplan) für Anmeldungen im Gelegenheitsverkehr für das Fahrplanjahr 2024
|
||||
- Das Front-End des Trassenbestellportals orientiert sich in der Gestaltung der User Experience an den Bedürfnissen und Geschäftsprozessen der EVU-Kunden und bietet einen hohen Bedienkomfort sowie einen intuitiven Workflow
|
||||
- Das Front-End bindet IT-technische Komponenten, die den EVU-Kunden bei der Planung seiner Zugfahrt unterstützen an, um den Bediener mit relevanten Planungsinformationen zu versorgen.
|
||||
Dies sind insbesondere:
|
||||
|
||||
- TPPuE (neXt BEP)
|
||||
- Routensuche (neXt)
|
||||
- FBZE (neXt)
|
||||
- PreisVerwaltungTrasse (AC Trasse)
|
||||
|
||||
|
||||
- Das Trassenbestellsystem setzt die Verantwortungstrennung zwischen Fahrplan und Vertrieb konsequent um. Im Front-End des Trassenbestellportals, in der TAF/TAP-TSI konformen Schnittstelle und in den Back-End-Komponenten für das Trassenbestellsystem finden sich keine Funktionalitäten, die eine Steuerung der Fahrplanerstellung verantworten.
|
||||
|
||||
Darstellung Ziel Trennung Vertrieb & Fahrplan
|
||||
|
||||
|
||||
|
||||
Darstellung Ziel TAF/TAP TSI Umsetzung
|
||||
|
||||
|
||||
## 1.4.2 Projektnutzen und nutzenbezogene Risiken
|
||||
|
||||
## Vermeidung möglicher Strafzahlungen und Schadenersatzforderungen
|
||||
|
||||
Die DB Netz AG ist als europäisches Eisenbahninfrastrukturunternehmen verpflichtet, die Vorgaben der EU-Kommission durch Implementierung von TAF/TAP TSI umzusetzen. Eine Nicht-Umsetzung eröffnet das erhebliche Risiko, das Strafen gegen die Bundesrepublik Deutschland bzw. die DB Netz AG festgelegt werden. Eine quantitative Bezifferung des finanziellen Risikos ist aktuell nicht möglich.
|
||||
Die DB Netz AG hat gegenüber den eigenen Kunden und der RNE mehrfach die Umsetzung von TAF/TAP TSI angekündigt. Zuletzt wurde am 23. Juli 2019 gegenüber unseren Kunden das Commitment zur Umsetzung von TAF/TAP in der Kundenveranstaltung zu den neuen Kundenschnittstellen bekräftigt. Daraus werden nun Kunden und Drittsystemanbieter in die Umstellung auf TAF/TAP TSI investieren. Eine Abkündigung der Umsetzung kann uns potenziell zum Ziel von Schadenersatzforderungen machen. Auch hier ist quantitative Abschätzung des finanziellen Risikos nicht möglich.
|
||||
## Trennung der Systemverantwortlichkeiten zwischen Fahrplan und Vertrieb
|
||||
|
||||
Der Aufbau eines neuen Bestellportals sowie der EVU-Schnittstelle entkoppelt die Weiterentwicklung des Kundeninterface von der heutigen DaVIT-Systemwelt. Somit kann der Vertrieb in erheblich kürzeren Release-Zyklen auf Kundenfeedback reagieren und Anmeldemasken, Workflows und neue Funktionalitäten im Bestellsystem integrieren. Dies ist insbesondere für diejenigen Kunden relevant, für die die Nutzung von Planungs- und Bestellsystemen von Drittherstellern nicht wirtschaftlich darstellbar ist. Die Vereinfachung unserer kundenwirksamen Prozesse und Anforderungen wird dort gegenüber dem heutigen Trassenportal Netz deutliche Effizienzsteigerungen nach sich ziehen, da ein Anmeldevorgang durch optimierte Workflows und entschlackte Abfragemasken erheblich schneller zu bewältigen ist. Eine verbesserte Nutzerführung verringert die fachliche Ãberhöhung der heutigen Fahrplananmeldung und kann so auch Schulungsbedarfe für Mitarbeiter auf Kundenseite stark reduzieren.Â
|
||||
Für Kunden die ihrerseits ein externes Planungs- und Bestellsystem einsetzen, besteht mit der neuen Bestellschnittstelle zukünftig ein Eingangskanal, der mit TAF/TAP ein europaweit standardisiertes Format zur nahtlosen End-2-End Integration mit den Systemen der DB Netz AG gewährleistet. Dies vereinfacht für die Softwareanbieter grundsätzlich die Bereitstellung von Drittsystemen für die Planung von Zugfahrten in Europa und reduziert damit Zugangshemmnisse auch auf Kundenseite.
|
||||
Beide Aspekte der Projektumsetzung zahlen auf Effizienz- und Zufriedenheitssteigerungen auf Kundenseite ein. Eine quantitative Bewertung aus DB Netz Unternehmenssicht ist nicht möglich. Eine Abschätzung auf die Entwicklung des CSI (Customer Satisfaction Index) ist nicht seriös vornehmbar.
|
||||
## Effiziensteigerung in der Bearbeitung von Trassenanmeldung
|
||||
|
||||
Auf Seiten der DB Netz AG ist hier eine Effizienzsteigerung insofern erwartbar, dass durch eine besser strukturierte Anmeldeoberfläche und die vollständige Einbindung der automatisierten Plausibilitätsprüfung die Wahrscheinlichkeit von Fehleingaben seitens der Kunden verringert wird. Daraus, und aus der Tatsache, dass TAF/TAP TSI allen Vorgangsbeteiligten Klarheit über einen Vorgangsstatus verschaftt, werden in der Behandlung einzelner Trassenanmeldungen weniger Rückfragen und Abstimmungen mit den Kunden erfolgen müssen, was Fahrplankonstrukteuren mehr Zeit für die Konstruktion von Trassen gibt.
|
||||
Die Einführung der TAF/TAP-TSI im Bestellprozess der DB Netz AG ermöglicht eine erhebliche Vereinfachung im Datenaustausch zwischen europäischen Infrastrukturbetreibern und Verkehrsunternehmen und trägt so naturgemäà zur Entschlackung der Abstimmungsprozesse bei. Durch die nahtlose Kommunikation zwischen nationalen Fahrplansystemen kann eine durchgängige Planung und die Kommunikation in Bezug auf Züge im Grenzverkehr erheblich vereinfacht werden. Die heute praktizierte manuelle Ãbertragung von PCS-Trassenanmeldungen nach TPN durch regionale Mitarbeiter im Fahrplan kann damit ersatzlos entfallen.
|
||||
Eine quantitative Bewertung der Effizienzsteigerung ist nicht belastbar möglich, da keine systematische Erfassung der Arbeitsaufwände für Anmeldungsplausiblisierungen und PCS-Anmeldungshandling erfolgt.
|
||||
## Benennung bereits bekannter Risiken bzgl. der Nutzengenerierung
|
||||
|
||||
Grundsätzlich ist der Nutzen des Projekts von der Anpassung weiterer Systemkomponenten anderer Domänen abhängig. Ohne eine vollständige Implementierung von TAF/TAP in allen am Trassenanmeldungsprozess beteiligten Systemen und Datenlieferanten können die benannten Nutzenpotenziale nicht oder nur begrenzt realisiert werden. Die unmittelbar betroffenen Funktionskomponenten sind:
|
||||
- TAF/TAP-TSI konformes Objektmodell im neuen Konstruktionssystem (Projekt BaDiFa/RuT-K neu)
|
||||
Sicherstellen eines durchgängig implementierten TAF/TAP Objektmodells mit ID-Logiken und 1:n Zuordnungen von Train : PathRequest : Path
|
||||
- TAF/TAP-TSI konforme Betriebsstellenbereitstellung
|
||||
insbesondere die Abbildung der Zuordnung von DB Betriebsstellen zu Primary Location Codes und Ãbertrag aktueller Betriebstellendaten an die RNE Central Reference File Database (CRD))Â
|
||||
- TAF/TAP-TSI konforme Fahrplan- und Fahrzeugstammdaten-Bereitstellung
|
||||
insb. TAF/TAP-TSI Codierungen für Stammdaten wie z.B. Streckenklasse, Zuggattung, Triebfahrzeug o.ä.Â
|
||||
Darüber hinaus sind ggf. weitere Anpassungen hinsichtlich TAF/TAP-TSI in der Systemlandschaft zu berücksichtigen. Hierfür liegen zum Zeitpunkt der Konzeption für das neue Bestellsystem keine detaillierten Informationen vor, sodass nicht mit abschlieÃender Sicherheit festgestellt werden kann, ob tatsächlich Anpassungen in den nachfolgend genannten Systemen notwendig sind. Ggf. notwendig werdende Anpassungen in den nachfolgenden Systeme hinsichtlich TAF/TAP-TSI liegen nicht im Projekt-Scope zur Erstellung eines neuen Bestellsystems:
|
||||
- ggf. Berücksichtigung TAF/TAP-TSI spezifischer Informationen in den Abrechnungssystemen (insb. ID-Zuordnung)
|
||||
- ggf. Berücksichtigung TAF/TAP-TSI spezifischer Informationen in den Veröffentlichungssystemen (insb. ID-Zuordnung)
|
||||
|
||||
Durch die Erstellung eines neuen Bestellsystems, mit dem Ziel zur Trennung von Vertrieb und Fahrplan, wird darüber hinaus im Vergleich zur derzeitigen IT-Systemlandschaft zukünftig keine Funktionalität zur Steuerung des Konstruktionsablaufs im Bestellsystem zur Verfügung stehen. Diese Funktionalität ist daher zeitgleich im neuen Konstruktionssystem ("RuT-K neu") bereitzustellen, um weiterhin den End-to-End-Prozess ("Trassenanmeldung - Konstruktion - Trassenangebot") technologisch unterstützt abbilden zu können. Andernfalls ist das neue Bestellsystem nicht einsatzfähig, da die notwendigen technischen Steuerungsprozesse für die Fahrplankonstruktion nicht zur Verfügung stehen.
|
||||
Detaillierte Informationen bzgl. der Abhängigkeiten von weiteren Projektvorhaben finden sich in Kapitel 2.4 weitere Rahmenbedingungen.
|
||||
## 1.4.3 Einordnung in die Geschäfts- und Konzernziele
|
||||
|
||||
Die Erstellung eines neuen Bestellsystems unterstützt die Strategie DB 2020+ sowie "Zukunft Bahn" u.a. insbesondere durch folgende Aspekte:
|
||||
- Unterstützung der "Digitalisierung" der Arbeit und des Konzerns auf dem Weg zur "Industrie 4.0"
|
||||
- Erhöhung der Kundenzufriedenheit und Effizienz der Arbeit mit IT der DB Netz AG
|
||||
- Anpassung an die Marktanforderungen
|
||||
Das Projekt zur Erstellung eines neuen Bestellsystems ist darüber hinaus im Kontext des Projekts "Zukunft Bahn" in den agilen Value Stream "Fahrplan und Infrastrukturbasis (FIB)" eingebettet. Die Geschäftsziele sind im Value Stream FIB Fachkonzept definiert, das Projekt zur Erstellung eines neuen Bestellsystems zahlt auf die folgenden Ziele ein:
|
||||
Entkopplung Vertrieb und Fahrplan:
|
||||
- Schaffung der Grundlagen für Einführung neuer Produktkombinationen durch Unterstützung des Angebots domänenübergreifender Produkte und schnelle und vereinfachte Konfiguration von Produkten (Vorbereitung für Unterstützung von Bündelprodukten)
|
||||
- Ermöglichung einer separate Steuerung von Vertriebs- und Konstruktionsprozessen (prozessuale Entkopplung des Bestellprozesses vom Konstruktionsprozess)
|
||||
Umsetzung TAF/ TAP TSI
|
||||
-
|
||||
Aufbau eines neuen TAF/TAP TSI konformen Bestellsystems zur Vermeidung von Strafzahlungen durch Sicherstellung der Passfähigkeit zu Europäischen Vorgaben zur Kommunikation mit EVU
|
||||
-
|
||||
âGesetzliche Voraussetzungâ: IT-Vorhaben, die wegen Auflagen des Gesetzgebers und der Rechtsprechung durchgeführt werden müssen. Hierunter fallen auch Selbstverpflichtungen gegenüber der EU. EU-Verordnungen 1305/2014 (TAF TSI) und 454/2011 (TAP TSI) enthalten Vorgaben und Anforderungen an die Standardisierung für Anmeldungen von und Angebote für Trassen. Die Umsetzung von TAF/TAP TSI hat Auswirkungen auf das Daten- und Fachmodell des Bestellsystems.
|
||||
|
||||
|
||||
## Konzept Trennung Trasse-Zug
|
||||
|
||||
Folgende Darstellung visualisiert anhand des Zielbilds FIB2, in welchen Themencluster das Projekt zur Umsetzung eines neuen Bestellsystems verortet wird. Zielkonflikte sind derzeit nicht erkennbar.
|
||||
|
||||
|
||||
|
||||
Darstellung Themencluster Zielbild FIB2
|
||||
|
||||
|
||||
Das Projekt zahlt auf keine der folgenden von der DB Netz AG definierten Strategieziele ein:
|
||||
- Reduktion von Lost Units (Vmin und LST-Störungen)
|
||||
- Verbesserung Projektabwicklung (Zeit, Budget, Qualität)
|
||||
- Verbesserte Nutzung von Analysepotentialen (Datenqualität, -verfügbarkeit, -aufbereitung, -darstellung)
|
||||
+116
@@ -0,0 +1,116 @@
|
||||
# 6.1 Trassenportal Netz (TPN)
|
||||
|
||||
> Confluence Page ID: 27525971
|
||||
> Version: 35
|
||||
> Pfad: /pathOS/Start / Vorstudie Bestellsystem/00_Vorstudie Bestellsystem/6 IT Ist-Analyse/6.1 Trassenportal Netz (TPN)
|
||||
> Labels:
|
||||
|
||||
---
|
||||
|
||||
Die Anwendung Trassenportal Netz (TPN) ist eine Bestandsanwendung und dient funktional der Annahme, Bearbeitung und Verwaltung von Trassenanmeldungen und deren Folgeaufträgen zwischen Eisenbahnverkehrsunternehmen (EVU) und DB Netz.
|
||||
Dabei werden die Trassenbestelldaten über einen TPN-internen Webclient durch die EVU (bzw. teilweise auch durch die Netz-Kundenbetreuer) erfasst oder über die EVU Schnittstelle aus einem EVU-eigenen Drittsystem empfangen. TPN beinhaltet mit dem KK-Client auch das Interface für die DB Netz interne Konstruktionssteuerung, also die Verteilung von Arbeitsaufträgen zu Trassenanmeldungen an Um-Systeme wie RuT-K, neXt Technische Prozesssteuerung und GFD-Z. Konstruktionsergebnisse werden über TPN verbindlich an den Kunden weitergegeben, die dieser - je nach gewähltem Eingangskanal - im entsprechenden Ausgangskanal wiederfindet.
|
||||
|
||||
|
||||
| |
|
||||
Allgemeines zu TPN |
|
||||
Zahlen-Daten-Fakten
|
||||
| |
|
||||
Produktiv seit: |
|
||||
2002
|
||||
| |
|
||||
aktuelle Version: |
|
||||
9.0.0 p00 Februar Release 2019
|
||||
| |
|
||||
Anzahl der Nutzer: |
|
||||
Circa 5.000 (Accounts)
|
||||
| |
|
||||
Programmiersprache: |
|
||||
Java
|
||||
| |
|
||||
IT-Architektur: |
|
||||
BahnNet RA (JEE)+Swing Client+Angular Client
|
||||
| |
|
||||
Kunden: |
|
||||
DB Netz â Fachliche Betriebsführung
|
||||
| |
|
||||
Ansprechpartner DB Systel: |
|
||||
Team TraB (ex TPN)
|
||||
| | Trassenanmeldung DB Netz Link: | https://fahrweg.dbnetze.com/fahrweg-de/kunden/leistungen/trassen/trassenanmeldung
|
||||
## 6.1.1 Fachliche Komponenten
|
||||
|
||||
TPN vereint heute eine Vielzahl fachlicher Komponenten mit unterschiedlichen Zielgruppen:
|
||||
## Webclient (Anita)
|
||||
|
||||
Der Webclient ist das B2B-Bestell-/Anmeldeinterface für EVU-Kunden, in dem Trassenanmeldungen eingegeben, Angebote geprüft und Trassenverträge verwaltet werden können. In der AuÃenwahrnehmung ist der Anita-Client ist das, was der Kunde mit dem Begriff Trassenportal Netz bzw. TPN meint. Der Webclient wird auÃerdem von DB Netz eigenen Kundenbetreuern genutzt, die im Auftrag von Kunden Anmeldungen eingeben oder bearbeiten.Â
|
||||
Die Fachlichkeit des Webclient ist künftig der Verantwortung des Vertriebs zuzuordnen.
|
||||
## EVU Schnittstellen Versionen 2.X und 3.X
|
||||
|
||||
Die EVU-Schnittstellen sind technische Schnittstellen und ermöglichen die Anmeldungsabwicklung aus Drittsystemen. Aus Kompatibilitätsgründen mit Kundensystemen werden zwei Versionen der EVU-Schnittstelle parallel vorgehalten und weitergepflegt.
|
||||
Die Fachlichkeit der Schnittstellen ist künftig der Verantwortung des Vertriebs zuzuordnen.
|
||||
|
||||
## KK-Client
|
||||
|
||||
Der KK-Client in TPN bildet die Kernkomponente für Fahrplankonstrukteure und -koordinatoren. Hierüber werden Trassenkonstruktionsaufträge konkreten Regionalbereichen zugeordnet und das Konstruktionsergebnis dem Kunden zugestellt.
|
||||
Die Fachlichkeit des KK-Client ist künftig der Verantwortung des Fahrplans zuzuordnen.
|
||||
|
||||
## Zugnummerngenerator
|
||||
|
||||
TPN hat mit dem Zugnummerngenerator (ZNG) die zentrale Komponente zur Zugnummern- und Zugnummernkontingentverwaltung im Fahrplan. Vereinfacht gesagt, prüft der ZNG in Anmeldungen angegebene Zugnummern auf Zulässigkeit bzw. weist Zugnummern zu, wenn Anmeldungen keine Zugnummern enthalten.
|
||||
Die Fachlichkeit des Zugnummerngenerator ist künftig der Verantwortung des Fahrplans zuzuordnen.
|
||||
|
||||
## Admin-Client
|
||||
|
||||
Der Admin Client ist die Komponente für die fachliche Betriebsführung in TPN. Hier werden Nutzer verwaltet, Zugnummernkontingente gepflegt, Fristen definiert, Rechte verwaltet und spezielle TPN-Funktionen gesteuert
|
||||
## Fristenverwaltung
|
||||
|
||||
Die Fristenverwaltung ist Teil des Adminclients. Sie verwaltet Fristen für die Fahrplanbearbeitung und Angebotsbeantwortung in verschiedenen Anmeldungstypen und Geschäftsvorfällen.
|
||||
Diese Fristen insgesamt sind nicht eindeutig als vertrieblich oder fahrplanerisch zu bewerten, daher muss die Verantwortungszuscheidung auf Basis der Fristenart erfolgen:
|
||||
- Fristen, die kundenseitig wirken, sind künftig dem Vertrieb zuzuordnen.
|
||||
- Fristen, die die Bearbeitungsdauer in der Angebotserstellung betreffen, sind künftig dem Fahrplan zuzuordnen.
|
||||
## 6.1.2 Technische Architektur
|
||||
|
||||
## Technische Komponenten
|
||||
|
||||
TPN besteht aus einer Reihe technischer Komponenten, die die fachlichen Anforderungen aus Fahrplan und Vertrieb abbilden. Die tiefe Integration zwischen vertrieblichen und fachlichen Funktionskomponenten verhindert die Umsetzung des Zielbilds einer Verantwortungstrennung zwischen Vertrieb und Fahrplan in TPN.Â
|
||||
|
||||
Vertriebliche Funktionen sind zentral in den Komponenten EVU-Schnittstelle und TPN Anita Web Client/-Facade abgebildet.Â
|
||||
## Systemkontextdiagramm TrassenPortalNetz (TPN) - ISTÂ
|
||||
|
||||
Das Kontextdiagramm TPN beschreibt, welche Systeme und NutzergrupÂÂÂpen direkt mit einem System kommunizieren. Zum Stand Februar 2019 ist TPN in der Version 9.0.0. produktiv. Die von TPN angesteuerten Schnittstellen sind im Kapitel Schnittstellenbeschreibung IST Analyse beschrieben.
|
||||
|
||||
|
||||
|
||||
|
||||
|
||||
## 6.1.3 Rollenmodell TrassenPortalNetz (TPN)
|
||||
|
||||
Die Verwendung von Anita TPN Internet Client erfordert folgende Rollen:
|
||||
- EVU- Sachbearbeiter
|
||||
- Kundenbetreuer (Zuständig für einen oder mehrere Kunden, Erfasst eingehende Vorgänge im System, Erstellt ein Angebot und übermittelt es an den Kunden)
|
||||
- RV-Manager
|
||||
|
||||
|
||||
Die Verwendung von Anita Client erfordert folgende Rollen
|
||||
- Konstrukteur
|
||||
- Koordinator
|
||||
- Kundenmanager
|
||||
|
||||
|
||||
Die Verwendung von Admin Client erfordert folgende RollenÂ
|
||||
- Admin NL
|
||||
- Admin FBF
|
||||
- Leser/Erfasser
|
||||
- Technischer Betriebsführer
|
||||
|
||||
|
||||
Die Verwendung des Zugnummerngenerators erfordert folgende Rollen.
|
||||
- ZN_Fremdbelegungsänderung
|
||||
- ZN_AB
|
||||
- ZN_BB (Betra Bearbeiter)
|
||||
|
||||
|
||||
|
||||
Abhängigkeit von der Weiterentwicklung Trassenportal (TPN)
|
||||
-
|
||||
Anforderungen, die noch im TPN umgesetzt werden u.a. Schienenlärmschutzgesetz, Pünktlichkeitsverkehre, Sicherheitsrelevanter Zug, Besondere Fristen müssen auch im neuen Bestellsystem berücksichtigt werden.Â
|
||||
- Die Entwicklung beider Systeme TPN und Bestellsystem greift teilweise auf dieselben Ressourcen und MitarbeiterInnen zu.
|
||||
+60
@@ -0,0 +1,60 @@
|
||||
# 1.5 'muss'-Eigenschaft und Folgen bei Nicht-Umsetzung
|
||||
|
||||
> Confluence Page ID: 27525973
|
||||
> Version: 31
|
||||
> Pfad: /pathOS/Start / Vorstudie Bestellsystem/00_Vorstudie Bestellsystem/1 Ziele des Projekts/1.5 'muss'-Eigenschaft und Folgen bei Nicht-Umsetzung
|
||||
> Labels:
|
||||
|
||||
---
|
||||
|
||||
## 1.5.1 Bewertung anhand der vier im CIO-Bereich der DB Netz AG definierten "muss"-KriterienÂ
|
||||
|
||||
## M1: Gesetzliche Voraussetzung
|
||||
|
||||
(IT-Vorhaben, die wegen Auflagen des Gesetzgebers und der Rechtsprechung durchgeführt werden müssen. Hierunter fallen auch Selbstverpflichtungen gegenüber der EU. Bezeichnung des Gesetzes inkl. Paragraph, in dem eine IT-Umsetzung zwingend gefordert wird (inkl. Angabe der zeitlichen Bezüge/Fristen).
|
||||
Die EU-Verordnung (EG) 62/2006 gibt den rechtlichen Rahmen für die Umsetzung zur Erreichung der Ziele von TAF/TAP-TSI vor. Die Umsetzung von TAF/TAP-TSI ist als EU-Verordnung Nr. 62/2006 zwingend für die Infrastrukturbetreiber und Eisenbahnverkehrsunternehmen umzusetzen.
|
||||
|
||||
Die Europäische Union definiert mit den technischen Spezifikationen für die Interoperabilität (TSI) europaweit die Anforderungen für die Entwicklung von interoperablen Telematikanwendungen im Güter- und Personenverkehr (TAF und TAP) für alle Bahnakteure (Eisenbahninfrastrukturunternehmen, Eisenbahnverkehrsunternehmen, Spediteure, Wagenhalter etc.). Die entsprechenden Verordnungen der EU, 1305/2014 (TAF TSI) und 454/2011 (TAP TSI), beinhalten u.a. die Vorgaben und Anforderungen an die Standardisierung für Anmeldungen von und Angebote für Trassen sowie den Austausch betrieblicher Meldungen zu Zügen. Daraus resultiert in Zukunft eine einfachere und effizientere Planung und Disposition von Verkehren entlang der gesamten Logistikkette auf der Schiene, insbesondere über Infrastruktur- und Ländergrenzen hinweg, sowie eine standardisierte und digitalisierte Kommunikation zwischen allen Beteiligten.
|
||||
Durch die Einführung von TAF/TAP-TSI muss daher zwingend eine grundlegende Anpassung im Bestellsystem, bestehend aus einem Kundenportal und einer EVU-Schnittstelle erfolgen, da die veränderte Objektstruktur und Objektlebenszyklen aus TAF/TAP-TSI nicht 1:1 auf das derzeitige technische Objektmodell der DB Netz AG übertragbar sind. Â
|
||||
Die in Kap. 1.4.1 beschriebenen Ziele 1 (i und ii) und 2 a (i und ii) zahlen unmittelbar auf die Erfüllung dieses Muss-Kriterium ein.
|
||||
## M2: Vertragliche Bindung
|
||||
|
||||
(IT-Vorhaben, die aufgrund bestehender vertraglicher Bindungen durch die DB durchgeführt werden müssen. Verweis auf konkrete Verträge und wann diese zwischen wem abgeschlossen wurde.)
|
||||
Kriterium liegt nicht vor.
|
||||
## M3: Technologische Notwendigkeit
|
||||
|
||||
(Ein IT-Vorhaben dieser Kategorie hat den Ersatz eines IT-Verfahrens zum Ziel. Diese sind aus Sicht des Konzernzwecks zwingend notwendig und werden durch auslaufende Technologien verursacht. Benennung der abgängigen Technologie und weshalb diese abgelöst werden muss.)
|
||||
Kriterium liegt nicht vor.
|
||||
## M4: Unternehmerische Entscheidung
|
||||
|
||||
(IT-Vorhaben, die aufgrund einer unternehmerischen Entscheidung zwingend notwendig werden, bspw. durch Outsourcing, Umstrukturierung oder Joint-Venture. Vorstandsentscheidungen oder Entscheidungen anderer Gremien über die Durchführung des Projektes selbst sind hier nicht gemeint und stellen kein geeignetes Kriterium für ein Muss-Projekt dar. Verweis auf Gremium (mit Datum), in dem die Entscheidung getroffen wurde.)
|
||||
Kriterium liegt nicht vor.
|
||||
## Hinweis:
|
||||
|
||||
Im Fachkonzept FIB ist das unternehmerische Ziel beschrieben, die Domänen Fahrplan und Vertrieb klar zu trennen. Die bisherige IT-Welt mit TPN ist stark integrativ aufgebaut und erlaubt keine klare Verantwortungstrennung zwischen den Domänen. Einzelne IT-Module sind in TPN vereint und können nicht bedarfsweise durch die Verantwortungsträger ausgetauscht werden. Den im Fachkonzept FIB beschriebenen Teil zur Umsetzung dieses Vorhabens wurde im Rahmen der initialen Beschlussvorlage für das Teilprojekt M31 durch den Vorstand in der Vorstandssitzung am 16.05.2017 beschlossen.Â
|
||||
|
||||
## 1.5.2 Folgen bei einer ausbleibenden bzw. verspäteten Umsetzung
|
||||
|
||||
Sofern das Vorhaben zur Umsetzung eines TAF/TAP-TSI konformen Bestellsystems gar nicht durchgeführt wird, sind folgende Folgen zu erwarten. Die selben Folgen gelten auch, wenn die Projektinhalte im Hinblick auf den Zieltermin März 2023 verspätet geliefert werden. Die Anmeldung zum Netzfahrplan ist nur einmal im Jahr möglich ist. Sofern der Termin März 2023 projektseitig nicht gehalten werden kann, kommt es automatisch zu einer Verschiebung von mindestens einem Jahr. Durch einen verspäteten Start (geplant zu 01/ 2020) steigt die Wahrscheinlichkeit, den Zieltermin März 2023 zu verfehlen.Â
|
||||
|
||||
|
||||
-
|
||||
Risiko von Geschäftsausfall:
|
||||
Aufgrund der europäischen Vereinbarung, die Kommunikation in der Geschäftsbeziehung zwischen EVU und EIU ab dem Fahrplanjahr 2024 in einem neuen Datenformat (TAF/TAP-TSI) durchzuführen, ist davon auszugehen, dass EVUs ab diesem Zeitpunkt unter Umständen nur noch in der Lage sein werden, ihre Angebotsanfragen in dem neuen Datenformat zu übersenden. Sofern die DB Netz ihre IT-Systeme hierauf nicht entsprechend vorbereitet hat, kann dies dazu führen, dass die Angebotsanfragen nicht verarbeitet werden können und die Kommunikation in der Geschäftsbeziehung zwischen EVU und DB Netz nicht reibungslos sichergestellt werden kann.Â
|
||||
Die konkreten Auswirkungen und die Tragweite dieses Risikos kann aufgrund unterschiedlichster Ausprägungen zum Zeitpunkt der Erstellung der Vorstudie nicht vorhergesehen werden und daher nicht konkret beziffert werden.
|
||||
|
||||
|
||||
- Reputationsrisiko:
|
||||
Die DB Netz AG hat auf europäischer Ebene gegenüber den anderen EIUs und EVUs eine verbindliche Zusage zur Umstellung auf den TAF/TAP-TSI konformen Nachrichtenaustausch gegeben. Den von den anderen EIUs angestrebten Zeitpunkt zur Unterstützung des neuen Nachrichtenformats bereits zum Fahrplanjahr 2021 wurde insbesondere von der DB Netz zurückgewiesen und auf das Fahrplanjahr 2024 verschoben. Eine erneute, durch die DB Netz veranlasste Verschiebung, kann zur Schädigung der Reputation von der DB Netz führen.
|
||||
Das Reputationsrisiko ist nicht monetär bewertbar.
|
||||
|
||||
|
||||
|
||||
- Rechtliche Folgen/ Pönalen:
|
||||
Zum Zeitpunkt der Erstellung dieser Vorstudie gibt es keine Anzeichen, dass bei einer verspäteten oder vollständig ausbleibenden Berücksichtigung des Nachrichtenformats TAF/TAP-TSI Pönalen zu erwarten sind. Nach Rücksprache mit der Rechtsabteilung der DB Netz AG, wird kein internationales oder nationales Gesetzt gebrochen, zudem kann die Europäische Union die DB Netz AG nicht rechtlich belangen.Â
|
||||
Darüber hinaus ist jedoch davon auszugehen, dass die EVUs Schadenersatzansprüche gegenüber der DB Netz AG geltend machen können, da die DB Netz AG die EVUs dazu aufgefordert hat, ihre System zum Fahrplanjahr 2024 IT-technisch umzustellen. Die hieraus resultierenden Aufwände, könnten im ungünstigsten Fall gegenüber der DB Netz eingeklagt werden.
|
||||
Eine konkrete Bezifferung des möglichen Schadens ist zum Zeitpunkt der Erstellung der Vorstudie nicht bekannt. Laut Aussage der Rechtsabteilung lässt sich dies nicht sinnvoll abschätzen, da nicht absehbar ist, inwiefern Schadenersatzansprüche geltend gemacht werden könnten.
|
||||
|
||||
|
||||
Darüber hinaus sind die weiteren Folgen zu erwarten:
|
||||
- Vorstandsbeschluss kann nicht umgesetzt werden, inbesondere das Thema Trennung Fahrplan + Vertrieb
|
||||
+38
@@ -0,0 +1,38 @@
|
||||
# 2019-02-06 Erstaustausch mit TAF/TAP Konzeptionsteam
|
||||
|
||||
> Confluence Page ID: 27525978
|
||||
> Version: 2
|
||||
> Pfad: /pathOS/Start / Vorstudie Bestellsystem/00_Vorstudie Bestellsystem/14 Besprechungsnotizen Vorstudie/2019-02-06 Erstaustausch mit TAF/TAP Konzeptionsteam
|
||||
> Labels: meeting-notes
|
||||
|
||||
---
|
||||
|
||||
## Datum
|
||||
|
||||
|
||||
## Teilnehmer
|
||||
|
||||
-
|
||||
Wolfgang Kuzai, Patrick Breun, Julian Holzner, Henning Henke, Martin M Schmitt, Marcel Hufgard, Ana Cvitkovic, Sebastian Hassemer, Alicia Schäfer, Konstantin Pussep, Matthias Laube, Holger Duis, Marco Krannich
|
||||
## Inhalt
|
||||
|
||||
Folgende Rahmenbedingungen wurden im Termin besprochen:
|
||||
-
|
||||
- Big Bang Umstellung auf Neues Bestellportal + EVU SST für Fpl-Jahr 2024 (alte EVU SST und TPN Kundenzugang wird abgeschaltet)
|
||||
- Â ja
|
||||
- Ja, das ist das Ergebnis aller bisherigen internen Abstimmungen und somit der aktuelle Ansatz, welchen wir auch gegenüber den EVU kommunizieren werden
|
||||
|
||||
- Ein sogenannter Nachrichten-Dispatcher für ein Verteilen von Nachrichten an Vertrieb und Betrieb ist fachlich nicht notwendig (ja, die Bündelung beider SST ist fachlich nicht notwendig), auch auf Kundenseite gibt es keine zwingende Anforderung dafür (wir selbst haben das nicht analysiert, der Vorschlag zur Verwendung von nur einer SST bei Fahrplan und Betrieb wurde vom CIO-Bereich gemacht). Es existiert eine klare Trennung der Kanäle, keine Rückkopplung möglich. Deshalb wird vorgeschlagen auf einen Dispatcher zu verzichten, dies impliziert, dass Betrieb und Vertrieb beide parallel ihre Ausprägung der notwenigen TAF/TAP Schnittstelle selbst entwickeln.
|
||||
- Noch gibt es die Idee eines gemeinsamen technischen Ein- und Ausgangs für die Kommunikation zwischen DB Netz und EVU (technischer SPOC). Ob der tatsächlich von den EVU zwingend gewünscht ist, können wir nicht beurteilen. Fachlich gibt es einerseits völlig unterschiedliche Messages und Abläufe für Betrieb und Fahrplan, die jeder für sich in einer eigenen Dokumentation beschreiben und umsetzen wird, andererseits gibt es auch Messages, die sowohl von Betrieb als auch Fahrplan genutzt werden, dabei jedoch in völlig anderen Prozessschritten und fachlichem Kontext.
|
||||
- Die Stammdatenbereitstellung für die EVUs ist nicht Teil des Bestellportals.Â
|
||||
- Das war uns vor dem heutigen Termin noch nicht bewusst. In jedem Fall muss das Thema aber betrachtet werden.
|
||||
- Offen ist dann aber weiterhin die Zuständigkeit für diesen sehr wichtigen Punkt.
|
||||
|
||||
- Ãber die Schnittstelle (bzw. Bestellportal) kommen nur PathRequestMessages herein, die vollständig auf der Infrastruktur der DB Netz liegen. Das Harmonisierungsverfahren wird - zumindest nicht im ersten Schritt - mit dem Bestellportal unterstützt.Â
|
||||
- ja
|
||||
- Die erste Aussage ist nicht richtig. Erstens konstruiert DB Netz in Abstimmung mit dem jeweiligen Nachbar-EIU auch auf fremder Infrastruktur und zweitens kann (und muss bei internationalen Zügen) die TrainInformation der PathRequestMessage auch Infrastrukturpunkte auf fremder IS enthalten. Diese Informationen werden zwingend durch den Betrieb und weitere Nachnutzer der Zug- und Trassendaten benötigt.
|
||||
Zur zweiten Aussage: Die Harmonisierung des Zuges und seines Laufwegs in der Vorplanungsphase ist eine reine Kommunikation zwischen den beteiligten EVU ohne Mitwirkung der EIU. Aus meiner Sicht kann es schon aus regulierungsrechtlichen Gründen nicht Aufgabe von DB Netz sein, diese interne EVU-Kommunikation zu unterstützen. Ich bitte hier klar zu trennen zwischen der Harmonisierung zwischen den EVU (mit überwiegend kommerziellen Aspekten und Endkundensicht) einerseits und den andererseits sicher notwendigen und zu optimierenden Abstimmungen zwischen den EIU bei der Trassenkonstruktion für internationale Züge. Letzeres ist Aufgabe des Fahrplans und nicht des Vertriebs.
|
||||
|
||||
|
||||
in blau: Ergänzungen bzw. Bestätigung durch Patrick Breun am 06.02.19 19:19 Uhr per Mail
|
||||
in grün: Ergänzungen bzw. Bestätigung durch Wolfgang Kuzaj am 07.02.19 08:42 Uhr per Mail
|
||||
@@ -0,0 +1,71 @@
|
||||
# 8.2 Rollout/Deployment
|
||||
|
||||
> Confluence Page ID: 27525986
|
||||
> Version: 64
|
||||
> Pfad: /pathOS/Start / Vorstudie Bestellsystem/00_Vorstudie Bestellsystem/8 Rollout und Change Management/8.2 Rollout/Deployment
|
||||
> Labels:
|
||||
|
||||
---
|
||||
|
||||
## EinführungÂ
|
||||
|
||||
Die Behandlung des Migrationskonzepts des Bestellsystems ist nicht vollständig losgelöst vom Nachbarprojekt BaDiFa betrachtbar. Eine rein vertriebliche Umsetzung der TAF/TAP-TSI-Anforderungen kann nicht funktionieren, da ansonsten der Vertrieb in die Objekthoheit über fahrplanerisch fachliche Inhalte gehen müsste. Dennoch kann zwischen Bestellsystem und BaDiFa differenziert betrachtet werden, wie ein Migrationskonzept aussehen kann. Dabei sind aus Sicht des Bestellsystems zwei wesentliche Ziele ausschlaggebend für die Konzeptentscheidung:
|
||||
- Zum Fahrplanjahr 2024 muss die Trassenbestellung zu 100% TAF/TAP-konform erfolgen
|
||||
- Um Schnittstellenkunden die Möglichkeit zu geben, anzupassende Drittsysteme integriert zu testen, soll frühestmöglich eine an das Common Interface angebundene Testumgebung für unternehmensübergreifende End-to-end-Tests bereitgestellt werden.
|
||||
Das hier beschriebene Migrationskonzept beschreibt ausdrücklich die Migration in den produktiven Systemeinsatz. Ungeachtet des hier beschriebenen Migrationskonzeptes wird es in den im Umsetzungsprojekt aufzubauenden Test- und Abnahmeumgebungen häufige Releases geben. Dies ist ganz im Sinne der vorgesehenen agilen Methode, bei welcher neue Funktionen in jedem Sprint entstehen und getestet werden und diese auch grundsätzlich immer releasefähig sind. Durch die Anwendung des Scaled Agile Framework (SAFe) werden auÃerdem Features immer so beschrieben, dass Sie innerhalb von sechs Sprints umsetzbar sind. Die so entstehenden Produktinkremente erweitern das System um gröÃere Funktionsblöcke. Grundsätzlich wird darauf geachtet, dass neuer Code mit Regressions- und Unittests durchzogen ist, um einen weitgehend automatisierten Freigabe- und Releaseprozess aufzubauen.
|
||||
## MigrationskonzeptÂ
|
||||
|
||||
## Produktivsetzung Bestellsystem
|
||||
|
||||
Die Einführung von TAF/TAP kann ausschlieÃlich zu einem Fahrplanwechsel erfolgen, da eine nahtlose Konvertierung von geplanten Trassen in TAF/TAP-konforme Objekte nicht garantiert verlustfrei möglich ist und so das Risiko besteht, den Bahnbetrieb nicht gewährleisten zu können. Zur Erfüllung des Ziels der DB Netz AG, ab Fahrplanjahr 2024 ausschlieÃlich TAF/TAP-konforme Anmeldungen zuzulassen und Trassenkonstruktionen ebenfalls ausschlieÃlich als TAF/TAP-kompatible Path-Objekte auszugeben, wird damit der 10.12.2023 (Fahrplanwechsel 2023/24) als Stichtag festgesetzt. Die Anmeldefrist für den Netzfahrplan 2024 endet am zweiten Montag im April (10.04.2023) um 24:00 Uhr. Die Anmeldephase beginnt üblicherweise einen Kalendermonat vor Ablauf der Frist, womit eine späteste Inbetriebnahme des Bestellsystems aus Bestellportal und -schnittstelle zum 10. März 2023 festgelegt werden kann.
|
||||
Daraus bedingen sich bereits zwei Festlegungen:
|
||||
- Ausschluss eines fachlichen Parallelbetriebs:
|
||||
- Alle Fahrplananmeldungen und trassenvertragsverwaltenden Aktivitäten für Zugfahrten, die vor dem 15.12.2024 stattfinden sollen, sind über die Altsysteme um TPN abzuwickeln.
|
||||
- Alle Zugfahrten, die ab dem 10.12.2023 stattfinden sollen, sind über das neue Bestellsystem anzumelden und zu verwalten.Â
|
||||
- Festlegung eines faktischen Parallelbetriebs:Â
|
||||
- Im Zeitraum von spätestens 10. März 2023 bis mindestens 11.12.2023 werden sowohl TPN mit den EVU Schnittstellen V2 und V3 als auch das neue Bestellsystem mit der neuen TAF/TAP-TSI EVU-Schnittstelle produktiv und betriebsgeführt sein.Â
|
||||
- Kundenseitig müssen Mitarbeiter in dieser Zeit mit beiden Systemen gleichzeitig arbeiten können, wenn Sie in beiden Fahrplanjahren aktiv Anmelden und Trassen verwalten möchten.
|
||||
Vor der spätestmöglichen Produktivsetzung zum 10. März 2023 soll im Rahmen eines Soft Releases das Bestellportal bereits in der Produktionsumgebung deployt werden und nach intensiven Tests das Funktionsmodul Planung sowie grundsätzlich die Vorgangsverwaltung produktiv geschaltet werden. Damit gewinnen unsere Kunden Zeit, sich mit dem neuen Bestellportal zu befassen und die Oberfläche kennen zu lernen. Das Anlegen von Entwürfen und deren Bearbeitung ist zu diesem Zeitpunkt vollumfänglich möglich. Die Funktionen zur Trassenanmeldung werden mit dem Stichtag 10. März 2023 aktiviert, sodass eine verfrühte Anmeldung ausgeschlossen ist.
|
||||
## Verzicht auf Teilproduktivsetzung TAF in der Click&Ride-App
|
||||
|
||||
Grundsätzlich besteht die Möglichkeit, eine nach auÃen hin wirksame Teilproduktivsetzung im Verfahren Click&Ride vorzunehmen. Dazu müsste die Click&Ride App früher als geplant an TAF TSI angepasst werden. Die am Durchlauf beteiligten Komponenten SteuerungVertriebsAblauf sowie die Fahrplan-Schnittstelle zur Ãbergabe an SteuerungKonstruktionsAblauf müssten zumindest in den benötigten Teilen erstellt und produktiv gesetzt werden. Der Belegungsautomat kann grundsätzlich mit den Anfragen umgehen, da sich der fachliche Inhalt auf das benötigte Eingangsformat ITOM mappen lässt.
|
||||
Die Implementierung würde dann aber ausschlieÃlich Fahrten des unterfristigen Güterverkehrs betreffen und die Umkehr des Ãberwiegendprinzips in der Entwicklung bedeuten. Aus der Anwendung eines Spezialfalls müssten wir dann die Aufweitung der Komponenten zum fachlichen Normalfall vornehmen. Die bessere Strategie ist die Entwicklung des Normalfalls, mit dem wir die gröÃste Zahl der Anwendungsfälle abdecken können und dann von da aus die Spezialisierungen vorzunehmen. Diese Umkehr wird nach Erfahrung des Projektteams mit hoher Wahrscheinlichkeit erheblich aufwendiger und mutmaÃlich weniger robust als die Entwicklung über den Normalfall. Zudem ist der erreichte Mehrwert mit einer vorgezogenen Einführung Click&Ride in TAF TSI zu hinterfragen. Da Click&Ride nur auf den Güterverkehr abzielt würde grundsätzlich nur TAF TSI, nicht TAP TSI Anwendung finden. Aus dem heutigen Mapping-Verlauf Click&Ride Objektmodell, würde statt auf ITOM auf TAF gemappt, um dann vor Eingang in den Belegungskern wieder auf ITOM zu mappen. Das Messaging nach TAF TSI wird weitgehend nicht angewendet, da die App durch uns angeboten wird und im internen Kommunikationslauf ein effizienteres Messaging genutzt werden soll.
|
||||
Zusätzlich gehen wir davon aus, dass eine vorgezogene Produktivsetzung von Click&Ride das Entwicklungsteam mit Aufgaben aus der Betriebsführung von Click&Ride belasten würde, was die weitere Entwicklung schwerer planbar macht und grundsätzlich die Verfügbarkeit von Entwicklungsressourcen einschränkt. Es wird daher empfohlen, auf eine Vor-Produktivsetzung mittels Click&Ride zu verzichten.
|
||||
## Datenmigration
|
||||
|
||||
Um insbesondere denjenigen Kunden, die auf die Benutzung des Bestellportals angewiesen sind ein möglichst nahtloses weiterarbeiten im neuen Bestellsystem zu ermöglichen, ist vorgesehen einen ausgewählten Teil der Daten aus TPN zu migrieren und im neuen Bestellportal zur Verfügung zu stellen. Dies geschieht standardmäÃig für alle Kundennummernbereiche, ohne besonderen Antrag der Kunden.
|
||||
Grundsätzlich werden zu zwei Zeitpunkten Daten gesichert und im neuen System zur Verfügung gestellt. Die folgende Liste beschreibt die Daten und zu welchem Zeitpunkt die Datensicherung und der Ãbertrag ins neue Bestellsystem erfolgen werden:
|
||||
- Initiale Produktivsetzung:
|
||||
- In TPN enthaltene Entwürfe, die die Fahrplanjahre 2024 fortfolgende betreffen
|
||||
- In TPN enthaltene Anmeldungen aus dem Kanal "TPN" zu den Netzfahrplanjahren 2022 und 2023
|
||||
- Fahrplanwechsel 2024:
|
||||
- In TPN seit der letzten Migration enthaltene Anmeldungen aus dem Kanal "TPN" des Fahrplanjahrs 2023
|
||||
Die Migration macht es erforderlich, die Daten aus dem alten Objektmodell von TPN in das Objektmodell von TAF/TAP zu überführen. Dabei entstehen nach aktueller Analyse zwei zentrale Herausforderungen:
|
||||
- Objektgenerierung und ID-Zuweisung
|
||||
In der Migration müssen aus Fahrlagen bzw. Trassenverträgen Objekte aus TAF/TAP generiert werden, die heute so nicht in den Daten enthalten sind
|
||||
|
||||
- Fahrlagen (Entwürfe und Anmeldungen) werden zu PathRequest-Objekten mit entsprechenden IDs umgewandelt
|
||||
- Train-Objekte müssen generisch erzeugt werden und mit IDs versehen werden. Hier können wir im schlimmsten Fall nur eine 1:1-Zuordnung zwischen PathRequest und Train erzeugen, was auf Kundenseite dazu führt, dass Sachverhalte, die in mehreren Zeitscheiben bestellt wurden, nicht in einem Train gruppiert werden
|
||||
- Stamm- und Ergänzerlogik
|
||||
Die heute bestehende Logik aus Stamm- und Ergänzerfahrplänen lässt sich nicht auf TAF/TAP TSI übertragen. Eine Logik, die verlustfrei Stamm- und Ergänzer in neue PathRequest-Objekte übersetzt wird als sehr aufwändig eingeschätzt. Da der Nutzen hier insgesamt als überschaubar zu betrachten ist, wird die Datenmigration ausschlieÃlich Stammfahrpläne berücksichtigen
|
||||
Die migrierten Daten werden sämtlich getaggt, um Altdaten im neuen Bestellsystem einfach zuordnen zu können. Hierbei werden Tags genutzt, die Daten aus einer Migrationsregel zusammenfassend markieren. Alle migrierten Daten werden ausdrücklich als PathRequest-Objekte angelegt und in den Status Entwurf im neuen Bestellsystem überführt. So wird sichergestellt, dass bestehende Vorgänge aus TPN nicht als aktiver Vorgang im neuen Bestellsystem bearbeitet werden können.
|
||||
Â
|
||||
Rückfallszenario
|
||||
Für den Fall einer nicht fristgerechten Einführung des Bestellsystems muss ein Weiterbetrieb des Altsystems möglich sein. Ebenso muss ein Rollback in die alte Systemwelt dann gewährleistet sein, wenn es zu unvorhergesehenen, nicht kurzfristig beseitigbaren Problemen bei der Produktivsetzung kommen sollte. Oberste Priorität hat zu jeder Zeit die Gewährleistung der regulierungskonformen Abwicklung von Zugtrassenanmeldungen.
|
||||
In der Konsequenz würde dies bedeuten, dass die Bestandssysteme TPN, GFD-Z und RUT-K um mindestens ein Jahr länger produktiv zur Verfügung stehen müssten. Der nächste mögliche Termin zur Produktivsetzung würde sich dann auf den Beginn der Anmeldephase zum Netzfahrplan 2025 verschieben, der fachlich relevante Stichtag wäre dann der 15.12.2024.
|
||||
Den Kunden ist der Verbleib beim bzw. der Rückfall auf die alte Systemwelt unverzüglich mitzuteilen, sodass deren Anmeldungen weiterhin in den Bestandssystemen durchgeführt werden können.Â
|
||||
## AuÃerbetriebnahme Altsystem (vertriebliche Sicht)
|
||||
|
||||
## AuÃerbetriebnahme TPN
|
||||
|
||||
Die AuÃerbetriebnahme von TPN erfolgt parallel zur Inbetriebnahme des neuen Bestellsystems. Nach dem Soft-Release des Bestellportals sollen idealerweise in TPN alle Fahrplanjahre ab 2024 nicht weiter editierbar sein. So wird sichergestellt, dass Kunden neue Entwürfe für das kommende Fahrplanjahr ab dann im neuen Bestellportal anlegen und dann auch nahtlos damit weiterarbeiten können. Mindestanforderung wäre, Kunden beim Einloggen in TPN auf das neue Bestellsystem und -portal hinzuweisen, wenn ein Fahrplanjahr 2024 oder gröÃer ausgewählt wird.
|
||||
Nach Umstellung auf das neue Bestellsystem wird den Kunden für eine Ãbergangsfrist weiterhin lesender Zugriff auf eine TPN-Instanz gewährt. Dies ermöglicht dem Kunden ggf. den Export von Altdaten nachträglich vorzunehmen bzw. Vorgänge in TPN einzusehen. Die Dauer für die Vorhaltung von TPN im Lesemodus wird in Abstimmung mit den Kunden festgelegt und frühzeitig kommuniziert. Das Projekt empfiehlt eine Vorhaltung von TPN im Lese-Modus bis Ende März 2024. Danach kann ein Datenexport vom Kunden nicht mehr durchgeführt werden. Â
|
||||
Grundsätzlich sind die Daten aus TPN zehn Jahre lang zu archivieren, um den gesetzlichen Anforderungen für Aufbewahrungsfristen von Geschäftsunterlagen gerecht zu werden. Um die vertriebliche Sicht auf diese Geschäftsdaten zu sichern, sind die Daten aus TPN in die TPN-Archivdatenbank zu konsolidieren. Diese Datenbank muss verantwortlich durch den Vertrieb aufbewahrt werden. Ein Zugriff auf diese Daten ist jederzeit mit einem üblichen Oracle SQL-Datenbanktool realisierbar. Je nach Anforderung an die Datenabfrage kann ein Datenabruf ggf. aufwändig sein. Eine regelmäÃige Bereinigung von Datensätzen die älter als zehn Jahre sind wird empfohlen.
|
||||
Die hier beschriebenen MaÃnahmen stellen die vertrieblichen Anforderungen an die AuÃerbetriebnahme von TPN dar. Die entsprechenden fahrplanerischen Anforderungen sind der Vorstudie des Projekts BaDiFa zu entnehmen.  Die Verantwortlichkeit zur technischen AuÃerbetriebnahme von TPN liegt grundsätzlich im Projekt BaDiFa.Â
|
||||
## AuÃerbetriebnahme EVU-Schnittstelle
|
||||
|
||||
Mit der AuÃerbetriebnahme von TPN zum 10.12.2023 muss auch die Bestands-EVU-Schnittstelle auÃer Betrieb genommen werden. Dies betrifft die heutigen produktiven Versionen 2.X und 3.X der Schnittstelle. Es muss sichergestellt sein, dass ab dem Fahrplanwechsel keine Anmeldungen mehr über die beiden Altschnittstellen angenommen werden. Weiter muss sichergestellt werden, dass Anmeldungen, die das Fahrplanjahr 2024 betreffen, an den beiden Schnittstellen mit Release des Common Interface (EVU Schnitstelle V4) nicht weiter akzeptiert werden.
|
||||
## Abhängigkeiten des Altsystems
|
||||
|
||||
Die Abhängigkeiten von TPN zu angrenzenden Systemen ist umfassend und ausführlich im Kapitel  beschrieben. Die Auflösung der Abhängigkeiten zum Altsystem ist im Rahmen der Projektumsetzung zu gewährleisten. Eine Inbetriebnahme des Bestellsystems ohne Berücksichtigung der an der Wertschöpfung beteiligten Umsystemen ist nicht durchführbar.
|
||||
Die Umstellung von Business Intelligence Systemen wird projektseitig durch neue Schnittstellenangebote unterstützt. Die rechtzeitige Systemanpassung liegt hier aber in der Verantwortung der Systeminhaber. Eine Erfordernis zur Verschiebung der Produktivsetzung des neuen Bestellsystems wird aus nicht angeschlossenen BI-Systemen aktuell nicht gesehen.
|
||||
+15
@@ -0,0 +1,15 @@
|
||||
# 8.1 Organisatorischer Ãnderungsumfang
|
||||
|
||||
> Confluence Page ID: 27525988
|
||||
> Version: 12
|
||||
> Pfad: /pathOS/Start / Vorstudie Bestellsystem/00_Vorstudie Bestellsystem/8 Rollout und Change Management/8.1 Organisatorischer Ãnderungsumfang
|
||||
> Labels:
|
||||
|
||||
---
|
||||
|
||||
In der ersten Ausbaustufe des neuen Bestellsystems sind keine Ãnderungen an operativen Geschäftsprozessen geplant. Es wird jedoch versucht, eine gewisse Trennung zwischen Vertrieb und Fahrplan zu erreichen, weshalb die beiden Projekte "Bestellsystem" und "BaDiFa" initiiert wurden, die TPN ablösen werden. Beim Vertrieb erhalten die Kundenbetreuer eine ähnliche Vorstellung wie die EVU-Kunden. AuÃerdem erhalten die Kundenbetreuer Zugriff für das neue Bestellportal, sodass sie dem Kunden für evtl. Fragen im 1st Level Support zur Verfügung stehen können. Das Projekt BaDiFa hingegen ist für die Fahrplan-Seite und das dort zu planende Change Management der Fahrplan-Konstrukteure verantwortlich.Â
|
||||
Das neue Bestellportal wird keine eigene Benutzerverwaltung haben. Die Benutzerverwaltung für das neue Bestellportal setzt auf dem bereits bestehenden eBRS (externes Benutzer- und Rollensystem) auf. Für Personen, die über das neue Bestellportal Trassen bestellen sollen, ist die hier bestehende Berechtigungsrolle âTrassenbestellungâ relevant. PowerUser und StandardUser mit dieser Rolle dürfen auf das neue Bestellportal zugreifen und Bestellungen tätigen.
|
||||
Die Voraussetzung für einen späteren Go-Live des neuen Bestellportals ist, dass für jedes EVU mind. ein PowerUser berechtigt ist, der wiederum StandardUser für sein Unternehmen in Eigenregie anlegen und diese entsprechend berechtigen kann.
|
||||
Die Verantwortlichkeit liegt bei I.NMK. Wir gehen zum Zeitpunkt der Konzeption davon aus, dass zum Go-Live des neuen Bestellportals die User, die das System nutzen werden, bereits angelegt sind, da andere Systeme (u.a. Click&Ride) bereits gepflegte Nutzer in eBRS benötigen.
|
||||
Damit das neue Bestellsystem zu jedem Zeitpunkt über die aktuellsten Kundenstammdaten verfügen kann, wird es sich Daten aus dem CRM System der DB Netz AG über den Kundendatenverwaltungsservice (KDV) ziehen. Damit der Abgleich der Daten einfach und vor allem TAF/TAP-konform erfolgen kann, muss im CRM System der DB Netz AG das Feld âCompany IDâ für jeden Kunden gepflegt sein und über den KDV übertragen werden. Verantwortlich für die Pflege im CRM System ist I.NMK 3. Im Rahmen des Projektverlaufs sind die Verantwortlichen einzubeziehen und die Datenpflege anzustoÃen.
|
||||
Damit das neue Bestellsystem über die richtigen Stammdaten verfügen kann, ist es unbedingt erforderlich, dass die âPrimary Location Codesâ und die âSubsidiary Location Codesâ im Stammdatensystem zur Verfügung gestellt werden. Insbesondere für die inländischen Infrastrukturstammdaten werden diese Informationen daher durch den InfrastrukturManager (Projekt M15) bereitgestellt. Primary Location Codes und Subsidiary Location Codes für auslänsiche Infrastrukturstammdaten dagegen werden über die Anbindung an die CRD bezogen.
|
||||
+10
@@ -0,0 +1,10 @@
|
||||
# 9 Weiteres Vorgehen und Kostenindikation
|
||||
|
||||
> Confluence Page ID: 27525989
|
||||
> Version: 4
|
||||
> Pfad: /pathOS/Start / Vorstudie Bestellsystem/00_Vorstudie Bestellsystem/9 Weiteres Vorgehen und Kostenindikation
|
||||
> Labels:
|
||||
|
||||
---
|
||||
|
||||
|
||||
@@ -0,0 +1,20 @@
|
||||
# 8.3 Change Management
|
||||
|
||||
> Confluence Page ID: 27525991
|
||||
> Version: 23
|
||||
> Pfad: /pathOS/Start / Vorstudie Bestellsystem/00_Vorstudie Bestellsystem/8 Rollout und Change Management/8.3 Change Management
|
||||
> Labels:
|
||||
|
||||
---
|
||||
|
||||
Zu Beginn des Umsetzungsprojekts sollten alle Projektteilnehmer an einer SAFe Schulung teilnehmen.
|
||||
Für das Thema Einführung und Change Management existiert bereits eine Grobplanung. Es steht bereits jetzt fest, dass die Inhalte von bestehenden Richtlinien und Geschäftsprozessen nicht angepasst werden müssen (siehe hierzu auch Kapitel 3.3.). Weiterhin wurde innerhalb der Konzeptionsphase auch identifiziert, dass voraussichtlich keine personellen Reorganisationen oder Höherqualifizierungen von Personal notwendig sein werden. Die Ausgestaltung dieser Grobplanung wird innerhalb des Umsetzungsprojekts maÃgeblich durch die Rolle des Change Managers vorangetrieben. Diese Rolle ist in der Projektplanung und -kalkulation vollständig berücksichtigt und bereits zum Projektstart (01.01.2020) zu besetzen. Die weiteren Aufgaben des Change Managers sind Folgende:
|
||||
|
||||
|
||||
- Umsetzung und Berücksichtigung der MaÃnahmen aus der Stakeholderanalyse (siehe Kapitel 2.1.).
|
||||
- Koordinierung der bereits identifizierten organisatorischen Rahmenbedingungen, die für die spätere Nutzung des neuen Bestellportals erforderlich sind (siehe Kapitel 8.1.). Im Rahmen der Konzeptionsphase sind keine maÃgeblichen, organisatorischen Ãnderungen identifiziert worden.
|
||||
- Definition und Leitung des Change-Managementprozesses während des IT-Projekts und auch nach dem IT-Projekt.
|
||||
- Erarbeitung eines detaillierten Einführungsplans unter Berücksichtigung von Change-MaÃnahmen und des bereits erstellten Projektplans. Hierzu zählt unter anderem das Einbinden der künftigen Anwender des Systems (interne/externe Kunden und Mitarbeiter). Im Rahmen der Konzeptionsphase sind folgende Ansätze für die Kommunikation erarbeitet worden: Workshops, Informationsveranstaltungen und Online Community (bezieht sich ausschlieÃlich auf die Projektlaufzeit).
|
||||
- Aufbau einer Online Community, um mit Endanwendern dauerhaft in Kontakt zu bleiben und in regelmäÃigen Abständen Informationen zum aktuellen Umsetzungsstand zu geben (Verantwortlich: Rolle Change Manager).
|
||||
- Vorbereitung und Ausgestaltung eines Schulungskonzepts. Dieses Schulungsangebot soll den Kunden bereits vor Go-Live des neuen Bestellportals zur Verfügung stehen, damit Sie von Beginn an effizient und ohne Unklarheiten mit dem neuen System arbeiten können. Im Rahmen der Konzeptionsphase sind folgende Ansätze erarbeitet worden: Erstellung eines FAQ-Bereichs, Erstellung eines Anwenderhandbuchs (sollte im Rahmen des Umsetzungsprojekts für den anschlieÃenden Betrieb erstellt werden, damit der Anwender bei auftretenden Fragen schnell auf Lösungen zurückgreifen kann). Zusätzlich sollen Online-Meetings angeboten werden, um eine Live-Einführung in das System zu geben.
|
||||
Das neue Bestellsystem und das Projekt BaDiFa lösen das jetzige Bestellsystem TPN gemeinsam ab, weshalb dieses erst nach einer erfolgreichen Einführung beider neuen Systeme abgeschaltet werden kann. Die Verantwortlichkeit hierfür liegt bei I.NMK und I.NMF und damit zunächst nicht im Rahmen von einem der beiden genannten Projekte. Der Change Manager sollte die notwendigen Tätigkeiten innerhalb der Projektlaufzeit identifizieren, konkrete Aufgaben ausarbeiten und schlussendlich die Ausführung dieser Aufgaben koordinieren.
|
||||
+36
@@ -0,0 +1,36 @@
|
||||
# 9.1 Vorgehensmodell und Projektorganisation
|
||||
|
||||
> Confluence Page ID: 27525993
|
||||
> Version: 10
|
||||
> Pfad: /pathOS/Start / Vorstudie Bestellsystem/00_Vorstudie Bestellsystem/9 Weiteres Vorgehen und Kostenindikation/9.1 Vorgehensmodell und Projektorganisation
|
||||
> Labels:
|
||||
|
||||
---
|
||||
|
||||
Die Umsetzung des Projekts zur Erstellung eines neuen Bestellsystems ist gemäà dem agilen Vorgehensmodell Scrum geplant. Aufgrund des zu erwartenden Umfangs werden mehrere agile Umsetzungsteams parallel arbeiten. Zur Koordination der agilen Umsetzungsteams im Rahmen gröÃerer Agile Release Trains im Programm FIB wird nach dem Scaled Agile Framework (SAFe) gearbeitet.
|
||||
|
||||
|
||||
|
||||
Abbildung: Organisationsmodell SAFe 4.0 für agile skalierte Vorhaben
|
||||
Im übergeordneten Programm (bzw. Value Stream; vgl. 2. Ebene bei SAFe 4.0) FIB wird â wie in den untergeordneten ARTs auch â nach agilen Prinzipien gearbeitet:
|
||||
|
||||
|
||||
|
||||
Agiles Arbeiten bietet sich durch des groÃen Umfangs der Anwendungsfälle und der komplexen Fachlichkeit an. Durch die agile Umsetzung lässt sich der Fachbereich frühzeitig und regelmäÃig einbinden. Durch die regelmäÃige Ãberprüfung der Ergebnisse mit dem Fachbereich wird sichergestellt, dass die Implementierung entsprechend der fachlichen Anforderungen erfolgt, da die Anforderungen regelmäÃig überprüft werden. Das Risiko âan den Bedarfen vorbei zu entwickelnâ ist somit gering. Die Einbindung des Fachbereichs sowie einiger ausgewählter EVU-Kunden kann dies somit gewährleistet und ihr Feedback aus Anwendersicht direkt berücksichtigt werden.
|
||||
Die übergeordnete Struktur, unter Einbezug der Boards (zur Entscheidungsfindung und bei Eskalationen), sieht folgende Aufbauorganisation bei M13, M15 und M31 im Value Stream FIB vor:
|
||||
- Design/Agile Board mit Product Management und RTE
|
||||
- Architekturboard mit den System Architects
|
||||
- Leitungsboard mit je einem Vertreter aus den ARTs sowie den Value Stream-Rollen
|
||||
- Leitungsboard+: wie oben, zusätzlich mit der PAG und dem Controlling
|
||||
- LK = Netzsprint
|
||||
|
||||
Die im Projekt M31 vorgegebene Methodik sowie die interaktiven Prozesse werden in den gültigen House Rules beschrieben.
|
||||
Darüber hinaus gelten die nach ADITEagil definierten Leitplanken für eine agile Vorgehensweise. Hierzu siehe auch:
|
||||
- http://ciodbn.noncd.rz.db.de/cio/info/Freigegebene Dokumente/ADITE agil/ADITEagil_AgilityGate.pdf
|
||||
- http://ciodbn.noncd.rz.db.de/cio/info/Freigegebene Dokumente/ADITE agil/ADITEagil_Anforderungsmanagement.pdf
|
||||
- http://ciodbn.noncd.rz.db.de/cio/info/Freigegebene Dokumente/ADITE agil/ADITEagil_AgileUmsetzung.pdf
|
||||
- http://ciodbn.noncd.rz.db.de/cio/info/Freigegebene Dokumente/ADITE agil/ADITEagil_AgileProjektleitung.pdf
|
||||
- http://ciodbn.noncd.rz.db.de/cio/info/Freigegebene Dokumente/ADITE agil/ADITEagil_ProductOwner.pdf
|
||||
- http://ciodbn.noncd.rz.db.de/cio/info/Freigegebene Dokumente/ADITE agil/ADITEagil_InterdisziplinäresFachteam.pdf
|
||||
- http://ciodbn.noncd.rz.db.de/cio/info/Freigegebene Dokumente/ADITE agil/ADITEagil_ScrumMaster.pdf
|
||||
- http://ciodbn.noncd.rz.db.de/cio/info/Freigegebene Dokumente/ADITE agil/ADITEagil_ScrumTeam.pdf
|
||||
+17
@@ -0,0 +1,17 @@
|
||||
# 5 Nichtfunktionale Anforderungen an das Bestellsystem
|
||||
|
||||
> Confluence Page ID: 27525997
|
||||
> Version: 31
|
||||
> Pfad: /pathOS/Start / Vorstudie Bestellsystem/00_Vorstudie Bestellsystem/5 Nichtfunktionale Anforderungen an das Bestellsystem
|
||||
> Labels:
|
||||
|
||||
---
|
||||
|
||||
## 5.1 Nichtfunktionale Anforderungen an das Bestellsystem
|
||||
|
||||
Die Nichtfunktionalen Anforderungen werden in einem gesonderten Dokument entsprechend der Konzernrichtlinien dokumentiert. Dieses Dokument ist unter folgendem Link zu erreichen:
|
||||
Nichtfunktionale Anforderungen Bestellsystem
|
||||
## 5.2Â Schutzbedarfsfeststellung und Restrisikodeklaration
|
||||
|
||||
Der Schutzbedarf ist aktuell "hoch". Die Schutzbedarfsfeststellung sowie das Risk Assessment sind im Tool risk2value hinterlegt:
|
||||
Link zu risk2value (Die Schutzbedarfsfeststellung für BS-Z ("Bestellsystem-Zugfahrt") ist initial mit Inhalten befüllt und zur Freigabe zur Verfügung gestellt)
|
||||
+74
@@ -0,0 +1,74 @@
|
||||
# Aufwandsindikation für Vorprojekt Bestellportal
|
||||
|
||||
> Confluence Page ID: 27526003
|
||||
> Version: 10
|
||||
> Pfad: /pathOS/Start / Vorstudie Bestellsystem/Planung Vorprojekt/Aufwandsindikation für Vorprojekt Bestellportal
|
||||
> Labels:
|
||||
|
||||
---
|
||||
|
||||
## Ressourcenplanung für Vorprojekt
|
||||
|
||||
| |
|
||||
Bereich |
|
||||
Rolle |
|
||||
Besetzung Vorprojekt |
|
||||
VzP | Ressource bestätigt durch beistellenden Bereich
|
||||
| |
|
||||
I.NMK 3 |
|
||||
Product Owner |
|
||||
Benjamin Schmücker |
|
||||
0,8 | siehe Gesprächsprotokoll vom 06.11.2018
|
||||
| |
|
||||
I.NMK 3 |
|
||||
Change Manager |
|
||||
N.N. |
|
||||
0,2 |
|
||||
|
||||
| |
|
||||
I.NMF 13 |
|
||||
Process Owner Fahrplan |
|
||||
Marco Krannich |
|
||||
0,2Â | siehe E-Mail von Anatol Scholz am 13.12.2018
|
||||
| |
|
||||
I.NVI 31 |
|
||||
Vorprojektsteuerer |
|
||||
Sebastian Hassemer |
|
||||
0,8 | siehe E-Mail von Klaus-Jürgen Englert am 05.02.2019
|
||||
| |
|
||||
I.NVI 31 |
|
||||
PMO |
|
||||
Alicia Schäfer |
|
||||
0,4 | siehe E-Mail von Klaus-Jürgen Englert am 05.02.2019
|
||||
| | I.NVI 2 | CIO-Architekt | Holger Duis | 0,4 (Zeitraum Jul - Aug 2019)Â | siehe E-Mail von Richard Berger am 20.02.2019
|
||||
| | I.NVI 2 | Business Analyst | Richard Berger | 0,2 | siehe E-Mail von Richard Berger am 20.02.2019
|
||||
|
||||
|
||||
## Kostenindikation für Vorprojekt
|
||||
|
||||
Die benötigten Mittel für das Vorprojekt zur Konzeption eines neuen Bestellportals wurden entsprechend eines Design-to-Budget-Ansatzes abgeschätzt. Ausgehend vom Ziel, das Quality Gate Plan im Oktober 2019 zu durchschreiten, um anschlieÃend im Rahmen des Mittel-Bewilligungsprozesses bis Ende 2019 beim Vorstand die Mittelfreigabe für das spätere Umsetzungsprojekt (ab 01/ 2020) zu erwirken, ergibt sich folgender Mittelbedarf für das Vorprojekt:
|
||||
|
||||
|
||||
Konzeptionsphase: Januar - Oktober 2019
|
||||
|
||||
|
||||
| | benötigte Unterstützungsleistung | benötigter Mittelbedarf
|
||||
| | 2 VZP Unterstützungsleistung Business Analyse | ca. 350 TEUR
|
||||
| | 1 VZP Unterstützungsleistung Technische Architektur | ca. 170 TEUR
|
||||
| | 0,5 VZP Unterstützungsleitung UX-Design (ab 03/ 2019) | ca. 80 TEUR
|
||||
| | Mittelbedarf Vorprojekt gesamt | ca. 600 TEUR
|
||||
|
||||
|
||||
## Kostenindikation für späteres Umsetzungsprojekt
|
||||
|
||||
Im Rahmen einer ersten Kostenindikation durch den Value Stream FIB, zur Abschätzung des Projektumfangs "Neubau Bestellportal & -schnittstelle", wurden ca. 17,5 Mio. Euro geschätzt. Diese Schätzung wurde am 15.09.2016 dem damaligen Lenkungskreis kommuniziert. Ãber den Härtegrad dieser Schätzung lassen sich keine Aussagen treffen, da die zugrunde liegenden Schätzannahmen nicht vorliegen.
|
||||
Es wird davon ausgegangen, dass im Rahmen dieser Schätzung die Funktionalität "Steuerung des Konstruktionsablaufs" (ProduktionsAuftragsSteuerung) berücksichtigt wurde. Diese Funktionalität wurde bei der Festlegung des Scopes vom Vorprojekt Bestellportal herausdefiniert und im Projekt "RuT-K neu" verortet.Â
|
||||
Die Kostenschätzung ist im Rahmen des Vorprojekts zu validieren und zu aktualisieren.
|
||||
|
||||
|
||||
|
||||
|
||||
|
||||
## Kostenindikation für späteres Life-Cycle-Management
|
||||
|
||||
Eine Kostenindikation für das spätere Life-Cycle-Management (u.a. technische Infrastruktur, Lizenzen, fachliche und technische Betriebsführung) ist zum Zeitpunkt vor dem Vorprojekt noch nicht abschätzbar. Diese Kosten sind im Rahmen des Vorprojekts indikativ zu ermitteln.Â
|
||||
@@ -0,0 +1,19 @@
|
||||
# 6 IT Ist-Analyse
|
||||
|
||||
> Confluence Page ID: 27526005
|
||||
> Version: 28
|
||||
> Pfad: /pathOS/Start / Vorstudie Bestellsystem/00_Vorstudie Bestellsystem/6 IT Ist-Analyse
|
||||
> Labels:
|
||||
|
||||
---
|
||||
|
||||
Es wird die Ausgangssituation vor Projektbeginn, bezogen auf die technischen Gegebenheiten, dargestellt, also der aktuelle Zustand der Anwendungssysteme abgebildet.
|
||||
Im Rahmen der Vorstudie im Kapitel 6 werden folgende IT Anwendungen analysiert und eine kurze Erläuterung im Hinblick auf das geplante Vorhaben beschrieben:
|
||||
|
||||
## DB Netz IT Anwendungen Primärverortung - IST Zustand
|
||||
|
||||
Die IT Anwendung Primärverortung wird auf der Seite der IT Architektur in EAM Modell gepflegt und ist Teil des Architekturmanagements der DB Netz AG. Der Aktuelle Zustand der Anwendungssysteme ist hier dargestellt.
|
||||
Â
|
||||
|
||||
|
||||
Â
|
||||
@@ -0,0 +1,16 @@
|
||||
# Planung Vorprojekt
|
||||
|
||||
> Confluence Page ID: 27526007
|
||||
> Version: 4
|
||||
> Pfad: /pathOS/Start / Vorstudie Bestellsystem/Planung Vorprojekt
|
||||
> Labels:
|
||||
|
||||
---
|
||||
|
||||
Für den Zeitraum des Vorprojekt von Januar - Oktober 2019 wurde folgende Zeitplanung aufgestellt:Â
|
||||
|
||||
|
||||
|
||||
|
||||
|
||||
Entsprechend einer Rückwärtsrechnung von der angestrebten Vorstandssitzung zur Einreichung der Beschlussvorlage (BV) und Freigabe der Mittel für die geplante Umsetzungsphase ab 01/ 2020, lässt sich folgende Zeitschiene für die Erstellung der BV und des Quality Gate Plan ableiten:
|
||||
@@ -0,0 +1,392 @@
|
||||
# QG Idee Lieferkriterien
|
||||
|
||||
> Confluence Page ID: 27526012
|
||||
> Version: 33
|
||||
> Pfad: /pathOS/Start / Vorstudie Bestellsystem/QualityGates/QG Idee Lieferkriterien
|
||||
> Labels:
|
||||
|
||||
---
|
||||
|
||||
Stand 26.02.2019
|
||||
|
||||
QG Idee
|
||||
Durchsprache QG Idee wurde am 26.02.2019 erfolgt. Alle Unterschriften zum 28.03.2019 vorliegend.
|
||||
unterzeichnet.
|
||||
|
||||
Die Einschätzung zum Bestehen des QG Idee wird nach folgender Skala vorgenommen:
|
||||
|
||||
|
||||
| | Wert | Erklärung
|
||||
| | 1 - vollständig erfüllt | Das Kriterium ist vollständig erfüllt. Die Inhalte haben einen angemessenen Umfang, sind vollständig dokumentiert, mit allen relevanten Stakeholdern abgestimmt, und erfüllen mögliche Empfehlungen zur Form. Erkenntnisse aus Prüfungen und Abstimmungen wurden eingearbeitet. Alle Dokumente sind in sich und untereinander konsistent.
|
||||
| | 2 - weitgehend erfüllt | Das Kriterium ist weitgehend erfüllt. Die Inhalte sind vorhanden, die wesentlichen Aussagen abgestimmt, es gibt aber kleinere Defizite hinsichtlich Umfang oder Form der Dokumentation. Nacharbeiten sind klar definiert und terminiert. Erkenntnisse aus Prüfungen und Abstimmungen wurden eingearbeitet. Alle Dokumente sind in sich und untereinander konsistent.
|
||||
| | 3 - teilweise erfüllt | Das Kriterium ist teilweise erfüllt. Es gibt Lücken hinsichtlich Inhalten oder Dokumentation, oder noch offene Abstimmungen, oder Erkenntnisse aus Prüfungen und Abstimmungen wurden noch nicht vollständig eingearbeitet, oder es gibt kleinere Inkonsistenzen.
|
||||
| | 4 - ansatzweise erfüllt | Das Kriterium ist nur in Teilen erfüllt. Es gibt erhebliche inhaltliche Lücken oder formale Mängel, noch einzuarbeitende wesentliche Erkenntnisse aus Prüfungen oder Abstimmungen, oder wesentliche Inkonsistenzen.
|
||||
| | 5 - nicht erfüllt | Das Kriterium ist nicht erfüllt.
|
||||
| | X - nicht relevant | Das Kriterium wird als nicht relevant eingeschätzt.
|
||||
|
||||
|
||||
|
|
||||
| |
|
||||
## LO-QK.ID
|
||||
|
|
||||
## Thema
|
||||
|
|
||||
## Link
|
||||
|
|
||||
## Einschätzung I.NVI 1 und FB
|
||||
|
|
||||
## Kommentar
|
||||
|
||||
| |
|
||||
|
|
||||
## Projektziele
|
||||
|
|
||||
|
|
||||
|
||||
|
|
||||
|
||||
| | 2 | Werden die wesentlichen Ziele des angestrebten Projekts bzw. Vorhabens dargestellt, d. h. nachprüfbare Kriterien hinsichtlich Vorgehen und Ergebnis, bei deren Erreichung das Projekt bei Abschluss als erfolgreich betrachtet werden kann? |
|
||||
|
||||
|
|
||||
Green2 |
|
||||
- 190206_RB: Erfüllt. AbschlieÃende Betrachtung der zu integrierenden System im Vorprojekt?
|
||||
- 190206_SH: AbschlieÃende Betrachtung zu QG Planung zu definieren
|
||||
- MMF: "Ziel 3" wäre im Rahmen "Konzeption und Planung" zu präzisieren, da vermutlich erheblicher Aufwandstreiber
|
||||
| | 3 | Werden die wesentlichen Geschäftsziele der DB Netz und des Konzerns benannt, die mit der angestrebten MaÃnahme unterstützt werden? | |
|
||||
Green1 |
|
||||
- MMF: auf der ref. Seite wird keines der Geschäftsziele aus dem Ideenportal-Katalog genannt
|
||||
- 190220_SH: Entsprechend im Kapitel ergänzt
|
||||
| | 4 | Sind die Projektziele lösungsunabhängig, d. h. unabhängig von einer spezifischen technischen Lösung oder einem (SW-) Produkt formuliert? Gibt es mindestens ein fachliches Ergebnisziel? | |
|
||||
Green1 |
|
||||
|
||||
|
||||
| | 238 | Wurde auf bereits erkennbare Zielkonflikte geprüft? | |
|
||||
Green1 |
|
||||
- 190206_RB: Ist eine End2End-Durchgängigkeit im Projekt selbst gegeben?
|
||||
- 190206_SH: wird in u.a. in berücksichtigt
|
||||
- Bisher keine Zielkonflikte identifiziert
|
||||
| | 9 | Wird ein fachliches Problem beschrieben, das durch das Vorhaben gelöst werden soll? | |
|
||||
Green1 |
|
||||
|
||||
|
||||
| | 10 | Wird der Umfang des Vorhabens aus fachlicher Sicht beschrieben? |
|
||||
|
||||
|
|
||||
Green1 |
|
||||
|
||||
|
||||
| | 239 | Erfolgt eine Abgrenzung, was aus fachlicher Sicht bewusst nicht Ziel, nicht Inhalt des Vorhabens ist? | |
|
||||
Green1 |
|
||||
|
||||
|
||||
| |
|
||||
|
|
||||
## Wirtschaftlichkeit
|
||||
|
|
||||
|
|
||||
|
|
||||
|
||||
| | 5 | Wird dargestellt, ob und welche Muss-Kriterien vorliegen? | |
|
||||
Green2 |
|
||||
- 190206_RB: Teilweise erfüllt. Beschlüsse dokumentieren
|
||||
- Beschlussfassung für Kriterium M4 ergänzt
|
||||
- MMF: M4-Begründung entspricht nicht M4-Definition (M4 ist nicht erfüllt)
|
||||
| | 8 | Gibt es eine nachvollziehbare Darlegung der Zwänge? Ist das Kriterium mit Quellen hinterlegt (z. B. Bezeichnung eines Gesetzes inkl. Paragraph)? | |
|
||||
Green1 |
|
||||
|
||||
| | 217 | Wird dargestellt, welche Anteile des Vorhabens zur (minimalen) Erfüllung des Muss-Kriteriums zwingend erforderlich sind? | |
|
||||
Green2 |
|
||||
- Kapitel 1.5 in Verbindung mit Kapitel 1
|
||||
| | 247 | Werden Folgen und konkrete Risiken benannt, die entstehen, wenn das Vorhaben überhaupt nicht durchgeführt wird? | 1.5 'muss'-Eigenschaft und Folgen bei Nicht-Umsetzung |
|
||||
Green1 |
|
||||
|
||||
| | 248 | Werden konkrete Risiken benannt, die entstehen, wenn das Vorhaben nicht zum angestrebten Zeitpunkt durchgeführt bzw. begonnen wird (insb. Verschiebung um 3 oder 12 Monate)? | 1.5 'muss'-Eigenschaft und Folgen bei Nicht-Umsetzung |
|
||||
Green2 |
|
||||
- MMF: wo steht das?
|
||||
- 190220_SH: im Kapitel unter dem Absatz "Folgen bei ausbleibender Umsetzung" - Kapitel überarbeitet
|
||||
- Für Planung: Zeitplan für Umsetzung entsprechend definieren, der keinen Puffer "suggeriert"
|
||||
| | 12 | Wird dargestellt, welcher qualitative Nutzen wird bei Umsetzung des Vorhabens erwartet wird, welche Verbesserungen das Vorhaben bringt und welche Schwachstellen behoben werden? | |
|
||||
Green1 |
|
||||
|
||||
|
||||
| | 16 | Wird dargestellt, wie hoch der quantitative Nutzen ist, wann und bei welchem Fachbereich / welchen Fachbereichen dieser (zeitlich) eintritt? | |
|
||||
Green1 |
|
||||
- 190206_RB: Erfüllt. Opportunitätskosten (der Pönalen) könnten ggf. beziffert werden.
|
||||
- MMF: EBIT-wirksam?
|
||||
- 190220_SH: Ergänzung im Kapitel: Quantitativer Nutzen ist nicht ausweisbar aufgrund verschiedener Gründe, u.a. aufgrund keines erwarteten Gewinns in der Geschäftsbeziehung (EBIT)
|
||||
- Treffen damalige Annahmen noch zu (DAN)?
|
||||
| | 52 | Wird dargelegt, ob die Generierung des im Rahmen der Wirtschaftlichkeitsbetrachtung angenommenen Nutzens von Faktoren abhängig ist, die nicht Bestandteil des Vorhabens bzw. des IT-Projekts sind? |
|
||||
|
||||
|
|
||||
Green1 |
|
||||
- 190206_RB: Teilweise erfüllt. Was ist mit anderen Projekten, wie Steuerung des Konstruktionsablaufs in Rut-K neu? Was ist mit dem Back-End? Ggf. Verknüpfung mit Projektrisiken.
|
||||
- 190220_SH: "Grundsätzlich ist der Nutzen des Projekts von der Umsetzung weiterer Projektvorhaben abhängig, u.a. von solchen, die zum Ziel die Befähigung von TAF/TAP-TSI in der Systemlandschaft der DB Netz AG haben. TAF/TAP-TSI muss sowohl im Konstruktionssystem und in den Veröffentlichungssystemen des Fahrplans, sowie in den Dispositionssystemen des Betriebs mindestens soweit Berücksichtigung finden, dass TAF/TAP-TSI konforme Trassenanmeldungen in den jeweiligen Systemen verarbeitet werden können." => Dies umfasst auch die Steuerung des Konstruktionsablaufs im Rahmen von RuT-K neu.
|
||||
- In QG Planung ggf. detaillieren â Abhängigkeitsmgmt
|
||||
| | 58 | Wird die praktische Realisierbarkeit des Nutzens dargelegt und bewertet? |
|
||||
|
||||
|
||||
|
||||
|
|
||||
Green1 |
|
||||
|
||||
|
||||
|
||||
| | 17 | Wurden Aufwände und Kosten für die Durchführung von Vorprojekt und IT-Projekt abgeschätzt? |
|
||||
|
||||
Verweis auf BV Vorprojekt |
|
||||
Green1 |
|
||||
- 190206_RB: Erfüllt.
|
||||
| | 18 | Sind die erwarteten "kostenlosen" Beistellungen (Räume, Personal, ...) bei Fachbereich und CIO ausgewiesen? |
|
||||
|
|
||||
X |
|
||||
- Trifft nicht zu
|
||||
| | 38 | Wurden Aufwände und Kosten für die spätere Nutzung des Projektergebnisses (technische Infrastruktur, Lizenzen, fachliche und technische Betriebsführung, ...) abgeschätzt? | |
|
||||
Green2 |
|
||||
- 190206_RB: Im Rahmen des Vorprojekts!
|
||||
- Heute nicht abschätzbar
|
||||
| | 59 | Wird erläutert, wie die Aufwandsschätzung zustande kam, und mit welchen Unsicherheiten sie behaftet ist? | |
|
||||
Green2 |
|
||||
- 190206_RB: Teilweise Erfüllt. Schätzannahmen unklar.
|
||||
| | 19 | Gibt es einen (groben) Business Case unter Berücksichtigung von erwartetem Projektaufwand, Lifecycle-Kosten und quantitativem Nutzen? | |
|
||||
X |
|
||||
- 190206_RB: Siehe Kommentar.
|
||||
- Argumentation für Priorisierung â Trifft nicht zu
|
||||
| |
|
||||
|
|
||||
## Anforderungen
|
||||
|
|
||||
|
|
||||
|
|
||||
|
||||
| | 20 | Werden die wesentlichen funktionalen Anforderungen beschrieben (Epic-Level, niedriger Detaillierungsgrad, aber möglichst vollständig)? Erfolgt eine Abgrenzung auf Anforderungsebene, d. h. Funktionalität, auf die ggf. bewusst verzichtet wird? |
|
||||
|
||||
https://fib.jaas.service.deutschebahn.com/browse/VSFIB-268 |
|
||||
Green2 |
|
||||
- 190206_RB: Teilweise Erfüllt. Epic vorhanden.
|
||||
- Detailgrad der Beschreibung der Projektziele entspricht EPIC-Level von FIB
|
||||
| | 22 | Werden die Anforderungen lösungsunabhängig, d. h. unabhängig von einer bestimmten Technologie oder Software beschrieben? | |
|
||||
Green1 |
|
||||
|
||||
|
||||
| | 21 | Werden grobe nicht-funktionale Anforderungen aus fachlicher Sicht beschrieben? Ist eine Abgrenzung erfolgt, d. h. eine Festlegung, auf welche nicht-funktionalen Anforderungen ggf. bewusst verzichtet wird? | Nichtfunktionale Anforderungen Bestellportal |
|
||||
Green2 |
|
||||
- MMF: "Ziel 3" abgrenzen bzw. auf später verweisen
|
||||
| | 86 | Hat der CIO-Bereich den Einreicher auf die Tragweite nicht-funktionale Anforderungen (und insbesondere späterer Ãnderungen an den NfA) hinsichtlich Architektur, Technologie, Aufwände und Kosten hingewiesen? |
|
||||
|
|
||||
Green1 |
|
||||
|
||||
|
||||
| |
|
||||
|
|
||||
## Rahmenbedingungen
|
||||
|
|
||||
|
|
||||
|
|
||||
|
||||
| | 29 | Ist der Besteller / Anforderer des Vorhabens eindeutig bezeichnet (eine OE des Fachbereichs als Hauptansprechpartner)? | |
|
||||
Green1 |
|
||||
|
||||
|
||||
| | 30 | Liegt eine Stakeholderanalyse vor, die nach Wichtigkeit und Umfang des Vorhabens sowie der betroffenen Einheiten und Geschäftsprozesse angemessen ist? | |
|
||||
Green1 |
|
||||
|
||||
|
||||
| | 31 | Liegt eine Liste aller Rollen, Gremien oder Organisationen (Arbeitnehmervertretungen, EBA, BNetzA, Datenschutz, Konzernkommunikation, Digitalisierungsbeauftragter, â¦) vor, die zustimmungspflichtig sind, oder die in anderer Form einbezogen werden müssen (z. B. Informationspflicht)? | |
|
||||
Green1 |
|
||||
|
||||
|
||||
| | 219 | Wurde für alle Rollen, Gremien oder Organisationen, die zustimmungspflichtig sind, oder die in anderer Form einbezogen werden müssen, festgelegt, wer die angemessene und rechtzeitige Einbeziehung sicherstellt? | |
|
||||
Green1 |
|
||||
- 190206_RB: Teilweise erfüllt. Wie und über wen erfolgt die enge Einbeziehung von Rut-K neu? â SAFe
|
||||
| | 220 | Wurden alle Rollen, Gremien oder Organisationen, deren Einbeziehung zu diesem Zeitpunkt sinnvoll, oder (z. B. aufgrund von Richtlinien, Gesetzen, Betriebsvereinbarungen) erforderlich ist, informiert bzw. eingebunden? |
|
||||
|
|
||||
Green1 | Relevante identifiziere Gremien wurden/ bzw. werden eingebunden ( Termin mit Betriebsrat findet am 18.03.19 statt)
|
||||
| | 246 | Wurden die Arbeitnehmervertretungen gemäà gesetzlicher oder tarifvertraglicher Vorgaben bzw. den geltenden Betriebsvereinbarungen (insb. GBV "Digitalisierungsvorhaben") eingebunden? |
|
||||
|
|
||||
Green1 | Termin mit Betriebsrat findet am 18.03.19 statt
|
||||
| | 32 | Wurden die Rahmenbedingungen untersucht, die Auswirkungen auf das Vorhaben haben oder haben könnten (z. B. gesetzliche Vorgaben, vertragliche Verpflichtungen oder Einschränkungen, Bindefristen, zeitlich eingeschränkte Verfügbarkeit von Schlüsselpersonen, Restriktionen zu möglichen Releasezeitpunkten, ...)? |
|
||||
|
||||
|
|
||||
Green2 |
|
||||
- 190206_RB: Kann erst abschlieÃend bewertet werden. Insgesamt ok.
|
||||
| | 33 | Wurden frühere Entscheidungen oder sonstige Vorgaben identifiziert, die Auswirkungen auf das Vorhaben haben oder haben könnten (z. B. Zuordnung zu übergeordneten Vorhaben oder Programmen, "make-buy-reuse", Vorgaben des Vorstands, ...)? Welche? |
|
||||
Verweis auf BV Vorprojekt
|
||||
|
||||
|
||||
|
|
||||
Green1 |
|
||||
|
||||
| | 34 | Werden alle wesentlichen Annahmen, die den Anforderungen, dem erwarteten Nutzen, den erwarteten Kosten, dem Terminplan oder sonstigen inhaltlichen, planerischen oder organisatorischen Aspekten des Vorhabens zugrunde liegen, transparent gemacht? | |
|
||||
Green2 |
|
||||
- 190206_RB: Kann erst abschlieÃend bewertet werden. Insgesamt ok.
|
||||
| | 35 | Sind wesentliche Abhängigkeiten des Vorhabens (auch möglicherweise) von Zulieferungen oder Mitwirkungen anderer (angedachter, geplanter, laufender) Vorhaben (inkl. Anpassungen an Services) identifiziert und die Konsequenzen einer Nicht-Zulieferung bekannt? |
|
||||
|
||||
|
||||
|
|
||||
Green1 |
|
||||
|
||||
|
||||
| | 39 | Sind mögliche andere (angedachte, geplante, laufende) Vorhaben, die von diesem Vorhaben ganz oder teilweise abhängig sind, identifiziert und die Konsequenzen einer Nicht-Zulieferung bekannt? |
|
||||
|
||||
|
||||
|
|
||||
Green1 |
|
||||
|
||||
|
||||
| | 40 | Sind wesentliche erforderliche Beistellleistungen oder Tätigkeiten identifiziert, die von Quellen auÃerhalb des künftigen Projektes zu liefern sind (z. B. Stammdaten, Testfälle, Ãbersetzungen von Schulungsunterlagen, Verbesserung der Datenqualität)? |
|
||||
|
||||
|
|
||||
Green1 |
|
||||
|
||||
|
||||
| | 41 | Sind organisatorische Rahmenbedingungen (z. B. Anpassung von Prozessen, personelle Reorganisation, Aufbau oder Höherqualifizierung von Personal, Anpassung von Richtlinien, ...) identifiziert, von denen die spätere Nutzung bzw. die Generierung des Nutzens abhängen? | |
|
||||
Green2 |
|
||||
- 190206_RB: Erfüllt. Schulungen usw. beim Roll-Out ergänzen
|
||||
- Keine organisatorischen Rahmenbedingungen bisher identifiziert
|
||||
| | 234 | Wurde geprüft und dokumentiert, ob sich das Vorhaben auf einen Prozess bezieht, der personenbezogene Daten verarbeitet (z. B. Disposition von Personaleinsatz), oder ob personenbezogene Daten zur Durchführung des Prozesses (z. B. Liste von Ansprechpartnern) oder im Rahmen einer IT-Lösung (z. B. Benutzerverwaltung) erforderlich sind? | |
|
||||
Green1 |
|
||||
- Zugriff auf zentrale Benutzerverwaltung der DB Netz AG
|
||||
| | 235 | Wurde mit dem Datenschutz eine Vereinbarung über die weitere Einbeziehung getroffen? | Absprechen per E-Mail |
|
||||
Green2 |
|
||||
- 190206_RB: Anfang des Jahres kam wohl jemand neues.
|
||||
- Datenschutzbeauftragter derzeit nicht bekannt, stattdessen interimsweise durch Einbeziehung von I.NVI 1(S) sichergestellt
|
||||
- Mail an Herrn Zundel folgt
|
||||
| |
|
||||
|
|
||||
## Geschäftsprozess
|
||||
|
|
||||
|
|
||||
|
|
||||
|
||||
| | 24 | Wurden die im Wesentlichen von dem Vorhaben betroffenen heutigen Geschäftsprozesse benannt (verbale Beschreibung) und deren Probleme oder Potentiale ermittelt? | |
|
||||
Green1 |
|
||||
|
||||
|
||||
| | 25 | Sind die jeweiligen Process Owner der Geschäftsprozesse, die an dem Prozess beteiligten und somit von dem Vorhaben betroffenen Einheiten sowie die Akteure bekannt? | |
|
||||
Green2 |
|
||||
- 190206_RB: Teilweise erfüllt. Betroffene Prozesse Mappen nicht auf Stakeholder ("wen muss ich ansprechen, wenn ich LN 34-02 anpassen will") â sollte aber in Symbio vermerkt sein?
|
||||
Process Owner über Prozessportal zum jeweiligen betroffenen Geschäftsprozess auslesbar
|
||||
| | 26 | Liegt eine grobe Beschreibung des Ist-Standes der betroffenen Geschäftsprozesse vor? | |
|
||||
Green1 |
|
||||
|
||||
|
||||
| | 27 | Liegt eine grobe Beschreibung des Soll-Standes der betroffenen Geschäftsprozesse vor? |
|
||||
|
||||
|
||||
|
||||
|
||||
|
|
||||
Green1 |
|
||||
|
||||
|
||||
| | 28 | Liegt eine positive Einschätzung aller von den Ãnderungen der Geschäftsprozesse betroffenen Einheiten zur Machbarkeit bzw. Durchsetzbarkeit vor? |
|
||||
|
||||
|
||||
|
||||
|
|
||||
Green1 |
|
||||
- 190206_RB: Teilweise erfüllt. Was ist mit den vermerkten Ãnderungen im Kapitel 3.3. "Trennung Vertrieb und Fahrplan"? Wer gibt die Zustimmung?
|
||||
- 290206_SH: Ãnderungen wirken auf anderer Ebene, keine Ãnderungen an den LN-Prozessen auÃer ggf. Umbenennung.
|
||||
|
||||
|
||||
| |
|
||||
|
|
||||
## Risiken
|
||||
|
|
||||
|
|
||||
|
|
||||
|
||||
| | 15 | Wurden absehbaren Risiken hinsichtlich der Nutzen-Generierung identifiziert, dokumentiert und bewertet? |
|
||||
|
||||
|
|
||||
Green1 |
|
||||
- gemeinsame Durchsprache im Workshop am 12.02.
|
||||
| | 42 | Wurden absehbare (organisatorische, technische, wirtschaftliche) Risiken für oder durch die Durchführung des Vorhabens identifiziert, dokumentiert und bewertet? | |
|
||||
Green1 |
|
||||
- gemeinsame Durchsprache im Workshop am 12.02.
|
||||
| |
|
||||
|
|
||||
## Architektur
|
||||
|
|
||||
|
|
||||
|
|
||||
|
||||
| | 60 | Werden die IT-Architekturprinzipien erfüllt? |
|
||||
|
|
||||
X |
|
||||
- 190206_RB: Siehe Kommentar.
|
||||
Wie lauten die IT-Architekturprinzipien und wer bestätigt, dass diese erfüllt sind? Wie wird dies dokumentiert?
|
||||
Rückmeldung Holger ausstehend (Mail an Holger am 11.02. 10:35 Uhr mit der Bitte um Einschätzung zu diesem Punkt)
|
||||
â Termin Holger KW08
|
||||
â Kriterium kann zum QG-Idee nicht beantwortet werden. Bisher keine Verletzung bekannt. Architekturentscheidung zum CI ist pending.
|
||||
| | 227 | Wurde eine Verortung des Vorhabens im fachlichen Zielbild - sofern vorhanden - vorgenommen und dokumentiert, oder andernfalls als fachliche Schwachstelle im Domänenmodell verortet? | |
|
||||
Green1 |
|
||||
Das neue Bestellportal wurde bereits in IngriT im fachl. Zielbild verortet. Für das APF gibt es bereits eine Vorab-Sollbebauung. Das APF ist bereits Bestandteil der Architektur FIB2.
|
||||
| | 263 | Wurde eine Verortung im Bebauungsplan vorgenommen? | |
|
||||
Green1 |
|
||||
ja, s.o.
|
||||
| |
|
||||
|
|
||||
## Planung
|
||||
|
|
||||
|
|
||||
|
|
||||
|
||||
| | 44 | Sind Eckdaten festgelegt (In welchem Zeitraum (Beginn, Ende) sollen Vorprojekt (Phase "Konzeption und Planung") sowie IT-Projekt (Phase "Umsetzung") liegen? Ab welchem Zeitpunkt soll die produktive Nutzung erfolgen?)? |
|
||||
|
||||
|
|
||||
Green1 |
|
||||
- 190206_RB: Teilweise erfüllt. Vorprojektplanung wäre detaillierter darzustellen.
|
||||
- 190211_SH: Vorprojektplanung ergänzt
|
||||
| | 61 | Liegt eine auf den Eckdaten basierende mögliche Vorhabensplanung (grobe Meilensteine, ...) vor? |
|
||||
|
||||
|
|
||||
Green1 |
|
||||
|
||||
|
||||
| | 62 | Sind die Eckdaten in Hinblick auf Vorlaufzeiten, Releasezyklen und sonstige die Terminkette einschränkenden Faktoren realistisch? |
|
||||
|
||||
|
|
||||
Green1 |
|
||||
- sofern diese als unrealistisch erachtet werden, würden diese als Projektrisiken unter aufgenommen werden
|
||||
| |
|
||||
|
|
||||
## Personalressourcen
|
||||
|
|
||||
|
|
||||
|
|
||||
|
||||
| | 45 | Liegt zumindest für die Phase "Konzeption und Planung" eine grobe Abschätzung der benötigten Personalressourcen des CIO-Bereichs nach Skills vor? Bei Muss-Projekten: Wurden Schlüsselpersonen des CIO-Bereichs namentlich identifiziert? | |
|
||||
Green1 |
|
||||
|
||||
|
||||
| | 46 | Liegen eine quantitative sowie bei Muss-Projekten für Schlüsselpersonen eine personenscharfe Ressourcenzusage des CIO-Bereichs für die Phase "Konzeption und Planung" vor, bzw. sind Verfügbarkeitskonflikte oder Vorbehalte transparent dargestellt? | |
|
||||
Green1 |
|
||||
- 190206_RB: Absprache, was gebraucht.
|
||||
- Mitarbeit R.Berger 0,2
|
||||
- Mitarbeit H.Duis in Phase "Architekturweiche" vrsl. Jul-Aug 0,4 VZP, davor max. 0,2 VZP
|
||||
| | 47 | Liegt zumindest für die Phase "Konzeption und Planung" eine grobe Abschätzung der benötigten Personalressourcen des FB nach Skills vor? Bei Muss-Projekten: Wurden Schlüsselpersonen des FB namentlich identifiziert? | |
|
||||
Green1 |
|
||||
|
||||
|
||||
| | 48 | Liegen eine quantitative sowie bei Muss-Projekten für Schlüsselpersonen eine personenscharfe Ressourcenzusage des FB für die Phase "Konzeption und Planung" vor, bzw. sind Verfügbarkeitskonflikte oder Vorbehalte transparent dargestellt? | |
|
||||
Green1 |
|
||||
|
||||
|
||||
| | 49 | Liegt zumindest für die Phase "Konzeption und Planung" eine grobe Abschätzung der benötigten Personalressourcen des Dienstleisters nach Skills vor? Wurden Schlüsselpersonen des Dienstleisters namentlich identifiziert? | |
|
||||
Green1 |
|
||||
|
||||
|
||||
| | 50 | Liegt für Schlüsselpersonen eine Verfügbarkeitszusage des Dienstleisters für die Phase "Konzeption und Planung" vor, bzw. sind Verfügbarkeitskonflikte oder Vorbehalte transparent dargestellt? | |
|
||||
Green1 |
|
||||
|
||||
|
||||
| |
|
||||
|
|
||||
## Einführungsplan
|
||||
|
|
||||
|
|
||||
|
|
||||
|
||||
| | 51 | Liegt ein Plan vor, der aus fachlicher Sicht grob die Einführung des Projektergebnisses (technische Bereitstellung, Big Bang oder schrittweises Roll-Out, Schulung, Pilotbetrieb, Datenübernahme, produktiver Nutzungsbeginn, Stilllegung oder Weiterbetrieb Alt-System) beschreibt? | |
|
||||
Green2 |
|
||||
@@ -0,0 +1,70 @@
|
||||
# 11 Glossar Vorprojekt
|
||||
|
||||
> Confluence Page ID: 27526014
|
||||
> Version: 22
|
||||
> Pfad: /pathOS/Start / Vorstudie Bestellsystem/00_Vorstudie Bestellsystem/11 Glossar Vorprojekt
|
||||
> Labels:
|
||||
|
||||
---
|
||||
|
||||
| | Abkürzung | Beschreibung |
|
||||
|
||||
| | AC | AbrechnungsCookpit |
|
||||
|
||||
| | CA | Certification Authority: Service zur Ausgabe und Verifikation von digitalen Zertifikaten |
|
||||
|
||||
| | CCS | Common Components System |
|
||||
|
||||
| | CR | CaseReference, siehe Geschäftsfall | Â
|
||||
| | CRD | Central Reference File Database |
|
||||
|
||||
| | CRD | Common Repository Domain: Europa-weite Metadaten, die im Central Reference Files Database des RNE verwaltet werden. Der letztere wird häufig ebenfalls als CRD bezeichnet. |
|
||||
|
||||
| | CRID | CaseReferenceIdentifier | Â
|
||||
| | CI | Common Interface: Spezifikation einer gemeinsamen Schnittstelle für den Austausch von TSI Nachrichten |
|
||||
|
||||
| | EAM | Enterprise Architecture Management |
|
||||
|
||||
| | Â EIU | Eisenbahninfrastrukturbetriebe | Â
|
||||
| | Â EVU | Eisenbahnverkehrsunternehmen | Â
|
||||
| | Fahrlage | Eine Fahrlage ist einem Zug zugeordnet und beschreibt den vom EVU gewünschten Laufweg des Zuges durch Angabe der Abfolge von Zuglaufpunkten, der technischen Konfiguration des Zuges (Zugcharakteristik), der Verkehrstage, der Verkehrshalte, geplanter Ankunfts- und/oder Abfahrtszeiten, Halthinweisen, Anschlussbeziehungen etc. | Â
|
||||
| | Geschäftsvorfall | Aktion zur Initiierung bzw. Ausführung eines konkreten, in sich abgeschlossenen Prozess-schrittes innerhalb des Bestell- und Bearbeitungsprozesses für Trassen, RV-Kapazitäten, Fahrplan- und Betriebsprogrammstudien sowie Fahrzeitberechnungen. | Â
|
||||
| | GFD-IÂ | GemeinsameFahrplanDatenhaltung-Infrastruktur |
|
||||
|
||||
| | Â LI | Local Instance: eine konkrete Installation des RNE CI | Â
|
||||
| | MVP | Minimal Viable Product |
|
||||
|
||||
| | NSP | national Spezific Parameter  | Â
|
||||
| | PA (Path) | Siehe Zugtrassenvariante | Â
|
||||
| | PAID | PathIdentifier | Â
|
||||
| | PR | PathRequest | Â
|
||||
| | PTID | PlannedTrasportIdentifier | Â
|
||||
| | RPTID | RelatedPlannedTransportIdentifier, die Identifikatoren TrainID, PathRequestID, PathID, CaseReferenceID könen als RPTID verwendet werden. |
|
||||
|
||||
| | RNE | RailNetEurope | Â
|
||||
| | SGV |  Schienengüterverkehr | Â
|
||||
| | SPNV | Schienenpersonennahverkehr |
|
||||
|
||||
| | SPFV | Schienepersonenfernverkehr |
|
||||
|
||||
| | TAF/TAP - TSI | Â Telematics Applikation for Freight/ Telematics Applications for Passanger Service - Technical Specification for Interoperability | Â
|
||||
| | TOI | TypOfInformation |
|
||||
|
||||
| | TOR | TypOfRequest |
|
||||
|
||||
| | TPS | Trassenpreissystem |
|
||||
|
||||
| | TR | Train |
|
||||
|
||||
| | TSI | Technical Specification for Interoperability |
|
||||
|
||||
| | UIC |
|
||||
Common Component: Synonym für RNE CI |
|
||||
|
||||
| | ZCH | Zugcharakteristik -
|
||||
Beschreibt die technische Konfiguration eines Zuges ab dem Zuglaufpunkt, zu welchem die Zugcharakteristik angegeben ist. Sie enthält Angaben zur Bespannung (Baureihe der Trieb-fahrzeuge und deren Stellung), zu Gewicht und Länge, zu Zugsicherungs- und steuerungsein-richtungen (z. B: ETCS, EBuLa, Neigetechnik u. a.), zur Bremsausrüstung, zur gewünschten Streckenklasse, zu Ladegut, Profilen etc. |
|
||||
|
||||
| | ZUG | Der Zug dient der Erbringung einer Verkehrsdienstleistung des Eisenbahnverkehrsunternehmens gegenüber (kommerziellen) Endkunden und stellt ein in der Zuständigkeit des Eisen-bahnverkehrsunternehmens liegendes Planungsobjekt mit einer oder mehreren zugeordneten Fahrlagen dar. Der Zug wird durch eine eindeutige TrainID identifiziert. |
|
||||
|
||||
| | Zugtrasse |  Ist die Gesamtheit aller einem Zug zugeordneten Zugtrassenvarianten. An einem Verkehrstag des Zuges kann nur eine Zugtrassenvariante gültig sein. D. h. die Verkehrstage aller aktiven Zugtrassenvarianten müssen disjunkt sein. | Â
|
||||
| | Zugtrassenvariante | Ist die im Ergebnis des Konstruktionsprozesses zugewiesene Trasse für eine konkrete Fahrlage eines Zuges. Aus konstruktiven Gründen können einer Fahrlage mehrere Zugtrassenvarianten (Path)zugewiesen werden, deren Verkehrstage disjunkt sind |
|
||||
+18
@@ -0,0 +1,18 @@
|
||||
# 7.1 make-, buy, re-use-Entscheidungen
|
||||
|
||||
> Confluence Page ID: 27526015
|
||||
> Version: 41
|
||||
> Pfad: /pathOS/Start / Vorstudie Bestellsystem/00_Vorstudie Bestellsystem/7 Umsetzungsalternativen und Bewertung/7.1 make-, buy, re-use-Entscheidungen
|
||||
> Labels:
|
||||
|
||||
---
|
||||
|
||||
2true
|
||||
Im folgenden Unterkapitel werden die Ergebnisse des Projektes APluS verarbeitet, die gegen eine vollständige Kauflösung für das Bestellsystem sprechen.
|
||||
Im weiteren Unterkapitel wird dargestellt, warum eine vollständige Wiederverwendung eines Altsystems (TPN) nicht möglich ist.
|
||||
AnschlieÃend werden in eigenen Unterkapiteln die möglichen Kauf-, Wiederverwendungs- und Neuentwickungs-Lösungen für einzelne Funktionalitäten der Trassenbestellungen dargestellt. Die Funktionalitäten sind dabei wie folgt gegliedert:
|
||||
- Kernfunktionen für die Trassenbestellungen im Vertrieb
|
||||
- Konstruktion (hier geht es um die Anbindung geeigneter Umsysteme)
|
||||
- Abrechnungsfunktionalitäten
|
||||
- Sonstige unterstützende Funktionen
|
||||
Â
|
||||
+35
@@ -0,0 +1,35 @@
|
||||
# 2019-01-16 Besprechungsnotizen
|
||||
|
||||
> Confluence Page ID: 27526017
|
||||
> Version: 2
|
||||
> Pfad: /pathOS/Start / Vorstudie Bestellsystem/00_Vorstudie Bestellsystem/14 Besprechungsnotizen Vorstudie/2019-01-16 Besprechungsnotizen
|
||||
> Labels: meeting-notes
|
||||
|
||||
---
|
||||
|
||||
## Datum
|
||||
|
||||
|
||||
## Teilnehmer
|
||||
|
||||
-
|
||||
|
||||
-
|
||||
|
||||
-
|
||||
-
|
||||
## Ziele
|
||||
|
||||
-
|
||||
- Terminabsprache für QG Idee/QG Planung/QG Board mit Markus Middendorf abstimmen â Durchsprache QG Idee Ende Februar 2019 / Terminblocker QG Board 21.10.2019
|
||||
- Prüfung der doppelten Struktur in Confluence â Alte Struktur entfernen, Templates für QG Planung einfügen
|
||||
- Absprache mit Architekten bez. "Multikanalarchitektur", Nutzung des EAM und Lieferobjekte von den Architekten bez. QG Idee (ggf. hierzu Einzeltermin mit Holger Duis)â Besprechung auf Workshop in KW04
|
||||
- Weiteres Vorgehen: Â
|
||||
- Sobald Draft der Dokumentation bzw. einzelne Kapitel fertig sind erfolgt Review durch Richard Berger mit Ersteinschätzung der Lieferkriterien, anschlieÃend Durchsicht durch Markus Middendorf. Wird im dokumentiert.
|
||||
- Einladung Richard Berger auf Regeltermine, bei Bedarf weitere Abstimmung in Einzelterminen. Inhaltliche Zuarbeit durch I.NVI2 aktuell nicht notwendig. Aktuell keine methodische Unterstützung notwendig (Projektteam hat alles im Griff), ggf. konsolidierende Workshops in Phase Konzeption und Planung.
|
||||
## Handlungspunkte
|
||||
|
||||
|
||||
1
|
||||
complete
|
||||
Terminabsprache mit Markus Middendorf bez. QG Idee und QG Board
|
||||
+10
@@ -0,0 +1,10 @@
|
||||
# 7 Umsetzungsalternativen und Bewertung
|
||||
|
||||
> Confluence Page ID: 27526020
|
||||
> Version: 9
|
||||
> Pfad: /pathOS/Start / Vorstudie Bestellsystem/00_Vorstudie Bestellsystem/7 Umsetzungsalternativen und Bewertung
|
||||
> Labels:
|
||||
|
||||
---
|
||||
|
||||
|
||||
+10
@@ -0,0 +1,10 @@
|
||||
# 8 Rollout und Change Management
|
||||
|
||||
> Confluence Page ID: 27526024
|
||||
> Version: 2
|
||||
> Pfad: /pathOS/Start / Vorstudie Bestellsystem/00_Vorstudie Bestellsystem/8 Rollout und Change Management
|
||||
> Labels:
|
||||
|
||||
---
|
||||
|
||||
|
||||
+41
@@ -0,0 +1,41 @@
|
||||
# 7.2 Bewertung der Umsetzungsalternativen und Empfehlung
|
||||
|
||||
> Confluence Page ID: 27526027
|
||||
> Version: 29
|
||||
> Pfad: /pathOS/Start / Vorstudie Bestellsystem/00_Vorstudie Bestellsystem/7 Umsetzungsalternativen und Bewertung/7.2 Bewertung der Umsetzungsalternativen und Empfehlung
|
||||
> Labels:
|
||||
|
||||
---
|
||||
|
||||
Auf die Entscheidung für eine Individualentwicklung des Bestellsystems wurde bereits in Kapitel  verwiesen bzw. diese erläutert.Â
|
||||
In Kapitel werden die Umsetzungsalternativen für die einzelnen Komponenten beschrieben. Viele Entscheidungen sind durch die Rahmenbedingungen des Projekts vorgegeben. Die verbliebenen Entscheidungen mit den hinreichenden Freiheitsgraden bzw. kritischen Pfaden sind:
|
||||
- Bestellschnittstelle: Kaufprodukt RNE Common Interface vs. Eigenentwicklung
|
||||
201903_Architekturentscheidung-RNE CI.xlsx
|
||||
- Empfehlung: Option Eigenentwicklung, aufgrund der Risiken und Limitierungen des RNE Common Interface.
|
||||
|
||||
|
||||
- Anmelde-UI: Wiederverwendung Click-and-Ride vs. EigenentwicklungÂ
|
||||
201906_Architekturentscheidung-Anmelde-UI.xlsx
|
||||
- Empfehlung: Aus Architektur-Sicht ist die Option Eigenentwicklung zu bevorzugen, allerdings ist aufgrund des erwarteten Auslaufs von C&R kurz nach der Produktivsetzung des Bestellsystems eine Wiederverwendung sinnvoll und wird empfohlen.
|
||||
|
||||
|
||||
- Planung-UI: Wiederverwendung Trassenfinder vs. Eigenentwicklung
|
||||
- siehe Kapitel 6.3
|
||||
|
||||
|
||||
-
|
||||
Prozesssteuerung Vertrieb: Wiederverwendung neXt KAM vs. Eigenentwicklung
|
||||
-
|
||||
Eine sinnvolle Bewertung ist erst nach der geplanten Migration der neXt KAM von EIP auf Camunda, sowie Aufsplittung in Fahrplan- und Vertieb-Prozesse abzuwarten (vsl. geplant bis Ende 2019). Dann ist eine Wiederverwendung (ggf. mit Migration auf BusinessHub) näher zu untersuchen.
|
||||
|
||||
|
||||
- Konstruktion-Steuerung: Wiederverwendung bisherige Kette TPN/GFD-Z/RUT-K vs. Direkt-Anbindung BaDiFa Projekt
|
||||
201906_Architekturentscheidung-Konstruktion.xlsx
|
||||
- Empfehlung: Option Direktanbindung BaDiFa, vorausgesetzt eine frühzeitige Bereitstellung der neuen Schnittstellen (siehe ).
|
||||
|
||||
|
||||
- Benutzerverwaltung: Wiederverwendung eBRS vs. EigenentwicklungÂ
|
||||
201906_Architekturentscheidung-Benutzerverwaltung.xlsx
|
||||
- Empfehlung: Option Wiederverwendung eBRS. Als übergreifende Funktionalität sollte die Benutzerverwaltung nicht Bestellsystem-spezifisch sein. Aufgrund von mangelnden Funktionen (2-Faktor-Authentifizierung, Verfahrensnutzer-Verwaltung) und nicht-funktionalen Einschränkungen (kein SL1 für Teilsysteme) ist zumindest für Teilfunktionen eine Eigenentwicklung notwendig.Â
|
||||
Des Weiteren wurden in Kapitel die Optionen für die PaaS bzw. IaaS vorgestellt. Die Bewertung dieser Optionen ist in 201906_Architekturentscheidung-Plattform.xlsx zu finden.
|
||||
- Empfehlung: Aus Effizienz-Gründen wird die Option 2 - Business-Hub Plattform verfolgt. Dies gilt vor allem für die Komponente Service Factory wegen der vorgefertigten CI/CD Pipeline und Umgebungsdefinitionen.
|
||||
+40
@@ -0,0 +1,40 @@
|
||||
# 4.5 Von der Vision zum Minimal Viable Product
|
||||
|
||||
> Confluence Page ID: 27526031
|
||||
> Version: 41
|
||||
> Pfad: /pathOS/Start / Vorstudie Bestellsystem/00_Vorstudie Bestellsystem/4 Anforderungen an das neue Bestellsystem der DB Netz/4.5 Von der Vision zum Minimal Viable Product
|
||||
> Labels:
|
||||
|
||||
---
|
||||
|
||||
## Produktstrategie I.NMK für Trassenprodukte und trassennahe Produkte
|
||||
|
||||
Produktseitig wird sich durch Einführung des neuen Bestellsystems grundsätzlich nichts ändern. Das wesentliche Produkt bleibt die Trasse in ihren verschiedenen Produktausprägungen, die dem Kunden die Zugfahrt ermöglicht. Die Produktsegmente wurden mit der Reform des Trassenpreissystems 2018 zuletzt grundlegend definiert. Im fünf-Jahres-Turnus ist die Produktsegmentierung zusammen mit Kunden und Regulierern neu zu bewerten und gegebenenfalls anzupassen. Am Kernprodukt Trasse in der AbrechnungsgröÃe Trassenkilometer sind aber keine Ãnderungen geplant.
|
||||
Mittel- bis langfristig sollen Bündelprodukte dabei helfen, nach auÃen hin den Anmeldungsprozess für den Kunden zu vereinfachen. Bündelprodukt heiÃt, dass Trassen, Anlagen und Serviceeinrichtungen im selben Vorgang durch das EVU angemeldet werden können. So hat der Kunde einen echten One-Stop-Shop und es entsteht der Eindruck, nur ein Produkt "Zugfahrt" zu bestellen. Faktisch soll aber die Komponente "SteuerungVertriebsablauf" in diesem Fall das Splitting in die dahinterliegenden Einzelprodukte übernehmen und die einzelnen Angebote der Anbieter I.NMF, I.NMK und DB Station&Service zu einem Gesamtangebot zusammenzufassen. Die Produkte der anbietenden DB Netz Einheiten Fahrplan und Vertrieb sowie von DB Station&Service bleiben aber eigenständig.
|
||||
## Von der Vision zum Minimal Viable Product
|
||||
|
||||
Das Bestellsystem wird vor allem im Bereich der Komponente Bestellportal deutlich über den Umfang des Projekts hinaus designed. Hintergrund dieses Vorgehens ist, dass ein anpassbares, zukunftssicheres System nur dann bewusst geschaffen werden kann, wenn bereits in der Konzeption des Produktinkrements, welches zuerst produktiv geht, die Erweiterbarkeit um ganze Module und die Verbesserungsfähigkeit einzelner Funktionen vorgedacht wurde.Â
|
||||
Die in dieser Vorstudie gezeigten Wireframe-Darstellungen des neuen Bestellportals bebildern neben Funktionen, die im initialen Projektumfang enthalten sein werden, auch Funktionalitäten, die letztlich nicht im Minimal Viable Product (MVP) abbildbar sein werden. Das MVP beschreibt den Funktionsumfang, der in jedem Fall gewährleistet sein muss, um mit dem neuen Bestellsystem produktiv gehen zu können. Methodisch wird das MVP aus der Vision abgeleitet, nicht umgekehrt.Â
|
||||
Funktionen des MVP müssen sein:
|
||||
- Prozessuale Abbildung aller Trassenanmeldungsgeschäftsvorfälle, insbesondere
|
||||
- Netzfahrplananmeldungen
|
||||
- Gelegenheitsverkehrsanmeldungen
|
||||
- Ãnderungsbestellungen zu bestehenden Trassenverträgen, also:
|
||||
- Stornierung einzelner Verkehrstage (bislang: Auslegung)
|
||||
- Ãnderung von Fahrtattributen an einzelnen oder mehreren Verkehrstagen des Trassenvertrags
|
||||
- Hinzunehmen einzelner Verkehrstage innerhalb des Verkehrszeitraums eines Train (Nicht: Erweiterung des Verkehrszeitraums)
|
||||
- Stornierung von TrassenverträgenÂ
|
||||
- Fachliche Abbildung aller für die Abwicklung der Trassenanmeldung erforderlichen Anmeldeattribute
|
||||
- Aufbau einer TAF/TAP-TSI Bestellschnittstelle gemäà den Mindestanforderungen der RNE und der DB Netz AG.
|
||||
- Aufbau eines Bestellportals zur Trassenanmeldung für Kunden, die nicht über die Bestellschnittstelle anmelden wollen oder können.
|
||||
- Leitmotiv im Aufbau des Bestellportals ist auch unter MVP: Schaffung eines kundenfreundlichen Bestellportals, das den Kunden in seinen Geschäftsprozessen (Vor allem Planung, Anmeldung und Verwaltung seiner Zugfahrten) unterstützt und die TAF/TAP-konforme Trassenanmeldung bei der DB Netz AG sicherstellt.
|
||||
Das MVP umfasst damit grundsätzlich alle Funktionalitäten, die unmittelbar dafür erforderlich sind, den Vermarktungsprozess von Trassen in der AbrechnungsgröÃe Trassenkilometer abzubilden.
|
||||
Fachliche Anwendungsfälle die im Bestandsystem aus TPN und RuT-K integriert, bzw. teilintegriert sind und nicht im MVP verortet sind, sind damit bewusst:
|
||||
- Anmeldungen von Fahrplanstudien und Betriebsprogrammstudien:
|
||||
Die Anmeldung von Studien wird grundsätzlich durch TAF/TAP unterstützt. MutmaÃlich ist die Integration in die neue Systemwelt des Bestell- und Konstruktionssystems einfach integrierbar. Zur Sicherung der Durchführung des Bahnbetriebs im Fahrplanjahr 2024 sind Studien aber nicht essentiell, weswegen die Studienfähigkeit nach Produktivsetzung der Trassenanmeldungen, voraussichtlich bis Beginn des Fplj. 2024, integriert werden soll.
|
||||
- Unterstützung der Fahrlagenberatung durch die neue Systemwelt:
|
||||
Die Fahrlagenberatung mit voll integrierter Systemunterstützung ist ein wichtiges Ziel, da die Fahrlagenberatung einen wesentlichen Beitrag in der Vorbereitung der Netzfahrplanerstellung liefert. Die Arbeitshypothese ist aber, dass für das Fahrplanjahr 2024 die Fahrlagenberatung noch in den Altsystemen stattfinden kann. Die Fahrlagenberatung bereits für das Fahrplanjahr 2024 anzubieten wird aus zwei zentralen Gründen nicht avisiert:
|
||||
- Die für die Systementwicklung zur Verfügung stehende Zeit würde dadurch um ca. neun Monate verringert.
|
||||
- Der TAF/TAP-Prozess sieht vor, dass Train-Objekte durch Kunden angelegt werden. Für kommende Fahrplanjahre vorkonstruierte Trassen brauchen aber ein Bezugsobjekt Zug, um zugeordnet werden zu können. Hier ist zunächst grundsätzlich prozessual zu klären, wie dieser zentrale prozessuale Bruch umgangen werden kann und in IT-Systemen abbildbar wird.
|
||||
Das MVP umfasst grundsätzlich auch nicht die Vermarktung von Nebenleistungen. Diese werden heute in einem TPN-fernen Verfahren oder Prozess vermarktet, der zunächst bestehen bleiben wird. Für die Zeit nach Produktivsetzung des Bestellportals wird aber dringend empfohlen, sämtliche Produkte im Bestellportal zu bündeln. Das modulare Design des Bestellportals erlaubt eine spätere Integration ergänzender Produkte in jedem Fall.Â
|
||||
Die umzusetzenden Features des MVP Bestellsystem sind in der M31 JIRA-Instanz angelegt und beschrieben. Die Features ordnen sich dabei den beiden Epics "Kundenorientiertes TAF/TAP-TSI Bestellportal" (Link auf Epic) und "TAF/TAP-TSI Bestellschnittstelle" (Link auf Epic) und einer Vielzahl von Capabilities und Enablern unter. Die zugrunde gelegte Logik ist dabei, dass Capabilities und deren Features eine Funktion aus Kundensicht und den erzeugten Kundennutzen beschreiben. Enabler und deren Features beschreiben Funktionen, die zum Erstellen von Funktionen mit Kundennutzen ausgebaut werden müssen, ohne selbst unmittelbar Kundennutzen zu erzeugen.Â
|
||||
+45
@@ -0,0 +1,45 @@
|
||||
# 4.1 Funktionale Architektur des neuen Bestellsystems
|
||||
|
||||
> Confluence Page ID: 27526040
|
||||
> Version: 85
|
||||
> Pfad: /pathOS/Start / Vorstudie Bestellsystem/00_Vorstudie Bestellsystem/4 Anforderungen an das neue Bestellsystem der DB Netz/4.1 Funktionale Architektur des neuen Bestellsystems
|
||||
> Labels:
|
||||
|
||||
---
|
||||
|
||||
## 4.1.1 Funktionale Komponenten - Soll
|
||||
|
||||
Das neue Bestellsystem soll es dem Kunden ermöglichen, unterschiedliche Kanäle (Web, Mobile, API) für seine Bestellvorgänge zu nutzen. Gleichzeitig wird das neue System vorbereitet, Bündelprodukte, also neben Trassenprodukten auch andere rund um die Zugfahrt anfallende Services, in einem System bestellen zu können. Das MVP wird allerdings zunächst nur Trassenprodukte unterstützen. Eine weitere wichtige Erweiterung zum Status Quo ist die Integration einer Planungskomponente für den Kunden in das Bestellsystem, also verschiedene Funktionen (z.B. Routenvorschläge, Preisinformationen, etc.. ) welche im Vorfeld einer Anmeldung erfolgen.
|
||||
In der folgenden Graphik sind die groben funktionalen Komponenten des neu zu schaffenden Bestellsystems (MVP) dargestellt und ihr Zusammenwirken in vereinfachter Form abgebildet.Â
|
||||
|
||||
Link Funktionale Architektur (MVP) im EAM
|
||||
## 4.1.2 Systemkontext Bestellportal - SOLLÂ
|
||||
|
||||
Die in der Abbildung der funktionalen Komponenten dargestellten extern genutzten Fachfunktionen implizieren notwendige Schnittstellen zu (internen) Drittsystemen. Es werden Drittsysteme aus den Subdomänen Vertrieb, Fahrplan sowie Infrastrukturdaten und Common Services genutzt. Dieser Zusammenhang wird im folgenden Systemkontext näher beleuchtet.
|
||||
Link EAM Modell Systemkontext Bestellsystem oderÂ
|
||||
## 4.1.3 Akteure Bestellportal -SOLLÂ
|
||||
|
||||
Im Bestellportal werden interne und externe Benutzer unterschieden:
|
||||
## Interne Benutzer
|
||||
|
||||
Mitarbeiter der DB Netz, die in den fachlichen Prozess der Anmeldung von Produkten rund um eine Zugfahrt involviert sind, nämlich:
|
||||
- Kundenbetreuer (lesender und schreibender Zugriff)
|
||||
- können mehreren Kundennummer zugeordnet sein
|
||||
- dürfen existierende Daten nur für die Kunden sehen und verändern, deren Kundennummern ihnen selbst zugeordnet sind
|
||||
- dürfen neue Aufträge nur für solche Kunden erstellen, für deren Kundennummern sie selbst zugeordnet sind
|
||||
- die Zuordnung erfolgt durch EVU-Sachbearbeiter Poweruser im eBRS-AD
|
||||
|
||||
|
||||
Ãber iMan/BKU werden folgende Rollen zu beantragen sein:
|
||||
- Fachliche Betriebsführung (FBF) (Konfiguration und lesender Zugriff)
|
||||
- Technische Betriebsführung (TBF)Â
|
||||
## Externe Benutzer
|
||||
|
||||
Bei den externen Benutzern handelt es sich um Mitarbeiter der EVU-Kunden, die einen Auftrag an die DB Netz übergeben. Es ist bzgl. der externen Benutzer zu erwähnen, dass keine Unterscheidung gemacht wird, ob es sich um Mitarbeiter konzernexterner oder konzerninterner EVU-Kunden handelt. Aus Gründen der Diskriminierungsfreiheit werden alle Mitarbeiter von Kunden als externe Benutzer geführt und IT-technisch gleich behandelt.
|
||||
Externen Benutzer des Bestellportals können im eBRS-AD folgende Rollen zugewiesen werden:
|
||||
- EVU-Sachbearbeiter Standarduser: Ihm können mehrere Kundennummern zugewiesen werden, hierbei lesender und schreibender Zugriff.
|
||||
- EVU-Sachbearbeiter Poweruser: Erbt von der Standardrolle, hat aber erweiterte Rechte, insbesondere für die Verwaltung von Benutzern eines Kunden
|
||||
- Aufgabenträger: Rolle, die nur einen lesenden Zugriff auf die berechtigten Kundennummern hat
|
||||
|
||||
|
||||
Wichtige Ãnderung zum Status Quo: Der Konstrukteur oder Koordinator erhält zukünftig keinen direkten Zugriff auf das neue Bestellsystem.
|
||||
+106
@@ -0,0 +1,106 @@
|
||||
# 2019-01-22 Erstabstimmung Vorprojekt Bestellportal & RuT-K neu
|
||||
|
||||
> Confluence Page ID: 27526041
|
||||
> Version: 2
|
||||
> Pfad: /pathOS/Start / Vorstudie Bestellsystem/00_Vorstudie Bestellsystem/14 Besprechungsnotizen Vorstudie/2019-01-22 Erstabstimmung Vorprojekt Bestellportal & RuT-K neu
|
||||
> Labels:
|
||||
|
||||
---
|
||||
|
||||
Von: Joachim Geidel -Extern
|
||||
Gesendet: Mittwoch, 23. Januar 2019 11:32
|
||||
An: Sebastian Hassemer <Sebastian.Hassemer@deutschebahn.com>
|
||||
Cc: Frank F Ludwig <Frank.F.Ludwig@deutschebahn.com>; Michael Theuerkauf <Michael.Theuerkauf@deutschebahn.com>; Nils Block <Nils.Block@deutschebahn.com>; Sascha Dördelmann <Sascha.Doerdelmann@deutschebahn.com>; Konstantin Pussep <Konstantin.Pussep@deutschebahn.com>; Benjamin Schmücker <benjamin.schmuecker@deutschebahn.com>; Marcel Hufgard <Marcel.Hufgard@deutschebahn.com>; Ana Cvitkovic <Ana.Cvitkovic@deutschebahn.com>; Martin M Schmitt <Martin.M.Schmitt@deutschebahn.com>; Alicia Schäfer <Alicia.Schaefer@deutschebahn.com>; Holger Duis <Holger.Duis@deutschebahn.com>; Daniel Görich <Daniel.Goerich@deutschebahn.com>
|
||||
Betreff: AW: Ergebnis: Erstabstimmung Vorprojekt Bestellportal & RuT-K neu
|
||||
Â
|
||||
Hallo Sebastian,
|
||||
Â
|
||||
Deine Zusammenfassung ist aus meiner Sicht ok, bis ein paar Kleinigkeiten.
|
||||
Â
|
||||
> die ProduktionsAuftragsSteuerung (Synonym: KonstruktionsablaufSteuerung / Steuerung der Konstruktion)
|
||||
Der korrekte Name dafür ist âSteuerung Konstruktionsablaufâ, unter diesem Namen ist die Fachkomponente seit langer Zeit im Sollbebauungsplan in der Domäne âZentrale Analyse, Konstruktion und Simulationâ eingeplant:
|
||||
Â
|
||||
|
||||
|
||||
Â
|
||||
> Die Bereitstellung von Informationen für die Và (Schnittstelle zu VÃ) liegt im Scope des Vorprojekts RuT-K neu.
|
||||
Das stimmt so nicht ganz. Ich hatte erwähnt, dass für die Ãbergabe von Bautrassen an GFD-Z eine neue Eingangsschnittstelle bei GFD-Z entstanden ist, über die Nachrichten inkl. zugehöriger Trassen an GFD-Z übergeben werden können, und dass diese Schnittstelle als Vorstufe für einen âVeröffentlichungsadapterâ im Sinne der IngriT-Konzepte dienen kann. In den Prozessmodellen, die bei IngriT erstellt wurden, gibt es Ereignisse in den Prozessen, bei denen etwas veröffentlicht werden muss. Je nach Auslöser kann das heiÃen, dass ein Auftrag an das Veröffentlichungssystem vom Bestellportal oder aus der Trassenkonstruktion kommen kann. Daten zu Trassen werden grundsätzlich über Services bereitgestellt, die zum Kapazitäts- und Fahrplanmanagement gehören â also Scope von RUT-K neu. Wenn ein System des Vertriebs einen Auftrag zur Veröffentlichung von Dokumenten erteilt, kann entweder das Veröffentlichungssystem sich die nötigen Daten abholen, oder das Vertriebssystem holt die nötigen Daten und übergibt sie an das Veröffentlichungssystem. Wie das gestaltet wird, muss noch geklärt werden â aber nur, falls das Bestellportal tatsächlich selbst Aufträge zur Veröffentlichung erteilt. Ob das der Fall ist, weià ich nicht mehr auswendig.
|
||||
Â
|
||||
> Fristenberechnung
|
||||
Meine These war, dass die Berechnung von Fristen keine zentrale Komponente sein muss, da es einerseits Fristen und Termine für Prozesse des Vertriebs gibt, die fachlich zur Domäne Vertrieb und dort zur Steuerung des Vertriebsablaufs gehören, andererseits Fristen und Termine in der Trassenkonstruktion, die zur Steuerung des Konstruktionsablaufs und zur Domäne âZentrale Analyse, Konstruktion und Simulationâ gehören. Da der Systemschnitt sich normalerweise an Domänengrenzen orientieren sollte, sehe ich die jeweiligen Fristenrechnungen eher als kleine Teilkomponenten der jeweiligen Ablaufsteuerungen.
|
||||
Â
|
||||
> Zugnummernverwaltung
|
||||
Ja, das ist noch abzustimmen, aber nicht nur bilateral, sondern auch mit der Architektur/dem CIO-Bereich. Da es sich um âoperational train numbersâ handelt, geht es Richtung Fahrplan, der ja auch für nicht vom Kunden bestellte Trassen betriebliche Zugnummern vergeben muss (z.B. netzinterne Fahrten, stark verspätete Züge alias â20-Stunden-Zügeâ usw.). Wir hatten auch schon festgestellt, dass es Sonderfälle gibt, in denen für eine Trasse mehr als eine Zugnummer vergeben wird, u.a. nach dem Kopfmachen bei Mehrfach-Durchfahrung eines wärterbesetzten Bahnübergangs. Meine Sicht auf Zugnummernkontingente ist, dass der Vertrieb diese beim Fahrplan anfordert, um sie bestimmten Kunden zur Verfügung zu stellen.
|
||||
Â
|
||||
Mit freundlichen GrüÃen
|
||||
Joachim Geidel
|
||||
Â
|
||||
Senior Consultant
|
||||
(externe Fachkraft)
|
||||
Sopra Steria SE
|
||||
Mainzer LandstraÃe 209
|
||||
60326 Frankfurt am Main
|
||||
|
||||
im Auftrag der DB Systel GmbH
|
||||
Â
|
||||
Projekterreichbarkeit:
|
||||
Mainzer Landstr. 185, 60327 Frankfurt am Main
|
||||
Tel. +49 (0)69-265-48153, intern 955-48153
|
||||
_________________________________________________________
|
||||
Â
|
||||
--- Bitte denken Sie an die Umwelt, bevor Sie diese E-Mail ausdrucken. ---
|
||||
Â
|
||||
Sitz der Gesellschaft: Frankfurt am Main
|
||||
Registergericht: Frankfurt am Main, HRB 78707
|
||||
USt-IdNr.: DE252204770
|
||||
Geschäftsführer: Christa Koenen (Vorsitzende), Bodo Gmel, Gerald Hofer, Dr. Klaus Rüffler
|
||||
Vorsitzende des Aufsichtsrates: Prof. Dr. Sabina Jeschke
|
||||
Â
|
||||
Nähere Informationen zur Datenverarbeitung im DB-Konzern finden Sie hier: https://www.deutschebahn.com/de/konzern/datenschutz
|
||||
Â
|
||||
Von: Sebastian Hassemer
|
||||
Gesendet: Mittwoch, 23. Januar 2019 10:09
|
||||
An: Joachim Geidel -Extern <Joachim.Geidel-extern@deutschebahn.com>
|
||||
Cc: Frank F Ludwig <Frank.F.Ludwig@deutschebahn.com>; Michael Theuerkauf <Michael.Theuerkauf@deutschebahn.com>; Nils Block <Nils.Block@deutschebahn.com>; Sascha Dördelmann <Sascha.Doerdelmann@deutschebahn.com>; Konstantin Pussep <Konstantin.Pussep@deutschebahn.com>; Benjamin Schmücker <benjamin.schmuecker@deutschebahn.com>; Marcel Hufgard <Marcel.Hufgard@deutschebahn.com>; Ana Cvitkovic <Ana.Cvitkovic@deutschebahn.com>; Martin M Schmitt <Martin.M.Schmitt@deutschebahn.com>; Alicia Schäfer <Alicia.Schaefer@deutschebahn.com>
|
||||
Betreff: Ergebnis: Erstabstimmung Vorprojekt Bestellportal & RuT-K neu
|
||||
Â
|
||||
Hallo Joachim,
|
||||
Â
|
||||
zunächst vielen Dank für den gestrigen Termin, der sehr aufschlussreich war.
|
||||
Â
|
||||
Im Nachgang zu unserem ersten Austausch zwischen den beiden Vorprojekten RuT-K neu und Bestellportal haben wir folgendes Ergebnis in unsere Unterlagen eingearbeitet. Bitte prüft dies kritisch und korrigiert uns, falls wir etwas falsch verstanden haben oder falsch wiedergeben.
|
||||
Vielen Dank bereits im Voraus!
|
||||
Â
|
||||
Â
|
||||
- Die Konzeption und spätere Umsetzung der Funktionalität für die ProduktionsAuftragsSteuerung (Synonym: KonstruktionsablaufSteuerung / Steuerung der Konstruktion) sowie die Trassenverwaltung liegt im Scope des Vorprojekts RuT-K neu.
|
||||
- Hierzu zählt u.a. auch die Orchestrierung der manuellen Konstruktion durch Mitarbeiter des Fahrplans mit der automatischen Konstruktion aus neXt-Gesamtfahrplan.
|
||||
- Aus Sicht der aktuellen IST-IT-Landschaft bezieht sich der Scope des Vorprojekts Bestellportal auf den Anteil TPN-Kundenclient.
|
||||
Der Scope des Vorprojekts RuT-K neu bezieht sich auf den Anteil TPN âKK-Clientâ (Funktionalitäten für die Benutzerrollen Konstrukteur und Koordinator) und sowie auf Anteile von GFD-Z (u.a. Trassenverwaltung & ProduktionsAuftragsSteuerung, nicht VÃ).
|
||||
- Die Bereitstellung von Informationen für die Và (Schnittstelle zu VÃ) liegt im Scope des Vorprojekts RuT-K neu.
|
||||
- Die Verantwortlichkeit zur Umsetzung folgender Funktionalitäten ist bisher keinem der beiden Vorprojekte eindeutig zugeordnet. Hierzu wird es im weiteren Zeitverlauf der beiden Vorprojekte gesonderte Abstimmungen geben, um die Funktionalitäten zu verorten:
|
||||
- Fristenberechnung
|
||||
- Zugnummernverwaltung
|
||||
- Eine erste Abstimmung auf Basis des Objektmodells soll vsl. ab März zwischen den beiden Projekte stattfinden, um insbesondere die Schnittstelle zwischen den beiden zukünftigen Systemen modellieren zu können.
|
||||
Â
|
||||
Â
|
||||
Mit freundlichen GrüÃen
|
||||
Â
|
||||
Sebastian Hassemer
|
||||
IT-Projekte Vertrieb und Fahrplan (I.NVI 31)
|
||||
Â
|
||||
DB Netz AG
|
||||
WeilburgerstraÃe 22, 60326 Frankfurt/M
|
||||
Tel. +49 69 265 47093, intern 95547093
|
||||
Mobil: +49 175 69 59 517
|
||||
_________________________________________________________
|
||||
Â
|
||||
--- Bitte denken Sie an die Umwelt, bevor Sie diese E-Mail ausdrucken. ---
|
||||
Â
|
||||
Sitz der Gesellschaft: Frankfurt am Main
|
||||
Registergericht: Frankfurt am Main, HRB 50879
|
||||
USt-IdNr.: DE 199861757
|
||||
Vorstand: Frank Sennhenn (Vorsitzender), Jens Bergmann, Dr. Volker Hentschel, Ute Plambeck, Prof. Dr. Dirk Rompf, Dr. Thomas Schaffer
|
||||
Vorsitzender des Aufsichtsrates: Ronald Pofalla
|
||||
Â
|
||||
Nähere Informationen zur Datenverarbeitung im DB-Konzern finden Sie hier: https://www.deutschebahn.com/de/konzern/datenschutz
|
||||
Â
|
||||
+45
@@ -0,0 +1,45 @@
|
||||
# 6.12 Geschäftsobjekte DB Netz - IST Zustand
|
||||
|
||||
> Confluence Page ID: 27526042
|
||||
> Version: 40
|
||||
> Pfad: /pathOS/Start / Vorstudie Bestellsystem/00_Vorstudie Bestellsystem/6 IT Ist-Analyse/6.12 Geschäftsobjekte DB Netz - IST Zustand
|
||||
> Labels:
|
||||
|
||||
---
|
||||
|
||||
Ãbergreifendes Fachliches Objektmodell (FOM)
|
||||
Das fachliche Objektmodell der DB Netz (FOM) ist Teil des Architekturmanagements der DB Netz AG. Das FOM findet funktionsgruppenübergreifend Anwendung und ist im Domänenmodell EAM.eap hinterlegt. Ãbergreifende Geschäftsobjekte der DB Netz sind in der  zu finden.
|
||||
Das FOM Domänenmodell ist für die Vorstudie relevant und wird in regelmäÃigen Abständen zusammen mit dem Projektteam evaluiert. Vor allem folgende Domänen:
|
||||
- LD25 Vertrieb,Â
|
||||
- LD40 Kapazitäts- und FahrplanmanagementÂ
|
||||
-
|
||||
LD60Â Infrastrukturdaten und
|
||||
-
|
||||
UD70 Common Service
|
||||
|
||||
|
||||
Die Domäne Vertrieb LD25 - Vertrieb, Auftragsmanagement und Abrechnung bündelt im Kontext der Kundeninteraktion und der kaufmännischen Abwicklung alle Funktionen zur Abwicklung vertrieblicher und kaufmännischer Vorgänge.Â
|
||||
Die fachliche Domäne Vertrieb LD25.10 ist verantwortlich für die Planung und Festlegung der vertrieblichen Ziele und benötigter Ressourcen rund um das vertriebliche Angebot sowie für die Gewährleistung des gesetzlich und vertraglich zugesicherten Netzzugangs, die Beratung des Kunden und die eigentliche Angebotserstellung.
|
||||
Analyse- und Statistikfunktionen werden (soweit nicht schon durch die Anfrage- und Angebotsverwaltung abgedeckt) durch den Funktionsblock Reporting erfüllt.
|
||||
Unterstützte Kernobjekte sind:Â
|
||||
- Vertriebsplan, Netzzugangsregelung, Fahrlagen / Fahrplankonzepte, Angebotsanfrage (Trassenanmeldung, Anlagennutzungsanfrage), Angebot (z.B. Trassenangebot)
|
||||
Unterstützte Kernfunktionen sind:Â
|
||||
- Planung und Festlegung von Vertriebszielen, Gewährleistung des gesetzlich garantierten Netzzugangs, Gewährleistung der vertraglich vereinbarten Netzzugangsregelung, Beratung des Kunden, z.B. Fahrlagenberatung im Vorfeld der EIBV-Phase, Aufnahme und Koordination von Angebotsanfragen /Trassenanmeldungen, Erstellung von Angeboten (Trassen-/Anlagenangeboten)
|
||||
|
||||
|
||||
## Die Domäne LD40 - Kapazitäts- und Fahrplanmanagement
|
||||
|
||||
|
||||
## und die Domäne LD60 - Infrastrukturdaten und UD70 Common Service.
|
||||
|
||||
|
||||
|
||||
|
||||
## FOM TAF-TSI-Tapete
|
||||
|
||||
Eine Ãbersicht ist initial als EAM Modell erstellt. Generell fehlt in diesem Objektmodell die Verbindung zwischen den TAF/TAP-TSI-Messages (= Objekten) und den Objekten des Fahrplans, z.B. Fahrlage und Zugtrasse. Die Modellierung hilft uns auch nicht unbedingt bei der Beantwortung einiger aktuell offener Fragen bzw. wirft sogar neue Fragen auf und stellt inzwischen getroffene Entscheidungen erneut in Frage.
|
||||
Fazit von Experten: Die Nutzung des vorliegenden Modells ist extrem riskant. Für die Weiterentwicklung sind sowohl viel Zeit, als auch detaillierte fahrplanerische Detailkenntnisse notwendig.
|
||||
Das IT Soll-FachObjektmodell wird im Rahmen der Vorstudie anhand der IT Anforderungen TAF/TAP-TSI durch die IT Architekten des CIO-Bereichs und Fachbereichs überprüft, abgestimmt und fortgeschrieben.
|
||||
Die OMs werden in einem EAM-Modell und TAF/TAP-TSI-Modell als Anlage 3, 4 und 5 gepflegt. Das OM TAF/TAP-TSI ist Teil des Architekturmanagements der DB Netz AG.
|
||||
|
||||
## IT- Objektmodell ITOMÂ
|
||||
+62
@@ -0,0 +1,62 @@
|
||||
# 4.2 Ãbersicht der Geschäftsvorfälle
|
||||
|
||||
> Confluence Page ID: 27526046
|
||||
> Version: 49
|
||||
> Pfad: /pathOS/Start / Vorstudie Bestellsystem/00_Vorstudie Bestellsystem/4 Anforderungen an das neue Bestellsystem der DB Netz/4.2 Ãbersicht der Geschäftsvorfälle
|
||||
> Labels:
|
||||
|
||||
---
|
||||
|
||||
Das Bestellsystem muss alle Geschäftsvorfällen und Geschäftsvorfallfolgen abdecken, die auch an der EVU-Schnittstelle 4.0 zu unterstützen sind. Die ausführliche Beschreibung der zu berücksichtigenden Geschäftsvorfälle ist entsprechend in der Schnittstellendokumentation zu TAF/TAP TSI zu finden, und wird hier nicht wiederholt.Â
|
||||
Im Folgenden werden die Geschäftsvorfälle produktspezifisch aufgelistet
|
||||
## Produkt Trasse
|
||||
|
||||
| | Geschäftsvorfall | Kommunikationsrichtung
|
||||
| | Erstanmeldung | EVU > DB Netz
|
||||
| | Ãnderung vor Angebotserhalt/-abgabe | EVU > DB Netz
|
||||
| |
|
||||
Abmeldung | EVU > DB Netz
|
||||
| | (fachliche) Zurückweisung | EVU < DB Netz
|
||||
| | Nichtkonstruierbarkeit | EVU < DB Netz
|
||||
| | Vorläufiger Netzfahrplanentwurf | EVU < DB Netz
|
||||
| |
|
||||
Endgültiger Netzfahrplanentwurf | EVU < DB Netz
|
||||
| | Berechtigte Beanstandung | EVU > DB Netz
|
||||
| | Netzausgelöste berechtigte Beanstandung | EVU < DB Netz
|
||||
| |
|
||||
Trassenangebot | EVU < DB Netz
|
||||
| | Ablehnung | EVU > DB Netz
|
||||
| | Ablehnung mit Ãberarbeitungswunsch | EVU > DB Netz
|
||||
| | Netzausgelöste Ablehnung nach Fristablauf zur Angebotsannahme | EVU < DB Netz
|
||||
| | Angebotsannahme | EVU > DB Netz
|
||||
| | Buchungsbestätigung | EVU < DB Netz
|
||||
| | Ãnderung nach Vertragsschluss | EVU > DB Netz
|
||||
| | Ankündigung Netzausgelöste Ãnderung | EVU < DB Netz
|
||||
| | Netzausgelöstes Trassenangebot | EVU < DB Netz
|
||||
| | Stornierung | EVU > DB Netz
|
||||
| | Stornierungsbestätigung | EVU < DB Netz
|
||||
| | Netzausgelöste Stornierung | EVU < DB Netz
|
||||
## Produkt KFB - Kurzfristige Trassenberatung mit Buchungsoption (Verfahren Click&Ride)
|
||||
|
||||
| | Geschäftsvorfall | Kommunikationsrichtung
|
||||
| | Erstanmeldung einer KFB | EVU > DB Netz
|
||||
| | (fachliche) Zurückweisung | EVU < DB Netz
|
||||
| | Nichtkonstruierbarkeit | EVU < DB Netz
|
||||
| | Ergebnis* | EVU < DB Netz
|
||||
*Das Ergebnis der KFB kann für eine begrenzte Zeit nach Ergebniserhalt (aktuell 10 Minuten) als Gelegenheitsverkehrsanmeldung mit Annahmeverzicht gebucht werden.
|
||||
## Fahrzeitberechnung, Fahrplanstudie, Betriebsprogrammstudie
|
||||
|
||||
| | Geschäftsvorfall | Kommunikationsrichtung
|
||||
| | Erstanmeldung | EVU > DB Netz
|
||||
| | Ãnderung vor Angebotserhalt/-abgabe | EVU > DB Netz
|
||||
| |
|
||||
Abmeldung | EVU > DB Netz
|
||||
| | (fachliche) Zurückweisung | EVU < DB Netz
|
||||
| | Nichtkonstruierbarkeit | EVU < DB Netz
|
||||
| | Ergebnis | EVU < DB Netz
|
||||
## Produktübergreifende Geschäftsvorfälle
|
||||
|
||||
| | Geschäftsvorfall | Kommunikationsrichtung
|
||||
| | (techn.) Zurückweisung | EVU <> DB Netz
|
||||
| | Empfangsbestätigung | EVU <> DB Netz
|
||||
| | Abruf Objektinformation |
|
||||
+65
@@ -0,0 +1,65 @@
|
||||
# 2019-01-24 Einbindung Datenschutzbeauftragen bzw. Sicherheitsmanager
|
||||
|
||||
> Confluence Page ID: 27526049
|
||||
> Version: 1
|
||||
> Pfad: /pathOS/Start / Vorstudie Bestellsystem/00_Vorstudie Bestellsystem/14 Besprechungsnotizen Vorstudie/2019-01-24 Einbindung Datenschutzbeauftragen bzw. Sicherheitsmanager
|
||||
> Labels:
|
||||
|
||||
---
|
||||
|
||||
Von: Sebastian Hassemer
|
||||
Gesendet: Donnerstag, 24. Januar 2019 15:05
|
||||
An: Drazen Morog <Drazen.Morog@deutschebahn.com>
|
||||
Cc: Benjamin Schmücker <benjamin.schmuecker@deutschebahn.com>; Richard Ri Berger <Richard.Ri.Berger@deutschebahn.com>
|
||||
Betreff: Information zu Projektvorhaben "Bestellportal"
|
||||
Â
|
||||
Hi Drazen,
|
||||
Â
|
||||
entsprechend der mir vorliegenden Infos (siehe letzter Absatz in der Mail anbei) sollen wir dich über neue Projektideen informieren, quasi als Ersatz für die unbesetzte Stelle des Datenschutzbeauftragten.
|
||||
Daher anbei eine kurze Beschreibung der Projektinhalte, mit denen wir uns derzeit im Rahmen eines Vorprojekts auseinandersetzen, für dich als Information:
|
||||
Â
|
||||
Projektname:
|
||||
Bestellportal (Teil von M31)
|
||||
Â
|
||||
Aktuelle Projekthase:
|
||||
Vorprojekt
|
||||
Â
|
||||
Zeitleise:
|
||||
Januar â Oktober 2019 Vorprojekt
|
||||
Ab Januar 2020 Umsetzungsprojekt
|
||||
Vsl. erstes Release zu Mitte 2022
|
||||
Â
|
||||
Auftraggeber:
|
||||
I.NMK 3 (Ralph Grassel)
|
||||
Product Owner: Benjamin Schmücker
|
||||
Vorprojekt-Steuerung: Sebastian Hassemer     Â
|
||||
Â
|
||||
Ziel des zukünftigen Umsetzungsprojekts
|
||||
Ziel ist der Aufbau eines kundenfreundlichen Bestellsystems, dass den Kunden TAF/TAP-TSI kompatibel bei der Planung aller Zugfahrten weitgehend unterstützt, die Anmeldung dieser ermöglicht sowie Informationen über Anmeldestatus und bestehende Trassenverträge und deren Verwaltung bereithält. Das Bestellsystem beinhaltet ein webbasiertes Bestellportal sowie eine Datenaustauschschnittstelle zum Anbinden von Trassenbestellsystemen von Drittherstellern.
|
||||
Â
|
||||
Im Projekt-Scope befindet sich daher maÃgeblich die Auflösung des heutigen Systems TPN mit dem Ziel zur Trennung von Vertrieb und Fahrplan. Der vertriebliche Anteil von TPN soll in einem neuen Bestellportal aufgehen, während der restliche Teil in einem neuen Konstruktionssystem (âRuT-K neuâ , nicht Scope dieses Projekts) verortet werden soll.
|
||||
Â
|
||||
Â
|
||||
Für weitere Rückfragen komme gerne auf mich zu!
|
||||
Â
|
||||
Â
|
||||
Mit freundlichen GrüÃen
|
||||
Â
|
||||
Sebastian Hassemer
|
||||
IT-Projekte Vertrieb und Fahrplan (I.NVI 31)
|
||||
Â
|
||||
DB Netz AG
|
||||
WeilburgerstraÃe 22, 60326 Frankfurt/M
|
||||
Tel. +49 69 265 47093, intern 95547093
|
||||
Mobil: +49 175 69 59 517
|
||||
_________________________________________________________
|
||||
Â
|
||||
--- Bitte denken Sie an die Umwelt, bevor Sie diese E-Mail ausdrucken. ---
|
||||
Â
|
||||
Sitz der Gesellschaft: Frankfurt am Main
|
||||
Registergericht: Frankfurt am Main, HRB 50879
|
||||
USt-IdNr.: DE 199861757
|
||||
Vorstand: Frank Sennhenn (Vorsitzender), Jens Bergmann, Dr. Volker Hentschel, Ute Plambeck, Prof. Dr. Dirk Rompf, Dr. Thomas Schaffer
|
||||
Vorsitzender des Aufsichtsrates: Ronald Pofalla
|
||||
Â
|
||||
Nähere Informationen zur Datenverarbeitung im DB-Konzern finden Sie hier: https://www.deutschebahn.com/de/konzern/datenschutz
|
||||
+184
@@ -0,0 +1,184 @@
|
||||
# 4.4 Soll-Schnittstellen Bestellsystem (Consumer oder Provider)
|
||||
|
||||
> Confluence Page ID: 27526054
|
||||
> Version: 231
|
||||
> Pfad: /pathOS/Start / Vorstudie Bestellsystem/00_Vorstudie Bestellsystem/4 Anforderungen an das neue Bestellsystem der DB Netz/4.4 Soll-Schnittstellen Bestellsystem (Consumer oder Provider)
|
||||
> Labels:
|
||||
|
||||
---
|
||||
|
||||
Das neue Bestellsystem benötigt Schnittstellen von und zu Drittsystemen. Die Hauptgebiete der anzubindenden Schnittstellen betreffen die kaufmännischen Systeme, die Fahrplansysteme, die externe Benutzerverwaltung und die Stammdatensysteme.Â
|
||||
Eine Ãbersicht der bereitgestellten und genutzten Services kann im Komponentendiagramm im Enterprise Architect Dokument eingesehen werden:Â Â Â oderÂ
|
||||
Darüber hinaus zeigt folgendes Systemkontextdiagramm die Gesamtsicht des Systems:Â
|
||||
Folgende Tabelle enthält eine Ãbersicht der Schnittstellen, die das neue System nutzt oder anderen Systemen bereitstellt. Darüber hinaus sind detaillierte Informationen zu den jeweiligen Schnittstellen in einer Excel Datei "Schnittstellendokumentation Vorprojekt Bestellsystem"zu finden zum Stand 09/2019 oder alternativ als BildÂ
|
||||
| | Nr. | Bereitstellendes System | Nutzendes System | Service | Operationen | Fachliche Daten/ Beschreibung
|
||||
| | 1 |
|
||||
DB Netz CRM System |
|
||||
Bestellsystem | KundenDatenVerwaltung (KDV) |
|
||||
leseKunde
|
||||
leseAlleKunden |
|
||||
Kundendaten (KdNr, Name, Company-ID, ,...)
|
||||
| | 2 |
|
||||
BKU-AD (iMan) |
|
||||
Bestellsystem |
|
||||
|
||||
|
|
||||
|
|
||||
Authentifizierung für DB Netz interne User
|
||||
| | 3 |
|
||||
DS-AD (ExterneBenutzerVerwaltung) | Bestellsystem |
|
||||
|
|
||||
|
|
||||
Authentifizierung für DB Netz externe User (u.a. EVUs)
|
||||
| | 4 |
|
||||
ExterneBenutzerVerwaltung |
|
||||
Bestellsystem | BenutzerBerechtigungZuordnung |
|
||||
leseAlleBenutzerkontoBerechtigungsZuordnungen |
|
||||
Mandant, Benutzername
|
||||
| | 5 |
|
||||
Bestellsystem |
|
||||
Common Interface EVU/RNE | Common Interface DB Netz |
|
||||
|
|
||||
Geschäftsvorfälle (Anmelden von Trassen, Ãndern, Stornieren, Angebote, ...)
|
||||
PathRequestMessage,
|
||||
PathCanceledMessage,
|
||||
ErrorMessage
|
||||
| | 6 |
|
||||
Infrastruktur-Manager (M15) | Bestellsystem |
|
||||
zum Zeitpunkt der Vorprojektphase Bestellsystem keine weiteren Informationen vorliegen |
|
||||
zum Zeitpunkt der Vorprojektphase Bestellsystem keine weiteren Informationen vorliegen |
|
||||
Stammdaten-Bereitstellung:
|
||||
BetriebsstellenListe,
|
||||
StreckenklassenListe,
|
||||
StreckenListe,
|
||||
TriebfahrzeugListe,
|
||||
ZuggattungsListe,
|
||||
ZugausruestungsListe,
|
||||
VerkehrsartKundeZusatz,
|
||||
Flexibilität,, VerkehrsartenKunde, betrieblichen Prioritäten, TfzLeerfahrtangabenÂ
|
||||
| | 7 |
|
||||
CRD (Common Reference Data = CRD) |
|
||||
Bestellsystem |
|
||||
Externes System der RNE über Internet |
|
||||
|
||||
|
|
||||
Company_ID, Location_ID
|
||||
| | 8 |
|
||||
Common Interface EVU/RNE |
|
||||
Bestellsystem |
|
||||
Common Interface (Externe Systeme über Internet) |
|
||||
UICMessage |
|
||||
PathDetailsMessage, PathNotAvailableMessage,
|
||||
ErrorMessage
|
||||
| | 9 |
|
||||
Bestellsystem |
|
||||
Drittsysteme der EVUs |
|
||||
StammdatenBereitstellen |
|
||||
leseFleixibilitaetListe
|
||||
leseVerkehrsartKundeZusatzListe
|
||||
leseZugausruestungen
|
||||
leseStrecken
|
||||
leseStreckenklassen
|
||||
leseZuggattungen
|
||||
leseTriebfahrzeugen
|
||||
leseBetriebsstellen, lese VerkehrsartenKunde, lese betrieblichen Prioritäten, leseTfzLeerfahrtangaben |
|
||||
Bereitstellung der Stammdaten für EVUs
|
||||
| | 10 |
|
||||
Abrechnung Cockpit Trasse (AC) | Bestellsystem | PreisVerwaltungTrasse |
|
||||
ermittleTrassenPreisInfo
|
||||
ermittleTrassenPreis |
|
||||
Trassenpreis-Informationen
|
||||
Verbindliche TrassenpreisAnfragen (mit Link auf LB)
|
||||
| | 11 |
|
||||
AbrechnungsCockpit Trasse (AC) |
|
||||
Bestellsystem | AufbereitungAbrechnungsInformationTrasse |
|
||||
abrechneVertragsAenderung |
|
||||
Vertragsstand mit referenziertem Trassenprodukt
|
||||
| | 12 |
|
||||
Common Services (EIP) umgesetzt durch AbrechnungsCockpit Trasse (AC) | Bestellsystem | BelegAnhangArchiv |
|
||||
leseBelegAnhang |
|
||||
DokumentenID, Konsument
|
||||
Lesen von kaufmännischen Beleganhängen (PDF)
|
||||
| | 13 |
|
||||
EIP (Anfrage-, Angebots-, Auftragsverwaltung) umgesetzt durch AbrechnungsCockpitTrasse (AC) |
|
||||
Bestellsystem | KaufmaennischeAuftragsverwaltung |
|
||||
aendereAngebotsAnfrage
|
||||
aendereVertragsAngebot
|
||||
aendereProduktVertrag
|
||||
beendeBeleg
|
||||
erstelleAngebotsAnfrage
|
||||
erstelleVertragsAngebot
|
||||
erstelleProduktVertrag
|
||||
leseAngebotsAnfrage
|
||||
leseVertragsAngebot
|
||||
leseProduktVertrag |
|
||||
Beleg
|
||||
| | 14 |
|
||||
AbrechnungsCockpit DiscountOrderSystem |
|
||||
Bestellsystem |
|
||||
Benachrichtigen des DiscoutOrderSystems wenn Rabatte gewährt werden sollen. Nach Genehmigung Rückmeldung an das Bestellsystem |
|
||||
Senden eines VertragsAngebots mit Rabattcode.
|
||||
Abholen des Genehmigungsstatus im Pullverfahren durch das Bestellsystem |
|
||||
VertragsAngebot (PathDetailsMessage)
|
||||
| | 15 |
|
||||
Bestellsystem |
|
||||
Netzmonitor,
|
||||
SAPBINe | AuftragsDatenBereistellung |
|
||||
leseAuftragsdaten |
|
||||
Daten- Auftragsgebirge in Rohform. AngebotsAnfragen, VertragsAngebote und ProduktVerträge
|
||||
Bestellsystem stellt seine AngebotsAnfragen, VertragsAngebote und Verträge im Bestellsystem-Format zur Verfügung.Â
|
||||
| | 16 |
|
||||
KonBel-K (M13) |
|
||||
Bestellsystem | TPPuE (BeP) |
|
||||
FahrlagePruefen |
|
||||
BestelleingangsprüfungenÂ
|
||||
| | 17 |
|
||||
KonBel-K (M13) | Bestellsystem | Routensuche |
|
||||
sucheRoute |
|
||||
Angebotsanfrage, Route
|
||||
| | 18 |
|
||||
BaDiFa | Bestellsystem | FahrplanSchnittstelle |
|
||||
erteileFahrplanKonstruktionsAuftrag
|
||||
bucheFahrplanKapazität
|
||||
freigabeFahrplanKapazität
|
||||
aendereFahrplanKonstruktionsAuftrag
|
||||
zurückziehenFahrplanKonstruktionsAuftrag
|
||||
verarbeiteFehlerNachricht |
|
||||
FahrplanKonstruktionsAuftrag, FahrplanKapazität
|
||||
| | 19 |
|
||||
Trassenmanagement (BaDiFa) |
|
||||
Bestellsystem |
|
||||
OTNService |
|
||||
pruefeOperationalTrainNumber
|
||||
erzeugeOperationalTrainNumber |
|
||||
Kundennr, OTN
|
||||
| | 20 |
|
||||
Bestellsystem | BaDiFa | VertriebsSchnittstelle |
|
||||
verarbeiteVertragsAngebot
|
||||
verarbeiteBuchungsbestaetigung
|
||||
verarbeiteNetzausgeloestesVertragsAngebot
|
||||
verarbeiteGebuchteTrasseNichtVerfuegbar
|
||||
verarbeiteFehlerNachricht |
|
||||
VertragsAngebot, ProduktVertrag, Buchungsbestätigung, Ablehnung
|
||||
| | 21 |
|
||||
Bestellsystem |
|
||||
Click&Ride App |
|
||||
Interne Schnittstelle zur Anbindung Click&Ride App an SteuerungVertriebsAblauf des Bestellsystems |
|
||||
Senden von AngebotsAnfragen (eintägiger Gelegenheitsverkehr) und Ãbermittlung von VertragsAngeboten. |
|
||||
AngebotsAnfrage (PathRequestMessage)
|
||||
VertragsAngebot (PathDetailsMessage)
|
||||
| | 22 |
|
||||
GeoServer (inkl. TileServer für die Kartendarstellung) |
|
||||
Bestellsystem |
|
||||
Anbindung des GeoServers für die Kartendarstellung mit Geodaten im Bestellportal |
|
||||
Im Kontext sind zwei Standards relevant und werden von den Services bereitgestellt: WMS = Web Mapping Service
|
||||
- Liefert auch Abfrage einen bestimmten Kartenausschnitt als Bild (z.B. ONG) zurück
|
||||
https://www.opengeospatial.org/standards/wms
|
||||
- WFS = Web Features Service
|
||||
Liefert auf Anfrage die konkreten Datensätze als XML zurück.
|
||||
https://www.opengeospatial.org/standards/wfs |
|
||||
Ãber den Zugriff auf die Streckenverläufe des GeoServers und den Karten des DB OpenStreetMap, kann eine Kartendarstellung von Routen angezeigt werden.
|
||||
(Team Geo-Services H. Heidelmayer)
|
||||
|
||||
|
||||
In den folgenden Unterkapiteln sind zu einigen der Soll-Schnittstellen noch weiterführende Informationen zu finden.
|
||||
@@ -0,0 +1,10 @@
|
||||
# 3 Geschäftsprozesse
|
||||
|
||||
> Confluence Page ID: 27526061
|
||||
> Version: 3
|
||||
> Pfad: /pathOS/Start / Vorstudie Bestellsystem/00_Vorstudie Bestellsystem/3 Geschäftsprozesse
|
||||
> Labels:
|
||||
|
||||
---
|
||||
|
||||
|
||||
+69
@@ -0,0 +1,69 @@
|
||||
# 3.2 Aktuelle Geschäftsprozesse ("Ist")
|
||||
|
||||
> Confluence Page ID: 27526063
|
||||
> Version: 59
|
||||
> Pfad: /pathOS/Start / Vorstudie Bestellsystem/00_Vorstudie Bestellsystem/3 Geschäftsprozesse/3.2 Aktuelle Geschäftsprozesse ("Ist")
|
||||
> Labels:
|
||||
|
||||
---
|
||||
|
||||
## EinführungÂ
|
||||
|
||||
Die primär betroffenen Geschäftsprozesse sind in den Leistungsprozessen âLN 34 Fahrplan und Kapazitätsmanagement durchführenâ enthalten und können dem Prozessportal der DB Netz AG entnommen werden. Die Integration der Anmeldung von trassenbezogenen Ergänzungsprodukten in den selben Anmeldeprozess, also das Angebot von so genannten Bündelprodukten, wird erst nach Aufbau des TAF/TAP-konformen Anmeldesystems umsetzbar sein, daher wird auf die entsprechenden Prozesse zur Anmeldung von Anlagen und Serviceeinrichtungen, Stationshalten und Energieleistungen hier nicht weiter eingegangen. Die zukünftige Integration dieser Produkte wird aber in der Entwicklung berücksichtigt, um die gewünschte spätere Integration möglichst ohne gröÃere Anpassungen zu erlauben.
|
||||
|
||||
|
||||
|
||||
Abbildung: Prozessportal DB Netz
|
||||
## Ãberblick der Leistungsprozesse âLN 34 Fahrplan und Kapazitätsmanagement durchführenâ
|
||||
|
||||
| | Process Owner | Bestätigung Betroffenheit der verantworteten Geschäftsprozesse
|
||||
| | Anatol Scholz |
|
||||
Bestätigt - siehe E-Mail Anatol Scholz am 15.03.2019 15:23 Uhr
|
||||
Aktuell werden die Trassenbestellungen im Netzfahrplan (Nfpl), Gelegenheitsverkehr (GelV) und Rahmenverträge (RV), sowie die Trassenverwaltung und groÃe Teile der Produktionssteuerung in der gleichen Anwendung Trassenportal Netz (TPN) abgebildet.
|
||||
Relevant sind folgende Prozesse und deren Teilprozesse:
|
||||
| | IST LN 34 |
|
||||
IST LN Unterprozesse
|
||||
| | LN34-01 Netzfahrplan erstellen | Ziel des Prozesses ist die zeitgerechte Erstellung des Netzfahrplans durch die Regionalbereiche und die Zentrale der DB Netz AG.
|
||||
| |
|
||||
| LN 34-01-01 Netzfahrplanerstellung vorbereiten
|
||||
| |
|
||||
| LN 34-01-02 Vorläufige Netzfahrplanerstellung durchführen
|
||||
| |
|
||||
| LN34-01-03 Netzfahrplanerstellung abschlieÃen
|
||||
| | LN34-02 Rahmenvertrag erstellen  | Der Prozess beschreibt die Abläufe in der Region und der Zentrale von der Antragstellung auf Abschluss von Rahmenverträgen, über die Fahrbarkeitsprüfung und die Prüfung der Kapazitätsbindung bis zum Vertragsschluss.
|
||||
| |
|
||||
| LN34-02-01 Rahmenvertragsanmeldung in Papierform bearbeiten
|
||||
| |
|
||||
| LN34-02-02 LN34-02-02 Rahmenvertrag anmelden
|
||||
| |
|
||||
| LN34-02-03 LN34-02-03 Fahrbarkeit der Rahmenvertragskapazitäten prüfen
|
||||
| |
|
||||
| LN34-02-04 Kapazitätsbindung für Rahmenvertrag prüfen
|
||||
| |
|
||||
| LN34-02-05 Rahmenverträge für Vorlage bei BNetzA erstellen
|
||||
| |
|
||||
| LN34-02-06 Rahmenvertrag abschlieÃen
|
||||
| | LN34-03 Gelegenheitsverkehre bearbeiten | Bei den Trassen des Gelegenheitsverkehrs handelt es sich um alle Trassenanmeldungen, die gemäà Schienennetz Benutzungsbedingungen (SNB) auÃerhalb der Trassenbearbeitung des Netzfahrplan-Prozesses bei der DB Netz AG eingehen.
|
||||
| |
|
||||
|
|
||||
Trassenanmeldung Gelegenheitsverkehr prüfen, Trassenkonstruktion Gelegenheitsverkehr durchführen, Angebot abgeben und Annahme empfangen
|
||||
Fahrplan für Gelegenheitsverkehr bekanntgeben, Konflikte lösen, Trassenablehnungen im Gelegenheitsverkehr durchführen
|
||||
| | LN34-07 Kapazitätsmanagement durchführen |
|
||||
LN 34-07-05 Betriebsprogrammstudie erstellen
|
||||
Der Prozess beschreibt die Erstellung von Betriebsprogrammstudien (BPS) durch die regionale Infrastrukturentwicklung. Ziel ist es, die Fahrbarkeit eines vorgegebenen Konzeptes nach Ril 402 mittels einer BPS zu prüfen und frühzeitig Trassenkonflikte und Risiken für die Betriebsqualität zu identifizieren.
|
||||
Neben den aufgeführten, im Prozessportal dargestellten Prozesse, hat das Bestellsystem auch Berührung zu den im Programm neXt Digitale Kapazitätssteigerung erstellten Prozessen. Diese Prozesse sind zum Zeitpunkt dieser Vorstudie noch nicht vollumfänglich produktiv, werden aber sicher vor Produktivsetzung des neuen Bestellsystems aufgrund von Bedingungen der Finanzierungsvereinbarung mit dem BMVI im produktiven Einsatz sein.
|
||||
## Ãberblick der Leistungsprozesse âLN 32 Trassen und Anlagenâ
|
||||
|
||||
"LN 32 Trassen und Anlagen "
|
||||
| | Process Owner | Bestätigung Betroffenheit der verantworteten Geschäftsprozesse
|
||||
| | Markus Vetter | Bestätigt - siehe E-Mail Markus Vetter am 25.03.2019 14:42 Uhr
|
||||
|
||||
|
||||
| | IST LN 32 | IST LN
|
||||
| | LN32-09 Produkte verkaufen bzw. vermieten | LN 32-09-01 Serviceeinrichtungen vermarkten
|
||||
| |
|
||||
| LN 32-09-02 Serviceeinrichtungen zuweisen
|
||||
| | LN32-10 After-Sales durchführen | LN32-10-03 Trassen abrechnen
|
||||
|
||||
|
||||
Â
|
||||
Some files were not shown because too many files have changed in this diff Show More
Reference in New Issue
Block a user