Inhalt

Kommunikationsarchitektur

Die österreichische E-Government-Strategie erfordert die aktive Erarbeitung behördenübergreifend standardisierter Schnittstellen und bundesweit gültiger Spezifikationen in der Kooperation zwischen Bund, Ländern, Städten und Gemeinden. Die im Rahmen der Arbeitsgruppen erarbeiteten Ergebnisse dieser Kooperation basieren, wenn möglich, auf internationalen Normen und Standards oder lehnen sich an diese an.

Die typischerweise in einem Verwaltungsverfahren und im Backoffice benötigten E-Government-Elemente fügen sich zu einem "Big Picture E-Government-Architektur" zusammen. Dazu gehören neben den einzelnen Basisbausteinen auch Anwendungen, die Module für Online-Applikationen und die Komponenten des Konzepts "Bürgerkarte". Die Protokolle (Spezifikationsdokumente und Konventionen) der Kommunikationsarchitektur fungieren im Sinne der Interoperabilität als verbindender Mörtel (Schnittstellen) zwischen diesen Bausteinen und Services, wobei die einzelnen XML-Spezifikationen oftmals zwiebelschalenartig aufgebaut sind.

Die folgenden XML-Spezifikationen behandeln vor allem die Datenebene, während der Styleguide für Online-Formulare, Online-Dialoge und Webanwendungen das User-Interface beziehungsweise das Layout und die Prozesse allgemein betreffen:

  • XML-Eingangsprotokoll
  • XML-Strukturen für Geschäftsobjekte
  • XML-Baukasten
  • XML-Struktur für Personendaten
  • EDIAKT II / EDIDOC
  • ELAK-Transaktionen
  • XML-Suchanfragen
  • SOAP Faults
  • Diakritische Zeichen

XML-Eingangsprotokoll

Anträge, Anzeigen, Gesuche oder andere Eingaben können an die Behörden in unterschiedlicher technischer Art und Weise, aus verschiedensten Systemen übermittelt werden. In jedem Fall muss zur Nachvollziehbarkeit von Eingängen in ein Aktensystem eine Protokollierung möglich sein, um die erfolgreiche Übergabe von Eingaben an eine elektronische Eingangsstelle festzuhalten und im Rahmen des Abschlussdialogs an die antragstellende Person rückmelden zu können. Mit dem XML-Eingangsprotokoll (XML-e) wurde ein Standard dafür definiert, unabhängig davon, ob die Eingangsdaten vom behördeneigenen Formularservice oder einer "fremden" Stelle übergeben werden. Von der elektronischen Eingangsstelle wird ein XML-Datensatz erzeugt, welcher in einem ELAK (Elektronischer Akt), Fachinformations- oder Archivsystem abgelegt und bei Bedarf von unterschiedlichen Anwendungen verarbeitet werden kann.

Das XML-Eingangsprotokoll bildet den Rahmen für alle Daten, die rund um einen Eingang anfallen. Das sind die eigentlichen, im Antrag enthalten Eingangsdaten sowie die hinzugefügten Protokollierungsdaten und zusätzliche von der Behörde intern benötigte Daten.

XML-Strukturen für Geschäftsobjekte

XML-Geschäftsobjekte (XML-g) ist eine Empfehlung für ein effizientes Vorgehen bei der Modellierung von XML-Strukturen für die Kommunikation zwischen Behördenapplikationen. Die Modellierungsempfehlungen haben unter anderem für die Erstellung elektronischer Antragsformulare Gültigkeit.

XML-Baukasten

Der XML-Baukasten stellt eine Konvention dar, welche organisatorische und technische Vorgaben für die Gestaltung fachspezifischer XML-Datenstrukturen von elektronischen Anträgen macht. Diese sollen auf in der Verwaltung einheitlichen Basiselementen und Basistypen aufbauen, für welche Design-Vorgaben und der organisatorische Erweiterungsprozess beschrieben werden. Außerdem werden Empfehlungen für die Verwendung von Basistypen und -elementen in eigenen Schemata gegeben. In elektronischen Verfahren kommen die im XML-Baukasten definierten Elemente und Typen im Element Eingangsdaten des Eingangsprotokolls zur Anwendung.

XML-Struktur für Personendaten

Der sogenannte Person Data Record dient der eindeutigen Beschreibung der (natürlichen und juristischen) Person durch die zusammenhängenden Informationsblöcke Person, Adresse, Telefonnummer, … und findet in allen personenbezogenen Prozessen im E-Government-Verwendung.

