Architekturkonzept - E

Transcription

VStV Neu
Architekturkonzept
Version 1.1
VStV Neu - Verwaltungsstrafverfahren
Seite i
Architekturkonzept
VStV Neu
t
Copyright © rubicon IT GmbH, A-1010 Wien, 2014.
Diese Unterlagen sind vertraulich. Die in diesem Dokument
enthaltenen Ideen und Vorschläge sind urheberrechtlich
geschützt.
rubicon, Acta Nova und Document Partner, sowie die
entsprechenden Logos sind geschützte Marken der rubicon
IT GmbH. Microsoft, Windows, Windows XP, Windows Vista,
Windows 2003,Windows 7, Windows 2008, Excel, Word,
Visual Studio sind entweder registrierte Warenzeichen oder
Warenzeichen der Microsoft Corporation.
Seite ii
Architekturkonzept
VStV Neu
Architekturkonzept
Inhaltsverzeichnis
1 Einführung ...............................................................................................................................................1
1.1 Bereitstellung Basiskomponenten .....................................................................................................1
1.2 VStV Neu ..........................................................................................................................................3
2 Umsetzung auf Basis des BM.I Layer ...................................................................................................4
3 Beschreibung des re-motion Frameworks ...........................................................................................5
4 Anwendungsschichten ..........................................................................................................................7
5 Zentrale Datenspeicherung ...................................................................................................................8
5.1 VStV Datenbank ................................................................................................................................8
5.2 Zentrales Archiv ................................................................................................................................9
6 Benutzerschnittstelle .............................................................................................................................9
7 Erweiterung von Modulen ....................................................................................................................10
8 Druck und Versand ...............................................................................................................................11
8.1 Massendruck ...................................................................................................................................13
8.2 Individualdruck ................................................................................................................................14
8.3 Druckstraßenanbindung ..................................................................................................................15
8.3.1 Datenmapping hpc-Dual ......................................................................................................15
8.3.2 Datenmapping BM.I-Collector ..............................................................................................17
9 Authentisierung und Berechtigungen ................................................................................................21
9.1 Authentisierung ...............................................................................................................................21
9.2 Benutzerdaten .................................................................................................................................21
9.2.1 Rollen ...................................................................................................................................22
9.3 Anwendungssicherheit ....................................................................................................................23
9.4 Abbildung der Organisationsstruktur...............................................................................................24
9.5 Abbildung von Berechtigungen .......................................................................................................24
9.6 Auswertung von Berechtigungen ....................................................................................................24
10 Bestehende Schnittstellen im BM.I-Layer ..........................................................................................26
10.1 Exchange-Schnittstellen..................................................................................................................26
10.2 Aktivitätsprotokollierung für TPA .....................................................................................................27
10.3 EKIS ................................................................................................................................................27
10.4 IAP...................................................................................................................................................28
10.5 ZMR.................................................................................................................................................28
10.6 EDIAKT II ........................................................................................................................................28
10.6.1 Einen Akt mit EDIAKT exportieren .......................................................................................28
10.6.2 Einen Fremdakt mit EDIAKT importieren .............................................................................29
10.7 EDIAKT II für ELAK im Bund ..........................................................................................................29
10.7.1 BM.I-Layer  ELAK im Bund ...............................................................................................29
10.7.2 ELAK im Bund  BM.I-Layer ...............................................................................................30
10.8 PDF-Amtssignatur ...........................................................................................................................30
10.9 Manuelle Schnittstellen ...................................................................................................................30
11 Ergänzende Schnittstellen in VStV .....................................................................................................30
11.1 Anliefernde Systeme .......................................................................................................................31
11.1.1 VKS Abstandsmessungen ...................................................................................................32
11.1.2 ASFINAG ..............................................................................................................................32
11.1.3 DAKO ...................................................................................................................................32
11.1.4 Einzahlungsüberwachung ....................................................................................................32
11.1.5 Argus Select (Radar, Section Control) .................................................................................33
11.1.6 Vorfeldapplikation Schwerverkehr ........................................................................................35
11.1.7 Wiener Linien .......................................................................................................................35
11.1.8 Glücksspiel ...........................................................................................................................35
11.2 Abzufragende Systeme ...................................................................................................................35
11.2.1 Zulassungsbesitzerabfrage (ZBA) ........................................................................................35
Seite iii
VStV Neu
Architekturkonzept
11.2.2 Unternehmensregister (UR) .................................................................................................36
11.2.3 Führerscheinregister (FSR) ..................................................................................................37
11.2.4 Adress-Datenbank................................................................................................................37
11.2.5 Verkehrsunternehmensregister ............................................................................................37
11.2.6 Identitätsdokumentregister ...................................................................................................38
12 VStV-Connector ....................................................................................................................................38
12.1 Anwendungsfälle .............................................................................................................................39
12.1.1 Neue Anzeige einbringen .....................................................................................................39
12.1.2 Verarbeitungsstatus abholen ...............................................................................................40
12.1.3 Verarbeitungsstatus rückmelden ..........................................................................................41
12.1.4 Verarbeitungsstatus-Liste melden........................................................................................41
12.1.5 Vorgänge abholen ................................................................................................................41
12.1.6 Maximale Paketgröße ..........................................................................................................42
12.1.7 Schriftverkehr übermitteln ....................................................................................................42
13 Länderconnector ..................................................................................................................................42
14 Abbildungsverzeichnis ........................................................................................................................43
Seite iv
VStV Neu
Seite v
Architekturkonzept
1 Einführung
Die Umsetzung von VStV erfolgt auf Basis des Standardproduktes Acta Nova sowie des
existierenden BM.I-Layers. Somit verwendet VStV die gleichen Technologien wie
andere aktuelle Projekte des BM.I im Bereich der spezifischen polizeilichen
Geschäftsfallbearbeitung inkl. Workflowmanagement. Daraus ergeben sich ein hoher
Grad an Wiederverwendung und daraus resultierend geringere Erstellungskosten sowie
das Potential für weitere Synergieeffekte in der zukünftigen Weiterentwicklung aller
Projekte.
Die modulare Architektur von Acta Nova ermöglicht es, Komponenten wie den BM.ILayer zentral zu entwickeln und dennoch in unabhängigen Systemen zu nutzen.
Darüber hinaus können Anpassungen in Komponenten wie PAD NG und den einzelnen
PAD Modulen unabhängig von Acta Nova und dem BM.I-Layer entwickelt werden und
sind somit update-fähig.
Abbildung 1: BM.I-Layer Überblick
1.1 Bereitstellung Basiskomponenten
Als Basis für die einzelnen Modul-Umsetzungen wurde im Rahmen des Projektes VStV
eine Basiskomponente "PAD NG" basierend auf dem aktuell gültigen BM.I-Layer und
Seite 1/43
der freigegebenen Acta Nova Version hergestellt. Damit wurde die Bereitstellung von
wesentlichen Kern-Funktionen bereits zu Projektbeginn ermöglicht.
Kernmodul
Im Kernmodul enthaltene Basisfunktionen sind:
 Geschäftsfallverwaltung mit Dokumenten-, und Workflow-Management
 Technische Basis für die papierlose/papierarme Geschäftsfallverwaltung
 Basis für die Abbildung von Elementen der Datenbasis (Personen und Objekte)
 Nutzung existierender BM.I-Schnittstellen
Neben den Kernfunktionalitäten der Geschäftsfallverwaltung sind in Acta Nova und dem
BM.I-Layer bereits eine Vielzahl an Schnittstellen vorhanden, die im Rahmen des
Projekts um die VStV-spezifischen Schnittstellen erweitert wurden.
Schnittstellen
Folgende Versand-Mechanismen stehen als zentrale Kommunikations-Komponenten in
VStV zur Verfügung:
 Versand mittels Workflow innerhalb des VStV-Verbund
 Versand mittels Elektronischem Verwaltungspolizeilichem Datenverkehr (EVD) an
andere Exekutivorgane und Behörden der LPDs
 Versand mittels Elektronischer Zustellung bzw. Druck- und Poststraße an externe
Empfänger
 Versand mittels Länderconnector an Behörden der Länder
Folgende Schnittstellen sind für eine zukünftige Umsetzung geplant:
 Versand mittels EiB-Schnittstelle an Teilnehmer von ELAK im Bund (Format
EDIAKT II)
 Versand mittels Kommunikationsserver an die Länder (Format in Anlehnung an
EDIAKT II)
 Versand mittels ERV-Schnittstelle zu Gerichten (Elektronischer Rechtsverkehr)
Im Modul VSTV Neu wird auf Basis einer XML-basierenden Schnittstelle über den
VStV-Connector die Möglichkeit des Empfangs von externen Akten zur Verfügung
gestellt, um eine direkte Weiterverarbeitung in VStV zu ermöglichen.
Offene Architektur
Durch die offene Architektur der Kernkomponente ist eine modulare Erweiterbarkeit auf
allen Ebenen durch verschiedene funktionale Module gewährleistet.
So wurde die architekturelle Basis geschaffen um in einem ersten Schritt das Modul für
Verwaltungsstrafverfahren (VStV Neu) umzusetzen, welches die bisherigen Systeme
VStV Polizei und VStV Gendarmerie abgelöst und die Vorteile aus beiden Systemen
vereint hat.
Seite 2/43
Zentrale Modul-Bereitstellung
Im Sinne der Strategie des BM.I wurde die zentrale Datenhaltung für VStV umgesetzt.
Dadurch wurden insbesondere Synergien in der Infrastruktur und im Betrieb generiert.
Weitere wesentliche Vorteile einer zentralen Datenhaltung sind:
 Standardisierter bundesweiter Einsatz auf Standard-Arbeitsplätzen (BAKS V)
 Option für die Verwendung durch externe Benutzer wie durch Landesbehörden
 Zentrale Technologie Microsoft SQL Server
 Getrennte Datenablage für Radar-Fotos
 Einheitliche, zentrale Administration
 Einheitliche Katalogverwaltung (z.B. Deliktskatalog)
 Berechtigungen (insbes. in Hinblick auf Einhaltung des Datenschutzrechts)
 Berücksichtigung unterschiedlicher Anforderungen aus Benutzersicht
 Schnelle Erfassung für Exekutive (Einmalerfassung)
 Flexibles Management von Geschäftsfällen (Strafakten und Rechtshilfeakten)
und hohe Nachvollziehbarkeit für Verwaltungsbehörden
 Hoher Automationsgrad im fachlichen Kontext der einzelnen Module
 Integration in die IT-Landschaft des BM.I
 Schnittstellen zu bestehenden Anwendungen durch BM.I-Layer
 Standardschnittstellen für weitere Anwendungen
 Verwendung von Standard-Technologien (z.B. Windows Server, SQL Server)
 Auslegung für einfachen Betrieb und Eingliederung in bestehende System
Management Prozeduren (Backup und Restore, Monitoring)
 Hohe Verfügbarkeit durch Mehrfachauslegung (redundante Systeme)
1.2 VStV Neu
VStV Neu wurde als erstes Modul für PAD NG umgesetzt. VStV nutzt dabei die
Funktionen und das Datenmodell von PAD NG als Basis und ergänzt diese um eigene
Artefakte:
 Erweiterung des Datenmodells1
 Eigene Workflow-Prozesse und Dokumentvorlagen
 Spezifische Funktionen zur Abwicklung von Verwaltungsstrafverfahren
 Erweiterungen der Web-basierten Benutzerschnittstelle zur Abbildung der
entsprechenden Daten und Funktionen
1
http://de.wikipedia.org/wiki/Datenmodell
Seite 3/43
 Eigenständiger Erfassungsclient für die Exekutive (effiziente
Einmaldatenerfassung)
 Spezielle Routinen zur automatisierten Massenverarbeitung ohne BenutzerInteraktion
