MISTRA Managementinformationssystem Strasse und Strassenverkehr. Systemarchitektur Gesamtsystem

Transkript

1 Eidgenössisches Departement für Umwelt, Verkehr, Energie und Kommunikation UVEK Bundesamt für Strassen ASTRA E. Bernard, InfoLite AG, Version 1.0 vom Doku Code: BCI ST MISTRA Managementinformationssystem Strasse und Strassenverkehr Systemarchitektur Gesamtsystem D:\Daten\Aufträge\MISTRA\Teilprojekte\Gesamtarchitektur\B MISTRA SAD V1.0.doc

2 Impressum Impressum Erstelldatum: 4. September 2007 Letzte Änderung: 30. Juni 2008 Projektleiter: Emile Bernard, InfoLite AG Assistenz: Verzeichnis/Datei: b mistra sad v1.0.doc Seitenanzahl gesamt inkl. Deckblatt 60 und Inhaltsverzeichnis: Dokumentenverwaltung Version Datum Autor Bemerkungen EB Entwurf EB Ergänzungen nach Sitzung mit GPL b mistra sad v1.0.doc Seite I

3 Inhaltsverzeichnis Inhaltsverzeichnis Seite 0 Allgemeines Zweck des Dokuments Abkürzungen Begriffe Anhänge zum SAD Mitgeltende Dokumente Weitere wichtige Dokumente 3 1 Ziele und Rahmenbedingungen 5 2 Grundsätze der Architektur MISTRA Modulares Konzept Gemeinsame Nutzung von Teilsystemen Gemeinsame Nutzung von Basis- und Generalistendaten Integration Fachapplikationen FA Integration Fremdapplikationen FR Integration Teilsysteme Dritter (Fertigprodukte) Neuentwicklungen als 3-Tier-Architektur 7 3 Systemarchitektur Logische Systemarchitektur: Gesamtsicht Logische Systemarchitektur: Sicht einer FA Physische Systemarchitektur (Deployment-Sicht) Deployment-Szenarien MISTRA Basisprodukte und -technologien Kommunikation FA <> BS 18 4 Service-Interfaces Geodienste Bund + AV-Geodatenportal LDAP-Services WebMap-Services BS WebFeature-Services BS WebServices des BS 22 5 Datenaustausch INTERLIS Allgemeine Festlegungen Transferverzeichnisse Datenaustausch BS FA offline Datenaustausch FA BS offline Referenzen auf BD und GD Referenzen auf Katalogeinträge 37 6 Weitere Themen Mandantenfähigkeit Benutzer- und Rechteverwaltung Visitenkarte Verwendung der BD Erzeugung der GD Datenaustausch zwischen verschiedenen Installationen Datenaustausch zwischen Mandanten einer Installation Identifikation UUID Dokumente 46 Version 1.0, Seite I

4 Inhaltsverzeichnis 6.10 Beteiligte Generische Objektklassen und Subtypen Metadaten Historisierungskonzept des BS GUI Mehrsprachigkeit Reporting (DWH) 51 7 Namenskonventionen Datenbank-Objekte GIS-Objekte 55 Abbildungen Seite Abbildung 1: Übersicht Dokumentation MISTRA 1 Abbildung 2: Logische Systemarchitektur in UML2 8 Abbildung 3: Überblick WebServices 12 Abbildung 4: Überblick INTERLIS-Schnittstelle 12 Abbildung 5: Physische Systemarchitektur (Deployment-Sicht) in UML2 13 Abbildung 6: Deployment-Szenarien 16 Abbildung 7: Varianten Anbindung online / offline 18 Abbildung 8: Schnittstelle zu Geodiensten KOGIS 19 Abbildung 9: Klassen im LDAP-Modell 20 Abbildung 10: Exemplarische LOG-Datei (Import) 29 Abbildung 11: Datenaustausch BS FA offline 30 Abbildung 12: Sequenzdiagramm Transferdefinition BS > FA 31 Abbildung 13: Sequenzdiagramm Export BD / GD durch BS 31 Abbildung 14: Sequenzdiagramm Import BD / GD durch FA 32 Abbildung 15: Datenaustausch FA BS offline 33 Abbildung 16: Sequenzdiagramm Transferdefinition FA > BS 34 Abbildung 17: Sequenzdiagramm Export BD / GD durch FA 34 Abbildung 18: Sequenzdiagramm Import GD durch BS 35 Abbildung 19: Klassendiagramm Katalog im BS 37 Abbildung 20: Verzeichnisbaum LDAP MISTRA (aus [6]) 41 Abbildung 21: Installation, Eigentümer, Mandant, LDAP-Rolle, Rolle, Funktion 42 Abbildung 22: Datenaustausch zwischen verschiedenen MISTRA Installationen 45 Abbildung 23: Datenmodell Metadaten in SDB 48 Abbildung 24: Historisierungskonzept BS (am Bespiel der Inventarobjekte) 49 Tabellen Tabelle 1: Begriffe 2 Tabelle 2: Basisprodukte und Technologien 17 Tabelle 3: LDAP Service GetUserForRole 20 Tabelle 4: LDAP Service GetUserForMandator 20 Tabelle 5: LDAP Service GetRole 21 Tabelle 6: LDAP Service GetRoleMandator 21 Tabelle 7: LDAP Service GetMandator 21 Tabelle 8: LDAP Service GetMandatorV2 21 Tabelle 9: LDAP Service GetUserInfo 21 Tabelle 10: LDAP Service GetAssemblyInfo 21 Tabelle 11: Liste der MapServices BS 22 Tabelle 12: BS Service GetAxes 22 Tabelle 13: BS Service TransformXyToRbbs 23 Version 1.0, Seite II

5 Inhaltsverzeichnis Tabelle 14: BS Service TransformRbbsToXy 23 Tabelle 15: BS Service KilometerToRbbs 23 Tabelle 16: BS Service TransformRbbsToKilometer 23 Tabelle 17: BS Services für Flächenverschnitt 24 Tabelle 18: BS Service Flächenaggregationen 24 Tabelle 19: BS Service Fachnetzverschnitt 24 Tabelle 20: BS Service Fachnetzaggregation 25 Tabelle 21: BS Service Fachnetzverschnitt 25 Tabelle 22: BS Service Abfrage von Metadaten 25 Tabelle 23: BS Service Aktualisierung RBBS 25 Tabelle 24: Verzeichnisstruktur Transferverzeichnisse BS (Details s. [3]) 27 Tabelle 25: Verzeichnisstruktur Transferverzeichnisse VMON (Details s. [3]) 28 Tabelle 26: Überblick Rollen BS (siehe auch [3]) 43 Version 1.0, Seite III

