MISTRA Managementinformationssystem Strasse und Strassenverkehr. Anforderungen an Fachapplikationen bezüglich dem Zusammenwirken mit dem Basissystem

Transkript

1 Eidgenössisches Departement für Umwelt, Verkehr, Energie und Kommunikation UVEK Bundesamt für Strassen ASTRA E. Bernard, InfoLite AG, Version 2.3 vom Doku Code: B RE MISTRA Managementinformationssystem Strasse und Strassenverkehr Anforderungen an Fachapplikationen bezüglich dem Zusammenwirken mit dem Basissystem Änderungen gegenüber der Version 2.2 des Dokuments sind blau gekennzeichnet D:\Daten\Aufträge\MISTRA\Teilprojekte\Allgemeines\B Anforderungen BS und FA V2.3.doc

2 Impressum Impressum Erstelldatum: 18. Mai 2006 Letzte Änderung: 28. Mai 2007 Projektleiter: Assistenz: Verzeichnis/Datei: b anforderungen bs und fa v2.3.doc Seitenanzahl gesamt inkl. Deckblatt und 46 Inhaltsverzeichnis: Dokumentenverwaltung Version Datum Autor Bemerkungen EB Entwurf EB Einarbeitungen Bemerkungen EBP, IMC, Sigmaplan EB Einarbeitung Technologien, Ergänzungen Rechtekonzept, Mandantenfähigkeit, Systemvoraussetzungen, Kataloge, Metadaten, Nutzung Achsband, WebServices, Namenskonventionen EB Ergänzungen Begriffe, Präzisierung Mandantenfähigkeit, Datenaustausch, Ticketing, CM und diverse EB Aktualisierung, Differenzierung nach RE1/RE2, Ergänzungen und Annexe zu Interlis, WebServices, GUI-Guideline EB - Ergänzungen und Korrekturen aus Review Erni Consulting AG berücksichtigt. - Liste der Grundlagen ergänzt und aktualisiert - Detaillierung Datenaustausch Interlis - Kapitel 2 in Kapitel 1 gemerged zwecks besserer Übersicht b anforderungen bs und fa v2.3.doc Seite I

3 Inhaltsverzeichnis Inhaltsverzeichnis Seite 0 Allgemeines Zweck des Dokuments Abkürzungen Grundsätze der Architektur MISTRA Begriffe Grundlagen Abgrenzung Systemarchitektur Basisprodukte und -technologien Deploymen-Szenarien MISTRA Mandantenfähigkeit Benutzer- und Rechteverwaltung Visitenkarte Datenbankaspekte Kommunikation FA <> BS Datenaustausch BS FA Datenaustausch zwischen verschiedenen Installationen Datenaustausch zwischen Mandanten einer Installation Bezug von Geodienste Bund (Web Map Service) Generische Objektklassen und Subtypen Metadaten Kataloge Historisierungskonzept des BS GUI Mehrsprachigkeit Modul Achsband Reporting (DWH) 37 2 Service-Interface Abfrage von Metadaten Aktualisierung RBBS 38 3 Namenskonventionen Datenbank-Objekte GIS-Objekte 41 Abbildungen Seite Abbildung 1: Systemabgrenzung 5 Abbildung 2: Logische Systemarchitektur (Details s. [3]) 6 Abbildung 3: Deployment-Szenarien 8 Abbildung 4: Übersicht Berechtigungsverwaltung BS 10 Abbildung 5: Installation, Eigentümer, Mandant, Benutzergruppe, Rolle, Funktion 11 Abbildung 6: Verwendung von Oracle-Datenbanken 14 Abbildung 7: Varianten Anbindung online / offline 16 Abbildung 8: Datenaustausch BS FA offline 20 Abbildung 9: Sequenzdiagramm Transferdefinition BS > FA 21 Abbildung 10: Sequenzdiagramm Export BD / GD durch BS 21 Abbildung 11: Sequenzdiagramm Import BD / GD durch FA 22

4 Inhaltsverzeichnis Abbildung 12: Datenaustausch FA BS offline 23 Abbildung 13: Sequenzdiagramm Transferdefinition FA > BS 24 Abbildung 14: Sequenzdiagramm Export BD / GD durch BS 24 Abbildung 15: Sequenzdiagramm Import BD / GD durch FA 25 Abbildung 16: Datenaustausch zwischen verschiedenen MISTRA Installationen 28 Abbildung 17: Schnittstelle zu Geodiensten KOGIS 30 Abbildung 18: Datenmodell Metadaten in SDB 31 Abbildung 19: Klassendiagramm Katalog BS 33 Abbildung 20: Historisierungskonzept BS (am Bespiel der Inventarobjekte) 34 Tabellen Tabelle 1: Begriffe 3 Tabelle 2: Basisprodukte und Technologien 7 Tabelle 3: Verzeichnisstruktur 18

5 Allgemeines 0 Allgemeines 0.1 Zweck des Dokuments Dieses Dokument beschreibt das Zusammenwirken der Fachapplikationen mit dem Basissystem. Es dient nebst den Dokumenten zur Fachapplikation (Pflichtenheft, Konzept usw.) als zusätzliche Grundlage für die Ersteller der FA. Bei Widersprüchen zwischen diesem Dokument und den Dokumenten [2] und [3] sowie dem Konzept und Pflichtenheft der FA gilt dieses Dokument. In Kapitel Fehler! Verweisquelle konnte nicht gefunden werden. Fehler! Verweisquelle konnte nicht gefunden werden. werden die wichtigen Grundlagen und Zusammenhänge erläutert. Sie dienen primär dem Verständnis der Entwickler der FA für das MISTRA-Konzept und dem Basissystem. In Kapitel Fehler! Verweisquelle konnte nicht gefunden werden. Fehler! Verweisquelle konnte nicht gefunden werden. werden die Anforderungen an die Fachapplikationen beschrieben, damit das Zusammenwirken mit dem Basissystem funktioniert. Im Kapitel 3 sind die WebServices beschrieben. Kapitel 4 legt die Namenskonventionen für die Datenbank- und GIS-Objekte fest. Die Anhänge 1 bis 5 zu LDAP, Mandantenkonzept, GUI-Richtlinie, Interlismodellierung und WebServices bilden integrierenden Bestandteil dieses Dokuments. 0.2 Abkürzungen Folgende Abkürzungen werden in diesem Bericht sehr häufig verwendet: BD = Basisdaten BS = Basissystem FA = Fachapplikation FDB = Fachdatenbank FR = Fremdapplikation GD = Generalistendaten SD = Spezialistendaten SDB = Sockeldatenbank Weitere Abkürzungen werden in [1] erläutert. Seite 1