VStV ist dabei als eigenständiger Anwendungskontext abgebildet. Dadurch sind die
Daten von VStV Neu von anderen Anwendungsdaten in PAD NG logisch getrennt,
trotzdem können die Vorteile einer physischen Installation (wie Betreuung, Betrieb,
Infrastruktur, …) genutzt werden. Dadurch können Verwaltungsstrafen effizient
bearbeitet werden, ohne durch modulübergreifende Datenverknüpfungen in Konflikt mit
diesbezüglichen Datenschutzbestimmungen zu geraten.
2 Umsetzung auf Basis des BM.I Layer
Die Anwendung VStV sowie die einzelnen PAD NG Module sind auf Basis des
Produktes Acta Nova sowie des BM.I-Layers erstellt. Die Grundlage bilden
Basistechnologien von Microsoft wie Windows Server und .NET Framework.
Darauf basierend stellt Acta Nova die Funktionalität für die automatisierte
Geschäftsfallbearbeitung bereit. Acta Nova beinhaltet zudem ein komponentenbasiertes
Erweiterungsmodell, mit dem weitere Module unabhängig vom Quellcode der
Basisanwendung erstellt und ausgeführt werden können.
Mittels dieses Erweiterungsmodells wurde der BM.I-Layer entwickelt, der Acta Nova an
die Gegebenheiten des BM.I anpasst und wesentliche Schnittstellen zu BM.I-Systemen
bereitstellt. Allfällige Weiterentwicklungen des BM.I-Layer im Rahmen von PAD NG
kommen auch anderen Projekten im BM.I zugute.
Im Folgenden werden kurz die Produkte und Module im Kernsystem von VStV, von der
Basisinfrastruktur hin zu den konkreten Projektergebnissen aufgelistet:
 Microsoft Windows Server ist das Standard-Serverbetriebssystem des BM.I.
 Das Microsoft .NET Framework stellt die Laufzeitumgebung für das gesamte
System bereit.
 IIS und WCF als Basis für Anwendungsservices für Web-Anwendungen (BrowserAnwendungen) respektive Web-Services (SOAP).
 Das re-motion Framework von rubicon stellt wesentliche Funktionen für das
Erstellen von standardisierten Web-basierten Anwendungen bereit:
 Erstellung eines objektorientierten Objektmodells, automatische Übersetzung
von Objektoperationen in Abfragen und Updates für Microsoft SQL Server
(Objektrelationales Mapping) im Modul re-store
 Automatische Abbildung von Objekten auf Web-Formulare (lesen und
bearbeiten) und Navigation in der Web-Anwendung (Data Binding/Scaffolding2)
im Modul re-form
2
Scaffolding - http://en.wikipedia.org/wiki/Scaffold_(programming)
Seite 4/43
 Rollenbasierte Berechtigungsverwaltung mittels Access Control Lists (ACLs)
inkl. Stellvertretungen im Modul re-strict
Nähere Informationen zu re-motion finden Sie in Abschnitt 3 dieses Dokuments.
 Acta Nova ist ein umfassendes Produkt zur Verwaltung von Geschäftsfällen.
 Verwaltung von Sachgebieten, Verfahrensbereichen, Katalogen, Fachdaten
u.v.m.
 Erstellung und Bearbeitung von Dokumenten mit Microsoft Office
 Funktionen der Geschäftsfallverwaltung wie Registrieren und Protokollieren
 Workflow-basierte Bearbeitung von Geschäftsfällen
 Der BM.I-Layer ist die Anpassung von Acta Nova an die Bedürfnisse des BM.I und
die Sammlung dieser wiederverwendbaren Ergebnisse.
 Kommt neben VStV Neu derzeit in EDIS II (BVT), Sirene für SIS II und IKDA
(jeweils .BK) zum Einsatz
 Beinhaltet standardisierte Schnittstellen zu bestehenden Systemen des BM.I
und Umsystemen (vgl. Integrationskonzept)
 PAD NG stellt die Funktionen bereit, die für die zentralen Dienste von PAD (z.B.
Erfassen von Anzeigen, Schriftverkehr) und mehreren PAD-Modulen benötigt
werden,
 Die einzelnen PAD-Module wie hier konkret das Modul VStV realisieren die
Funktionalität der jeweiligen Fachverfahren.
 Es kommen ergänzend eigenständige Teilanwendungen zum Einsatz, wie
etwa der Erfassungsclient für die Exekutive von VStV.
Neben den Standard-Funktionen aus der Anwendung kommen zusätzlich vor allem
folgende weitere Produkte zum Einsatz:
 Microsoft SQL Server für das Speichern sämtlicher Daten aus PAD NG sowie für
Auswertungen und Berichte
 Document Partner von rubicon für die vorlagenbasierte Erstellung von
Dokumenten für den Massen- und Individual-Druck
3 Beschreibung des re-motion Frameworks
re-motion ist eine Erweiterung des Microsoft .NET Frameworks, mit dessen Hilfe sehr
einfach konkrete Anwendungen entwickelt werden können, die typische
Anforderungsbereiche des Öffentlichen Sektors abdecken:
 re-store: Datenhaltung in relationalen Datenbanken
Intern arbeitet re-motion strikt objektorientiert. Dadurch vermindert sich der
Entwicklungsaufwand bei gleichzeitiger Erhöhung von Wartbarkeit und Wiederverwendbarkeit. Die Datenhaltung erfolgt unabhängig davon in relationalen Datenbanken, nicht zuletzt da sich diese sehr gut in bestehende Betriebskonzepte der
Seite 5/43
Auftraggeber fügen. Die Übersetzung zwischen beiden Welten erfolgt automatisch
durch „objektrelationales Mapping.
 re-form: Web-basierte Benutzerschnittstelle
Basierend auf der Funktionalität von Microsoft ASP.NET bietet re-form sehr weit
gehende Möglichkeiten zur Erstellung von datenbasierten Anwendungen.
Komplexe Aufgaben in Bereichen wie Datenerfassung, Validierung, Navigation und
Darstellung werden von re-strict übernommen, ohne dabei die Flexibilität bei der
Anwendungsimplementierung einzuschränken.
Auch die Durchsetzung der Sicherheitskonfiguration wird von diesen Komponenten
sichergestellt (z.B. Ein/Ausblenden von Feldern oder Navigationsmöglichkeiten).
So wird erreicht, dass dem Benutzer nicht zugängliche Funktionen gar nicht erst
angeboten werden.
 Integration des Desktops
Web-basierte Anwendungen bieten oft nur sehr eingeschränkte Möglichkeiten, mit
lokalen Daten am Arbeitsplatz zu arbeiten. re-motion bietet auch für Browserbasierte Anwendungen eine Vielzahl von komfortablen Integrationspunkten: OfficeDokumente können durch ein .NET Control direkt aus der Web-Anwendung
geöffnet und gespeichert werden (inkl. automatischem Sperren während der
Bearbeitungsdauer), Dateien können per Drag-and-Drop ausgetauscht werden,
der Scanner wird direkt angesteuert, und E-Mails können direkt aus dem MailClient in die Aktenverwaltung registriert werden.
 re-strict: Umfassende Autorisierungsfunktionen
Die Komponente re-strict ermöglicht die Abbildung der Organisationsstruktur nach
verschiedenen Kriterien (hierarchisch, strukturell, rollenbasiert). Zusätzlich
beinhaltet dieses Modul Funktionen zur Definition von Stellvertreterregelungen
sowie (optional) zur Delegation bestimmter Administrationsaufgaben.
Diese reichhaltige Informationsbasis kann direkt zur Definition der Zugriffsberechtigungen herangezogen werden. Dazu werden zu den Entitätsklassen der
Anwendung Access Control Lists (ACLs) erstellt und mit Kriterien aus der
Organisationsstruktur befüllt. Zusätzlich werden zur Berechtigung auch Status der
Entitäten sowie spezielle Berechtigungsstufen („Verschlusskennzeichen“)
herangezogen. Zusätzliche Kriterien können im Rahmen der Anwendungserstellung definiert und implementiert werden.
Die Informationen von re-strict werden auch für die Definition von WorkflowProzessen herangezogen. Besonders bei der Erstellung abstrakter
Musterprozesse ist es sehr hilfreich, auf ebenso abstrakte Elemente der
Organisationsstruktur zurückgreifen zu können.
Bei Bedarf kann re-strict auch als eigenständige Anwendung installiert und
betrieben werden. In diesem Fall können auch unterschiedliche Anwendungen
Berechtigungsinformationen von einer einzigen re-strict-Instanz beziehen.
Seite 6/43
4 Anwendungsschichten
Die Kernanwendung VStV ist in mehreren logisch getrennten Schichten aufgebaut. Das
hat den Vorteil, dass keine unbeabsichtigten Abhängigkeiten entstehen können, die in
Folge die Weiterentwicklung einschränken, verteuern oder gar verhindern. So ist etwa
keine Funktionalität innerhalb der Benutzerschnittstelle realisiert, wodurch sichergestellt
ist, dass auch externe Systeme durch Bereitstellung entsprechender Schnittstellen
möglichst alle Funktionen von VStV ansprechen bzw. nutzen können. Jede der
abgebildeten Schichten kann nur auf darunter liegende Schichten zugreifen.
Abbildung 2: Logisches Schichtenmodell der Kernanwendung PAD NG
Die Schichten im Einzelnen:
 Datenzugriff ist für das Speichern und Laden von Objekten in/aus Microsoft SQL
Server sowie die Erstellung von Datenbankabfragen (Queries) zuständig. Diese
Funktionen werden vollautomatisch von der re-motion-Komponente re-store
übernommen.
 Das Objektmodell ist die Definition von Geschäftsobjekten ("Entitäten", z.B.
Geschäftsstücke oder Verwaltungsstrafanzeigen) sowie deren Beziehungen
zueinander verantwortlich. Es ist außerdem die Basis für die (automatische)
Erstellung eines Datenbankschemas. Das Objektmodell wird durch Objektklassen
in der Programmiersprache C# definiert und beinhaltet die
objektklassenspezifische Geschäftslogik der Anwendung (z.B. Berechnungs-
Seite 7/43
oder Validierungsregeln). Des Weiteren ist das Objektmodell die Basis für die
rollenspezifische Definition von Zugriffsberechtigungen.
 Die Anwendungsfunktionalität beinhaltet Funktionen, die über die
Geschäftslogik einzelner Objektklassen hinausgehen. Dazu gehören Funktionen
wie Protokollieren, Skartierung oder Import und Export. Web-Services und andere
Schnittstellen externer Systeme werden aus dieser Schicht aufgerufen
("ausgehende Schnittstellen").
 Die Schicht Benutzerschnittstelle beinhaltet alle Funktionen zur Bedienung der
Anwendung mittels Web Browser. Sie beinhaltet Formulardefinitionen sowie die
gesamte Ablaufsteuerung und Navigation der Web-Anwendung.
 Die interaktive Komponente des DMS (Dokumentenmanagementsystem) stellt die
Verbindung der Web-Anwendung zu Anwendungen am PC der Benutzer her. Sie
öffnet Dokumente mit lokalen Anwendungen, sperrt diese für die
Bearbeitungsdauer am Server und übergibt den Inhalt nach einer Bearbeitung
wieder an den Server, der dann z.B. eine automatische Versionierung vornehmen
kann.
 Web Services dienen dem Zugriff externer Anwendungen auf Daten und Prozesse
von VStV ("eingehende Schnittstellen"). Sie stellen ausgewählte Daten und
Funktionen bereit. Dabei wird unterschieden zwischen
 internen Services, die exklusiv für den Zugriff anderer Anwendungen im
Rahmen von PAD NG bzw. des jeweiligen PAD-Moduls erstellt werden (z.B.
Web Services für den Erfassungsclient von VStV), und
 Standard-Services, die auch anderen Anwendungen innerhalb und bei Bedarf