6 Allgemeines 0 Allgemeines 0.1 Zweck des Dokuments Dieses Dokument beschreibt die übergeordnete Systemarchitektur SAD des Gesamtsystems MISTRA. Sie gilt als Grundlage für alle Applikationen, welche im Umfeld von MISTRA entwickelt werden. Die Positionierung des SAD innerhalb der gesamten Dokumentation MISTRA ist in der nachfolgenden Abbildung durch die strichlierte Linie dargestellt. Abbildung 1: Übersicht Dokumentation MISTRA Das SAD dient als Grundlage für das Zusammenwirken der Fachapplikationen mit dem Basissystem und ergänzt diejenigen Dokumente, welche spezifisch für die Realisierung der einzelnen Fachapplikation erstellt wurden (Pflichtenheft, Konzept, Datenmodell usw.). Das SAD ist ein für die FA verbindliches Dokument. Widersprüche zwischen dem SAD, der übrigen übergeordneten Dokumentation sowie der Dokumentation der FA müssen mit der GPL bereinigt werden. Dieses Dokument löst das bisherige Dokument "Anforderungen an Fachapplikationen bezüglich dem Zusammenwirken mit dem Basissystem", Version 2.4 ab. 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 GPL = Gesamtprojektleitung MISTRA Version 1.0, Seite 1

7 Allgemeines GD = Generalistendaten SAD = Systemarchitekturdokument SD = Spezialistendaten SDB = Sockeldatenbank Weitere Abkürzungen sind in [4] erläutert. 0.3 Begriffe Installation Eigentümer (Owner) Mandant Benutzergruppe LDAP Rolle UseCase (Funktion) Datenbank Umfasst alle Hardware-, Datenbank- und Software-Komponenten einer MISTRA-Installation. BS, DWH und alle in der Installation benötigten FA sind die Bestandteile einer Installation. 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 Gruppe von MISTRA-Benutzern, die einer LDAP Rolle zugewiesen sind. 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 und Mandanten gleich. Die Gliederung erfolgt nach Themenbereichen (Topics). Eine Datenherrschaftsgruppe ist genau einer LDAP Rolle zugeordnet (1:1-Beziehung). Eine LDAP Rolle deckt einen Aufgabenbereich, welcher mit MISTRA bearbeitet werden kann, ab. Die Gliederung erfolgt nach Themenbereichen (Topics). Eine Rolle definiert, welche Funktionen einer Applikation (UseCases) ausgeführt werden dürfen und somit implizit auch die Zugriffsrechte auf die entsprechenden Daten. 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 eigenen 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 [4] erläutert. Version 1.0, Seite 2

8 Allgemeines 0.4 Anhänge zum SAD [1] "MISTRA Basissystem Schnittstellen", Version 2.3 MISTRA Extranet: BCI Business Collab Infrastructure/ABS Components/Gesamtsystemarchitektur NB: Diese Dokument wird in Kürze aufgeteilt in je ein Dokument für WebServices und INTERLIS. [2] "MISTRA Gruppen, Rollen, Rechte, Verzeichnisse" Version 5.2 T_MISTRA_RollenRechteVerz_V5.2.xls MISTRA Extranet: BCI Business Collab Infrastructure/ABS Components/LDAP/Rollen-Rechte-Transfer [3] "MISTRA Interlis-Modell" MISTRA Extranet: BCI Business Collab Infrastructure/ABS Components/Interlis Modelle 0.5 Mitgeltende Dokumente [4] "MISTRA Gesamtsystem Vision und Ziele", Version 1.7, M Gesamtsystem /... [5] "MISTRA Glossar", Version [6] "LDAP Infrastruktur MISTRA", Version 0.08, BCI Business Collab Infrastructure/ABS Components/LDAP/LDAP Services [7] ISB Informatikstrategieorgan Bund, I007 Basisstandards Interoperabilität [8] ISB Informatikstrategieorgan Bund, I013 Interoperabilitätsstandards für Web Services [9] "Corporate Design Bundesverwaltung" [10] "MISTRA Datenkatalog Sockeldaten", Version [11] "MISTRA - GUI Guidelines", Version 5.1 MISTRA Extranet: BCI Business Collab Infrastructure/ABS Components/Guidelines GUI [12] "MISTRA Dokumentations-Guidelines" MISTRA Extranet: BCI Business Collab Infrastructure/ST Standards/Guideline User-Dokumentation [13] "MISTRA Namenskonventionen" MISTRA Extranet: BCI Business Collab Infrastructure/ABS Components/Naming Conventions (URL) [14] "MISTRA Dokumentation HelpDesk ", Version MISTRA Extranet: BCI Business Collab Infrastructure/ABS Components/BE Betrieb/HelpDesk 0.6 Weitere wichtige Dokumente [15] ASTRA, "Geschäftsprozesse Basissystem", Version 6.0 MISTRA Extranet: GP Geschäftsprozesse/ GP Geschäftsprozesse /Basissystem [16] ASTRA, "Pflichtenheft Basissystem", Version 4.1 MISTRA Extranet: BS Basissystem/RE-1/RE Realisierung/Anforderungen [17] "INTERLIS 2 Referenzhandbuch", bzw. download_f.php [18] KOGIS "ech-0056 Anwendungsprofil Geodienste" [19] KOGIS "geocat.ch: Metadatenkatalog für Geodaten", August [20] KOGIS "Metadatenmodell GM03" [21] Open GIS Consortium Inc. "Catalog Service Implementation Specification", Version 2.0 Version 1.0, Seite 3

9 Allgemeines [22] Open GIS Consortium Inc. "Simple Feature Implementation Specification", Version [23] ISO/TC211 ISO/DIS "Web Map Service (WMS) Implementation Spec.", V [24] Open GIS Consortium Inc. "Web Feature Service (WFS) Implementation Spec", V Version 1.0, Seite 4

10 Ziele und Rahmenbedingungen 1 Ziele und Rahmenbedingungen Die Visionen, Ziele und Rahmenbedingungen sind in [4] beschrieben. Version 1.0, Seite 5