6 Allgemeines 0.3 Grundsätze der Architektur MISTRA Modulares Konzept MISTRA ist ein Gesamtsystem lose gekoppelter Teilsysteme. BS, DWH, Achsband und die verschiedenen FA sind dabei die Teilsysteme. Die Kopplung erfolgt über WebServices und über die Offline-Interlis-Schnittstelle. Beim Zusammenwirken zwischen BS und FA sind immer die FA aktiv. Es gibt keine Abhängigkeit vom BS zu einer FA. Die FA stellen den Abgleich der Daten mit dem BS sicher. Die FA besitzen untereinander keine Abhängigkeiten. FA besitzen Abhängigkeiten zum BS. Dabei wird unterschieden zwischen: Eigenständige FA Setzt die Verfügbarkeit eines BS nicht voraus. Benötigte Daten des BS werden durch die Offline-Interlis-Schnittstelle durchgeführt. Abhängige FA Setzt die Verfügbarkeit eines BS voraus und greift auf das BS über Webservices zu. Eine solche FA ist ohne ein verfügbares Basissystem nicht oder nur teilweise funktionsfähig Gemeinsame Nutzung von Teilsystemen Die Teilsysteme Benutzerverwaltung, Datenbanksystem, GIS, Achsband und DWH sollen von allen Teilsystemen gemeinsam genutzt werden Gemeinsame Nutzung von Basis- und Generalistendaten Das BS bewirtschaftet die BD, welche von allen Teilsystemen gemeinsam genutzt werden und stellt diese den FA zur Verfügung. BD werden ausschliesslich im BS gepflegt. Das FA bewirtschaften die Spezialistendaten. Jede FA hat ihre eigenen Spezialistendaten. Sie stellen diese den anderen FA in Form von Generalistendaten über die Datenbank des BS zur Verfügung. Eine FA kann somit auf die Generalistendaten einer anderen FA via BS zugreifen Integration Fachapplikationen FA berücksichtigen die folgenden Aspekte: Authentisierung und Autorisierung im gemeinsam genutzten LDAP Mandantenfähiges System Datenaustausch mit dem BS über die INTERLIS-Schnittstelle Benutzerschnittstelle nach dem festgelegten GUI-Konzept (siehe [5]) Integration Fremdapplikationen Fremdapplikationen werden über die Import- / Exportschnittstellen integriert Integration Teilsysteme Dritter (Fertigprodukte) Mit MISTRA sollen bewährte Fertigprodukte als FA oder FR genutzt werden können Neuentwicklungen als 3-Tier-Architektur Die Teilsysteme müssen als 3-tier-Anwendung entwickelt werden. Hierdurch ist die gemeinsame Nutzung von Business-Logik, die Unterstützung mobiler Clients sowie effiziente Softwareverteilung sicher gestellt. Seite 2

7 Allgemeines 0.4 Begriffe Installation Eigentümer (Owner) Mandant Benutzergruppe Rolle UseCase (Funktion) Datenbank Umfasst alle Hardware-, Datenbank- und Software-Komponenten einer MISTRA-Installation. BS, DWH und alle in der Installation benötigten FA bilden Komponenten einer Installation. Die Komponenten gehören logisch zusammen. Der Datenaustausch zwischen BS und FA ist nur innerhalb einer Installation möglich. Mehrere Eigentümer können gemeinsam eine Installation betreiben. Ist der Eigentümer der Daten. Jedes MISTRA-Objekt ist genau einem Eigentümer zugeordnet (Owner-ID). Daten können zur Nachführung einer anderen Installation und einem anderen Mandanten übergeben werden. Dabei wird der Eigentümer nicht verändert. Die Eigentümerschaft ist unabhängig von der Nachführungshoheit bzw. Datenherrschaft. Ein Mandant ist eine organisatorische Einheit. Ein Mandant ist immer genau einem Eigentümer zugeordnet. Ein Eigentümer kann die Datenbewirtschaftung nach organisatorischen Gesichtspunkten auf mehrere Mandanten aufteilen. So kann z.b. das ASTRA für jede Filiale einen Mandanten einrichten. Jedes MISTRA-Objekt ist genau einem Mandanten zugeordnet (Mandant-ID). Damit ein Benutzer Daten bearbeiten darf, muss er einer Benutzergruppe (mit Schreibrecht) dieses Mandanten angehören. Eine Benutzergruppe ist eine LDAP Gruppe von MISTRA-Benutzern. Es gibt pro Mandant eine Benutzergruppe mit Leserecht, der alle Benutzer des Mandanten angehören und verschiedene Gruppen mit Schreibrecht (Datenherrschaftsgruppen), denen die Benutzer je nach Funktion gezielt zugeordnet werden. Die Gruppierung ist statisch und bei allen MISTRA-Installationen gleich. Die Gliederung erfolgt nach n (Topics). Eine Datenherrschaftsgruppe ist genau einer Rolle zugeordnet. Eine Rolle deckt einen Aufgabenbereich, welcher mit MISTRA bearbeitet werden kann, ab. Die Gliederung erfolgt nach n (Topics). Eine Rolle definiert, welche UseCases ausgeführt werden können. Ein UseCase (deutsch Anwendungsfall) ist eine in sich abgeschlossene Funktionseinheit, welcher von einem Benutzer am System ausgeführt wird. Er wird entweder als Ganzes oder gar nicht ausgeführt. Er liefert dem Benutzer ein klar definiertes Ergebnis zurück. Ein UseCase kann mehreren Rollen zugeordnet werden. Eine Datenbank ist die Speichereinheit des BS oder FA. BS und FA verwalten ihre Daten in verschiedenen Datenbanken. Ein MISTRA-Objekt kann in mehreren Datenbanken vorliegen. Das Original eines MISTRA-Objekts darf jedoch nur in einer Datenbank vorliegen. Jedes MISTRA-Objekt enthält die Information in welcher Datenbank es als Original vorliegt (OrigDB-ID). Damit ein Benutzer Daten bearbeiten darf, muss die OrigDB-ID des Objekts mit der ID der aktuellen Datenbank übereinstimmen. Typischerweise haben BD die OrigDB-ID der SDB, SD und GD diejenige der FDB. Tabelle 1: Begriffe Weitere Begriffe sind in [1] erläutert. Seite 3