auch außerhalb des BM.I (z.B. für Länder) zur Verfügung stehen.
 Alle Zugriffe über Web Services unterliegen denselben Zugriffsbeschränkungen
wie die Verwendung der Web-Anwendung.
Dabei ist zu beachten, dass jedes Modul (Acta Nova, BM.I-Layer, PAD NG, VStV)
Komponenten für jede dieser Schichten bereitstellen kann. Ein typisches PAD-Modul
wird beispielsweise aus Erweiterungen des Objektmodells, einer Reihe von
Anwendungsfunktionen, Formularen für die Benutzerschnittstelle und einigen Web
Services bestehen.
5 Zentrale Datenspeicherung
5.1 VStV Datenbank
Alle Daten von VStV werden von Acta Nova verwaltet und in einer zentralen Instanz von
Microsoft SQL Server gespeichert.
Die Speicherung erfolgt in relationaler Weise, redundanzfrei mit korrekt konfigurierter
deklarativer relationaler Integrität (DRI: Fremdschlüssel, Unique Keys etc.).
Eine Auswertung dieser Datenbank, etwa für OLAP oder Reporting, ist grundsätzlich
möglich. Dabei muss jedoch beachtet werden, dass die Berechtigungen auf
Datenbankebene nicht automatisch durchgesetzt werden können.
Seite 8/43
Obwohl das physische Datenbank-Schema aufgrund der dynamischen VererbungsAbbildung weitgehend von der Konfiguration durch den Administrator abhängig ist,
können doch einige Fixpunkte festgehalten werden:
 Der Primärschlüssel jeder Tabelle ist eine GUID. Andere Entitäten referenzieren
diese GUID als Fremdschlüssel. Ein Foreign Key Constraint sorgt dafür, dass die
referentielle Integrität auch auf Datenbankebene sichergestellt wird.
 Eine Timestamp-Spalte wird bei jedem Update-Vorgang aktualisiert. So können
gleichzeitige Zugriffe auf dasselbe Objekt verhindert werden, die Inkonsistenzen
oder gar Datenverlust zur Folge hätten.
5.2 Zentrales Archiv
Dokumente werden direkt in der SQL Server Datenbank gespeichert. Das hat folgende
Vorteile:
 Erfassung durch die Volltextindexierung von SQL Server, optimierte Abfragen mit
kombinierten Kriterien (Metadaten und Volltext)
 Transaktionale Verarbeitung von Metadaten und Dokumenten, keine
Inkonsistenzen durch divergierende Datenbestände
 Vereinfachter Betrieb, insbes. bei Backup und Recovery und Berechtigungsadministration
Sollte sich im Zuge des laufenden Betriebs die Notwendigkeit zur Auslagerung der
Dokumente aus der Datenbank in das Filesystem ergeben, so könnte folgender
Lösungsansatz angedacht werden:
Dateien werden bei Erstellung in VStV für kurze Zeit in der eigenen Datenbank
vorgehalten und gleichzeitig in das zentrale Archiv übermittelt. Nach einiger Zeit werden
diese automatisch aus der Datenbank von VStV entfernt, um das Datenvolumen gering
zu halten (Entlastung der Infrastruktur). Die Verzögerung sollte größer als die BackupIntervalle sein, um im Fall eines Restore sämtliche Daten zur Verfügung zu haben.
Nach der Löschung der Dokumente in VStV verbleiben nur noch die Links zum
zentralen Archiv erhalten. Das Betrachten der Archivinhalte kann somit auch aus VStV
heraus erfolgen.
6 Benutzerschnittstelle
Die Benutzeroberfläche von VStV Neu ist getrennt nach Exekutive und Behörde um die
speziellen Anforderungen an Anwendungsfälle je Benutzergruppe optimal umzusetzen,
wobei grundsätzliche Paradigmen der Gestaltung der Benutzeroberfläche für beide
Systeme ident sind. Das Exekutivtool von VStV Neu ist vollständig in PAD NG integriert
und bietet damit vollen Zugriff auf alle Daten, Funktionen und Prozesse von VStV Neu.
Die Anwendung wird vom Benutzer im Browser (Internet Explorer) gestartet. Die
Anmeldung erfolgt automatisch über den PVP-Login.
Technisch basiert die Oberfläche auf HTML, CSS und JavaScript. Um eine schnelle und
komfortable Eingabe ohne störende Seitenwechsel zu ermöglichen, wird das Verfahren
AJAX (Asynchronous JavaScript and XML) eingesetzt. Durch den Einsatz der AJAX-
Seite 9/43
Technologie wird auch in Browser-Anwendungen der Komfort der schnellen Eingabe,
wie dies aus der HOST-Anwendung VStV-Polizei der Fall war, Rechnung getragen.
Dabei läuft die Anwendung teilweise unabhängig vom Server innerhalb des Browsers
und lädt nur einzelne Daten vom Server nach. Die Umsetzung innerhalb der
Anwendung erfolgt mit der re-motion-Komponente re-form (rubicon) sowie ASP.NET
WebForms (Microsoft .NET Framework).
Für die Benutzerschnittstelle des DMS wird ein .NET Control im Browser geladen, was
aus Sicherheitsgründen eine entsprechende (automatisierbare) Konfiguration der
Clients erfordert. Zukünftig ist ein Umstieg auf ein Active-X-Control angedacht um den
administrativen Aufwand zur Einrichtung des Arbeitsplatzes zu reduzieren.
Die Schnittstellen wie z.B. EKIS, ZMR, FSR oder IDR werden direkt von VStV Neu
abgefragt. Es ist in diesen Fällen kein Aufruf fremder Anwendungen oder Masken
erforderlich. Dies ermöglicht es dem System einerseits den Aufruf zu dokumentieren
und andererseits die Ergebnisse aus den Fremdsystemen direkt bei der Anzeige in
VStV zu speichern und somit die Nachvollziehbarkeit der Aktenverwaltung weiter zu
steigern.
Die Bedienung ist so gestaltet, dass sie einfach zu erlernen ist (intuitive Anwendung,
Mausbedienung, sprechende Auswahlmöglichkeiten) und dennoch von erfahrenen
Mitarbeitern schnell und effizient bedient werden kann (Tastaturbefehle).
7 Erweiterung von Modulen
Die Komponentenarchitektur von Acta Nova ermöglicht es, einzelne Module
unabhängig voneinander zu entwickeln und zu warten. So können Module nicht nur
neue Elemente hinzufügen, sondern auch bestehende Elemente erweitern und in
vernünftigen Grenzen modifizieren.
Folgende Elementtypen werden in erster Linie von Modulen hinzugefügt und erweitert:
 Das Objektmodell kann um eigene Objektklassen erweitert werden. Dabei können
auch bestehende Klassen erweitert werden, oder durch Vererbung neue Klassen
basierend auf bestehenden Klassen erzeugt werden. Auch Beziehungen zwischen
bestehenden und zusätzlichen Klassen können hinzugefügt werden.
 Neue und bestehende Klassen können mit Geschäftslogik versehen werden, die
etwa Berechnungen oder Restriktionen beinhaltet.
 Beliebige Funktionen und Menübefehle können hinzugefügt werden.
 Eingabeformulare für bestehende und neue Objektklassen können hinzugefügt
werden. Bestehende Formulare können erweitert werden.
 Neue Web Services können die fachliche Funktionalität für andere Anwendungen
zur Verfügung stellen.
 Zusätzliche Prozessdefinitionen steuern die Bearbeitungen im Workflow-Modul
Seite 10/43
Abbildung 3: Hinzufügen von Funktionalität durch Komponenten
Neben der Erweiterung der Kernanwendung PAD NG können für PAD-Module auch
eigene Anwendungen erstellt werden. Ein Beispiel dafür ist der Erfassungsclient von
VStV, der eine einfache Benutzerschnittstelle für die Einmalerfassung durch die
Exekutive bereitstellt.
8 Druck und Versand
Wesentliche Funktionen von VStV Neu sind das vorlagenbasierte Generieren von
Dokumenten sowie deren physischer oder elektronischer Versand. Dazu kommt das
Standardsoftwareprodukt Document Partner von rubicon zum Einsatz.
Document Partner ist eine umfassende Lösung für das Enterprise Output Management,
also das Erstellen und Versenden von Schriftstücken aus Anwendungsdaten. Document
Partner bietet folgende Kernfunktionalitäten:
 Erstellung und Verwaltung von Vorlagen mit Microsoft Word
 Interaktive Erstellung mit Platzhaltern für Datenfeldern
 Fortgeschrittene Funktionen für bedingte Ausgabe von Daten und
Wiederholungen (Tabellen, Listen)
 Wiederverwendung von Vorlagenteilen als Textbausteine
Seite 11/43
 Generierung von Dokumenten aus Daten (XML) und Vorlagen
 Interaktive Bearbeitung generierter Dokumente
 Ganze oder partielle Bearbeitung (lt. Definition in Vorlage)
 Verwendung von Textbausteinen (mit oder ohne Datenfeldern)
 Erzeugung von PDF- oder Postscript-Dateien
 Versand per definiertem Output-Kanal
Für VStV wird außerdem eine Integration der BM.I-Implementierung für Amtssignaturen
und dem seitens des BM.I entschiedenen Dienst für die elektronische Zustellung
bereitgestellt. Je Installation kann eine Url für das zu verwendende AmtssignaturService hinterlegt werden.
Als Druckstraßen-Anbieter werden derzeit hpc-dual und zukünftig auch der BM.ICollector unterstützt. Dabei werden Dokumente von Document Partner gerendert und
anschließend automatisch zum Amtssignaturservice gesendet, um den Signaturblock
auf der Reinschrift anzubringen. Im Anschluss werden nach Möglichkeit mittels sicherer
elektronischer Zustellung über die zentrale Zustellinfrastruktur die Ausgangsschreiben
versendet bzw. an die Druckstraße ausgesteuert.
Grundsätzlich wird in VStV zwischen zwei Versandarten unterschieden:
 Individualdruck: Dokumente werden von Document Partner erstellt, können im
vordefinierten Rahmen aber vom Sachbearbeiter modifiziert werden. Danach
können sie am lokalen Drucker ausgedruckt oder ebenfalls an die Druckstraße
übergeben werden. Die Archivierung der vollständigen Dokumente erfolgt in in
jedem Fall innerhalb von VStV, um eine einfache Nachvollziehbarkeit in der
Historie von Geschäftsfällen zu gewährleisten.
 Massendruck: Konvertierung und Versand einer großen Anzahl gleichartiger