11 Grundsätze der Architektur MISTRA 2 Grundsätze der Architektur MISTRA 2.1 Modulares Konzept MISTRA ist ein Gesamtsystem lose gekoppelter Teilsysteme. BS, DWH 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 von der FA über die Offline-Interlis-Schnittstelle bezogen. Beispiele solcher FA sind VMON, KUBA und LVS. 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. Beispiele sind FN und VU. Beim Zusammenwirken mit dem DWH dient das BS als Datenlieferant von BD und GD. In einzelnen Fällen werden auch SD von den FA an das DWH übergeben (VMON, VU). Die Daten werden dem DWH mittels Filetransfer übergeben. 2.2 Gemeinsame Nutzung von Teilsystemen Die Teilsysteme Benutzerverwaltung / LDAP, Datenbanksystem, GIS und DWH sollen von allen Teilsystemen gemeinsam genutzt werden. 2.3 Gemeinsame Nutzung von Basis- und Generalistendaten Das BS bewirtschaftet die BD, welche von allen Teilsystemen gemeinsam genutzt werden können. Die BD werden im BS gepflegt. Die FA bewirtschaften die SD. Jede FA hat ihre eigenen SD. Sie stellt diese den anderen FA als GD über das BS, auch Sockeldatenbank genannt, zur Verfügung. Die GD beinhalten i.d.r. einen Extrakt oder eine speziell aufbereitete, verdichtete Form von SD (siehe auch [10]). Eine FA kann somit auf die GD einer anderen FA via BS zugreifen. 2.4 Integration Fachapplikationen FA FA berücksichtigen die folgenden Aspekte: Authentisierung und Autorisierung im gemeinsam genutzten LDAP Mandantenfähiges System Nutzung von BD und GD über die WebServices des BS Datenaustausch mit dem BS über die INTERLIS-Schnittstelle Nutzung Geodienste Bund für Kartenmaterial (Landeskarten, Vector25, Orthofotos) Benutzerschnittstelle nach dem festgelegten GUI-Konzept (siehe [11]) Einhaltung der Naming Conventions gemäss [13] 2.5 Integration Fremdapplikationen FR Daten von FR werden über Import- / Exportschnittstellen integriert. Version 1.0, Seite 6

12 Grundsätze der Architektur MISTRA 2.6 Integration Teilsysteme Dritter (Fertigprodukte) Mit MISTRA sollen bewährte Fertigprodukte als FA oder FR genutzt werden können. Auch einzelne Komponenten können als Fertigprodukte in FA integriert genutzt werden. 2.7 Neuentwicklungen als 3-Tier-Architektur Die FA 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. Version 1.0, Seite 7

13 Systemarchitektur 3 Systemarchitektur 3.1 Logische Systemarchitektur: Gesamtsicht cmp Logische Systemarchitektur Component Diagram Perimeter MISTRA DWH ASTRA DateMarts FFR ETL ETL FABER VMON ETL WebiGeo MOFIS ADMAS Filetransfer FFR VU ETL Interlis Geod ata TDCost B S FN Interlis ETL Basissystem CSV Outlook / Exchange GEWI / TIC B S KUBA Interlis Interlis BS WebServices B S MultiNet SAP Filetransfer SA P LVS Interlis B S VM UVEK EMSG Interlis B S VM-CH GEVER Fabasoft LV Interlis Appl. Portal SBW Internet/Extranet HelpDesk Legende Applikation LD AP Services Change Mgmt Serv ice Interface Fi le Interface Geodienste Bund AV Geodatenportal Service Zugriff Interlis ETL Abbildung 2: Logische Systemarchitektur in UML2 Version 1.0, Seite 8

14 Systemarchitektur Beschreibung der Komponenten: Applikationsportal MISTRA AV Geodatenportal Bund Basissystem BS Change Mgmt DWH ASTRA EMSG FFR FN Statische Webseite, von welcher aus die einzelnen Rich- und Web- Anwendungen gestartet werden können. WebServer der swisstopo, welcher die Daten aus der amtlichen Vermessung bereitstellt. Verwaltung von Basisdaten (Raumbezug, Flächennetze, Fachnetze, Inventarobjekte, Administrative Daten etc. siehe [10]). Das BS ist die zentrale Kommunikationsplattform in MISTRA. Es stellt den FA WebServices für den Bezug von Basisdaten, für Koordinatentransformationen und Auswertungen zur Verfügung. Über die Interlis- File-Schnittstelle können BD und GD ausgetauscht werden. Module: 1. WebClient-Anwendung für Datensichtung und Verwaltung von Sachdaten, für Reporting, Planerstellung, Datenexport und Achsbanddarstellungen. 2. RichClient-Anwendung für die Verwaltung der grafischen Daten zum Raumbezug, zu Inventarobjekten, Fach- und Flächennetzen sowie für Planerstellung. 3. Importer für den Datenbezug aus FA und anderen BS. Technische Basis: 3-Tier-Anwendung,.NET, GIS-Server ArcGIS 9.2, Datenbank Oracle 10g Koordination, Erfassung, Verarbeitung und Nachverfolgung von Problem- und Change-Requests. Plattform für das Konfigurations- und Releasemanagement. Wird von allen MISTRA-Anwendungen für das Aenderungswesen in den Anwendungen verwendet. Technische Basis: php-webanwendung MANTIS, Datenbank MySQL. Data Warehouse des ASTRA. Das DWH hat im ASTRA eine übergeordnete Funktion, wird u.a. auch von MISTRA-Anwendungen (BS, VU und VMON) gespiesen. Technische Basis: Business Objects, Datenbank Oracle 10g Das DWH bezieht die Daten soweit möglich aus der Datenbank des BS und, für sehr detaillierte Auswertungen, zusätzlich auch aus den FA Verkehrsmonitoring und Verkehrsunfälle. Erhaltungsmanagement im Siedlungsgebiet. Vereinfachte Optimierung der Erhaltungsplanung unter Einbezug von Strassen und Leitungen. Technische Basis: noch offen Fahrzeug- und Führerregister: Sammelbegriff für die Anwendungen MOFIS (Motorfahrzeug-Informationssystem), FABER (Führerberechtigung), ADMAS (Administrative Massnahmen). Technische Basis: bestehende Anwendungen, technisch tendenziell veraltet, Anbindung an DWH mittels Filetransfer Fahrbahn und Nebenanlagen. Beschreibung der Fahrbahnsubstanz (Querschnitt, Streifen, Schichtaufbau), Zustandsaufnahmen und In- Version 1.0, Seite 9