8 Allgemeines 0.5 Grundlagen [1] ASTRA, "Glossar", Version [2] ASTRA, "Geschäftsprozesse Basissystem", Version [3] ASTRA, "Datenkatalog Sockeldaten", Version [4] ASTRA, "Pflichtenheft Basissystem", Version [5] ASTRA "MISTRA - GUI Guidelines", Version 5.1 vom [6] ASTRA "LDAP Konzept Mandantenfähigkeit", Version 0.01 vom [7] ASTRA "MISTRA Basissystem Schnittstellen", Version 1.8 vom [8] ASTRA "Sockeldatenbank, Datenmodell Interlis", Modell Interlis V4.0.zip [9] "INTERLIS 2 Referenzhandbuch", bzw. download_f.php [10] KOGIS "geocat.ch: Metadatenkatalog für Geodaten", August [11] KOGIS "Metadatenmodell GM03" [12] ISB Informatikstrategieorgan Bund, I007 Basisstandards Interoperabilität [13] ISB Informatikstrategieorgan Bund, I013 Interoperabilitätsstandards für Web Services [14] Open GIS Consortium Inc. "Catalog Service Implementation Specification", Version [15] Open GIS Consortium Inc. "Simple Feature Implementation Specification", Version [16] ISO/TC211 ISO/DIS "Web Map Service (WMS) Implementation Spec.", V [17] Open GIS Consortium Inc. "Web Feature Service (WFS) Implementation Spec", V Seite 4

9 1 1.1 Abgrenzung Abbildung 1: Systemabgrenzung Abbildung 1 zeigt die MISTRA-Teilsysteme bestehend aus Basissystem und den Fachapplikationen sowie die Abgrenzung zu den Fremdapplikationen Bei den Fachapplikationen ist der Integrationsgrad mit dem BS höher als bei den Fremdapplikationen. Die Verwendung von UUIDs als Identifikation, die Datenschnittstelle INTERLIS2, die Benutzerverwaltung, die GUI-Guidelines und die Verwendung von WebServices sind festgelegt und zu verwenden. Bei den Fremdapplikationen hat MISTRA keinen Einfluss auf die Anbindung und die Kommunikation ist häufig nur in einer Richtung (FR BS) möglich. Für die Datenübernahme muss in der Regel eine Spezialschnittstelle (Konnektor) gebaut werden, welche die Daten der FR von einer Transferdatei einliest und nach einer Modelltransformation der Standard- Schnittstelle des BS zuführt. Seite 5

10 1.2 Systemarchitektur Abbildung 2: Logische Systemarchitektur (Details s. [3]) Legende: Endbenutzerarbeitsplätze / Client-Typen Komponenten BS und DWH Komponenten einer FA (stellvertretend für alle FA) Komponenten Internet-Infrastruktur (Realisierung noch nicht festgelegt) Kommunikationswege Datenfluss zwingend vorgesehen Datenfluss je nach FA zusätzlich vorgesehen Seite 6

11 Abbildung 2 zeigt die wesentlichen Komponenten des Systems MISTRA in einer 3-Schicht- Architektur. Links in der Produktionsumgebung die FA mit Fach-Client, Applikationsserver, DataAccess und Fachdatenbank. Jede FA verwaltet die Daten mit einer eigenen Datenablage (FDB). Sie liefert Fachdaten als Extrakt oder Aggregation an das Basissystem (GD). Bei Bedarf bezieht sie BD oder GD anderer FA oder FR über die Datenschnittstelle (online oder offline) oder als WebMap-Service. Die Online-Anbindung an das BS erfolgt über die mittlere Schicht. In der Mitte der Produktionsumgebung das Basissystem bestehend aus GIS-Client, BS- Business-Server, DataAccess-Server und SDB. Das BS ist für die Bewirtschaftung der BD zuständig und dient als Plattform für den Austausch von GD zwischen den FA. FA kommunizieren nie direkt untereinander. Es stellt den FA die BD und GD anderer FA zur Verfügung. Das BS ist eine GIS-Anwendung auf der Grundlage der GIS-Software Arc- GIS 9.x von ESRI. In der Produktionsumgebung rechts das Data Warehouse für das Reporting mit Web- Client, dem BI-Server du den Data Marts. Das DWH bezieht seine Daten soweit möglich aus der SDB und, für sehr detaillierte Auswertungen, zusätzlich auch aus den FA Verkehrsmonitoring und Verkehrsunfälle. Hierbei geht es primär um Reports in Form von Listen und Businessgrafiken, z.t. auch kombiniert mit Kartenausschnitten aus dem GIS des BS. Die Reports aus dem DWH können von den Anwendern abonniert und als PDF per verteilt werden. Rechts der Firewall die Internet-Infrastruktur. Sie ist primär für die Öffentlichkeit vorgesehen und umfasst einen Extrakt der Daten aus dem Basissystem. Die Daten können über Internet nur gesichtet werden. Der GIS-Teil wird von der Infrastruktur der KOGIS abgedeckt. Der Betrieb des DWH-Teils ist noch nicht festgelegt. 1.3 Basisprodukte und -technologien Dem Basissystem sind folgende Basisprodukte und technologien zu Grunde gelegt: Betriebssystem Data Tier ab Windows 2003 oder Unix/Linux Betriebssystem Application Tier ab Windows 2003 Betriebssystem Rich-Client Datenbank für Sockeldatenbank und DWH ab Windows XP ab Oracle 10g GIS ab ESRI ArcGIS-Server 9.2, ArcSDE 9.2, ArcIMS 9.2, ArcEditor 9.2 Browser ab MS Internet Explorer 6.0 ab Firefox 1.5 Büroanwendungen Reporting ab MS Office XP Entwicklungsplattform ASP.NET 2.0 Tabelle 2: Basisprodukte und Technologien Anforderungen FA: Business Objects XI R2 für Auswertungen im DWH WebiGeo von Galigeo 1 für kombinierte DWH-Reports mit Karten MS Reporting Services für OLTP-Auswertungen (auf SDB oder FDB) Es gelten die gleichen technologischen Rahmenbedingungen wie für das BS. 1 Siehe Seite 7