Schriftstücke erfolgen vollautomatisch ohne Benutzerinteraktion. Das Ergebnis
wird je Akt in der Applikation VStV Neu gespeichert und der Status des Versands
vermerkt. Dieser Mechanismus wird beispielsweise für den Versand von
Anonymverfügungen in VStV verwendet.
Seite 12/43
8.1 Massendruck
Abbildung 4: Massendruck in VStV
Beim Massendruck werden die betroffenen Akten durch einen Workflow-Command in
VStV selektiert und zur Erstellung der Formulare an DocumentPartner übergeben.
Document Partner generiert das Dokument anhand einer Vorlage, sodass VStV die
Finalisierung inkl. Anbringung der Amtssignatur durchführen kann. Der Versand an den
definierten Dienstleister zur Zustellung findet nach Generierung des PDFs durch ein
BackgroundService in VStV statt.
Die einzelnen Schritte (jeweils ohne Benutzerinteraktion) sind:
1. VStV erstellt ein XML-Datenpaket mit den Daten für die Dokumentgenerierung
Dieses wird an DocumentPartner übergeben.
2. Document Partner generiert aus der entsprechenden Vorlage ein Dokument und
wandelt dieses in das PDF-Format um.
3. Das unsignierte Dokument wird an die BM.I Amtssignatur gesendet und signiert
retourniert.
4. VStV übergibt das signierte Dokument an den Zustelldienstleister mit dem Auftrag
das Schreiben nachweislich zuzustellen.
Seite 13/43
5. Das Zustellservice (des Zustelldienstleisters) fragt beim Zustellkopf für die
elektronische Zustellung an, ob der im XML-Datenpaket angegebene Adressat
über eine Adresse für die sichere elektronische Zustellung verfügt.
Wenn eine elektronische Zustellung möglich ist, wird das Dokument an das
entsprechende Service übergeben. (Dadurch wird das Service für die Zustellung
nur mit jenen Anfragen belastet, die es auch verarbeiten kann.)
6. Wenn keine elektronische Zustellung möglich ist, wird das Dokument an die
Druckstraße des Zustelldienstleisters übergeben und dort gedruckt, kuvertiert und
mit der entsprechenden Versandart (z.B. RSa-Brief) versendet.
8.2 Individualdruck
Abbildung 5: Individualdruck
Beim Individual-Druck werden die Daten von VStV an Document Partner übergeben.
Document Partner generiert das Dokument anhand einer Vorlage und liefert eine
editierbare Version in Form eines Word-Dokumentes (versehen mit einem EntwurfsWasserzeichen) zurück an die Anwendung VStV zur weiteren Verarbeitung durch den
Benutzer. Die einzelnen Schritte sind:
1. Wie beim Massendruck wird ein XML-Datenpaket übergeben.
Seite 14/43
2. Document Partner generiert daraus ein Microsoft Word Dokument (Office Open
XML: DOCX-Format).
3. Das generierte Dokument wird an VStV retourniert.
4. Mit Microsoft Word und dem optionalen Word Add-in von VStV kann der
Sachbearbeiter das Dokument bearbeiten.
5. Das fertige Word-Dokument wird wieder an Document Partner übergeben.
6. Document Partner konvertiert dieses Entwurfs-Dokument in das PDF-Format.
7. Das Dokument wird signiert und versendet (Entspricht den Schritten 3 bis 6 beim
Massendruck).
8. Das signierte PDF-Dokument wird in VStV beim Geschäftsfall als Ausgangsstück
gespeichert.
8.3 Druckstraßenanbindung
8.3.1 Datenmapping hpc-Dual
deliveryRequest
Mapping in VStV
documentID
Geschäftszahl der Ausfertigung
(Rückscheinnummer)
senderProfileID
Name des HPC Versandprofils, das beim
ausgewählten HPC Versandprofilkatalog
hintelegt ist
quality
Versandqualität (RSa, non-RSa, etc.), die beim
ausgewählten HPC Versandprofilkatalog
hintelegt ist
mimetype
immer „application/pdf“
receiver
enthält Daten zum Empfänger des Formulars
(Ausfertigung)
Receiver.email
bei Ausfertigung ausgewählte Versandaddresse
Receiver.allowEmail
Flag „Elektronische Übermittlung“ bei
Rechtsträger
Receiver.postalAddress
bei Ausfertigung ausgewählte postalische
Adresse
Receiver.postalAddress.countryCode Ländercode (ISO 2) des Staats
Receiver.postalAddress.city
Seite 15/43
Ort
Receiver.postalAddress.postalCode
Postleitzahl
Receiver.postalAddress.street
Straße
Receiver.postalAddress.doorNumber
Hausnummer/Stiege/Tür
Receiver.legalPerson
wird nur befüllt falls Empfänger der Ausfertigung
eine Organisation ist
Receiver.legalPerson.name
Name
Receiver.legalPerson.firmenBuchNr
Identität mit der Klassifizierung
„Firmenbuchnummer“
Receiver.physicalPerson
wird nur befüllt falls Empfänger der Ausfertigung
eine Person ist
Receiver.physicalPerson.dateOfBirth
Geburtsdatum
Receiver.physicalPerson.familyName Nachname
Receiver.physicalPerson.givenName
Vorname
Receiver.physicalPerson.postfixTitle
Namenszusatz
Receiver.physicalPerson.prefixTitle
Titel
document
enthält die Reinschrift
Document.name
die ersten 120 Zeichen des Dokumentnamens
Document.mimeType
MimeType der Reinschrift (application/pdf)
Document.content
base64-codierte Inhalt der Reinschrift
sender
Daten der bei der Erledigung ausgewählten
absendenden Dienststelle
Sender.legalPerson.name
Name
Sender.postalAddress
Addresse der Diensstelle, gleiches Mapping wie
bei receiver.postalAddress
payment
enthält Liste von Zahlscheindaten, falls es vom
Formular unterstützt wird und bei der
Formularvorlage in Administration von VStV das
Flag „Zahlschein andrucken“ gesetzt ist
Payment.kundendaten
Zahlscheinnummer des Akts
Seite 16/43
Payment.amount
Falls Bescheid Teilzahlung der Betrag der Rate,
ansonsten der offene Betrag
Payment.faelligAm
Fälligkeitsdatum der Rate (Bescheid
Teilzahlung)
Payment.zweck1
Payment.zweck2
formatierter Name des Beschuldigten
Payment.empfaengerName
Anzeigename der bei der Erledigung
ausgewählten Dienststelle
Payment.bic
BIC der bei der Erledigung ausgewählten
Dienststelle
Payment.iban
IBAN der bei der Erledigung ausgewählten
Dienststelle
8.3.2 Datenmapping BM.I-Collector
Die Schnittstelle zum BM.I-Collector, welcher die Daten an das BRZ zur
Weiterverarbeitung weitergibt, wird derzeit in VStV-Neu umgesetzt.
REQUEST
Mapping in VStV
MetaData.Transaction.TransactionID
Eindeutige ID des aktuellen Vorganges
MetaData.Transaction.TransactionTS
Aktuelles Datum mit Zeitinformation
MetaData.Mandant
Die in der Mandantenkonfiguration
hinterlegte DUZ Mandant ID (derzeit:
„padaps“)
MetaData.ApplicationDeliveryID
Eindeutige ID für die aktuelle Sendung
MetaData.GZ
Geschäftszahl des Aktes
MetaData.Betreff
Dokumentname der Reinschrift
MetaData.PostZustellung.Qualität
Versandqualität (RSa, RSb, nonRSa), die
beim ausgewählten BMI
Versandprofilkatalog hinterlegt ist
MetaData.PostZustellung.PapierFormat
Fix A4
MetaData.PostZustellung.PostZustellungE
xt.Rsx_Umschlag.RsID
Geschäftszahl der Ausfertigung
(Rückscheinnummer)
Seite 17/43
MetaData.PostZustellung.PostZustellungE
xt.Rsx_Umschlag.Namenszeile
Falls der Empfängername der Erledigung
> 40 Zeichen ist, wird der Name auf
mehrere Zeilen getrennt eingetragen.
MetaData.ApplicationCallbackURL
Leer
SenderProfilID
Name des Versandprofils = Name der
Dienststelle.
Absender
Daten der bei der Erledigung
ausgewählten absendenden Dienststelle
Absender.Name
Name
Absender.Adresse.StaatsCode
Ländercode (ISO 2) des Staats
Absender.Adresse.Postleitzahl
Postleitzahl
Absender.Adresse.Gemeinde
Gemeinde
Absender.Adresse.Strasse
Straße
Absender.Adresse.Tuer
Absender.Email
E-Mail Adresse
Absender.Telefon
Telefon
Empfaenger
enthält Daten zum Empfänger des
Formulars (Ausfertigung)
Empfaenger.NatuerlichePerson
wird nur befüllt falls Empfänger der
Ausfertigung eine Person ist
Empfaenger.NatuerlichePerson.
Identification.Type
Leer
Identification.Value
Leer
Familienname
Familienname
Empfaenger.NatuerlichePerson.Vorname
Vorname
GeburtsDatum
Geburtsdatum
Empfaenger.NatuerlichePerson.TitelVor
Titel (vorgestellt)
Seite 18/43
Empfaenger.NatuerlichePerson.TitelNach
Titel (nachgestellt)
Empfaenger.JuristischePerson
wird nur befüllt falls Empfänger der
Ausfertigung eine Organisation ist
Empfaenger.JuristischePerson.RegisterNr
Leer
Empfaenger.JuristischePerson.
RegisterType
Leer
Empfaenger.JuristischePerson.FullName
Name
Empfaenger.Email
bei Ausfertigung ausgewählte
Versandadresse
Empfaenger.Adresse
bei Ausfertigung ausgewählte postalische
Adresse
Empfaenger.Adresse.StaatsCode
Ländercode (ISO 2) des Staats
Empfaenger.Adresse.Postleitzahl
Postleitzahl
Empfaenger.Adresse.Gemeinde
Gemeinde
Empfaenger.Adresse.Strasse
Straße
Empfaenger.Adresse.Tuer
Sendung.Schriftstueck.MetaData.
Dateiname
Name des Dokumentes
Sendung.Schriftstueck.MetaData.
MimeType
MimeType der Reinschrift (application/pdf)
Sendung.Schriftstueck.Datei
enthält die Reinschrift
Sendung.Zahlschein
enthält Liste von Zahlscheindaten, falls es
vom Formular unterstützt wird und bei der
Formularvorlage in Administration von
VStV das Flag „Zahlschein andrucken“
gesetzt ist
Sendung.Zahlschein.Receiver
Name der Dienststelle
Sendung.Zahlschein.ReceiverBank
Bank der Dienststelle
Sendung.Zahlschein.Amount
Falls Bescheid Teilzahlung der Betrag der
Rate, ansonsten der offene Betrag
Seite 19/43
Sendung.Zahlschein.Purpose
Leer
Sendung.Zahlschein.PaymentReference
Sendung.Zahlschein.CheckNumber
Leer
Sendung.Zahlschein.Repetitions
Fixer Wert: 1
Sendung.Zahlschein.Currency
Fixer Wert: „EUR“
Sendung.Zahlschein.AccoutInfo.Receiver.
InternationalAccount.BIC
BIC der bei der Erledigung ausgewählten
Dienststelle
Sendung.Zahlschein.AccoutInfo.Receiver.
InternationalAccount.IBAN
IBAN der bei der Erledigung ausgewählten
Dienststelle
Sendung.Zahlschein.AccoutInfo.Depositor. leer
InternationalAccount.BIC
Sendung.Zahlschein.AccoutInfo.Depositor. leer
InternationalAccount.IBAN
Seite 20/43
9 Authentisierung und Berechtigungen
9.1 Authentisierung
Für externe Systeme und alle Benutzer wird die Authentisierung über PVP unterstützt.
Dazu ist die Verwendung eines PVP-fähigen Stammportals sowie die Einbindung in das
BM.I-Anwendungsportal erforderlich. Der Benutzer meldet sich dabei über sein
jeweiliges Stammportal beim BM.I-Anwendungsportal an. Dieses gibt die erforderlichen
Header-Informationen und Parameter an die Anwendung VStV weiter.
Ist der Benutzer in der Anwendung VStV noch unbekannt, so wird er auf Basis der im
Header mitgesendenten Informationen automatisch angelegt.
Abbildung 6: Authentisierung von Anwendungen und Benutzer
9.2 Benutzerdaten
Zur Auswertung der Berechtigungsregeln von VStV sind Informationen erforderlich, die
über das PVP-Rollensystem nicht komplett verfügbar sind. Dies betrifft insbesondere
dynamische Berechtigungen die an abstrakte Strukturelemente der Aufbauorganisation
Seite 21/43
geknüpft sind (z.B. „Zuständiger Sachbearbeiter“ oder „Stelle in der Gruppe des
Objekts“).
Benutzerdaten werden beim Ersteinstieg in die Anwendung über das BM.I-Portal neu
angelegt. Die Rolleninformationen sowie die erforderlichen Parameter werden im PVPHeader mitgesendet, sodass die Anwendung VStV die Benutzerdaten korrekt erzeugen
bzw. aktualisieren kann.
Jene Informationen, die nicht über den PVP-Header geliefert werden, wie
beispielsweise Stellvertretungen oder Buchstabenkreise, können nach Anlage des
Benutzers in VStV gewartet werden.
VStV
PVP-Parameter
Gruppe
x-Authenticate-Ou
Benutzername
x-Authenticate-gvGID
Username2
x-Authenticate-userID
Vorname/Nachname
x-Authenticate-cn
Rollen
x-Authenticate-roles
StandardGruppe
Erste Gruppe in welcher der Benutzer eine Rolle hat
Eine direkte Vergabe von Berechtigungen im VStV ist nicht vorgesehen, diese werden
durch das zentral definierte Berechtigungsschema anhand der vergebenen Rollen
berechnet.
9.2.1 Rollen
Folgende Rollen stehen für das VStV-Exekutivtool zur Verfügung:
 Erfasser
 Genehmiger
 Administrator
 GeraeteAdmininistrator
 LandesSupportAdmin
 SupportAdmin
 Datenschutzbeauftragter
 Verbindungstest