15 Systemarchitektur Geodienste Bund GEVER GEWI / TIC HelpDesk KUBA LDAP Services LV LVS MultiNet Outlook / Exchange Portal MISTRA SB TDCost spektionen, Bewertung, Unterhaltsplanung. Technische Basis: noch offen WebMapServer der swisstopo, welcher die Landeskarten, Vector25, Orthofotos und Reliefkarte bereitstellt. Die Verwendung ist in [18] dokumentiert. Geschäftsverwaltung und DMS des ASTRA: Verwaltung von Adressen und Dokumenten. Technische Basis: RichClient-Anwendung auf Basis des Fertigprodukts Fabasoft. Erfassung und Verteilung von Verkehrereignissen (Unfälle, Falschfahrer, Staus, Baustellen usw.). Technische Basis: Windows-Anwendung, Datenbank MS*SQL-Server Erfassung, Verarbeitung und Nachverfolgung von HelpDesk-Anfragen. Technische Basis: php-webanwendung MANTIS, Datenbank MySQL. Kunstbauten. Beschreibung der Bauwerke und Bauwerksteile, Inspektionen, Bewertung, Unterhaltsplanung. Technische Basis: 3-tier-Anwendung, C#.NET, MapObjects, Datenbank Oracle 10g WebServices zur Abfrage von Mandanten, Rollen und Rechten angemeldeter Benutzer. Technische Basis:.NET, Mandanten, Rollen und Rechte werden aktuell mit ADAM, ab ca im AD UVEK verwaltet. Langsamverkehr: Wegachsen, Wege, Routen, Signalisation für Wandern, Velo, Mountainbike, Skating etc. Technische Basis: noch offen Verwaltung Liegenschaften- und Verträge zu Grundeigentum und Dienstbarkeiten. Technische Basis: Java-Anwendung, Datenbank Oracle 10g, Fertigprodukt ConTracker. Datenbank der Verkehrsnavigationsdaten von TeleAtlas. Anwendung zur Verwaltung von Adressen. Technische Basis: MS Exchange Internet- und Extranet-Portal MISTRA. Technische Basis: MS-Sharepoint-WSS-Anwendung, Datenbank MS SQL-Server Erteilung von Sonderbewilligungen für Ausnahmetransporte, Transportrouten, Hindernisse, administrative Abwicklung. Technische Basis: Daten Transportrouten und Hindernisse im BS, Beurteilung Anträge und Bewilligungen über Fertigprodukt BEAT als Client/Server-Anwendung, Datenbank MS-Access. Baukostenmanagementsystem. Technische Basis:.NET-Anwendung, Datenbank Oracle 10g Version 1.0, Seite 10

16 Systemarchitektur VM UVEK VM-CH VMON VU WebiGeo Verkehrsmodell UVEK: Berechnung der Verkehrsmenge umgelegt von den Zählstellen Streckenbezogen auf das Strassennetz in verschiedenen Varianten (Jahreswerte Ist-Zustand, Prognosezustände etc.). Technische Basis: Anwendung VISUM von PTV Deutschland Verkehrsmanagement Schweiz: Überwachung und Steuerung des Verkehraufkommens. Technische Basis: noch offen Verkehrsmonitoring: Übernahme und Validierung von Daten von Verkehrszählern. Technische Basis: RichClient-Anwendung 3-tier,.NET, Datenbank Oracle 10g Verkehrsunfälle: Erfassung und Verwaltung von Verkehrunfällen. Technische Basis: WebClient-Anwendung 3-tier,.NET, zusätzlich WebGIS-Viewer, Datenbank Oracle 10g Zusatzkomponente zum DWH ASTRA für die kartografische Analyse und Ausgabe von DWH-Daten. Technische Basis: BusinessObjects und ESRI ArcGIS 9 Version 1.0, Seite 11

17 Systemarchitektur 3.2 Logische Systemarchitektur: Sicht einer FA In den nachfolgenden Abbildungen sind die wichtigsten Aspekte für eine FA zusammengefasst. Abbildung 3: Überblick WebServices Abbildung 4: Überblick INTERLIS-Schnittstelle Version 1.0, Seite 12

18 Systemarchitektur 3.3 Physische Systemarchitektur (Deployment-Sicht) deployment Physische Systemarchitektur Benutzer Arbeitsplätze RDP Client Brow ser Annex Systeme rd p Basissystem rd p FA mit GIS FA als WebApp ohne GIS DWH ASTRA rd p «terminal Server» Terminal Serv er BS ht tp «terminal Server» TS FA1 (optional) «termin... DWH NAS Filesystem win http Importer rpc ArcMap Business Serv er BS Web Serv er BS Rich Appl (optional) rpc Busines s Serv er FA1 ht tp Business S erver FA2 ht tp rpc ht tp DWH S erv er Ora cl e Warehouse Bui lde r (Client) rpc LDAP S erv er LD AP Serv ices rpc soap MIS TR A Extension rpc ArcGIS Server Repo rting Serv ices soap rpc soap WebApp BS WebServ ices B S soap Bus ine ss Logik FA1 ArcG IS Serv er FA rpc rpc Web Serv er FA1 WebApp F A1 WebServ ices FA Bus ine ss Logik FA2 rpc Web Serv er FA2 WebA pp FA 2 WebSer v ices FA 2 WebiGeo rpc ArcG IS Ser v e r DWH Bus ine ss Obj e cts Ora cl e Warehouse Bui lde r (serv er) rpc sql*net sql*net soap swisstopo / KOGIS sql*net soap rpc ArcSDE Server MISTRA rpc Gemeinsame Ressourcen rpc sql*net sql*net sql*net GeoDienste Bund WebM ap Serv ices «ArcSDE Instanz» BS «ArcSDE Instanz» FA sql*net sql*net sql*net sql*net Oracle Cluster BIT «Oracle Instanz» DB Importzone «Oracle Instanz» Geo DB «Oracle Instanz» Sac hdb «Oracle Instanz» FA1 DB «Oracle Instanz» FA2 DB «Oracle Instanz» DB DWH Abbildung 5: Physische Systemarchitektur (Deployment-Sicht) in UML2 Version 1.0, Seite 13

19 Systemarchitektur Legende: Physisches Serversystem als einzelner Server oder mehrere Server in einem Verbund (Cluster oder Farm). Es wird nicht zwischen physischen und virtuellen Servern unterschieden (Sache des Betreibers). Auf einem Rechner installierte Softwarekomponente, wobei hier nur die wichtigsten Komponenten gezeigt werden. Datenbankknoten bzw. -instanz soap Die Pfeile symbolisieren die Kommunikationspfade - Quelle ist das aufrufende System (Client) - Ziel (Pfeilspitze) ist das Service-liefernde System Der Text definiert das Kommunikationsprotokoll: rpc steht stellvertretend für die verschiedenen synchronen Protokolle wie.net Remoting, DCOM, Java RMI usw. Bei den FA sind zwei typische Konfigurationen abgebildet: FA mit Rich- und Web-Applikation und GIS-Funktionalität in beiden Applikationen. FA als einfache Web-Applikation ohne GIS Bei beiden FA ist auch eine Komponente "WebServices" enthalten. Sie ist optional, jedoch spätestens dann zwingend, wenn die FA Datenservices zu Händen Achsband (Teil des BS) genutzt werden sollen. Die Kommunikationspfade wurden aus Gründen der Übersichtlichkeit nicht alle dargestellt. Grundsätzlich hat es noch die folgenden zusätzlichen Kommunikationspfade: Zugriff auf NAS Filesystem für alle Applikationen Zugriff auf LDAP Services für alle Applikationen Zugriff auf WebMap Services Bund für alle Applikationen Weitere Bemerkungen: Der ArcSDE-Server wird von allen GIS-basierten Applikationen gemeinsam genutzt. Jede Applikation unterhält eine oder mehrere eigene ArcSDE-Instanzen. Die Oracle-Datenbanken werden alle im Oracle Cluster betrieben. Jede Applikation betreibt eine oder mehrere eigene Oracle-Instanzen. 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 aus der Datenbank des BS und legen ihre GD in darin ab. Direktzugriffe oder Fremdschlüsselbeziehungen auf die Oracle- oder ArcSDE-Instanz einer anderen Applikation (gewissermassen übers Kreuz) sind nicht zulässig. Version 1.0, Seite 14