12 Für den Einsatz der Produktpalette von ESRI wird eine Projektlizenz abgeschlossen. Sie gilt für alle MISTRA-Installationen mit BS und allen FA schweizweit. Für die Verwendung von Business Objects, MS Reporting Services und Webigeo wird ebenfalls ein Lizenzpool für MISTRA angestrebt. Bei bestehenden Anwendungen, welche als FA für die Benutzung unter MISTRA adaptiert und nicht neu entwickelt werden, ist der Einsatz anderer Technologien mit der GPL MISTRA abzustimmen. 1.4 Deploymen-Szenarien MISTRA MISTRA kann mit BS, DWH und seinen FA auf folgende Arten installiert werden: 1. Zentral: das heisst mehrere Eigentümer betreiben gemeinsam eine zentrale Installation, bestehend aus BS und ein oder mehreren FA. 2. Dezentral: das heisst jeder Eigentümer betreibt eine eigene MISTRA-Installation oder kann im Extremfall (jedoch nicht empfohlen) sogar mehrere Installationen betreiben. Jede MISTRA-Installation muss zwingend über ein Basissystem verfügen. Die Wahl der benötigten FA ist dem jeweiligen Eigentümer überlassen. Das DWH des ASTRA kann als Ganzes oder teilweise ebenfalls eingesetzt werden. Der grosse Vorteil der zentralen Installation ist, neben den tieferen Betriebskosten, vor allem, dass der Aufwand für den Datenaustausch zwischen Eigentümern entfällt. Abbildung 3: Deployment-Szenarien Abbildung 3 zeigt drei verschiedene Deployment-Szenarien, nämlich: 1. Die Installation des ASTRA, komplett mit BS, DWH und allen FA 2. Die Installation eines Kantons mit BS, mit DWH und ausgewählten FA. Die Bewirtschaftung von BD findet extern statt. 3. Einer minimalen Installation mit nur dem BS. Diese Installation eignet sich für die Bewirtschaftung von BD. In jeder Installation muss das BS mit SDB zwingend vorhanden sein. Jede FA verwaltet die SD in einer eigenen FDB. BS und FA sind immer klar einer Installation zugeordnet. Diese Zuordnung kann nicht verändert werden. Mehrere Eigentümer können an der gleichen Installation partizipieren (vgl. Kap. 1.5) Seite 8

13 1.5 Mandantenfähigkeit MISTRA ist als mandantenfähiges 2 System konzipiert. Der Grundsatz der Mandantenfähigkeit gilt für BS und FA. Mandantenfähigkeit bedeutet, dass mehrere Strassenbehörden (Eigentümer) ihre Daten in einer gemeinsamen MISTRA-Installation bearbeiten können. Das Konzept geht in MISTRA noch einen Schritt weiter, indem jeder Eigentümer die Datenhoheit nach Organisationseinheiten gliedern kann. Diese Organisationseinheiten bilden die Mandanten 3. Die Kennzeichnung der Daten nach Eigentümer und Mandant erfolgt über Attributierung in den Datensätzen. Die Mandantenfähigkeit unterliegt folgenden Randbedingungen: 1. Die Eigentümerschaft regelt, wem der Datensatz gehört. Ein Datensatz (engl. Record) ist eindeutig einem Eigentümer (Attribut OWNER_ID) zugeordnet. Die Eigentümerschaft hat keinen Einfluss auf die Datenherrschaft. 2. Ein Eigentümer kann die Datenbewirtschaftung nach organisatorischen Gesichtspunkten auf ein oder mehrere Mandanten verteilen. Jeder Datensatz ist einem Mandanten (MANDANT_ID) zugeordnet (konzeptionelle Datenherrschaft). Die Daten eines Mandanten dürfen nur von einer Person, welche zum Mandanten gehört gepflegt werden. 3. Ein Datensatz ist eindeutig einer Datenbank (ORIGDB_ID) zugeordnet und kann nur dort bearbeitet werden (technische Datenherrschaft). Der Datensatz kann in andere Datenbanken (SDB und FDB) kopiert werden. Kopien dürfen nicht bearbeitet werden. 4. Die Sichtbarkeit der Daten wird im BS sehr offen gehandhabt. Mit Ausnahme von Kosten-, Zustands-, Projekt- und Vertragsdaten sind alle Daten für alle Mandanten einer Installation sichtbar. 5. Vorlagen für Legenden, Reports, Pläne und Achsbanddarstellungen werden von allen Mandanten einer Installation gemeinsam benutzt. 6. Bei Vorlagen für Reports, Pläne und Achsbanddarstellungen kann für jeden Eigentümer ein eigenes Logo eingefügt werden. 7. Kataloge, Selektionen, Standardreports und pläne werden gemeinsam von allen genutzt. 2 Die Mandantenfähigkeit des Basissystems wird erst mit RE2 implementiert und ist Anfang 2008 operabel. 3 Diese Aufteilung kann aus organisatorischen Gründen zweckmässig sein, weil hierdurch die Zugriffsrechte innerhalb eines Datenbestandes differenziert werden können. Im Normalfall dürfte dies jedoch nicht erforderlich sein. Seite 9

14 1.6 Benutzer- und Rechteverwaltung Abbildung 4: Übersicht Berechtigungsverwaltung BS Die Verwaltung der Benutzer und Benutzergruppen (Rollen) erfolgt über LDAP, d.h. in Win2003 in der LDAP-Implementation des Active Directory. Dabei werden nur Funktionen eingesetzt, welche dem LDAP-Standard entsprechen. Im BS werden die Gruppen periodisch in die SDB repliziert. In der SDB erfolgt die Zuordnung der Benutzergruppen zu Rollen und weiter zu den UseCases. Je nach Rolle erhalten Benutzer ein Ausführungsrecht auf die UseCases. Das BS hat die Rechteverwaltung durch die Verwendung von Rollen und Ausführungsrechten auf einzelne Anwendungsfälle (UseCases) erweitert. Hierbei handelt es sich um eine applikatorische Erweiterung im BS, ausserhalb des LDAP. Das BS stellt den FA eine Library mit Funktionen für die Abfrage der Zugehörigkeit des aktuellen Benutzers zu Mandanten und Gruppen zur Verfügung (s. [6]). Diese Funktionen sind zur Zeit gegen eine ADAM-Benutzerdatenbank entwickelt, welche ca auf ein AD umgestellt werden soll. Diese Funktionen stehen den FA zur Verfügung. Die folgende Abbildung zeigt die Struktur des BS von der Installation bis hinunter zu den U- secases: Seite 10