Folgende Rollen stehen für das VStV-Behördentool zur Verfügung:
 Leitung
Seite 22/43
 Referent
 Vollzugsreferent
 Protokoll
 Vormerkung
 Statistik
 Budget
 Administration
 LandesSupportAdmin
 SupportAdmin
 Verbindungstest
 Datenschutzbeauftragter
9.3 Anwendungssicherheit
Acta Nova verfolgt ein umfassendes Sicherheitskonzept, dass automatisch allen darauf
basierenden Anwendungen zur Verfügung steht.
Die Authentisierung wird vollständig von den bewährten Technologien des PVP
übernommen.
Die Definition von Berechtigungen erfolgt zentral und abstrakt auf Basis der
Aufbauorganisation (Organigramm). Eine Berechtigung einzelner Objekte ist nicht
erforderlich, es werden je nach Konfiguration immer die jeweils ausschlaggebenden
Eigenschaften der konkreten Objekte herangezogen (z.B. Modul, Eigentümer oder
Status).
Die Durchsetzung von Berechtigungen erfolgt bereits unterhalb der Anwendungsschicht
durch das re-motion Framework. Eine versehentliche Darstellung geheimer Daten oder
eine Änderung gesperrter Daten durch einfache Anwendungsfehler kann somit
weitgehend ausgeschlossen werden.
Alle Berechtigungen werden sowohl in der Benutzerschnittstelle als auch in der ServerAnwendung überprüft. Somit wird sichergestellt, dass Funktionen ohne entsprechende
Berechtigung gar nicht angeboten werden (Benutzerfreundlichkeit), während ein
technisches Umgehen dieser Einschränkungen zu einer Fehlermeldung führt
(Sicherheit gegen Hacking).
Auch technische Angriffe auf die Anwendung, selbst durch grundsätzlich berechtigte
Benutzer, werden schon auf einer technischen Ebene verhindert. So sind viele
klassische Probleme wie sogenannte Buffer Overflows schon durch das Microsoft .NET
Framework ausgeschlossen.
Die häufigsten Angriffe auf Anwendungsebene verwenden SQL Injection oder HTML
Injection. Dabei werden SQL- bzw. JavaScript-Befehle als Eingabewerte an die
Anwendung übergeben. Eine unsichere Anwendung könnte diese Befehle dann an die
Datenbank bzw. den Browser übergeben, wo diese ausgeführt werden. Das re-motion
Framework verhindert diese Angriffsmöglichkeiten grundsätzlich durch konsequente
Verwendung von strukturierten Parametern bei Datenbankabfragen und automatische
Seite 23/43
Kodierung ("Escaping") bei der Darstellung von Benutzereingaben und sonstigen
variablen Werten.
Viele Aktionen lassen sich in Acta Nova durch eine zusätzliche Passworteingabe
absichern, um bei gemeinsam genutzten PCs eine missbräuchliche Verwendung
kritischer Funktionen (etwa "Genehmigung") zu verhindern.
9.4 Abbildung der Organisationsstruktur
Ausgehend von Erfahrungen im Öffentlichen Sektor wurde re-strict mit weit reichenden
Möglichkeiten zur Abbildung von Organisationsstrukturen ausgestattet, die weit über die
üblichen hierarchischen Gruppenmodelle hinausgehen.
Zuerst wird zwischen einer abstrakten und einer konkreten Aufbauorganisation
unterschieden. Die abstrakte Aufbauorganisation legt die Art der vorhandenen
Organisationseinheiten (z.B. Sicherheitsbehörde, Abteilung etc.) und die damit verbundenen Rollen (Leitung, Referent etc.) fest.
Die konkrete Aufbauorganisation bildet die konkreten Organisationseinheiten
hierarchisch ab und ordnet ihnen Mitarbeiter in den zur Verfügung stehenden Rollen zu.
Ein Mitarbeiter kann mehrere Rollen in einer oder mehreren Organisationseinheiten
besitzen. Zusätzlich kann er in einem definierten Rahmen die Stellvertretung anderer
Mitarbeiter übernehmen oder zugewiesen bekommen.
Zur Abbildung der Aufbauorganisation stehen Teilnehmer und Gruppen zur Verfügung.
Jeder Gruppe muss ein Teilnehmer zugeordnet sein. Die Verknüpfung zwischen
Teilnehmer und Gruppe erfolgt über die Eigenschaft „TargetParticipant“ bzw.
„TargetGroupt“. Die Verknüpfung ist 1:1 und wird beim jeweils anderen Objekt
aktualisiert. Teilnehmer, die postalische Anzeigenemfpänger sind, benötigen keine
Gruppenzuordnung.
Beim Teilnehmer sind die Daten des Briefkopfs, wie Adressdaten, Telefonnummer,
Bankdaten und DVR-Nummer hinterlegt. Über die Gruppe wird die Hierarchie der
Aufbauorganisation abgebildet und Daten wie Gruppenname, OKZ und
Sicherheitsbehörde verwaltet.
9.5 Abbildung von Berechtigungen
Berechtigungen werden in Form von Access Control Lists (ACLs) hinterlegt. ACLs
werden bei Objektklassen der Anwendung hinterlegt (z.B. Akt, Person) und können
dabei an Attributszustände gebunden werden (z.B. Bearbeitungsstatus).
Pro Attributszustand kann eine Liste von Kriterien und Rechten hinterlegt werden. Als
Kriterien können Gruppen, Rollen, aber auch komplexere Regeln unter Anwendung der
abstrakten Aufbauorganisation verwendet werden.
9.6 Auswertung von Berechtigungen
Berechtigungen auf folgende Ressourcen werden von re-motion automatisch ausgewertet und durchgesetzt:
 Menüpunkte
Seite 24/43
 Objektoperationen (Öffnen, Ändern, Skartieren etc.)
 Abfragen
 Darstellung geschützter Eigenschaften
Dynamische Aspekte wie die Teilnahme eines Benutzers oder einer Gruppe im
Prozessablauf eines Aktes können von der Anwendung bei der Erstellung des
Sicherheitskontexts berücksichtigt werden. Auch spezifische Anforderungen wie die
Trennung nach Modulen können so direkt in das Konzept von re-strict integriert werden.
So können die Vorteile eines deklarativ konfigurierbaren, ACL-basierten Systems
genutzt werden, ohne auf anwendungsspezifische Anforderungen verzichten zu
müssen.
Seite 25/43
10 Bestehende Schnittstellen im BM.I-Layer
Durch den Einsatz des BM.I-Layer wird eine Vielzahl von Schnittstellen bereitgestellt,
welche unmittelbar in PAD NG und VStV genutzt werden können.
10.1 Exchange-Schnittstellen
Die Schnittstelle wird vom BM.I-Layer bereitgestellt, ist jedoch in VStV Neu nicht im
Einsatz.
Zur automatisierten Eingangserfassung bietet der BM.I-Layer eine Schnittstelle zu
Microsoft Exchange (2003, 2007, 2010). Technisch basiert die Schnittstelle für Microsoft
Exchange für 2003 und 2007 auf WebDav und für Microsoft Exchange 2010 kommen
Web-Services zum Einsatz. Das im BM.I Layer implementierte Background-Service
führt in definierbaren Intervallen Zugriffe auf die konfigurierten Funktionspostfächer
durch.
Die Exchange-Schnittstellen werden dabei zur automatisierten Verarbeitung von EMails von definierten Funktionspostfächern herangezogen. Dabei bieten die ExchangeSchnittstellen folgend angeführte Funktionalitäten:
 Abruf eines oder mehrerer definierten Funktionspostfächer
 Definition des Benutzer-Kontexts
 Konfiguration der Weiterverarbeitung von E-Mails
Abruf eines oder mehrerer definierten Funktionspostfächer
Die Exchange-Schnittstelle bietet die Möglichkeit, für ein oder mehrere
Funktionspostfächer den gewünschten zu überwachenden Quell-Ordner in der ServiceDefinition zu referenzieren. Gemäß Service-Konfiguration können alle auf diesem
Funktionspostfach einlangenden E-Mails über das Acta Nova Exchange Service
abgearbeitet werden.
Zur korrekten Verarbeitung von abzurufenden E-Mails bietet die Schnittstelle zusätzlich
die Möglichkeit der Referenzierung je eines Mail-Ordners für die erfolgreiche und die
nicht erfolgreiche Verarbeitung an.
Definition des Benutzer-Kontexts
Im Rahmen der Konfiguration der Schnittstelle bietet der Acta Nova BM.I-Layer die
Möglichkeit, für das Ausführen des Services einen Benutzer-Kontext zu hinterlegen.
Dabei wird im Rahmen der Definition festgelegt, unter welchem Benutzer, in welchem
Mandanten und unter Berücksichtigung welches Anwendungskontextes die
Verarbeitung der Daten im Acta Nova BM.I-Layer erfolgt.
Zur Authentisierung des Benutzers am abzufragenden E-Mail-Konto besteht die
Möglichkeit der Authentisierung mittels des Service-Benutzers, unter welchem das
Background-Service betrieben wird, sowie der expliziten Nennung eines Domain-Users
in der Service-Konfiguration.
Konfiguration der Weiterverarbeitung von E-Mails
Neben der im obigen Abschnitt angeführten Definition des Benutzer-Kontexts bietet die
Schnittstelle die Möglichkeit, pro Funktionspostfach festzulegen, welcher Workflow-
Seite 26/43
Prozess nach der Verarbeitung von E-Mails als Eingangsstücke automatisiert gestartet
werden soll.
10.2 Aktivitätsprotokollierung für TPA
Acta Nova bietet im BM.I-Layer die im BM.I erforderlichen Mechanismen zur AktivitätsProtokollierung gemäß den Anforderungen des Datenschutzes. Grundsätzlich werden
alle Zugriffe innerhalb des Acta Nova BM.I-Layers in geeigneter und nachvollziehbarer
Form protokolliert. Die Schnittstelle zur Ablieferung der Protokolldaten wird vom BM.I
als Webservice bereitsgestellt. Dadurch sollen die Daten nahezu in Echtzeit an die
TPA-Anwendung gesendet werden. Die Daten werden jedenfalls zuerst in VStV
gespeichert, um keine direkte Abhängigkeit zur Anwendung TPA aufzubauen.
Bereits erfolgreich an TPA übermittelte Protokolldaten können in der Anwendung VStV
nicht mehr durch einen Anwendungsbenutzer online ausgewertet werden sondern nur
über BM.I-interne Strukturen
10.3 EKIS
Acta Nova bietet im BM.I-Layer die Möglichkeit der direkten Durchführung von EKISAbfragen aus der Fachanwendung heraus. Dabei kann eine EKIS-Abfrage direkt im
Zuge der Priorierung nach polizeilichen Objekten (Person, Fahrzeug) vorgenommen
werden.
Die Kommunikation der EKIS-Schnittstelle des BM.I-Layers erfolgt dabei über die durch
das BM.I zur Verfügung gestellte Web-Service-Schnittstelle. Die Authentisierung der
Acta Nova basierten Umgebung erfolgt mittels eines vom BM.I ausgestellten Zertifikates
über das BM.I-Layer Stammportal. Dabei wird die Anwendung VStV berechtigt,
definierte Registerabfragen durchführen zu können.
Der BM.I-Layer bietet neben der Protokollierung der Abfrage im Aktivitätsprotokoll auch
die Dokumentation der Abfragekriterien und Ergebnis-Dokumente als PDF-Dokumente
im beteiligten Geschäftsfall. Dabei werden die in Form von Z-Tags zurückgelieferten
Anfrageergebnisse durch die BM.I-Layer-Anwendung in ein für den Benutzer lesbares
PDF-Format konvertiert.
Zur einfachen Verarbeitung des Ergebnisses werden definierte Rückgabe-Werte in der
Suchergebnis-Liste dargestellt um den gewünschten Treffer rasch zu ermitteln.
Folgende EKIS-Anwendungen stehen über die Schnittstelle zur Abfrage zur Verfügung:
 Kriminalpolizeilicher Aktenindex
 Personeninformation
 Strafregister SA-Auskunft
 Personenfahndung
 Strafregister SC-Auskunft
 Erkennungsdienstliche Evidenz
 Strafregister SC-Auskunft
 KZR-Personenabfrage