20 Systemarchitektur Die Kommunikation zwischen den Applikationen erfolgt ausschliesslich auf Stufe der Business Server oder durch filebasierten Datenaustausch. FA kommunizieren nie direkt untereinander, sondern immer über das BS. Das BS stellt den FA die BD und GD anderer FA zur Verfügung. Version 1.0, Seite 15

21 Systemarchitektur 3.4 Deployment-Szenarien MISTRA Auch wenn MISTRA für das ATSRA und die Kantone auf der Infrastruktur Bund beim BIT gehostet wird, sind eigene Installationen möglich. 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 in der Konfiguration des ASTRA ebenfalls eingesetzt werden. Abbildung 6: Deployment-Szenarien Abbildung 6 zeigt zwei verschiedene Deployment-Szenarien, nämlich: 1. Die Installation des ASTRA, komplett mit BS, DWH und allen FA 2. Die Installation eines Kantons mit BS (ohne RichGIS-Client) und ausgewählten FA. Die Bewirtschaftung von BD findet extern statt, z.b. in einem Ingenieurbüro in dem für die Nachführungsarbeiten der BD ein BS installiert ist. 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. 6.1) Version 1.0, Seite 16

22 Systemarchitektur 3.5 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 ab Windows XP ab Oracle 10g GIS ab ESRI ArcGIS-Server 9.2 SP3, ArcSDE 9.2, ArcGIS Desktop 9.2 Browser ab MS Internet Explorer 6.0 ab Firefox 2.0 Büroanwendungen Reporting ab MS Office XP Entwicklungsplattform ab.net 2.0 Tabelle 2: Basisprodukte und Technologien Anforderungen FA: Business Objects XI R2 für Auswertungen im DWH WebiGeo von Galigeo 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. Für den Einsatz der Produktpalette von ESRI wird vom ASTRA eine Projektlizenz abgeschlossen. Sie gilt für alle MISTRA-Installationen mit BS und allen FA schweizweit. Für die Verwendung von Business Objects und WebiGeo wird ebenfalls ein Lizenzpool für MISTRA angestrebt. MS Reporting Services ist beim BIT für alle Applikationen lizenziert. 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. Version 1.0, Seite 17

23 Systemarchitektur 3.6 Kommunikation FA <> BS Die Kommunikation zwischen FA und dem BS ist auf zwei Arten vorgesehen: 1. Online über Services: Die FA greift über eine Netzwerkverbindung auf das BS zu. Auf diese Art kann die FA die vom BS angebotenen WebServices nutzen und auch Web- Map-Services beziehen (siehe [1]). Die Kommunikation online ist für die Nutzung der WebServices des BS zu verwenden. 2. Über die Offline-Schnittstelle mittels Filetransfer. Die Kommunikation offline ist für den geregelten Datenaustausch gemäss Kap. 5.3 und 5.4 zu verwenden. Davon betroffen sind der Import von BD durch die FA sowie der Export von GD von der FA zu Handen des BS. 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 Weitere Angaben sind in Kap 4 und 5 sowie in Dokument [1] enthalten. Version 1.0, Seite 18

24 Service-Interfaces 4 Service-Interfaces Die Online-Kommunikation mit den Geodiensten Bund, dem AV-Geodatenportal, dem LDAP- Server und dem BS erfolgt über Web-Services. Die zur Verfügung gestellten Services werden in WSDL beschrieben. Die WebServices für den Zugriff auf das LDAP sowie auf das BS, welche im Rahmen der Realisierungseinheit RE1 des BS realisiert wurden, sind in den nachfolgenden Kapiteln kurz beschrieben. Für eine detaillierte Beschreibung, siehe Dokument 3 (LDAP) und [1] (BS). Für die verbindliche Liste der Request- und Response-Parameter sind die WSDL der aktuellen WS zu beachten. 4.1 Geodienste Bund + AV-Geodatenportal Die Hintergrunddaten von swisstopo, die im MISTRA BS oder den FA als Hintergrund- oder Kontextdaten für kartografische Darstellungen genutzt werden, werden vom Geodatenservice KOGIS bezogen. Sie stellt zu diesem Zweck einen Service auf HTTP-Basis zur Verfügung (wms-mistra). GIS-Serv er wms-mistra «trace» wms-mistra KOGIS Abbildung 8: Schnittstelle zu Geodiensten KOGIS BS und FA beziehen den WMS immer direkt vom Geodatenserver KOGIS. Die Benutzung der Geodienste ist in [18] beschrieben. Da ein WFS Bund noch nicht zur Verfügung steht, werden Kantone, Bezirke und Gemeinde als Kopien in der SDB gehalten. Version 1.0, Seite 19

25 Service-Interfaces 4.2 LDAP-Services Die LDAP-Services werden als WebServices angeboten und sind in [6] beschrieben. Die aktuellen Informationen zu den LDAP-Services sind im MISTRA-DMS unter Dokumente / BCI Business Collab Infrastructure / ABS Components / LDAP verfügbar LDAP-Klassen UserInfo User DN Pfad im LDAP-Baum DN Pfad im LDAP-Baum UID Eindeutige ID CN Allgemeiner Name SureName Nachname Mandator Mandantname GivenName Vorname UID Eindeutige ID Language Sprache Mail Mail-Adresse Mandator MandatorV2 DN Pfad im LDAP-Baum astramandatorname Mandantname astramandatorname Mandantname astraapplicationname Applikationsname astraapplicationname Applikationsname Role VersionInfo DN Pfad im LDAP-Baum AssemblyVersion Version LDAP-Service CN Allgemeiner Name AssemblyDescription Beschreibung LDAP-Service astramandatorname Mandantname Abbildung 9: Klassen im LDAP-Modell Die Benutzer sind in der Klasse UserInfo definiert. Die Klasse Mandator führt eine Liste von Mandant / Applikationsbeziehungen, d.h. der Applikationen, welche für einen Mandanten eingerichtet sind. Die Klasse Role führt eine Liste der Rollen innerhalb von Mandator. Die Klasse User ordnet den Benutzer einem oder mehreren Mandator zu LDAP-Services GetUserForRole Beschreibung Request Response Liefert alle Benutzer, welche einer bestimmten Rolle einer Applikation über alle Mandaten zugeteilt sind. Tabelle 3: LDAP Service GetUserForRole Applikationsname Rollenname Array von User GetUserForMandator Beschreibung Request Response Liefert alle Benutzer, welche einer Mandanten- / Applikationsbeziehung zugeteilt sind. Tabelle 4: LDAP Service GetUserForMandator Applikationsname Mandantname Array von User GetRole Beschreibung Request Response Liefert alle Rollen, welche ein Benutzer Applikationsname Array von Role Version 1.0, Seite 20

