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


Â