Seite 27/43
10.4 IAP
Die EKIS-Schnittstellen werden schrittweise durch die Schnittstelle IAP abgelöst,
wodurch mehr Möglichkeiten für die automatisierte Übernahme von Informationen
angeboten werden. Derzeit wird das Register „IZR“ über die neue IAP-Schnittstelle
abgefragt. Die weiteren Register folgend, sobald die Umstellung seitens BM.I erfolgt ist.
10.5 ZMR
Acta Nova bietet im BM.I Layer die Möglichkeit der direkten Durchführung von ZMRAbfragen aus der Fachanwendung heraus. Dabei kann eine ZMR-Abfrage direkt im
Zuge der Erfassung bzw. Bearbeitung einer Person zur Verifizierung und zum Abgleich
vorgenommen werden.
Die Kommunikation der ZMR-Schnittstelle des Acta Nova BM.I-Layers erfolgt dabei
über die durch das BM.I zur Verfügung gestellte Web-Service-Schnittstelle. Die
Authentisierung der auf Acta Nova basierenden Umgebung erfolgt mittels eines vom
BM.I ausgestellten Zertifikates über das BM.I-Layer Stammportal.
Der BM.I-Layer bietet neben der Protokollierung der Abfrage im Aktivitätsprotokoll auch
die Dokumentation der Abfragekriterien und Ergebnis-Dokumente als PDF-Dokumente
im beteiligten Geschäftsfall.
Ergänzend besteht die Möglichkeit zur Übernahme der Meldedaten in strukturierter
Form in die Anwendung VStV in die Person (inkl. bPK) sowie die Adressen.
Zukünftig ist bei der Abfrage von Personen im ZMR die Verwendung der „kombinierte
Anfrage“ geplant, sodass gleichzeitig im ZMR als auch im ERnP gesucht werden kann.
Die Treffer sollen zusammengeführt und als ein Suchergebnis retourniert werden, wobei
die Treffer aus dem ZMR höher gewichtet werden. Es sollen nur die ersten fünf Treffer
zurückgesendet werden.
Speicherungen von Personendaten in das ERnP sind für spätere Module von PAD NG
vorgesehen, derzeit in VStV jedoch nicht freigeschalten.
10.6 EDIAKT II
Die Schnittstelle wird vom BM.I-Layer bereitgestellt, ist jedoch in VStV Neu bislang nicht
im Einsatz.
Der BM.I-Layer bietet die Funktionalität, Geschäftsobjekte der Aktenverwaltung mittels
EDIAKT-Export auch ohne automatisierte Schnittstelle anderen AktenverwaltungsSystemen bzw. Fachanwendungen elektronisch zur Verfügung zu stellen.
10.6.1
Einen Akt mit EDIAKT exportieren
Die Funktion Einen Akt mit EDIAKT exportieren stellt Funktionen bereit, um einen Akt
aus Acta Nova als EDIAKT-Dokument zur Verfügung zu stellen. Dabei werden der Akt
und die im Akt abgebildeten Informationen des Aktes (Dokumente, Erledigungen) im
EDIAKT-Container abgebildet und exportiert. Zusätzlich wird das erstellte EDIAKTPaket auch im Akt gespeichert, um die Revisionssicherheit der Informationen zu
gewährleisten.
Seite 28/43
10.6.2
Einen Fremdakt mit EDIAKT importieren
Die Funktion Einen Fremdakt mit EDIAKT importieren stellt einen Menüpunkt zum
Import eines EDIAKT-Containers in der BM.I-Layer Anwendung zur Verfügung. Für die
Abbildung von EDIAKT-Eingängen ist das Eingangsstück um die Registerkarte
„EDIAKT Import“ erweitert, in welchem die EDIAKT-Struktur des Eingangs zur
Navigation abgebildet wird.
 Folgende Metadaten des EDIAKT-Pakets werden automatisch auf das
Eingangsstück abgebildet bzw. übernommen:
 Übernahme des Geschäftszeichens vom Akt (Identifikation) in der Eigenschaft
„Fremdzahl“. Sind mehrere Akte im EDIAKT-Paket enthalten, dann werden alle
Geschäftszeichen durch Komma getrennt in die Fremdzahl übernommen.
 Der Betreff des im EDIAKT-Paket referenzierten Aktes wird in den Betreff des
Eingangsstücks übernommen.
 Als Fremddatum wird das Erstellungsdatum des EDIAKT-Pakets
vorgeschlagen.
 Fremddokumente im EDIAKT-Paket können als Dokumente in die BM.I-LayerAnwendung übernommen und zur Weiterverarbeitung herangezogen werden. Ein
neuer Import des EDIAKT-Pakets ersetzt dabei keine vorhandenen Fremdobjekte.
10.7 EDIAKT II für ELAK im Bund
Die Schnittstelle wird vom BM.I-Layer bereitgestellt, ist jedoch in VStV Neu nicht im
Einsatz.
Der BM.I-Layer bietet die Bereitstellung einer XML-basierenden EDIAKT-II-Schnittstelle
für die Kommunikation mit ELAK im Bund (EiB), dem zentralen ELAK System des
Bundes auf Basis der Fabasoft eGov-Suite.
Die Schnittstelle bietet Funktionen zur definierten Übergabe von Daten der
Aktenverwaltung an ELAK im Bund gemäß dem EDIAKT-II Schema. Die Schnittstelle
EiB implementiert die Anwendungsfälle zur Übergabe von Reinschriften an definierte
Empfänger-Dienststellen im Kontext der Abfertigung von Erledigungen.
Weiters adressiert die Schnittstelle ELAK im Bund den Anwendungsfall zur Übergabe
eines Aktes in Form eines Fremdaktes mit den gemäß EDIAKT-II Schema definierten
Eigenschaften und Inhaltsreferenzierungen.
10.7.1
BM.I-Layer  ELAK im Bund
Die Schnittstelle EiB legt fest, welche Anwendungsfälle für eine EiB-Übergabe
unterstützt sind.
Der BM.I-Layer stellt die notwendigen Mechanismen zur Übergabe von Daten der
Aktenverwaltung an das zentrale ELAK System des Bundes zur Verfügung. Dafür
stehen die erforderlichen Mechanismen zur Verfügung um eine Erledigung an einen
EiB-Empfänger im Zuge der Abfertigung von Reinschriften, einen Akt zur Einsicht und
eine Einsichtsbemerkung an EiB zu übermitteln.
Seite 29/43
Über die Funktionalitäten der Katalogverwaltung ist eine manuelle Verwaltung der EiBEmpfänger vorgesehen, da keine Schnittstelle zur dynamischen Beziehung von EiBEmpfängern durch die BRZ-EiB-Schnittstelle zur Verfügung gestellt wird.
10.7.2
ELAK im Bund  BM.I-Layer
Im BM.I-Layer werden die von ELAK im Bund empfangen XML-Pakete im EDIAKT-IISchema als Eingangsstücke mit Fremd-Akt-Informationen dargestellt. Dabei kommen
grundsätzlich die angeführten Use Cases, welche auch für die Übergabe an ELAK im
Bund unterstützt werden zur Anwendung. Dokumente können dabei automatisch aus
dem Paket extrahiert werden.
Die eingetroffenen Eingangsstücke können im BM.I-Layer direkt weiterverteilt werden.
Für den Fall der Einsicht durch ELAK im Bund in einem BM.I-Layer Akt sieht die EiB
Schnittstelle keine automatisierte Rückführung der Einsichtsbemerkung zum BM.ILayer-Akt vor.
10.8 PDF-Amtssignatur
Der BM.I-Layer bietet die Möglichkeit der Anbringung einer elektronischen Amtssignatur
auf Ausgangsstücke in Form von Erledigungen. Aktuell steht im BM.I-Layer die StandAlone-Komponente des E-Government-Innovations-Zentrums (kurz EGIZ) sowie die
vom BM.I bereitgestellte Lösung zum Einsatz zur Verfügung. Je Umgebung kann eine
Amtssignatur-URL hinterlegt werden.
10.9 Manuelle Schnittstellen
Die Möglichkeit wird vom BM.I-Layer bereitgestellt, ist jedoch in VStV Neu nicht im
Einsatz.
Der BM.I-Layer bietet als zentrales Verwaltungswerkzeug auch die Möglichkeit der
Verwaltung von manuellen Schnittstellen. Diese manuellen Schnittstellen können im
zentralen Administrations-Bereich verwaltet und Benutzern mandantenspezifisch als
Favoriten-Liste für die Durchführung von externen Priorierungs-Schritten bzw. externen
Anwendungsaufrufen zur Verfügung gestellt werden.
Manuelle Schnittstellen können über einen Web-Link bzw. Start einer lokalen
Anwendung aufgerufen werden können. Die Liste der manuellen Schnittstellenaufrufe
für HTML-Seiten kann im Administrationsbereich von Acta Nova zentral verwaltet und
beliebig erweitert werden.
11 Ergänzende Schnittstellen in VStV
Gemäß den Anforderungen im Lastenheft VStV Neu wurden neue Schnittstellen im
Projekt definiert, welche in diesem Kapitel aufgelistet sind. Wo Schnittstellen von
externen Partnern bereitgestellt oder aufgerufen werden, müssen diese von den
Partnern selbst implementiert werden.
Die Definition der Schnittstellen erfolgt anhand des SOAP-Protokolls.
Schnittstellendefinitionen werden in Form von WSDL-Beschreibungen und textuellen
Seite 30/43
Erläuterungen erstellt. Alle Schnittstellen sind kompatibel mit der Spezifikation WS-I
Basic Profile, um eine Interoperabilität mit anderen Plattformen (z.B. Java) zu
gewährleisten.
Abbildung 7: Kommunikation über Standard-Schnittstellen
In dem in der Grafik dargestellten Beispiel, implementiert die Anwendung A selbst die
von VStV bereitgestellte Schnittstellenspezifikation, während für die Anwendung B ein
eigener Konnektor erstellt ist. Durch Konnektoren können verschiedenste
Zugriffsmöglichkeiten bis hin zum direkten Datenbankzugriff abgebildet werden. Der
Vorteil von Konnektoren ist, dass bei Änderungen in der Schnittstellendefinition kein
Eingriff in die Anwendung erforderlich ist.
Die in den nachfolgenden Kapiteln angeführten Schnittstellen wurden im Zuge des
Projekts VStV Neu angebunden werden.
11.1 Anliefernde Systeme
Das Kapitel der anliefernden Systeme beschreibt die Möglichkeiten zur Übernahme von
Anzeigen aus externen Anwendungen in VStV. Dabei wird eine einheitliche
Webservice-Schnittstelle eingesetzt, sodass die Integrationskosten sowie die
Wartbarkeit der Anwendung verringert werden.
Seite 31/43
11.1.1
VKS Abstandsmessungen
Es ist vorgesehen, dass die Daten aus dem VKS der Firma Vidit an den
Beweismittelserver des BM.I übergeben werden. Dieser wiederum übergibt die
Anzeigen an den VStV-Connector zur direkten Weiterleitung an die jeweiligen
Empfängerbehörden.
Die Anbindung ist seitens VKS (Vidit) derzeit noch nicht produktiv.
11.1.2
ASFINAG
Die Anzeigen der ASFINAG werden in einem Vorfeldsystem durch ASFINAGMitarbeiter verfasst. Die Rohdaten der Anzeige sollen über eine WebserivceSchnittstelle in den VStV-Connector eingespielt werden.
Die Anbindung ist seitens ASFINAG derzeit noch nicht produktiv.
11.1.3
DAKO
Die Daten der Lenk- und Ruhezeiten werden in der Anwendung DAKO protokolliert und
in einer zip-Datei exportiert. Die zip-Datei wird in einem definierten Datei-Verzeichnis
zur Abholung durch VStV bereitgestellt. Über ein Service von VStV werden die Daten in
das VStV-Exekutivtool importiert und können durch den Sachbearbeiter
weiterbearbeitet und genehmigt werden. Der Versand an die Behörden erfolgt analog
zu manuell in VStV erfassten Anzeigen über den VStV-Connector.
Weitere Details sind in der Spezifikation der Schnittstelle DAKO zu VStV neu definiert.
11.1.4
Einzahlungsüberwachung
VStV unterstützt für die Einzahlungsüberwachung SEPA sowie das vom BM.I bzw. der
PSK auf CREMUL-basierende Format. Über die Schnittstelle der
Einzahlungsüberwachung werden die von der jeweiligen Bank im definierten Format
bereitgestellten Daten in die Applikation importiert.
Folgende Informationen werden beim auf CREMUL-basierenden Format importiert:
 Numeratornummer
 Betrag
 Einzahlungsdatum
 Buchungsdatum