26 Service-Interfaces innerhalb einer Applikation über alle Mandanten innehat. Username Tabelle 5: LDAP Service GetRole GetRoleMandator Beschreibung Request Response Liefert alle Rollen, welche ein Benutzer innerhalb einer Applikation für einen spezifischen Mandanten innehat. Tabelle 6: LDAP Service GetRoleMandator Applikationsname Username Mandantname Array von Role GetMandator Beschreibung Request Response Liefert alle Mandanten, welchen ein Benutzer in einer Applikation zugeordnet ist. Tabelle 7: LDAP Service GetMandator Applikationsname Username Array von Mandator GetMandatorV2 Beschreibung Request Response Liefert alle Mandanten, welchen ein Benutzer in einer Applikation zugeordnet ist. Tabelle 8: LDAP Service GetMandatorV2 Applikationsname Username GetUserInfo Beschreibung Request Response Liefert Informationen zu einem Benutzer. Username UserInfo Tabelle 9: LDAP Service GetUserInfo Array von MandatorV2 GetAssemblyInfo Beschreibung Request Response Liefert Informationen zum Service keine VersionInfo Tabelle 10: LDAP Service GetAssemblyInfo 4.3 WebMap-Services BS Hier werden die Standard WMS von ArcGIS-Server verwendet. Dokument [1] gibt Hinweise zur Benutzung der WMS. Die vom BS bereitgestellten WMS sind: Service-Name Beschreibung / Inhalt ARE AXR IVD Bezugssystem und Administrative Einteilungen: Raumbezug: Kilometrierung, Bezugspunkte, Achsen Gefahrenhinweiskarte: schadenpotentialrelevante Prozessräume Administrative Einteilungen: ASTRA Filialen, ASTRA Gebietseinheiten, Agglomerationen, Kantone, Bezirke, Gemeinden Bezugssystem in 3 verschiedenen geometrischen Abbildungen: Bezugspunkte Kalibrierungspunkte Achsen Inventarobjekte, Ausnahmetransportrouten, Raumbezug: Inventarobjekte: Brücken, Mauern, Gewässerbauten, Plätze, Höfe, Version 1.0, Seite 21

27 Service-Interfaces NET OVW Tunnel, Trassen Ausnahmetransportrouten: Routen, Hindernisse, Informationen Raumbezug: Kilometrierung, Bezugspunkte, Transportrouten Fachnetze, Fahrbahndaten, Raumbezug: Fachnetze: Unterhaltsabschnitte, Betriebsstrecken, Geschwindigkeitsabschnitte usw. Fahrbahn: Deckbelag, Zustand I1 bis I4, Längsneigung, Querneigung Raumbezug: Kilometrierung, Bezugspunkte, Transportrouten Update Request, Administrative Einteilung, Kartenhintergrund: Update Request ASTRA Filialen ASTRA Gebietseinheiten Agglomerationen Kantone, Bezirke, Gemeinden WMS-Server Bund Tabelle 11: Liste der MapServices BS 4.4 WebFeature-Services BS Hier werden die Standard WFS von ArcGIS-Server verwendet. Dokument [1] gibt Hinweise zur Benutzung der WFS. 4.5 WebServices des BS GetAxes und GetAxesArray Beschreibung Request Response Liefert eine Liste von Achsen, welche in einem definierten Umkreis eines bestimmten Punktes liegen. Im Request kann optional die ID einer Achse übergeben werden. Für diesen Fall wird nur diese Achse im definierten Umkreis gesucht. Wird die ID nicht übergeben, werden alle Achsen im definierten Umkreis zurück gegeben. Tabelle 12: BS Service GetAxes X: Ost-Koordinate Y: Nord-Koordinate Radius: Suchradius ID: optional, ID einer Achse, welche gesucht werden soll AxisList () mit AxisID Name: KonzSchlüssel (Nummer) der Achse; Distance: Abstand der Achse zum angegebenen Suchpunkt ErrorString string TransformXyToRbbs Beschreibung Request Response Liefert RBBS-Koordinaten eines Punktes auf der Grundlage der Bezugsgeometrie aus. Im Request kann optional die ID einer Achse übergeben werden. Für diesen Fall erfolgt die Transformation gezielt für diese Achse. Wird die ID nicht übergeben, erfolgt die Transformation für die am nächsten gelegene Achse. Im Request kann optional das Bezugsdatum übergeben werden. Für diesen Fall erfolgt die Transformation in der History der Achse für dieses Datum. Wird kein ID: optional, Vorgabe einer Achse, für die Transformation X: Ost-Koordinate des Punktes Y: Nord-Koordinate H: Meereshöhe RefDate: optional, gewünschtes Bezugsdatum AxisID: ID der Achse RefPt: ID des Bezugspunkts U: Längsdistanz zum Bezugspunkt U V: Querdistanz V in m (links negativ) W: Lotrechte Höhe ü- ber/unter Achse in m M: Längsdistanz ab Beginn der Achse Version 1.0, Seite 22