15 Abbildung 5: Installation, Eigentümer, Mandant, Benutzergruppe, Rolle, Funktion Bemerkungen (betreffend BS): 1. Eine Installation kann Daten eines oder mehrerer Eigentümer umfassen. Theoretisch kann ein Eigentümer Daten auf verschiedenen Installationen verteilt haben. Dies tritt u.a. dann ein, wenn Daten temporär zur Nachführung einer anderen Installation, z.b. bei einem Ingenieurbüro, übergeben werden. 2. Ein Objekt kann von einem Benutzer nur bearbeitet werden, wenn: Der Benutzer der zugehörigen Datenherrschaftsgruppe 4 angehört. Der Mandant, dem der Benutzer zugeordnet ist, mit dem Mandanten des Datensatzes übereinstimmt. Die OrigDB-ID des Datensatzes mit der Datenbank-ID der aktuellen Datenbank ü- bereinstimmt. Das Objekt nicht bereits von einem anderen Benutzer bearbeitet wird Ende Gültigkeit nicht gesetzt ist. 3. Neu eingefügte Objekte erhalten automatisch zugeordnet: Den Eigentümer, dem der Mandant zugewiesen ist. Den Mandanten, dem der Benutzer angehört. Die OrigDB-ID der aktuellen Datenbank 4. Die Gruppen mit Schreibrecht (Datenherrschaftsgruppen) werden nach den verschiedenen Datenbereichen erstellt. Die Namen dieser Gruppen beginnen mit "Oper". 4 Eine Datenherrschaftsgruppe ist eine LDAP-Benutzergruppe, welche für einen bestimmten Teil der Daten die Datenherrschaft ausübt und für die Datennachführung verantwortlich ist. Seite 11

16 5. Die Gruppenstruktur für das BS ist bei allen MISTRA-Mandanten gleich. Diese Gruppen sind: Basissystem BS Übergeordnete Rollen BS ConfurationManager BS ProblemManager BS Einfügen, ändern, löschen von Sprachen, Länder, Katalogen, Katalogeinträgen, generischen Objekttypen, Eigenschaftstypen, Eigentümer, Mandanten, Datenbanken, statische Metadaten, sonstige Konfigurationsdaten (für alle Mandanten) Rolle für Support-Aufgaben Einfügen, ändern, löschen alle Sockeldaten, alle Mandanten Mandantenspezifische Rollen BS DataManager BS Gast BS OperAreas BS OperLinearRef BS OperPlanarRef BS OperTopology BS OperLinearNets BS OperInventory BS OperProjects BS OperMaint BS OperSites BS OperTrans BS OperDocs BS Für jeden Mandanten wird der gleiche Satz von Rollen eingerichtet Import, Export, DatenChecks, Reparaturen, Überwachung Bearbeitungseinheiten, Einfügen, ändern, löschen alle Sockeldaten, Verwalten UpdateRequests Lesen, alle Sockeldaten. Einfügen Update Requests. In diese Rolle werden alle BS-Benutzer des Mandanten eingetragen. Einfügen, ändern, löschen Flächennetze Einfügen, ändern, löschen RBBS Einfügen, ändern, löschen Achsgeometrien, Kalibrierung Einfügen, ändern, löschen Knoten / Kanten / Abbiegebeziehungen sowie Daten TeleAtlas Einfügen, ändern, löschen Fachnetze Einfügen, ändern, löschen Inventarobjekte Einfügen, ändern, löschen Projektperimeter Einfügen, ändern, löschen Daten betrieblicher Unterhalt Einfügen, ändern, löschen Daten zu Baustellen Einfügen, ändern, löschen Daten zu Ausnahmetransportrouten Einfügen, ändern, löschen Dokumente Alle Personen in Oper-Gruppen werden auch hier eingetragen und können Dokumentdaten einfügen, ändern, löschen sowie zuweisen. 6. Die Beziehung der UseCases bzw. Funktionen zu den Gruppen (Rollen) wird in der Applikation gehalten. 7. Bei den Gruppen 5 bis 15, beginnend mit "Operxxx" handelt es sich um die Datenherrschaftsgruppen im BS. Die Benutzer dieser Gruppen sind für die Pflege der entsprechenden Daten zuständig. 8. Die Gruppe "User BS" hat lesenden Zugriff auf alle Daten des Mandanten. Dieser Gruppe sind alle Benutzer des Mandanten zugeordnet. Anforderungen an FA: Das Rechtekonzept des BS ist in [6] beschrieben. Für die FA gilt: 1. Die Benutzer und Benutzergruppen der FA werden gemeinsam mit dem BS über das LDAP verwaltet. 2. Die FA müssen wie unter 1.5 beschrieben mandantenfähig sein. Seite 12

17 3. Die Zuordnung von Rollen zu UseCases und der damit verbundenen Definition von Ausführungsrechten auf UseCases, ist innerhalb der FA applikatorisch zu lösen. 4. Die Datenbearbeitung muss wie im BS über eine oder mehrere Rollen aufgeteilt sein. Diese Gruppen haben schreibenden Zugriff auf die entsprechenden Daten. 5. Die Eigentümerschaft (OWNER_ID) muss verändert werden können (Administratorfunktion). 6. Die Zugehörigkeit zu einem Mandanten muss verändert werden können (Administratorfunktion). 7. Der Benutzer muss, falls er in einer oder mehreren Rollen zugeteilt ist, bei der Anmeldung die gewünschte Rolle auswählen können. Während einer Session muss er die gewünschte Rolle wechseln können. 1.7 Visitenkarte Bevor Daten zwischen verschiedenen BS oder zwischen BS und FA einer Installation oder zwischen gleichen FA verschiedener Installationen ausgetauscht werden können, müssen die sog. "Visitenkarten" übergeben werden (vgl. Handshaking). Die Visitenkarte umfasst Eigentümer-ID, Mandant-ID und Datenbank-ID. Die Identifikation erfolgt je über eine UUID. Will z.b. die Filiale 1 des ASTRA aus FA VMON Generalistendaten an das BS übertragen, müssen die Kennwerte Eigentümer-ID, Mandant-ID und Datenbank-ID im BS eingetragen (registriert) werden. Die erfolgt durch die Übertragung der Visitenkarten. Der Austausch erfolgt mit einer Interlis-Datei. 1.8 Datenbankaspekte Datenhaltung Die Datenhaltung zwischen BS und FA muss in Bezug auf Datenspeicherung getrennt sein. Es gelten die folgenden Grundsätze: Das BS verhält sich gegenüber den FA immer passiv und greift nie in die Datenbank der FA ein. Die FA holen BD und die GD anderer FA und legen ihre GD in die SDB ab. Der Zugriff auf die SDB erfolgt ausschliesslich offline über Transferdateien oder online über die WebServices des BS. Ein Direktzugriff der FA in die SDB ist nicht erlaubt. Die FA halten keine Schemata oder Tabellen in der SDB. Es dürfen keine Fremdschlüsselbeziehungen zwischen den DB der FA und SDB angelegt werden und umgekehrt. Das BS verwendet als Datenbank-Produkt Oracle. Dieses kann von den FA mitgenutzt werden. Dabei ist jedoch auf eine klare Trennung gemäss oben stehenden Grundsätzen und nachstehender Grafik zu achten. Seite 13