Folgende Informationen werden bei SEPA importiert:
 Kundendaten
 Auftraggebername
 Auftraggeber-Bankdaten (IBAN/BIC, Kontonummer/BLZ)
 Betrag
 Einzahlungsdatum
Seite 32/43
In VStV erfolgt auf Basis der gelieferten Numeratornummer eine Zuordnung zum
betreffenden Akt. Die Daten werden in die Liste der Zahlungen zum Akt gespeichert und
der Betrag der offenen Forderungen entsprechend angepasst. Sofern der Betrag
vollständig getilgt ist, wird der Akt geschlossen und in die Ablage verschoben.
Die zuständige Behörde für die Klärung einer nicht zuordbaren Zahlung wird aus der
Empfänger-Kontonummer (Konto der Behörde) ausgelesen. Gibt es hier
Abweichungen, wird die Zahlung ebenfalls zur Klärung ausgesteuert.
Sofern die Strafverfügung schon versendet wurde (da zu spät eingezahlt wurde), wird
zwar der Betrag in den Forderungen vermerkt, jedoch trotzdem das Verfahren durch die
Behörde eingeleitet. Der Prozess gilt sowohl für Einzahlungen zu Organmandaten als
auch für Anonymverfügungen.
Wurde zur betroffenen Nummeratornummer zu viel eingezahlt, wird im Strafakt ein
entsprechender Überschuss vermerkt, der in der Liste der überschüssigen Zahlungen
zur manuellen Umbuchung aufgelistet wird.
Kann keine eindeutige Zuordnung getroffen werden, so wird ein Eintrag in die Liste der
nicht zuordenbaren Zahlungen gespeichert und muss manuell durch einen
Sachbearbeiter geprüft werden.
Tritt bei der Abarbeitung der Einzahlungen ein technischer Fehler auf, stehen die dazu
relevanten Informationen im Logfile der Importschnittstelle.
11.1.5
Argus Select (Radar, Section Control)
Die Übernahme der Daten aus dem System Argus Select erfolgt über den vom BM.I
bereitgestellten Beweismittelserver für Radaranzeigen. Durch diesen werden die RadarRohdaten aus den Argus-Bundesland-Server in asychronen Batchjobs in eine zentrale
Datenbank geladen. Die Anwendung VStV übernimmt diese Rohdaten, ergänzt sie um
die ZBA-Daten sofern noch kein Beschuldigter ausgefüllt wurde und stellt die Anzeigen
zur Abholung durch die Länder bereit.
Eine direkte Schnittstelle zwischen VStV und Argus Select gibt es somit nicht.
Jene Radardaten die Dienststellen des BM.I betreffen, werden nach den inhaltlichen
Kriterien validiert und in den Aktenbrowser des zuständigen Strafamts gelegt.
Folgende Daten werden je Radaranzeige übermittelt:
Inhalt
Format
Länge
Funktionscode
INT
2
Absendende Behörde (GKZ)
INT
3
Zielbehörde (GKZ)
INT
3
Laufende Nummer innerhalb dieser Übermittlung
INT
6
Satztype zu laufender Nummer
INT
1
Seite 33/43
Deliktscode
STRING
10
Erstellungsdatum d. Datensatzes in EDV-Zentrale
BMI
DATE
8
Erstellungszeit d. Datensatzes in EDV-Zentrale BMI
DATETIME
6
Datum der Anzeige
DATE
8
Geschäftszahl der Anzeige
STRING
30
Name des messenden Beamten
STRING
25
Name des anzeigenden Beamten
STRING
25
Name des Unterschriftsberechtigten
STRING
25
Zielbehörde im Klartext
STRING
41
Marke, Type u. Nummer des Messgerätes
STRING
30
Marke u. Type des Fahrzeuges
STRING
40
Kennzeichen
STRING
10
Fahrzeugart aus Tabelle
CATALOG
3
Datum der Übertretung (Einfahrtsdatum in
SectionCotrol)
DATE
8
Uhrzeit der Übertretung (Einfahrtszeit in
SectionCotrol)
TIME
6
Gemeindegebiet
INT
5
Art des Tatortes – Tabelle
CATALOG
3
Straßenbezeichnung (Anfangs und Endkilometer
SectionControl)
STRING
110
Fahrtrichtung
STRING
32
Geschwindigkeit gemessen
(Durchschnittsgeschwindigkeit bei SC)
FLOAT
3
Übertretung um nnn KMH (Meßtoleranz
berücksichtigt)
FLOAT
3
Straßennummer
STRING
6
Seite 34/43
Straßenkilometer (Beginn der SectionControl)
FLOAT
7
Internationales Unterscheidungszeichen
CATALOG
3
erlaubte Höchstgeschwindigkeit KFG, KDV
INT
3
erlaubte Höchstgeschwindigkeit gem. StVO
INT
3
Messart
CATALOG
2
Kennzeichen-Besonderheit
Datum und Uhrzeit der Ausfahrt aus Section Control
11.1.6
2
DATETIME
14
Vorfeldapplikation Schwerverkehr
Die Schnittstelle übernimmt die Rohdaten aus der Vorfeldapplikation betreffend
Wiegedaten von LKWs vor.
Die Rohdaten werden in einem definierten Datei-Verzeichnis zur Abholung durch VStV
bereitgestellt. Über ein Service von VStV werden die Daten in das VStV-Exekutivtool
importiert und können durch den Sachbearbeiter weiterbearbeitet und genehmigt
werden. Der Versand erfolgt analog zu den im VStV-Exekutivtool erfassten Anzeigen
über den VStV-Connector.
Weitere Details sind in der Spezifikation der Schnittstelle VFA zu VStV Neu definiert.
11.1.7
Wiener Linien
Die Anzeigedaten werden in einem Vorfeldsystem der Wiener Linien erfasst. Die Daten
sollen über eine Webserivce-Schnittstelle in den VStV-Connector eingespielt werden.
Die Anbindung ist seitens Wiener Linien derzeit noch nicht produktiv.
11.1.8
Glücksspiel
Die Anzeigedaten werden in einem Vorfeldsystem der Finanzpolizei erfasst. Die Daten
sollen über eine Webserivce-Schnittstelle in den VStV-Connector eingespielt werden.
Die Anbindung ist seitens Finanzpolizei derzeit noch nicht produktiv.
11.2 Abzufragende Systeme
Die Kommunikation mit externen Anwendungen erfolgt bevorzugt über ein PVP-fähiges
Stammportal. Für die rein BM.I-interne Kommunikation können auch
Direktverbindungen über Webservices eingerichtet werden.
11.2.1
Zulassungsbesitzerabfrage (ZBA)
Die Halterdaten von Fahrzeugen mit inländischen oder ausländischen Kennzeichen
können einerseits durch den Benutzer über die ZBA-Abfrage abgefragt werden, oder
bei Übermittlung der Anzeigedaten über den VStV-Connector in einer Batch-Abfrage
Seite 35/43
abgefragt werden. In den Systemen VStV Exekutive und VStV Behörde wird ZBA
synchron abgefragt. Bei Übermittlung über den VStV-Connector erfolgt die Abfrage im
Batch, wodurch die Antworten asynchron zurück geliefert werden. Bei der Abfrage wird
jeweils nach folgenden Parametern abgefragt:
 Zulassungsland
 Kennzeichen
 Stichtag
Die Daten zu Fahrzeug und Zulassungsbesitzer werden in strukturierter Form
übernommen.
Um eine Abfrage von ausländischen Kennzeichen durchführen zu können muss ein
CBE-RL-Delikt gemäß der definierten Deliktsgruppen in VStV Exekutive in der OZ bzw.
in VStV Behörde im Akt protokolliert sein. Für eine erfolgreiche Abfrage muss das
abzufragende Zulassungsland an der CBE-Richtlinie teilnehmen. Diese Voraussetzung
wird von ZBA geprüft. Die erforderlichen Daten (CBE-RL-Deliktsgruppe,
Zulassungsland) werden bei der Abfrage von VStV-Neu an ZBA übergeben.Durch die
Abfrage von ZBA wird die Schnittstelle zu Flensburg obsolet und somit nicht
implementiert.
11.2.2
Unternehmensregister (UR)
Im Unternehmensregister sind ausgewählte Daten der folgenden Register gespeichert
und abfragbar:
 Firmenbuch
 Gewerberegister
 Vereinsregister
 Ergänzungsregister sonstige Betroffene
Je Datensatz werden, sofern in den anliefernden Registern enthalten, folgende Daten
gespeichert:
 Kennziffer des Unternehmensregisters (KUR)
 Name
 Adresse
 Rechtsform
 Registernummer (Firmenbuchnummer, Steuerschlüssel, zentrale
Vereinsregisternummer)
 Vertretungsbefugte Personen
 Vorname
 Nachname
 Geburtsdatum
 Information ob bPK ermittelbar war
 Personenfunktion (Rolle der Person im Unternehmen)