28 Service-Interfaces Datum übergeben, erfolgt die Transformation für die aktuelle Version der Achse. ErrorString Tabelle 13: BS Service TransformXyToRbbs TransformRbbsToXY Beschreibung Request Response Liefert XY-Koordinaten auf der Grundlage der Bezugsgeometrie aus. Tabelle 14: BS Service TransformRbbsToXy RefPt: ID des Bezugspunkts U: Längsdistanz zum Bezugspunkt U V: Querdistanz V in m (links negativ) W: Lotrechte Höhe ü- ber/unter Achse in m RefDate: optional, gewünschtes Bezugsdatum X: Ost-Koordinate Y: Nord-Koordinate H: Meereshöhe ErrorString TransformKilometerToRbbs Beschreibung Request Response Liefert RBBS-Koordinaten auf der Grundlage der Bezugsgeometrie aus. Es wird der jeweils absolut am nächsten gelegene Bezugspunkt gesucht und zurückgegeben, d.h. u kann negativ sein. Tabelle 15: BS Service KilometerToRbbs ID: optional, Vorgabe einer Achse, für die Transformation KM: Kilometerwert H: Meereshöhe RefDate: optional, gewünschtes Bezugsdatum AxisID: ID der Achse RefPt: ID des Bezugspunkts U: Längsdistanz zum Bezugspunkt U V: Querdistanz V in m (links negativ) W: Lotrechte Höhe ü- ber/unter Achse in m M: Längsdistanz ab Beginn der Achse ErrorString TransformRbbsToKilometer Beschreibung Request Response Liefert Kilometerangaben auf der Grundlage der Bezugsgeometrie aus. RefPt: ID des Bezugspunkts U: Längsdistanz zum Bezugspunkt U V: Querdistanz V in m (links negativ) W: Lotrechte Höhe ü- ber/unter Achse in m RefDate: optional, gewünschtes Bezugsdatum X: Ost-Koordinate Y: Nord-Koordinate H: Meereshöhe ErrorString Tabelle 16: BS Service TransformRbbsToKilometer Version 1.0, Seite 23

29 Service-Interfaces Verschnitt Objekt mit Flächennetz Beschreibung Request Response Macht den Verschnitt eines MISTRA- Objekts mit einem Flächennetz zur Bestimmung der Flächenzugehörigkeit des Objekts. Das Objekt verfügt über planare Geometrie. Der Verschnitt ruft ein mit dem ModelBuilder von ArcGIS erstelltes und publiziertes Modell auf. Shape des Objekts Die Parameter Flächentyp und Verschnittoperator sind Teil des Modells. AreaID: GUID der Fläche AreaCK: KonzKey der Fläche) Tabelle 17: BS Services für Flächenverschnitt Aggregation Objektdaten mit Flächennetz Beschreibung Request Response Macht den Verschnitt von MISTRA- Objekten mit einem Flächennetz zur Bestimmung eines aggregierten Werts pro Fläche, z.b. Anzahl Unfalltote pro Kanton. Die Objekte verfügen über eine planare Geometrie. Das Resultat wird als Array zurückgegeben. Die Aggregation ruft ein mit dem Model- Builder von ArcGIS erstelltes und publiziertes Modell auf. Shapes der Objekte Shapes des Flächennetzes Set von Wertepaaren Aggregationswert und FlächenID Tabelle 18: BS Service Flächenaggregationen Verschnitt Objekt mit Fachnetz Beschreibung Request Response Liefert den Verschnitt eines MISTRA- Objektes mit einem Fachnetz zur Bestimmung der Fachnetzzugehörigkeit. Dieser Code wird mittels Python im Model (durch das ESRITool Calculate Value) ausgeführt. Die MISTRA-Objekte verfügen über RBBS-Koordinaten. Der Verschnitt ruft ein mit dem ModelBuilder von ArcGIS erstelltes und publiziertes Modell auf. Tabelle 19: BS Service Fachnetzverschnitt Shape des Objekts Die Parameter Fachnetztyp und Verschnittoperator sind Teil des Modells. Aggregation Objektdaten mit Fachnetz Beschreibung Request Response Macht den Verschnitt von MISTRA- Objekten mit einem Fachnetz zur Bestimmung eines aggregierten Werts pro Segment, z.b. Anzahl Unfalltote pro Unfallabschnitt. Die Objekte verfügen über eine lineare Geometrie. Das Resultat wird als Array zurückgegeben. Der Verschnitt ruft ein mit dem ModelBuilder von ArcGIS erstelltes und publiziertes Modell auf. Shapes der Objekte Shapes des Fachnetzes True, wenn Objekt durch Fachnetzsegment abgedeckt ist. Set von Wertepaaren Aggregationswert und SegmentID Version 1.0, Seite 24

30 Service-Interfaces Tabelle 20: BS Service Fachnetzaggregation Verschnitt von Fachnetzen (16) Beschreibung Request Response Liefert den Verschnitt von zwei Fachnetzen als Fachnetz aus. Tabelle 21: BS Service Fachnetzverschnitt Mistra-ID der Achse M-Werte für Beginn und Ende des zu betrachtenden Abschnittes Rows mit dem Verschnitt der beiden Netze Die folgenden WebServices des BS werden erst in RE2 realisiert. Aus diesem Grund werden sie hier nur kurz beschrieben. Abfrage von Metadaten Beschreibung Request Response Liefert Informationen über den Nachführungsstand von BD und GD in der SDB. Tabelle 22: BS Service Abfrage von Metadaten Name des Topics (string) Bezugsdatum Aktualisierung RBBS Beschreibung Request Response Rechnet einen vorhandenen RBBS-Bezug in einen RBBS-Bezug mit einem anderen Zeitstempel um. Tabelle 23: BS Service Aktualisierung RBBS Liste Linearer Punkte Bezugsdatum RBBS alt Bezugsdatum RBBS neu Liste der seit dem Bezugsdatum mutierten Objekte je Objektklasse. Liste Linearer Punkte Version 1.0, Seite 25

31 Datenaustausch INTERLIS 5 Datenaustausch INTERLIS Diese Kapitel befassen sich mit dem Datenaustausch mittels Filetransfer in INTERLIS2. Die INTERLIS-Schnittstelle ist in [1] beschrieben. Die aktuellen INTERLIS-Modellbeschreibungen sind im MISTRA-DMS unter Dokumente / BCI Business Collab Infrastructure / ABS Components / Interlis Modelle verfügbar. 5.1 Allgemeine Festlegungen Die Standardschnittstelle von MISTRA basiert auf INTERLIS2. Für den Datenaustausch zwischen FA und BS gilt für beide Übertragungsrichtungen die Modellbeschreibung des BS (siehe [3]). Das BS ist somit Modell bestimmend und die FA muss für eventuell notwendige Modelltransformation der Daten besorgt sein. Der Datenaustausch über die Standardschnittstelle muss inkrementell möglich sein. Jede FA und FR, welche mit dem BS Daten austauschen möchte, muss im BS durch den Eintrag der DB-ID registriert sein. 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 im BS konfiguriert und automatisch in das Exportverzeichnis abgelegt. Die Exporte werden durch den Scheduler von Windows ausgelöst. Der Import in das BS wird durch den BS-Importer durchgeführt. Bei jedem Start des Importers werden die Transferverzeichnisse nach nicht verarbeiteten Transferdateien geprüft. 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 des BS werden die Daten definitiv in die SDB übernommen. Für den Datenaustausch mit dem BS müssen die FA folgende Funktionen bereitstellen: Export und Import der Visitenkarte, Interlis-Modell "MbsAuthorisation.ili", s. [3] Inkrementelle Interlis2-Schnittstelle für den Import und Export von Daten offline. Import der Daten in die FDB über die Standard-Schnittstelle Interlis2 initial und inkrementell. Für Import und Export muss ein Transferprotokoll erstellt werden. Automatische Nachführung der Referenzen auf BD und GD. Periodische, automatisierte Überprüfung des Nachführungsstatus der BD und GD durch Aufruf des entsprechenden WebService der BS (Abfrage von Metadaten). Automatische Nachführung der Referenzen auf BD und GD Damit die Integrität der Daten beim Datenaustausch erhalten bleibt, müssen die Regeln gemäss Kap 6.1 bis 6.7, und 6.13 eingehalten werden. Version 1.0, Seite 26