18 Abbildung 6: Verwendung von Oracle-Datenbanken Anforderungen an FA betr. UUID: Als technischen Datenbankschlüssel (Primärschlüssel) für SD muss in den FA eine UUID bzw. unter Windows eine GUID verwendet werden. Dieser Schlüssel kann direkt durch einen Systemaufruf in der FA (setzt Vorhandensein einer Netzwerkkarte im Host voraus) bezogen werden. Für Fremdschlüsselbeziehungen ist diese UUID zu verwenden. Die UUID eines Objekts darf nie verändert werden. Nach Löschung eines Objekts darf dessen UUID nicht wieder verwendet werden. Beim Import von BD und GD durch eine FA muss diese die UUID ebenfalls importieren Verwendung der BD Die BD sind in [2] detailliert beschrieben. Die BD sind von den FA zwingend zu verwenden. Dies gilt insbesondere für Beteiligte, Flächennetze, Inventarobjekte, Raumbezug RBBS, Geometrie und Fachnetze. Bei den Flächen- und Fachnetzen kann die Datenhoheit je nach Subtyp beim BS oder auch bei einer FA liegen (z.b. Verkehrsabschnitte, Unfallabschnitte) welche bei Bedarf von der FA in das BS abgespeichert werden. Solche Fachnetze sollen von den Anwendern der FA im BS erstellt werden. Die BD können von den FA auf verschiedene Art vom BS bezogen werden: Durch den Import und die Speicherung einer Kopie in der DB der FA. Die Kopie kann entweder online über einen Web-Service oder offline über einen Filetransfer bezogen werden. Durch temporäre Verwendung online über einen WebService ohne Speicherung einer Kopie, z.b. für die Berechnung eines RBBS-Bezuges. In einer GIS-gestützten FA durch den Bezug als WebMap-Service im WebGIS- oder RichGIS-Client. Hierbei wird keine Kopie in der DB der FA abgelegt. Die BD sind historisiert. Damit die Raum-/Zeit-Konsistenz der Fachdaten in der FA sichergestellt ist, muss das Bezugsdatum der BD in der DB der FA geführt werden. Dies kann z.b. geschehen, indem zu jeder Referenz in den SD auf BD deren Bezugsdatum als Attribut gespeichert wird. Seite 14

19 Beim Bezug einer neuen Version von BD muss die FA dafür besorgt sein, dass die Bezüge aus den SD auf die BD angepasst werden. Ändert beispielsweise die Linienführung einer Achse, müssen die Bezüge auf die Achse überprüft und ggf. angepasst werden. Das BS stellt für die Aktualisierung des RBBS-Bezuges einen WebService zur Verfügung (vgl. 2). Mutationen der BD können von den FA den Metadaten entnommen werden. Es gilt das Holprinzip. Es gibt vom BS keine explizite Benachrichtigung Erzeugung der GD Aus dem Bedarf anderer Fachbereiche ergibt sich, welche GD von der FA an das BS abgegeben werden müssen. GD können ein Extrakt oder eine Aggregation von SD sein. Aggregationen bzw. statistische Aufbereitungen müssen, wenn immer möglich, FA-seitig vor oder beim Export gemacht werden (fachliche Verantwortung). Voraussetzung ist, dass das BS die Aggregations-Anforderungen z.hd. der FA definiert. Damit beim Ablegen von GD in das BS der Bezug zu BD zeitlich konsistent behandelt wird, muss das Bezugsdatum der BD, auf welche sich die GD beziehen von der FA dem BS zurückgegeben werden. Die eventuell erforderliche Umrechnung auf aktuellere BD erfolgt durch das BS beim Import der GD Dokumente Die Grundversion von MISTRA benutzt zur Ablage von Dokumenten das Filesystem 5. Die Dokumentendaten (Dokument-Metadaten gemäss [2]) werden in der Objektklasse Dokument im BS bewirtschaftet und können von den FA über die Standard-Schnittstelle (online oder offline) bezogen werden (vgl. Fehler! Verweisquelle konnte nicht gefunden werden.). Es ist den FA freigestellt selber Dokumente zu verwalten, wenn dies ein dringendes Bedürfnis darstellt. Sollten diese Dokumente von den GD referenziert werden, müssen die Dokumentendaten zwingend über die Standard-Schnittstelle von der FDB in die SDB abgeglichen werden. Das BS und die FA haben auf Dokumente sowohl lesenden, als auch schreibenden Zugriff. Dokumente, welche in BS oder FA erzeugt werden, können im Filesystem gespeichert werden. Dabei werden das Dokument selbst und die Dokumentendaten abgelegt. Die ASTRA-Version MISTRA benötigt eine Schnittstelle zum DMS GEVER von Fabasoft. Z.Zt. wird abgeklärt inwiefern der Austausch von Dokumenten und Dokumentdaten mit dem BS und den FA über WebServices von Fabasoft gelöst werden kann. Erst nach Abschluss dieser Abklärungen wird die Schnittstelle MISTRA <> GEVER spezifiziert Beteiligte Das BS enthält keine Funktionalität zur Bewirtschaftungen von Beteiligten (keine Adressverwaltung). In der Grundversion des BS werden die Beteiligten aus der Exchange/Outlook- Datenbank bezogen. Beteiligte werden im BS vorgehalten und können von den FA zwecks Referenzierung durch die SD bezogen werden. Die Schnittstelle zur Beteiligtendatenbank Outlook deckt das BS ab. BS und FA haben auf Beteiligte ausschliesslich lesenden Zugriff. Fehlt ein Beteiligter in der FA und im BS, muss er in der Beteiligtendatenbank erfasst und von dort in das BS eingespielt werden. 5 Seite 15