Applikationen, die auf dieser XML-Struktur aufbauen, können diese nach ihren Anforderungen ableiten, einschränken oder erweitern. Der übergeordnete gemeinsame Personenbegriff definiert Elemente sowohl für natürliche als auch juristische Personen. Das Element mit den Angaben zur natürlichen Person definiert etwa Namen, alternative Namen (zum Beispiel Künstlername), Familienstand, Geschlecht, Geburtsort, Geburtsdatum, Staatsbürgerschaft und so weiter. Das Identifikationselement für juristische Personen beinhaltet unter anderem den vollständigen Namen, Alternativnamen sowie Organisations- und Rechtsform.

Das Schema beschreibt außerdem einen abstrakten Adressbegriff mit verschiedenen Ausprägungsformen wie Telefonnummern, Web- oder Postadressen und die dafür jeweils spezifischen Merkmale.

EDIAKT II / EDIDOC

EDIAKT wurde als Standardformat für die Kommunikation zwischen den verschiedensten öffentlichen Einrichtungen (Behörden, Gerichte, öffentliche Unternehmen) entwickelt, da deren Aktenverwaltungs- und Bearbeitungssysteme zwar elektronische Akten, Geschäftsfälle und Geschäftsstücke mit Dokumenten verwenden, diese Objekte je nach Software jedoch herstellerspezifisch unterschiedlich und nicht nach einem einheitlichen Standard aufgebaut sind. Im Zuge der Weiterentwicklung und zunehmenden Verbreitung von ELAK-Systemen wurde der Standard zum aktuellen EDIAKT II weiterentwickelt. Die Daten werden in sogenannten EDIAKT-Paketen zusammengefasst. Diese bestehen aus:

  • Metadaten, die einen Akt, einen Geschäftsfall, ein Geschäftsstück oder ein Dokument beschreiben,
  • Prozessdaten zu Prozessinstanzen und Aktivitäten gemäß dem Standard XPDL der Workflow Management Coalition,
  • Inhaltsdaten aus Akt, Geschäftsfall, Geschäftsstück und Dokument,
  • verfahrensspezifische Fachdaten die jedem Objekt hinzugefügt werden können.

Um den verschiedenen Anforderungen der Betreiber von ELAK-Systemen gerecht zu werden, besitzt EDIAKT eine 4-stufige Hierarchie, deren unterstes Element das Dokument ist. Dieses beinhaltet eine Datei im Originalformat, die – wenn das Originalformat nicht einem Standardformat entspricht – auch in einem Standardformat beigelegt sein muss.

Ein oder mehrere Dokumente sind in einem Geschäftsstück zusammengefasst. Dieses stellt das kleinste versendbare Paket von Objekten in EDIAKT II dar. Zusätzlich kann das Geschäftsstück gemeinsam mit weiteren Stücken in einem übergeordneten Geschäftsfall enthalten sein. Behörden ohne eigenes ELAK-System können empfangene EDIAKT-Pakete mithilfe des kostenfreien EDIAKT-Viewers lesen. Die aktuelle Version erlaubt das Auslesen von Meta- und Prozessdaten, das Darstellen der enthaltenen Dokumente und die Überprüfung der digitalen Signatur beziehungsweise des elektronischen Siegels.

EDIAKT dient nicht nur als Schnittstelle zwischen verschiedenen ELAK Systemen, sondern soll auch verstärkt für den internen Austausch zu Fachanwendungen beziehungsweise Archivsystemen zur Anwendung kommen. Gemeinsam mit den Werkzeugen EDIAKT-Viewer und Creator bildet der XML-Standard EDIAKT II in Ergänzung zum Standarddokumentenformat PDF/A die Basistechnologie für die Langzeitarchivierung von Akten.

Dieses Format kann in Hinkunft auch zunehmend eine zentrale Rolle bei geforderter Vorlage von Originalakten im Instanzenweg spielen.

Eine Erweiterung der bestehenden EDIAKT II Spezifikation aufgrund von Erfahrungswerten beziehungsweise technischen Rahmenbedingungen zu EDIDOC ist in Umsetzung begriffen.

Links

ELAK-Transaktionen

Mit EDIAKT wurde ein einheitlicher Standard für den Transport von Akteninformationen geschaffen. Die Konvention ELAK-Transaktionen geht einen Schritt weiter und definiert für Fachinformations- sowie elektronische Aktenbearbeitungssysteme Funktionen und Schnittstellen für den automatisierten Austausch von EDIAKT-Paketen über Web Services. Damit ist es nicht mehr notwendig, EDIAKT-Pakete zu exportieren, zwischen zu speichern und nach erfolgter Übermittlung wieder zu importieren.