Seite 36/43
Die KUR (Kennziffer Unternehmensregister) wird vom Unternehmensregister vergeben
und ermöglicht eine registerübergreifende eindeutige Identifizierung der Unternehmen.
Die KUR wird bei der Institution in VStV als Fremdschlüssel gespeichert.
Das Unternehmensregister wird über ein WebService abgefragt, welches über das
Portalverbund-Protokoll authentisiert wird. Unterstützt werden die Methoden zur Suche
nach Unternehmen im UR sowie die Übernahme von Daten zu einem bestimmten
Unternehmen in strukturierter Form.
11.2.3
Führerscheinregister (FSR)
In der Anwendung VStV erfasste Führerscheine können über das Webservice des
Führerscheinregisters abgefragt werden. Dabei wird mit den Personendaten oder
Führerschein/Dokumentnummer angefragt und die Führerscheindaten retourniert und
beim Dokument in VStV gespeichert:
 Führerscheinnummer
 Ausgestellt am
 Ausgestellt bis
 Gruppen
 Ausstellende Behörde
 Auflagen
11.2.4
Adress-Datenbank
Mittels der Anbindung der Adressdatenbank ist die Übernahme von Adressen zu
bebauten Objekten aus dem Gebäude und Wohnungsregister möglich. Bei Erfassung
eines Orts in VStV kann über ein Adresssuchfeld in der Adressdatenbank gesucht
werden. Durch Auswahl eines Suchergebnisses werden die Daten zu Gemeinde,
Gemeindekennzahl, PLZ, Ort und Straße übernommen.
11.2.5
Verkehrsunternehmensregister
Für die Übermittlung von zu meldenden Delikten an das Verkehrsunternehmensregister
(VUR), wird die Anzeige in VStV erfasst und die Rohdaten an das VUR übermittelt.
Die Übermittlung der Daten erfolgt über eine WebService-Schnittstelle.
Daten die an das VUR übergeben werden sind:
 Geschäftszahl
 Datum der Übertretung
 Tatortbehörde
 Lenkerdaten
 Vorname
 Nachname
Seite 37/43
 Geburtsdatum
 KUR
 Deliktscodes (1..n)
Die Übermittlung der Daten wird vom Benutzer über eine Schaltfläche in VStV gestartet.
Die Daten werden über eine WebService-Schnittstelle in XML-Form an das
Verkehrsunternehmensregister übertragen, welche die Zuteilung der Anzeige zu dem
jeweiligen Unternehmen vornimmt. Zur Identifikation des betroffenen Unternehmens
dient die KUR, welche durch Abfrage des Unternehmensregisters übernommen werden
kann. Als Basis der Unternehmensdaten wird sowohl in VStV als auch im
Verkehrsunternehmensregister das Unternehmensregister herangezogen.
11.2.6
Identitätsdokumentregister
Die in VStV erfassten natürlichen Personen können über das BM.I-Webservice im
Identitätsdokumentregister prioriert werden. Dabei wird nach der Dokumentnummer
gesucht.
Das Ergebnis der IDR-Auskunft wird in strukturierter Form bei Legitimationsdokument
der Person gespeichert.
 Dokumentnummer
 Ausgestellt am
 Ausgestellt bis
 Ausstellende Behörde
12 VStV-Connector
Der VStV-Connector dient als zentrale Drehscheibe für den Austausch von
Verwaltungsstrafen. Sämtliche anliefernde Schnittstellen speichern zunächst die Daten
im VStV-Connector. Die Daten werden gemäß den definierten Schemata geprüft und in
der Datenbank gespeichert. Durch Schnittstellen können die Empfänger die für sie
bestimmten Daten in einem standardisierten Format abholen.
In die Anwendung VStV Neu werden nur Daten übernommen, die von den
teilnehmenden Behörden benötigt werden. Dadurch gelangen Anzeigen, für die das
BM.I nur die Drehscheibe ist (z.B. Maut-Anzeigen oder Radar-Anzeigen der Länder),
nicht in die Anwendung VStV Neu. Es wird jedoch bereits im Zuge der Übernahme
eines Datensatzes von einem anliefernden System die ZBA (ggf. auch EUCARIS)
Abfrage im Auftrag für die zuständige Behörde durchgeführt, um den
Zulassungsbesitzer im Falle einer Kennzeichenanzeige bereits dem Empfänger
mitzusenden.
Spezifische anliefernde Systeme die ausschließlich im BM.I zum Einsatz kommen,
haben eine Direktschnittstelle zu VStV, siehe Einzahlungsüberwachung, DAKO oder
VFA.
Seite 38/43
Sobald ein Datensatz dem VStV-Connector übergeben wurde, erhält der Absender eine
Empfangsbestätigung zu diesem Datensatz. Sobald der definierte Empfänger den
Datensatz abgeholt hat, wird eine Zustellbestätigung für den Absender bereitgestellt. In
dieser können zusätzlich auch Verarbeitungsinformationen der Zielumgebung an den
Absender mitgegeben werden (z.B. Datensatz erfolgreich importiert oder Fehler beim
Import aufgetreten inkl. Grund).
Argus Select (Beweismittelserver)
Abstand
ASFINAG
Glücksspiel
FTP
Wr. Linien
Statistik Austria
Bundesländer
VStV-Format Alt
FTP
Anliefernde Bundesländer
Systeme VStV-Format Neu
LänderConnector
Auslaufendes
Format
SOAP
SOAP
SOAP
VStV-Connector
·
·
·
·
·
ZMR
ZBA
EKIS
IDR
IAP
·
·
FSR
VUR
VStV WebAnwendung
SO
SOAP
Spezifische
Systeme
VSTV Neu
AP
BM.I
SO
AP
BRZ
SOAP
·
·
·
·
Einzahlungen
VFA
DAKO
UR
Statistik Austria
Abbildung 8: Schemadarstellung Kommunikationsserver
12.1 Anwendungsfälle
12.1.1
Neue Anzeige einbringen
Ausgangspunkt ist hier eine neue Anzeige, die in verschiedenen Fremdsystemen
erstellt werden kann.
Seite 39/43
Durch einen Auslöser im Fremdsystem wird die SOAP-Aktion „AnzeigenUebermitteln“
des VStV-Connectors aufgerufen und dadurch eine neue Anzeige vom VStV-Connector
in der VStV WebAnwendung mit den gelieferten Daten erstellt.
Im Zuge der Neuanlage wird eine Liste von Vorgängen an den VStV-Connector
übermittelt und danach eine Liste von Verarbeitungsstatus an das einbringende System
zurück gesendet. Liste von Verarbeitungsstatus:
 Erfolgreich: ja/nein
 Fehlermeldungen
 Warnungen
 Vorgangsnummern
12.1.2
Verarbeitungsstatus abholen
Die Fremdsysteme/Empfängersysteme können über die VStV-Schnittstelle alle
Vorgänge abholen, für die sie zuständig sind und den Status „Erhalten“ in der VStVSchnittstelle besitzen. Dem Empfängersystem wird dabei eine Liste von Vorgängen
übermittelt.
In der VStV-Schnittstelle werden die Empfänger/Sender der Fremdsysteme (z.B.:
Asfinag, Radar,…) über folgende Informationen identifiziert:
 PVP-Header-Information
Bei unbekanntem Sendersystem, wird ein User angelegt mit:
 Portal-ID als Username
 Systemkatalogwert (URL für Webansicht)
Jeder Sender muss als Mitwirkender in der VStV-Applikation existieren.
Andernfalls wird ein Fehler ausgegeben wenn der Mitwirkende nicht zugeordnet
ist.
 SOAP Header
Ist kein PVP-Header vorhanden, wird der Sender über den SOAP-Header
identifiziert. Die dabei benötigten External-ID’s werden im VStV Systemkatalog
eindeutig gespeichert.
Wird von einem Fremdsystem ein Vorgang mit unbekanntem Systemkatalog abgeholt,
dann muss sich das Fremdsystem diesen Katalogwert aus den mitgelieferten
Informationen selbst anlegen.
Zusätzlich zu der Empfängeridentifikation, die sich im Header befindet, kann noch
folgende Information mitgeschickt werden:
 Bereits abgeholte Inkludieren
Seite 40/43
12.1.3
Verarbeitungsstatus rückmelden
Über die SOAP Aktion „Verarbeitungsstatus rückmelden“ kann jedes Endsystem den
eigenen Verarbeitungsstatus einer Anzeige an den VStV-Connector zurück melden. In
weiterer Folge werden die so rückgemeldeten Anzeigen mit dem neuen Status der
Endsysteme abgeglichen.
Zu übermittelnde Informationen dabei sind:
 Technische ID
 Beschreibung
 Erfolgreich
 Geschäftszahl Empfänger
 Vorgangsnummer
12.1.4
Verarbeitungsstatus-Liste melden
Mit Hilfe der SOAP-Aktion VerarbeitungsstatusListeMelden kann jedes Endsystem den
eigenen Verarbeitungsstatus für eine Liste von Anzeigen an den VStV-Connector
zurück melden. In weiterer Folge werden die so rückgemeldeten Anzeigen mit dem
neuen Status der Endsysteme, im VStV-Connector abgeglichen.
 requestID
 Empfaenger
 Empfaengersystem
 Erfassungsdatum
 GeschaeftszahlEmpfaenger
 GeschaeftszahlSender
 GesetzlicheFrist
 LegalBasis
 Sender
 Sendersystem
 Vorgangsnummer
12.1.5
Vorgänge abholen
Die SOAP-Aktion VorgaengeAbholen wird verwendet um Vorgänge vom VStVConnector auszulesen und in das eigene System zu holen. Dabei werden nur jene
Vorgänge abgeholt, bei denen das abholende System und das Empfängersystem
übereinstimmen. Des Weiteren kann entschieden werden ob bereits abgeholte
Vorgänge inkludiert werden oder nicht.
Seite 41/43
 requestID
 bereitsAbgeholteInkludieren
12.1.6
Maximale Paketgröße
Die SOAP-Aktion MaximalePaketGroesse liefert die maximal erlaubte Paketgröße
(Größe des Arrays) für die SOAP-Aktionen des VStV-Connectors zurück. Z.B.: dürfen
bei AnzeigeUebermitteln im gesendeten Anzeigen-Array nur so viele Anzeigen
enthalten sein, wie bei "MaximalePaketGroesse" zurückgeliefert wird.
12.1.7
Schriftverkehr übermitteln
Fremdsysteme haben die Möglichkeit, Schriftverkehr zu einer Anzeige an die VStV
Schnittstelle zu übermitteln.
13 Länderconnector
Der Länderconnector wurde für die Übermittlung der Anzeigen an die Bundesländer
implementiert und bereitgestellt. Mit Hilfe des Länderconnectors werden die
Anzeigedaten aus dem VStV-Connector in das definierte Länderformat gemäß dem
Dokument VSTVSchnittstellendefinition.pdf übertragen.
Die Anzeigen werden je Bundesland in einem .txt-File zusammengefasst, welches
täglich vom BM.I zur Statistik Austria kopiert wird, wo es für die Länder zur Abholung
bereit liegt. Die Länder melden nach Abholung des Files den Verarbeitungsstatus
zurück, welcher je Akt im Connector gespeichert wird.
Werden keine Bestätigungssätze zurück gemeldet, so werden die Anzeigen nach 15
Tagen erneut versendet.
Seite 42/43
14 Abbildungsverzeichnis
Abbildung 1: BM.I-Layer Überblick ................................................................................................................1
Abbildung 2: Logisches Schichtenmodell der Kernanwendung PAD NG .....................................................7
Abbildung 3: Hinzufügen von Funktionalität durch Komponenten ..............................................................11
Abbildung 4: Massendruck in VStV .............................................................................................................13
Abbildung 5: Individualdruck .......................................................................................................................14
Abbildung 6: Authentisierung von Anwendungen und Benutzer .................................................................21
Abbildung 7: Kommunikation über Standard-Schnittstellen ........................................................................31
Abbildung 8: Schemadarstellung Kommunikationsserver ...........................................................................39
Seite 43/43

Architekturkonzept - E

Transcription

Similar documents

Imagebroschüre 2014 - winwin Office Network AG

AG-IZ - Identity Management Glossar - E

ELAK Konzept 1.1, Teil A

marke41 Ausgabe 3, 2011

Information and Communication Technologies