20 Die ASTRA-Version MISTRA benötigt eine Schnittstelle zum DMS GEVER von Fabasoft. Z.Zt. wird abgeklärt inwiefern der Austausch von Adressen mit dem BS und den FA über WebServices von Fabasoft gelöst werden kann. Erst nach Abschluss dieser Abklärungen wird die Schnittstelle MISTRA <> GEVER spezifiziert. 1.9 Kommunikation FA <> BS Grundsätzlich gibt es für die FA zwei Möglichkeiten mit dem BS zu kommunizieren: 1. Online über WS: Die FA greift über eine LAN-Netzwerkverbindung oder über eine Fernverbindung auf das BS zu. Auf diese Art kann die FA die vom BS angebotenen WebServices nutzen und auch WebMap-Services beziehen (siehe [7]). 2. Über die Offline-Schnittstelle Der Datenaustausch findet mittels Filetransfer statt. Kommunikation online Fachapplikation BS-Interface Kommunikation offline Fachapplikation Import/Export-Modul Interlis2 Transfer-Datei Service-Interface Basissystem Import/Export-Modul Basissystem Abbildung 7: Varianten Anbindung online / offline Der geregelte Datenaustausch findet entsprechend Kap und offline statt. Davon betroffen sind der Import von BD durch die FA sowie der Export von GD von der FA zu Handen des BS. Der Kommunikation online ist für die Nutzung der WebServices des BS vorgesehen. Weitere Details sind in [3] und in [7] enthalten. Seite 16

21 1.10 Datenaustausch BS FA Allgemeine Festlegungen Die Standardschnittstelle von MISTRA basiert auf INTERLIS2. Für den Datenaustausch zwischen FA und BS gilt für beide Übertragungsrichtungen die Modellbeschreibung für das Basissystem (siehe [7] und [8]). Der Datenaustausch über die Standardschnittstelle muss inkrementell möglich sein. Jede FA und FR mit der das BS Daten austauschen möchte, muss im BS durch den Eintrag der DB- ID registriert sein (siehe 1.10). Bei der Registrierung wird für diese FA je ein Import- und Exportverzeichnis auf dem File-Server eingerichtet. Exporte von BD und GD aus dem BS werden automatisch in das Exportverzeichnis abgelegt. Die Exporte können durch Konfiguration eines Exportjobs im BS und Verwendung des Schedulers von Windows automatisiert werden. Der Import in das BS wird über ein Polling auf dem Importverzeichnis gestartet. Das Zeitintervall für das Polling ist konfigurierbar. Der Datentransfer kann entweder für mehrere Objekte gleichzeitig oder für Einzelobjekte, z.b. nach jeder Mutation, gemacht werden. Das BS importiert Daten über eine Importzone der SDB, in welcher Daten zur Prüfung temporär zwischengespeichert werden. Erst nach erfolgter Prüfung und Freigabe durch den Datenmanager werden die Daten definitiv in die SDB übernommen. Seite 17

22 Struktur der Transferverzeichnisse: Verzeichnisse Gruppen Bemerkungen Root Level Mandant Level Applikation Level Transferverz. Level Daten DataManager ASTRA DataManager BS ASTRA DataManager DWH ASTRA DataManager FA VU ASTRA UseCase MISTRA-APP v r r r ASTRA v r r r BS v r r Zugriff GS via Internet, andere BS via Internet Doc v v Wird von der Applikation weiter unterteilt ExportSD v r In v v BS: Export Sockeldaten an andere BS Out v v BS: Ablage Logfile nach Abschluss Export ImportSD v r In v v BS: Ablage Sockeldaten von anderen BS Out v v BS: Ablage Logfile nach Abschluss Export Save v v BS: Sicherungskopie nach Abschluss Import ExportDWH v r r In v v rd BS: ETL Sockeldaten an DWH Out v v rd BS: Ablage Logfile nach Abschluss Export FA VU v r r r Zugriff ASTRA via KOMBV, GS via Internet Doc v v Wird von der Applikation weiter unterteilt ExportSD v r r In v v rd BS: Export Sockeldaten aus BS FA: Import Sockeldaten Out v v v BS: Ablage Logfile nach Abschluss Export FA: Ablage Logfile nach Abschluss Import Save v r v FA: Sicherungskopie nach Abschluss Import ImportGD v r r In v rd v FA: Export Generalistendaten aus FA BS: Import Generalistendaten Out v v r BS: Ablage Logfile nach Abschluss Import Save v v r BS: Sicherungskopie nach Abschluss Import ExportDWH v r r In v rd v FA: ETL Spezialistendaten an DWH ExportSpez v r In v v FA: Export Spezialistendaten für andere FA VU Out v v FA: Ablage Logfile nach Abschluss Export ImportSpez v r In v v FA: Ablage Transferdateien von anderen FA VU Out v v FA: Ablage Logfile nach Abschluss Import Save v v FA: Sicherungskopie nach Abschluss Import Mandant2 noch nicht anlegen usw. noch nicht anlegen usw. noch nicht anlegen Zugriffsrechte: r = read; w = write; d = delete; v = vollzugriff Tabelle 3: Verzeichnisstruktur Seite 18