Viele Verwaltungen arbeiten heute schon mit elektronischen Aktenbearbeitungssystemen und verwaltungsübergreifenden Fachinformationssysteme. Zudem gewinnen zum Beispiel zentrale Register immer mehr an Bedeutung für die elektronische Verwaltung. Die Konvention stellt einen Standard dar, um diese verschiedenartigen Informationssysteme über produktunabhängige Schnittstellen leichter koppeln zu können und so die Verwaltungssysteme interoperabler zu machen und besser integrieren zu können. Verwaltungsdaten, die in Verfahren benötigt werden und verwendet werden dürfen, können so effizienter in den Arbeitsfluss eingebunden werden.

Die Spezifikation ELAK-Transaktionen baut auf mehreren Basis-Spezifikationen der IKT-Strategie auf und hat die Umsetzung folgender Anwendungsfälle zum Ziel:

Die vorliegende Spezifikation zu ELAK-Transaktionen positioniert sich wie folgt in dem gegebenen Spezifikations-Rahmenwerk des österreichischen E-Governments beziehungsweise greift auf die folgenden Basis-Spezifikationen zurück:

  • XML-Baukasten
  • XML-Eingangsprotokoll
  • EDIAKT II
  • PersonData
  • SOAP-Faults

XML-Suchanfragen

Die XML-Spezifikation für Suchanfragen (XML-sw) stellt einen standardisierten Rahmen für die Entwicklung von Schnittstellen für die Suche, Abfrage und Rückgabe von Informationen aus E-Government-Applikationen wie etwa Registern bereit.

Die Konvention spezifiziert 2 Anwendungsfälle: die Suche mit Attributen, welche zu mehreren Treffern führen kann, und die Suche mit der Ergebniskennung einer vorhergehenden Suche, die genau einen Treffer liefern muss. Es werden gemeinsame XML-Elemente für alle Suchanfragen der beiden Use Cases, ein Mechanismus zum segmentweisen Abfragen von großen Ergebnismengen, Konventionen für das Wildcarding sowie Fehler-Codes und Vorgaben für eigene Codes bereitgestellt. Die Konvention orientiert sich soweit möglich an bestehenden Implementierungen konkreter Registerabfragen.

SOAP Faults

Gemäß den Prinzipien der IKT-Strategie (Informations- und Kommunikationstechnik) wird für die Kommunikation zwischen E-Government-Anwendungen der internationale offene Standard SOAP verwendet. Dabei werden Nachrichten mit entsprechenden Transportinformationen im XML-Format versehen und mittels etablierter Internet-Protokolle wie HTTP oder SMTP übermittelt. Im Rahmen dieser Verbindungen treten mitunter Probleme auf, die Fehler an der aufrufenden Applikation erzeugen. Während Protokolle wie HTTP-Fehlermeldungen spezifizieren (zum Beispiel Fehlercode 404: File not Found), die an die Applikation zurück übermittelt werden, gibt es für SOAP keine applikationsübergreifenden einheitlichen Fehlercodes.

Für die österreichische Verwaltung empfiehlt die Konvention SOAP-Faults (XML-sf) generell die Rückgabe von Fehlern. In Entwicklungsumgebungen erzeugt dies eine Ausnahme, die entsprechend abzufangen ist. Damit wird die technisch einheitliche Behandlung von Fehlern in der Kommunikation zwischen Webservice-orientierten E-Government-Applikationen erreicht. Darüber hinaus werden Klassen von Fehlercodes definiert, welche die Einordnung der Fehlerquelle und leichtere organisatorische Behandlung ermöglichen.

Diakritische Zeichen

Diakritische Zeichen sind jene Zeichen der lateinischen Schrift, die aus den Buchstaben A bis Z durch Hinzufügen diakritischer Marker wie etwa Umlaut, Akzent oder Ogonek entstehen. Weiters zählen auch Sonderbuchstaben, die vor allem bei in lateinischer Schrift geschriebenen Sprachen benutzt werden, sowie Ligaturen dazu. Die Sprachen benachbarter europäischer Staaten verwenden etwa 400 diakritische Zeichen. In Österreich ist der Einsatz von diakritischen Zeichen im Personenstandswesen und damit zum Beispiel im Zentralen Melderegister rechtlich vorgeschrieben.

Um alle Zeichen dieser Sprachen gleichzeitig zu nutzen, muss als Zeichensatzcodierung Unicode eingesetzt werden. Diese Codierung wird aufgrund ihrer Zukunftssicherheit vom Standardisierungsgremium World Wide Web Consortium (W3C) als Standardcodierung für Webapplikationen empfohlen. Alle gängigen Datenbanksysteme, Betriebssysteme und Programmiersprachen unterstützen Unicode.

Um Interoperabilität zu gewährleisten und Inkonsistenzen von Daten zu vermeiden, sollten alle neu entwickelten E-Government-Applikationen Unicode unterstützen. Nicht Unicode fähige Applikationen sollten auf der Webschnittstelle Unicode akzeptieren und intern umwandeln.