Files
Orchestrator/bahn/project-audit/data/confluence-export/pages/27525683-4.4.5 Anbindung an Verwaltungsunterstuetzende Services KDV und eBRS.md
T
ankn a5f8fb49ab 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.
2026-06-30 20:39:52 +02:00

14 KiB

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)