23 Namenskonvention der Dateien: Transferdateien vor dem Import: Dateiname: [ZeitstempelSender]_[Interlis-Schemaname].xtf ZeitstempelSender im Format yyyymmtthhmmss, z.b Der ZeitstempelSender steuert die Reihenfolge der Abarbeitung Interlis-Schema z.b. MbsAccident, MbsAuthorisation etc. Beispiel Dateiname: _MbsAccident.xtf Logdatei des Senders nach dem Export: Dateiname: [ZeitstempelSender]_[Interlis-Schemaname].log ZeitstempelSender im Format yyyymmtthhmmss, z.b Der ZeitstempelSender stimmt mit dem Zeitstempel der Transferdatei überein. Interlis-Schema z.b. MbsAccident, MbsAuthorisation etc. Beispiel Dateiname: _MbsAccident.log Transferdatei nach dem Import im Save-Verzeichnis: Dateiname: [ZeitstempelSender]_[Interlis-Schemaname]_[ZeitstempelEmpfänger].xtf ZeitstempelEmpfänger im Format yyyymmtthhmmssnnnn, z.b Der ZeitstempelEmpfänger zeigt den Start des Imports durch den Empfänger Beispiel Dateiname: _MbsAccident_ xtf Logdatei des Empfängers nach dem Import: Dateiname: [ZeitstempelSender]_[Interlis-Schemaname]_[ZeitstempelEmpfänger].log ZeitstempelEmpfänger im Format yyyymmtthhmmssnnnn, z.b Der ZeitstempelEmpfänger stimmt mit dem Zeitstempel der Transferdatei überein. Beispiel Dateiname: _MbsAccident_ log Seite 19

24 Datenaustausch BS FA offline Abbildung 8: Datenaustausch BS FA offline Bemerkungen: 1. Definitionsphase: Bevor der erste Datenaustausch gestartet werden kann, müssen die Visitenkarten ausgetauscht und es muss zwischen BS und FA eine Transferdefinition festgelegt werden. Hierbei wird festgelegt: Umfang der auszutauschenden Daten (Interlis-Topics). Die Beschreibung des Dateninhalts wird in der Modellbeschreibungsdatei von Interlis2 (.ili) festgelegt (siehe [7] und [8]). Auswahl ob voller oder inkrementeller Datenaustausch. Festlegung des Verzeichnisses, in welchem die Transferdatei abgelegt wird. Bezeichnung der Transferdatei. Startdatum und Periodizität des inkrementellen Datenaustauschs. 2. Der Datenexport aus der SDB wird über den Job.Scheduler automatisch ausgelöst. 3. Die FA stellt über ein Polling auf dem Exportverzeichnis fest, ob eine Transferdatei (.xtf) vorliegt und importiert die Daten. 4. Nach einem erfolgreichen Import wird die Transferdatei von der FA in ein Archiv- Verzeichnis verschoben und es wird eine Log-Datei des Imports abgelegt. 5. Konnte der Import nicht erfolgreich stattfinden oder liegen Fehler im Datenbestand der FA vor, muss der Transfer entweder wiederholt werden oder es kann ein einmaliger Zwischentransfer definiert und ausgelöst werden. Als Bezugsdatum wird in der Regel das Datum des letzten erfolgreichen Inkrements eingegeben. Im Extremfall wird der Bestand an BD durch einen vollen Datenaustausch ersetzt. 6. Ein nicht erfolgreicher Import muss von der FA rückgängig gemacht werden können. 7. Anschliessend läuft der inkrementelle Austausch wieder normal ab. Seite 20

25 Der Austausch BS > FA als Sequenzdiagramme: sd BS: BS>FA Transfer definieren Data Manager FA Anforderungen DataManager BS BS>FA Transfer Agreement BS Configure Export BS>FA Export Parameter (from FA Import Interlis) (from BP4: Export Service) Scheduler BS Definition Done Done Export konfigurieren Speichern Done Scheduler einstellen Done (from FA Use (from Cases) Integration Processes) (from Integration Processes) Abbildung 9: Sequenzdiagramm Transferdefinition BS > FA sd BS: BS>FA Transfer exportieren Scheduler BS Start Exporter BS BS Export Interlis (from BP4: Export Service) BS DB Reader BS File Writer BS Interlis Checker File Server MISTRA ok Start Hole Daten Schreibe Daten Interlis-Check ablegen ok Logfile ablegen ok (from Integration (from Processes) BP4: Export Service) Abbildung 10: Sequenzdiagramm Export BD / GD durch BS 6 6 Orange = BS; Grün = FA; Blau = Filesystem Seite 21

26 sd FA: BS>FA Transfer importieren Import Interlis FA File Serv er MISTRA Importer FA (from FA Import Interlis) FA File Reader Check Transfer Dateien FA Interlis Checker FA DB Writer Dateien vorhanden Import starten Lese Katalogdaten BS Lesen Liefern Interlis-Check Katalogdaten BS Schreibe Katalogdaten BS Lese Objektdaten Lesen Liefern Interlis-Check Objektdaten BS Schreibe Objektdaten BS in DB FA Dateien verschieben Logfile ablegen Done (from FA Import Interlis) Abbildung 11: Sequenzdiagramm Import BD / GD durch FA 7 7 Orange = BS; Grün = FA; Blau = Filesystem Seite 22

27 Datenaustausch FA BS offline Abbildung 12: Datenaustausch FA BS offline Bemerkungen: 1. Definitionsphase: Bevor der erste Datenaustausch gestartet werden kann, müssen die Visitenkarten ausgetauscht und es muss zwischen FA und BS eine Transferdefinition festgelegt werden. Hierbei wird festgelegt: Umfang der auszutauschenden Daten (Interlis-Topics). Die Beschreibung des Dateninhalts wird in der Modellbeschreibungsdatei von Interlis2 (.ili) festgelegt (siehe [7] und [8]). Auswahl ob voller oder inkrementeller Datenaustausch. Festlegung des Verzeichnisses, in welchem die Transferdatei abgelegt wird. Bezeichnung der Transferdatei. Startdatum und Periodizität des inkrementellen Datenaustauschs. 2. Der Datenexport aus der FDB wird über den Job.Scheduler automatisch ausgelöst. Die Export-Dateien werden in das definierte Exportverzeichnis abgelegt. 3. Die BS stellt über ein Polling auf dem Importverzeichnis fest, ob eine Transferdatei (.xtf) vorliegt und importiert die Daten. 4. Nach einem erfolgreichen Import wird die Transferdatei von der FA in ein Archiv- Verzeichnis verschoben und es wird eine Log-Datei des Imports abgelegt. 5. Konnte der Import nicht erfolgreich stattfinden oder liegen Fehler im Datenbestand der BS vor, wird der Import durch das BS wiederholt oder kann ein einmaliger Zwischentransfer definiert und ausgelöst werden. Als Bezugsdatum wird in der Regel das Datum des letzten erfolgreichen Inkrements eingegeben. Im Extremfall wird der Bestand an GD durch einen vollen Datenaustausch ersetzt. 6. Anschliessend läuft der inkrementelle Austausch wieder normal ab. Seite 23