32 Datenaustausch INTERLIS 5.2 Transferverzeichnisse Die Struktur der Transferverzeichnisse am Beispiel von BS und VMON: Verzeichnisse Verwendung Root Level Mandant Level Applikation Level Doc / Transfer Sublevel 1 Sublevel 2 MISTRA-App CH BS Doc Wird von der Applikation weiter unterteilt Transfer ExportSD In BS: Export Sockeldaten an andere BS Out BS: Ablage Logfile nach Abschluss Export ImportSD In BS: Ablage Sockeldaten von anderen BS Out BS: Ablage Logfile nach Abschluss Export Save BS: Sicherungskopie nach Abschluss Import ExportDWH In BS: ETL Sockeldaten an DWH Out BS: Ablage Logfile nach Abschluss Export ETL DWH: Ablage Logfile nach Abschluss Import DWH Save DWH: Sicherungskopie nach Abschluss Import Tabelle 24: Verzeichnisstruktur Transferverzeichnisse BS (Details s. [2]) Version 1.0, Seite 27

33 Datenaustausch INTERLIS Verzeichnisse Verwendung Root Level Mandant Level Applikation Level Doc / Transfer MISTRA-App CH VMON Doc Sublevel 1 Sublevel 2 Beliebige Dokumente der Applikation. Dieses Verzeichnis kann nach Bedarf weiter unterteilt werden. Transfer ExportSD In BS: Export Sockeldaten aus BS FA: Import Sockeldaten Out FA: Ablage Logfile nach Abschluss Import Save FA: Sicherungskopie nach Abschluss Import ImportGD In FA: Export Generalistendaten aus FA BS: Import Generalistendaten Out BS: Ablage Logfile nach Abschluss Import Save BS: Sicherungskopie nach Abschluss Import ExportDWH In FA: ETL Spezialistendaten an DWH Out FA: Ablage Logfile nach Abschluss Export ETL DWH: Ablage Logfile nach Abschluss Import DWH Save DWH: Sicherungskopie nach Abschluss Import ImportSpez In FA: Ablage Transferdateien vom Übertragungssystem und von Fremdsystemen. Ordner wird weiter strukturiert. Out FA: Ablage Logfile nach Abschluss Import Save FA: Sicherungskopie nach Abschluss Import ExportSpez In FA: Ablage Transferdateien aus der FA für Fremdsysteme Out FA: Ablage Logfile nach Abschluss Export Save FA: Sicherungskopie nach Abschluss Import Tabelle 25: Verzeichnisstruktur Transferverzeichnisse VMON (Details s. [2]) Namenskonvention der Dateien für den INTERLIS-Datenaustausch: Transferdateien vor dem Import: Dateiname: [ZeitstempelSender]_[Interlis-Schemaname].xtf ZeitstempelSender im Format yyyymmddhhmmss, 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 yyyymmddhhmmss, 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 yyyymmddhhmmssnnnn, z.b Version 1.0, Seite 28

34 Datenaustausch INTERLIS 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 yyyymmddhhmmssnnnn, z.b Der ZeitstempelEmpfänger stimmt mit dem Zeitstempel der Transferdatei überein. Beispiel Dateiname: _MbsAccident_ log Abbildung 10: Exemplarische LOG-Datei (Import) Version 1.0, Seite 29

35 Datenaustausch INTERLIS 5.3 Datenaustausch BS FA offline Abbildung 11: 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 (Auswahl der Interlis-Topics und Eigentümerschaft). Die Beschreibung des Dateninhalts wird in der Modellbeschreibungsdatei von Interlis2 (.ili) festgelegt (siehe [3]). Auswahl ob voller oder inkrementeller Datenaustausch. Startdatum und Periodizität des inkrementellen Datenaustauschs. 2. Der Datenexport aus der SDB wird über den Job.Scheduler automatisch ausgelöst. Das BS legt die Transfer- und die Export-Logdatei in die vorgesehenen Verzeichnisse ab. 3. Die FA stellt 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 das Save- 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 1. Als Bezugsdatum wird 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. 1 Bei Fehlern im zu importierenden Datenbestand sollten der Import als Ganzes zurückgewiesen und nicht eine Teilimport durchgeführt werden. Version 1.0, Seite 30

36 Datenaustausch INTERLIS 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 Done Scheduler einstellen done Done (from FA Use (from Cases) Integration Processes) (from Integration Processes) Abbildung 12: 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 done Schreibe Daten Interlis-Check done ablegen ok done Logfile ablegen ok done (from Integration (from Processes) BP4: Export Service) Abbildung 13: Sequenzdiagramm Export BD / GD durch BS 2 2 Orange = BS; Grün = FA; Blau = Filesystem Version 1.0, Seite 31

37 Datenaustausch INTERLIS 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 done done Schreibe Katalogdaten BS done Lese Objektdaten Lesen Liefern Interlis-Check Objektdaten BS done done Schreibe Objektdaten BS in DB FA done Dateien verschieben done Logfile ablegen done Done (from FA Import Interlis) Abbildung 14: Sequenzdiagramm Import BD / GD durch FA 3 3 Orange = BS; Grün = FA; Blau = Filesystem Version 1.0, Seite 32

38 Datenaustausch INTERLIS 5.4 Datenaustausch FA BS offline Abbildung 15: 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 und Eigentümerschaft). Die Beschreibung des Dateninhalts wird in der Modellbeschreibungsdatei von Interlis2 (.ili) festgelegt (siehe [3]). Auswahl ob voller oder inkrementeller Datenaustausch. 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 das Save- 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 es kann ein einmaliger Zwischentransfer definiert und ausgelöst werden. Als Bezugsdatum wird 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. Version 1.0, Seite 33