Orchestrator/bahn/project-audit/data/confluence-export/pages/98500862_2020-10-14 Besprechungsnotizen Konzeption KDV.md

2020-10-14 Besprechungsnotizen Konzeption KDV

Confluence Page ID: 98500862 Version: 83 Pfad: /pathOS/Kommunikationskanäle, Termine, Besprechungsnotizen pathOS/Besprechungsnotizen/Sonstige Termine/2020-10-14 Besprechungsnotizen Konzeption KDV Labels: meeting-notes

---

Datum

Teilnehmer

• Optimal: Holger Wiese I.NVI 31 (Sponsor 😉)

• Jason Wendler I.NVI 1 (Architektur)

• Kevin Fischer (Servicemanager)  

•  verantwortlich für Betrieb auf EIP und künftig auf CNP

• Notwendig:

•  (Abnehmendes System)

• Florian Bednarz (Abnehmendes System)

• Marvin Reik (PO)

• Richard Cacik (Entwickler) 

• Antony Bilev (Entwickler Antony + Richard: Entwickler (englisch)

Ziele

• in diesen Terminen möchten wir die REST-API mit den Abnehmern des KDV konzipieren.

Diskussionspunkte

Anbei der aktuelle Stand der Konzeption: As project manager I want to get the operations for the output interface from the KDV as Rest-API  so that the KDV deliver the output as Rest-API to the customers.   For the Rest-API there are same modifaktions in the output to the customer in conparison with the SOAP-Outpot: Acceptance:

• get all operations in the mapping als Rest-API with the modifations   Mapping:
• Die Objekte der Servicebeschreibung basieren auf dem IT- Objektmodell  „ITOM“ 

Folgende Fragen sind Grundlage der Konzeption:

126 complete

Sollen Operationen zu Verfügung gestellt werden und wenn ja welche? (Lese alle Kunden, Lese einen Kunden, ….)

| | | Service / Komponente | Beschreibung | Kommentar | |

leseKunde | Liefert zu einer gegebenen Kundennummer detaillierte Kundendaten zurück |

| |

leseAlleKunden |

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.

73 incomplete Die Operation leseKunde liefert zu einer Kundennummer den entsprechenden Kunden (Geschäftseinheit). Das Bestellsystem nutzt insbesondere folgende Felder: 

• CompanyID >  CompanyID__c

• Bestellberechtigt > Bestellberechtigt__c  

• Accountname

• Kunde [*] (gemäß Kunden und Partnerdatenmanagement::Kunde)

• geschäftspartner:Geschäftspartner [1]

•  Name (Grundsatzkundennummer, Firma, G_Kn_Nr z.B. DB Regio)

• Grundsatzinfrastrukturnutzungsvertrag [0..n]

• GINV-Bezeichnung [1]

• GINV Gültig von [1]

• GINV Gültig bis [1]

• Aktiv-Status [1]   Gültiger G-INV vorhanden?  (Nur wenn Vorhanden ist, aktiv Status )

• Geschäftseinheit [1..n]

• Name 

• HR-Name [0..1] (Firmenname gemäß Handelsregister, Firma

• Kundennummer [1] (Firma, Tab Firma, Kunden-Nr.)

• Kaufmännische Sperre [1]

• Stopp-Kennzeichen [1]

136 complete

Kunde Accountname (HRName), HRAdresse, kaufmännischeSperre, Company _iD, die Sperrvermerke (Kunde ist kaufmännisch gesperrt und inaktiv),  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 OperationleseKunde 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. (kaufm. Sperre bzw. auf Null gesetzt in KDV). Das Bestellportal muss dem Bearbeiter vor Übergabe einer Bestellung an die DB Netz AG eine konfigurierbare Warnmeldung anzeigen.

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).  Dokumentation 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

122 complete Welche Felder sollen durch die Rest-API zur Verfügung gestellt werden? (Alle, Auswahl)

• Der Umfang der Daten noch in Abstimmung, eher mehr Daten als in der alten SOAP/XML-API

123 complete Welche Formationen sind für die einzelnen Felder notwendig?

JSON

124 complete Welche weiteren Anforderungen gibt es an die REST-API? 

• Entwicklung in Oktober, Release noch unbekannt, ende November ist end of code 

88 complete

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

92 complete

AdministrativeContactInformation - aus LDAP

| | 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).

LDAP 

Pflichtfelder

• Anrede (Herr/Frau)
• Vorname
• Nachname
• Passwort

Optionale Felder

• Titel (Prof. / Dr.)
• Straße und Hausnummer
• PLZ
• Ort
• Land
• Telefonnummer

-1 incomplete

• Welches Servicelevel kann durch den Service sichergestellt werden?

Nichtfunktionale Aspekte KDV

| | Vertraulichkeit |

97 incomplete  sehr hoch

98 incomplete  hoch

99 complete  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)  Frage Bestellsystem: Welche Kosten ?
• SL1 nicht geplant --> eher SL3/+ oder SL2 (Stefan Jahn prüft es)
• leseAlleKunden liefert ca. 4000 Kundennummern, in XML sind es ca 12 MB (bei JSON kleiner, Kompression sollte gehen)

| | | 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: rest api

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)

Handlungspunkte

• Servicebeschreibung (SB) für Service KundendatenVerwaltung Servicetyp: Business Service Service-Version 5.0 wird erweitert
• Als Dokumentation wird die Schnittstellenbeschreibung aktualisiert/erweitert + Swagger-UI Dokumentation für die technische Anbindung.
• ruft Daten aus CRM (alle 2-5 Minuten), speichert sie in der Datenbank und liefert sie aus.
• Daten können auch älter als 5 Minuten sein.
• leseAlleKunden liefert ca. 4000 Kundennummern, in XML sind es ca 12 MB (bei JSON kleiner, Kompression sollte gehen)
• Auth über EIP (virtueller Service + BasicAuth), da BizHub nicht geplant (nach Meinung von Stefan Jahn geht es gar nicht mit CNP, vermutlich scheut man den Aufwand für den Api-Proxy Service auf DBCS)
• Testumgebungen: aktuell nur 3 (Test, Abnahme, Prod? Oder Entw, Test, Prod?), bei Bedarf extra Umgebungen
• Sinnvolle Testdaten können von Projekten in Salesforce eingepflegt werden
• Dazu Antrag über iMan + Mail an Marvin Reik (?)
• Produktive Daten können ggfls. Genutzt werden, nach Klärung von Datenschutzaspekten (gewünscht von anderen Abnehmern)