Modernes E-Government mit Fabasoft egov

Transcription

modernes e-government
mit fabasoft egov-forms
Modernes E-Government mit
Fabasoft egov-Forms
Thomas Bühringer, Peter Stürmer
ISBN: 3-902495-15-4
Alle Rechte der Verbreitung, auch durch fotomechanische Wiedergabe, Tonträger
jeder Art, auszugsweiser Nachdruck oder Einspeicherung und Rückgewinnung in
Datenverarbeitungsanlagen aller Art, sind vorbehalten.
Es wird darauf verwiesen, dass alle Angaben in diesem Fachbuch trotz sorgfältiger
Bearbeitung ohne Gewähr erfolgen und eine Haftung der Autoren oder des
Verlages ausgeschlossen ist.
Aus Gründen der einfacheren Lesbarkeit wird auf die geschlechtsspezifische
Differenzierung, z.B. Benutzer/-innen, verzichtet. Entsprechende Begriffe gelten im
Sinne der Gleichbehandlung grundsätzlich für beide Geschlechter.
Fabasoft und das Fabasoft Logo sind registrierte Warenzeichen der Fabasoft AG.
Microsoft, MS-DOS, Windows, das Windows-Logo, Windows 95, Windows 98,
Windows Me, Windows XP, Windows NT, Windows 2000, Windows Server, Active
Directory, Outlook, Excel, Word, PowerPoint, Visual Studio, Visual Basic, Visual C++
sind entweder registrierte Warenzeichen oder Warenzeichen der
Microsoft Corporation.
Alle anderen verwendeten Hard- und Softwarenamen sind Handelsnamen
und/oder Marken der jeweiligen Hersteller.
© Fabasoft Intl. Software GmbH & Co KG, Linz 2005
Honauerstraße 4, 4020 Linz
Tel.: +43 (732) 606162
http://www.fabasoft.at
Gestaltung: SCHRANGL’PRESLMAYR’SCHAURHOFER Marketing GmbH, Linz
Satz: idee quadrat Werbeagentur Langanke & Stolz OEG, Linz
Druck: Estermann Druck GmbH, Aurolzmünster
Fabasoft eGov-Forms
inhaltsverzeichnis
2005
1
Fabasoft eGov-Forms
einleitung
____________________________________________________________________
1
________________________________________________________________________________________________
11
1.1 Ziel und Gliederung des Buches ____________________________________ 13
1.2 Erläuterung zum Beispiel ________________________________________ 14
1.3 Trennung von Formularentwicklung und Formularserver ________________ 21
2
standards
______________________________________________________________________________________________
25
2.1 Styleguide______________________________________________________________________________________________________ 25
Online-Formular Styleguide ________________________________________________________________________________ 25
Druckstyleguide ________________________________________________________________________________________________ 27
2.2 Web Accessibility Initiative
__________________________________________________________________________
28
2.3 Digitale Signatur ____________________________________________________________________________________________ 30
Wie funktioniert die digitale Signatur __________________________________________________________________ 31
Schnittstelle – Security-Layer 1.2 ________________________________________________________________________ 35
Schnittstelle – CAPICOM __________________________________________________________________________________ 36
2.4 Elektronische Zahlung
3
architektur
__________________________________________________________________________________
37
________________________________________________________________________________________________
41
3.1 Betreiber ______________________________________________________________________________________________________ 41
Hardwarearchitektur __________________________________________________________________________________________ 41
Softwarearchitektur __________________________________________________________________________________________ 44
3.2 Administrator
3.3 Bürger
________________________________________________________________________________________________
45
__________________________________________________________________________________________________________
45
5
Hardwarearchitektur __________________________________________________________________________________________ 45
Softwarearchitektur __________________________________________________________________________________________ 45
Bürgerkarte in Österreich __________________________________________________________________________________ 46
4
fabasoft formulardesigner
____________________________________________________
51
4.1 Zielgruppe und Beweggründe ________________________________________________________________________ 51
4.2 Aufbau und Elemente ____________________________________________________________________________________ 52
Antragsprojekt __________________________________________________________________________________________________ 53
Formularblockelemente ______________________________________________________________________________________ 56
Plausibilitätsprüfung __________________________________________________________________________________________ 61
Formularblöcke ________________________________________________________________________________________________ 63
Formularschaltflächen________________________________________________________________________________________ 70
Formularelemente ____________________________________________________________________________________________ 71
Formularseiten__________________________________________________________________________________________________ 74
Antragsformulare ______________________________________________________________________________________________ 78
4.3 Projektorientierter Ansatz und Einbindung des Workflows
____________________________
81
4.4 Übertragung auf den Formularserver ______________________________________________________________ 82
5
formularentwicklung im
generischen interface
________________________________________________________________
85
5.1 Datenmodell eines Formulars________________________________________________________________________
Datentypen ____________________________________________________________________________________________________
Wiederverwendung von Datenstrukturen – Standardblöcke ____________________________________
Datenmodellierung anhand eines Beispiels __________________________________________________________
86
88
90
91
5.2 Visuelle Repräsentation eines Formulars ______________________________________________________ 99
Formularsystem ______________________________________________________________________________________________ 99
Dynamische Inhalte __________________________________________________________________________________________ 100
Formularkopf und Formularfuß __________________________________________________________________________ 105
Formularlayout anhand eines Beispiels ________________________________________________________________ 106
5.3 Ablaufsteuerung in Formularen ____________________________________________________________________ 107
Anwendungsschritte mit GUI ____________________________________________________________________________ 108
Anwendungsschritte ohne GUI __________________________________________________________________________ 108
Schrittsequenzen ____________________________________________________________________________________________ 109
Die Laufzeitumgebung ______________________________________________________________________________________ 110
Ablaufmodellierung anhand eines Beispiels ________________________________________________________ 112
5.4 Betrieb des Formulars __________________________________________________________________________________ 113
Starten aus einem Webbrowser ________________________________________________________________________ 113
5.5 Einbindung von PDF-Formularen
6
__________________________________________________________________
weiterbearbeitung
eingebrachter formulare
115
119
________________________________________________________________________
Sicherheitsaspekte ______________________________________________________________________________________________________120
6.1 Push-Verfahren ________________________________________________________________________________________________________121
Formularserver ____________________________________________________________________________________________________________122
Backoffice __________________________________________________________________________________________________________________123
XML-Schema ______________________________________________________________________________________________________________130
6.2 Pull-Verfahren __________________________________________________________________________________________________________139
Auslösen des Transports in der Fabasoft eGov-Suite ____________________________________________________140
Ablauf des Transports__________________________________________________________________________________________________140
Ablauf der Datenübernahme in der eGov-Suite ____________________________________________________________142
7
schnittstelle für
automatisierte antragstellung
151
__________________________________________________________
7.1 XML-Schema ____________________________________________________________________________________________________________153
7.2 Ablauf________________________________________________________________________________________________________________________154
7
8
schnittstellen zu weiteren
fabasoft softwareprodukten
157
______________________________________________________________
8.1 Fabasoft eGov-Suite/WBT ______________________________________________________________________________________157
8.2 Fabasoft CMS
159
__________________________________________________________________________________________________________
SOAP-Aktion auf Seiten von Fabasoft eGov-Forms ______________________________________________________160
Einbindung auf Seiten von Fabasoft CMS ____________________________________________________________________162
9
module für online-applikationen
165
____________________________________________
9.1 MOA-ID ________________________________________________________________________________________________________ 165
Einstellungen in der Administrations-Konfiguration
______________________________________________
166
Aufruf des MOA-ID-Logins ________________________________________________________________________________ 168
9.2 MOA-SP/SS __________________________________________________________________________________________________ 169
Konfiguration für die Signaturprüfung ________________________________________________________________ 169
Aufruf der Signaturprüfung ________________________________________________________________________________ 171
10
funktionsbeschreibung
173
________________________________________________________________________
10.1 Anwendungsschritte mit GUI ________________________________________________________________________ 173
Editorseite anzeigen
________________________________________________________________________________________
173
Lesen und Akzeptieren ______________________________________________________________________________________ 173
10.2 Antragsschritte mit GUI ________________________________________________________________________________ 174
Bürgerkarte auswählen ____________________________________________________________________________________ 174
Formularseite bearbeiten __________________________________________________________________________________ 174
Vollständigen Antrag anzeigen __________________________________________________________________________ 174
Zusammenfassung anzeigen ______________________________________________________________________________ 175
10.3 Anwendungsschritte ohne GUI ______________________________________________________________________ 176
Argument setzen______________________________________________________________________________________________ 176
Ausdruck auswerten ________________________________________________________________________________________ 176
SMTP-Mail versenden ______________________________________________________________________________________ 176
10.4 Anwendungsschritt für Ablaufkontrolle ________________________________________________________ 177
Anwendungen ausführen __________________________________________________________________________________ 177
11
ausblick
____________________________________________________________________________________________________
179
12
glossar
____________________________________________________________________________________________________
181
13
abbildungsverzeichnis
14
literaturverzeichnis
______________________________________________________________
191
________________________________________________________________________
194
9
1
11
1 einleitung
B2G, C2G, G2G – diese und ähnliche Schlagworte stellen eine Herausforderung für bürgerfreundliche Behörden dar. Sie beschreiben die Interaktion von Behörden mit externen Kommunikationspartnern wie Bürgern (C2G), Unternehmen (B2G) und natürlich auch anderen Behörden (G2G). Fabasoft
bietet Standardlösungen zur optimalen Umsetzung der Externwirkung von Behörden und Interessenvertretungen.
Mit E-Government steht der öffentlichen Verwaltung eine moderne Technologie zur Verfügung, um der Allgemeinheit die Leistungen über das Internet besser anbieten zu können. Ein gesamter Überblick über die Möglichkeiten des E-Governments im deutschsprachigen Raum wurde bereits im Buch „E-Government mit Fabasoft: Vom
Antrag bis zur Zustellung“ [GrAr04] gegeben. Ein wichtiger Bestandteil des gesamten E-Governments ist die Kommunikation mit Bürgern, Kunden, privatwirtschaftlichen Unternehmen und anderen öffentlichen Einrichtungen.
Zur Umsetzung der Kommunikation bietet Fabasoft seit vielen Jahren Standardsoftwareprodukte für ContentManagement (siehe Buch „Das Fabasoft Content-Management-System“ [Hofm04]), Online-Formulare und elektronische Zustellung (siehe Buch „Fabasoft Zustellung“ [Kast05]) an.
Aus Abbildung 1 ist ersichtlich, dass die elektronische Antragstellung am Anfang des durchgängigen E-Governments steht. Bürger können über eine klar strukturierte Online-Plattform (siehe [Hofm04]) mit der Behörde in Verbindung treten und Online-Verfahren (Anträge, Wünsche, Beschwerden, etc) initiieren.
Im Rahmen des Standardproduktportfolios stellt Fabasoft hinreichende Software für die Umsetzung von Formularserverlösungen zur Verfügung. Das Standardsoftwareprodukt Fabasoft eGov-Forms stellt in diesem Zusammenhang eine Plattform für Online-Formulare dar. Zur Entwicklung von Online-Formularen dient der grafische
Formulardesigner der Fabasoft eGov-Suite, mit dessen Hilfe Online-Formulare einfach und schnell gestaltet werden können.
Im Zuge der Produktentwicklung ist Fabasoft stets bestrebt, sowohl weltweit gültige (SOAP, XML, WAI, etc.)
als auch national geltende Standards einzuhalten. Das österreichische E-Government Gütesiegel wurde Fabasoft eGov-Forms am 5. November 2003 verliehen (siehe [Lein05]). Bei diesem Gütesiegel handelt es sich um eine
Initiative des IKT-Boards der österreichischen Bundesregierung. Bürgerinnen und Bürger sollten mit seiner Hilfe
Abbildung 1
Durchgängiges
E-Government
Abbildung 2
E-Government Gütesiegel
1. Einleitung
1.1 Ziel und Gliederung des Buches
rasch erkennen können, ob ein Produkt, eine Webseite oder eine Transaktion hinreichend sicher und qualitativ
hochwertig gemäß den Richtlinien des österreichischen E-Government Gütesiegels ist.
Das österreichische E-Government Gütesiegel wurde dem Produkt Fabasoft eGov-Forms für folgende Kriterien
überreicht:
Styleguide für E-Government Formulare
Modul für Online-Applikationen (MOA), Identifikation und Authentifikation
MOA, Signaturprüfung und Signaturerstellung
Security-Layer Spezifikation
WAI Richtlinien
Auswahl der Bürgerkartenumgebung
1.1
Ziel und Gliederung des Buches
Fabasoft eGov-Forms ist das Standardprodukt von Fabasoft für die Umsetzung der Externwirkung von Behörden.
Ziel dieses Buches ist die Darstellung des Funktionsumfanges von Fabasoft eGov-Forms inklusive der Formularentwicklungsumgebungen und Datenübernahmemöglichkeiten in eine Backoffice-Anwendung anhand eines
durchgehenden Beispiels.
Als Grundlage für die Erstellung und Publikation von Online-Formularen beschreibt das Kapitel 2 unterschiedliche
Standards (z.B. Styleguides oder digitale Signatur), die vom Produkt Fabasoft eGov-Forms unterstützt werden.
Kapitel 3 gibt einen Überblick über die nötige Hard- und Softwarearchitektur einer Fabasoft eGov-Forms-Umgebung beim Betreiber und Bürger. Speziell wird hier auf die Unterschiede zur Fabasoft Referenzarchitektur eingegangen. Die Software-Umgebung umfasst vor allem notwendige Drittsoftware.
Kapitel 4 und 5 beschäftigen sich mit unterschiedlichen Herangehensweisen an die Umsetzung von Online-Formularen. Hierzu zählt die Umsetzung mittels Fabasoft Formulardesigner (Kapitel 4) und mittels generischem
13
Interface (Kapitel 5). Jedes dieser Kapitel stellt anhand eines durchgehenden Beispiels die Vorgehensweise für
die Umsetzung dar und erläutert die einzelnen Schritte.
Kapitel 6 beschäftigt sich mit der Weiterbearbeitung der vom Antragsteller eingegebenen Daten. Hier wird das
Pull- und Push-Verfahren erläutert.
Die Möglichkeiten einer automatisierten Datenübergabe an ein Fabasoft eGov-Forms-Service werden im Kapitel 7 dargestellt.
Kapitel 8 zeigt Schnittstellen des Produkts Fabasoft eGov-Forms mit anderen Fabasoft Standardprodukten. Im
Speziellen handelt es sich hierbei um Fabasoft eGov-Forms/WBT und Fabasoft CMS.
Authentisierung und Identifikation des Antragstellers sowie die Signatur von Antragsdaten und ihre Überprüfung
sind Inhalt des Kapitels 9.
Kapitel 10 gibt einen kleinen Überblick über die wichtigsten Elemente, die zum Erstellen von Onlineformularen
mit Fabasoft eGov-Forms benötigt werden. Es werden überblicksweise die am häufigsten benötigten Funktionen
bei der Verwendung des Produkts Fabasoft eGov-Forms erläutert.
Abschließend bietet Kapitel 11 einen Ausblick auf zukünftige Entwicklungen und Anforderungen an ein Formularserver-System.
Nicht Ziel des Buches ist die detaillierte Beschreibung einzelner Funktionalitäten und Use Cases im Sinne eines
Benutzerhandbuches.
1.2
Erläuterungen zum Beispiel
Dieses Buch erläutert die Entwicklung von Online-Formularen mit dem Standardsoftwareprodukt Fabasoft eGovForms anhand eines durchgängigen Beispiels. Bei der Recherche nach einem geeigneten Musterformular wurde
primär der österreichische Amtshelfer [Bund05] im Internet durchsucht. Diese prämierte österreichische OnlinePlattform dient als Anlaufstelle für Bürger, die sich über Behördenwege, Formulare etc. informieren möchten.
Aktuell werden dort rund 500 Formulare teils zum Download als PDF bzw. RTF, teils zum Online-Ausfüllen bereit-
1. Einleitung
1.1 Ziel und Gliederung des Buches
1.2 Erläuterungen zum Beispiel
gehalten. Laut einer Statistik dieser Plattform stehen an der Spitze der Nachfrage die österreichische Hundeanmeldung und der Antrag auf Ausstellung einer Wahlkarte. Da der Antrag auf Ausstellung einer Wahlkarte im
Gegensatz zur Hundeanmeldung lediglich zu Zeiten einer Wahl interessant ist, dient das Formular für die Hundeanmeldung als Grundlage für die Beispiele in diesem Buch.
Im Folgenden wird ein Überblick über die Beschaffenheit des Beispielformulars gegeben, um die nötige Grundinformation über den Umfang der Beispiele zu erhalten.
Abbildung 3
Fertiges Beispielformular
(Seite 1)
15
BEZEICHNUNG
TYP LT. E-GOVERNMENT
STYLEGUIDE
ANMERKUNG
Antragsteller
N-PERS2
Standardblock
Adresse
ADR1
Standardblock
Kontakte
KONT1
Standardblock
Angaben zum Hund
Details siehe Tabelle 2
individueller Block
BEZEICHNUNG
TYP
ANMERKUNG
Rufname *
Zeichenkette
Geschlecht *
Werteliste
„männlich“, „weiblich“
Geburtsjahr *
Ganzzahliger Wert
4 Ziffern
Rasse *
Zeichenkette
Farbe *
Zeichenkette
Datum der Übernahme des
Hundes *
Datum
Wie haben Sie den Hund
erhalten? *
Werteliste
Tabelle 1: Formularblöcke für Seite 1
Tabelle 2: Formularblockelemente für Formularblock „Angaben zum Hund“
„Kauf“, „Wurf“, „Geschenk“,
„Anderes“
1. Einleitung
Das Formular besteht aus einem Formularkopf, der den Adressaten (die Behörde), dessen Logo, den Titel, eine
Kurzbeschreibung und Hinweise zum Ausfüllen beinhaltet. Es folgen auf der ersten Formularseite vier Formularblöcke, die maßgebliche Informationen über den Hund sowie dessen Halter abfragen (Details zu den Formularblöcken und Formularblockelementen siehe Aufstellung in Tabelle 1 und Tabelle 2). Als Navigationselemente
sind nach den Formularblöcken Schaltflächen für „Weiter“ und „Abbrechen“ enthalten. Abgeschlossen wird das
Formular mit einem Formularfuß, der eine Formularkennung und einen Link zum Seitenanfang beinhaltet.
Abbildung 4
(Seite 2)
Die zweite Seite des Beispielsformulars enthält die Standardelemente Header, Footer und Navigationsschaltflächen. Auf ihr werden Informationen über den Vorbesitzer und die gewünschte Bezahlungsart abgefragt. Tabelle
3 bis Tabelle 5 beinhalten die Angaben zu dieser Seite.
17
BEZEICHNUNG
TYP
ANMERKUNG
Vorbesitzer
individueller Block
Adresse Vorbesitzer
ADRK1
Standardblock
Bezahlung
individueller Block
Anmerkungen zum Antrag
ANM
Standardblock
BEZEICHNUNG
TYP
ANMERKUNG
Familienname
Zeichenkette
Vorname(n)
Zeichenkette
Tabelle 3: Formularblöcke für Seite 2
Tabelle 4: Formularblockelemente für Formularblock „VorbesitzerIn“
BEZEICHNUNG
TYP
ANMERKUNG
Zahlungsart *
Werteliste
„Erlagschein“,
„Bar bei Abholung“
Abgaben und Gebühren in EUR *
Gleitkommawert
max. 3 Vorkomma- und
2 Nachkommastellen
Tabelle 5: Formularblockelemente für Formularblock „Bezahlung“
1. Einleitung
Nachdem sämtliche für die Antragstellung notwendigen Daten auf den ersten beiden Seiten abgefragt wurden,
wählt man auf Seite 3 die gewünschte Umgebung für die digitale Signatur aus.
Abbildung 5
(Seite 3)
Die Auswahl der gewünschten Signaturumgebung ist speziell in Österreich relevant, da hier zwischen der Signatur über einen lokal installierten Smartcard-Reader und einer Server-seitigen digitalen Signatur über das
Mobiltelefon unterschieden wird. Bei der Umsetzung von digitalen Signaturen über die Schnittstelle CAPICOM
(siehe Kapitel 2.3) kann auf die Auswahl der Signaturumgebung verzichtet werden.
Nach Eingabe der Daten und Auswahl der Signaturumgebung werden die Daten in einer rein lesbaren Darstellung dem Antragsteller präsentiert und können hier digital signiert werden. Einen abschließenden Eingangsbericht erhält der Antragsteller direkt am Bildschirm sowie per Mail.
19
Abbildung 6
(Seite 4)
Abbildung 7
Abtransport ins Backoffice –
Grundsätzliches Zusammenspiel
1. Einleitung
1.3 Trennung von Formularentwicklung und Formularserver
Die Übertragung an die zuständige Behörde erfolgt per Push-Methode. Die Methode beruht darauf, dass die
empfangende Behörde ein Web-Service für die Entgegennahme von Formulardaten zur Verfügung stellt. Alternativ bietet Fabasoft eGov-Forms die Möglichkeit eines Pull-Mechanismus. Hierbei holt sich die BackofficeAnwendung der Behörde die Daten direkt über ein Web-Service von Fabasoft eGov-Forms ab.
1.3
Trennung von Formularentwicklung und Formularserver
Beim Produkt Fabasoft eGov-Forms handelt es sich um einen Formularserver für Online-Formulare, der auf einer
eigenen Hardware direkt beim Kunden installiert ist. Für die Entwicklung von Online-Formularen stehen mehrere Varianten zur Verfügung:
Formularentwicklung mit Hilfe des Formulardesigners der Fabasoft eGov-Suite (siehe Kapitel 4)
Formularentwicklung mit Hilfe des generischen Interfaces von Fabasoft eGov-Forms (siehe Kapitel 5)
Diese Trennung von Entwicklungs-, Test- und Produktiv-Umgebung (siehe Abbildung 8) dient zur qualitativ hochwertigen Umsetzung von Online-Formularen (vgl. [GrAr04]):
Entwicklung
Die Entwicklung eines Online-Formulars sollte in einem abgegrenzten System durchgeführt werden. Der Formularersteller erstellt die benötigten Online-Formulare und extrahiert diese nach einer abgeschlossenen
Entwicklung. Das Ergebnis ist eine Softwarekomponente, die in eine Testumgebung eingespielt werden
kann. Diese muss die vorausgesetzten Softwarekomponenten beinhalten.
Testvorgang
In einem Testvorgang wird das Online-Formular auf Vollständigkeit geprüft und eventuelle Änderungen dem
zuständigen Formularersteller mitgeteilt.
Fehlerbehebung (Bugfixing)
Nachdem ein Formularersteller eine Liste von weiteren Anforderungen bekommen hat, setzt dieser die
Anforderungen um und übermittelt eine neu generierte Softwarekomponente an die Testumgebung.
21
Abbildung 8
Entwicklungs-, Test- und
Produktiv-Umgebung
Qualitätssicherung
Der Testvorgang und die Fehlerbehebung müssen so lange wiederholt werden, bis die Softwarekomponente mit den Online-Formularen den Qualitätsanforderungen entspricht. Hierfür wird die Softwarekomponente ein letztes Mal aus der Entwicklungsumgebung extrahiert und abschließend in die Produktionsumgebung
geladen. Ab diesem Zeitpunkt sind die Online-Formulare für den Bürger verfügbar.
1. Einleitung
1.3 Trennung von Formularentwicklung und Formularserver
Zusammenfassung
Abbildung 9
Einleitung
23
2
25
2 standards
Die Einhaltung von nationalen und internationalen Standards ist Voraussetzung für qualitativ hochwertige und längerfristig gesicherte Online-Verfahren. Fabasoft legt hohen Wert auf die Einhaltung
gültiger Standards. Details dazu werden in diesem Kapitel dargestellt.
Dieses Kapitel stellt die für das Produkt Fabasoft eGov-Forms relevanten Standards dar. Hierzu zählen Styleguide, Web Accessibility Initiative (WAI), digitale Signatur und elektronische Zahlung. Bewusst wird auf die
Beschreibung von XML, SOAP, HTML, etc. verzichtet, da eine Online-Applikation ohne Einhaltung dieser Standards ohnehin nicht denkbar ist.
2.1
Styleguide
E-Government sollte in erster Linie bürgerfreundlich und einfach sein. Ein unerlässlicher Punkt ist die einheitliche behördenübergreifende Gestaltung von Online-Formularen. Aus diesem Grund wurde der österreichische EGovernment Styleguide entwickelt. Vergleichbare Styleguides für Deutschland, die Schweiz oder England sind
derzeit zwar angedacht, aber noch nicht verfügbar.
Online-Formular Styleguide
Für die Gestaltung von Online-Formularen wurden in Österreich durch die Stabsstelle IKT-Strategie des Bundes
Richtlinien im Rahmen des E-Government-Styleguide (aktuelle Version 1.3) vorgegeben [MiWi04a]. Diese Richtlinien sollen eine hohe Qualität und ein einheitliches Auftreten der Online-Dienste österreichischer Verwaltungseinheiten sicherstellen.
Zu den grundlegenden Vorgaben dieses Styleguides zählen:
weitgehend einheitliche und modulare Struktur durch Standardbausteine (z.B. Antragsteller, Anschrift)
einheitliches Layout und Farbgebung
einheitliche Navigationselemente
Identifikation des Antragstellers mittels Bürgerkarte [ASIT05] (vgl. Kapitel 9.1)
Texte sollten bürgerfreundlich aufbereitet und in leicht verständlicher, klarer Umgangssprache formuliert
sein.
Formulare sollten auch von Menschen mit Benachteiligung (z.B. Sehbehinderten) ausgefüllt werden können.
Als Mindestmaß gilt die Erfüllung von Stufe A nach den Richtlinien der Web Accessibility Initiative (WAI)
(vgl. Kapitel 2.2)
Darauf basierend definiert der Styleguide für Online-Formulare das einheitliche Layout. Es werden Wertebereiche für die Positionierung von Eingabefeldern, Icons und Hilfetexten vorgegeben. Für manche Elemente wird
auch die Farbgebung vorgeschrieben.
Der grundlegende Aufbau eines Styleguide-konformen Online-Formulars wird in Abbildung 10 dargestellt.
Abbildung 10
E-Government Styleguide
2. Standards
2.1 Styleguide
Im Zuge des Styleguides wurden für die Entwicklung von Online-Formularen Standardblöcke [MiWi04b] definiert, die in öffentlichen Formularen häufig vorkommen. Hierzu zählen unterschiedliche Darstellungen von:
natürlichen Personen
nicht natürlichen Personen (juristische Personen, Vereine, etc.)
Adressen
Kontaktinformationen
Schlussendlich soll es dem Antragsteller möglich sein, einen roten Faden durch alle Online-Formulare zu erkennen. Die einheitliche Farbgebung der einzelnen Formularteile innerhalb einer Behörde spielt bei der optischen
Gestaltung eine erhebliche Rolle. Es muss eine einheitliche Corporate Design durch alle Online-Formulare einer
Behörde durchgezogen werden. Dies macht es dem Antragsteller leichter Online-Formulare auf Anhieb einer
Behörde zuzuordnen.
Fabasoft hat sich im Zuge der Verleihung des E-Government-Gütesiegels [Lein05] für das Produkt Fabasoft eGovForms zur Einhaltung der im österreichischen E-Government Styleguide definierten Richtlinien verpflichtet und
unterstützt darüber hinaus die verantwortlichen Gremien bei der Weiterentwicklung.
Druckstyleguide
Im Zusammenhang mit dem Styleguide für Online-Formulare gibt es Überlegungen und Richtlinien für die Aufbereitung von Formulardaten in der Druckansicht eines Online-Formulars, den so genannten Druckstyleguide
[WiMi04]. Im Wesentlichen sind hier folgende Rahmenbedingungen zu berücksichtigen:
Ausdruck im Format A4
Seitennummer muss angebracht werden
Position der Adresse der Behörde für Versand mittels Fensterkuvert
Abbildung von Wertelisten (Select-Boxen) auf Papier
Darstellung von Hilfetexten, die im Online-Formular über Link erreichbar sind
27
Das Produkt Fabasoft eGov-Forms bietet derzeit die Möglichkeit des Ausdrucks einer Schlussübersicht der
Antragstellung, die sämtliche vom Antragsteller eingegebenen Daten darstellt. Weiterentwicklungen in diesem
Zusammenhang zielen auf die detaillierte Umsetzung der Anforderungen aus dem Druckstyleguide und eine
jederzeitige Möglichkeit des Ausdrucks.
Auch hier gilt, dass vergleichbare Styleguides in anderen Ländern derzeit nicht verfügbar sind.
2.2
Web Accessibility Initiative
Menschen mit Behinderung werden mit dem vermehrten Einsatz von visuellen Gestaltungselementen in Webseiten und Online-Formularen von deren Nutzung ausgegrenzt, da behindertengerechte Hilfsmittel diese Webseiten und Online-Formulare nicht richtig verarbeiten können. In erster Linie betrifft dies sogenannte Screen Reader, die textuelle Inhalte in synthetische Sprache umwandeln und für sehbehinderte Menschen hör- und dadurch
nutzbar machen. Überdies gibt es für blinde Menschen spezielle Tastaturerweiterungen, die sogenannte BrailleZeile, welche die interpretierten Texte in einem Ausgabebereich in Blindenschrift umsetzen.
Behörden und Unternehmen sollten daher die anwendbaren Richtlinien und Standards im Zuge der Entwicklung
von Online-Verfahren berücksichtigen. Die Web Accessibility Initiative (WAI) [W3Co05] des World Wide Web
Consortium (W3C) definiert Standards und Richtlinien zur barrierefreien Webgestaltung. Aktuell sind vierzehn
Richtlinien bzw. allgemeine Prinzipien für ein zugängliches Design von Webseiten verfügbar. Die Richtlinien gliedern sich in Checkpunkte, wobei jedem Checkpunkt eine Priorität zugeordnet ist.
Priorität 1 bedeutet, dass die Webinhalte diesen Checkpunkt erfüllen müssen.
Priorität 2 bedeutet, dass die Webinhalte diesen Checkpunkt erfüllen sollen.
Priorität 3 bedeutet, dass die Webinhalte diesen Checkpunkt erfüllen können.
Abgeleitet von der Priorität der einzelnen Checkpunkte und der Erfüllung durch Webinhalte können drei Stufen
der Konformität definiert werden:
Konformität Stufe „A“: Alle Checkpunkte der Priorität 1 sind erfüllt.
2. Standards
2.1 Styleguide
Konformität Stufe „Double-A“: Alle Checkpunkte der Priorität 1 und 2 sind erfüllt.
Konformität Stufe „Triple-A“: Alle Checkpunkte der Priorität 1, 2 und 3 sind erfüllt.
Die folgende Liste gibt einen kurzen Überblick über die Richtlinien zur Erstellung von barrierefreien Webinhalten, die besondere Bedeutung für Online-Formulare haben. Detaillierte Informationen über die Erstellung von
barrierefreien Inhalten sind auf der W3C-Website zu finden [W3Co05].
Verweise und Bilder sollen mit einem Alternativtext ausgezeichnet werden, der den verknüpften Inhalt
beschreibt (Priorität 1).
Man soll sich nicht auf Farben allein verlassen, da diese zur Hervorhebung von wichtigen Informationen auf
Monochrom-Monitoren oder von Menschen mit gestörtem Farbsehvermögen (z.B. Rot-Grün-Blindheit) nicht
richtig wahrgenommen werden (Priorität 1). Zudem sollte für genügend Kontrast zwischen Vordergrund- und
Hintergrundfarbe gesorgt werden (Priorität 2 für Bilder, Priorität 3 für Text).
Barrierefreie Webinhalte sollten veröffentlichten formalen Grammatiken (z.B. HTML 4.0) entsprechen
(Priorität 2).
Formatierungen sollten aufgrund von relativen anstelle von absoluten Einheiten erfolgen. D.h. man sollte
z.B. bei Schriftgrößenangaben „em“ oder Prozentsätze anstelle von „pt“ oder „cm“ verwenden (Priorität 2).
Befinden sich Sprachübergänge im Webinhalt (z.B. englische Begriffe), so sollten diese entsprechend
gekennzeichnet werden (Priorität 1).
Tabellen sollten ausschließlich zur Darstellung tabellarischer Informationen verwendet und nicht zu Layoutzwecken missbraucht werden (Priorität 2). Zusätzlich müssen Datentabellen mit Zeilen- und Spaltenüberschriften ausgestattet sein (Priorität 1).
Textbasierte Systeme und Screen Reader unterstützen Technologien (wie etwa JavaScript) oft nicht oder nur
unzureichend, daher müssen Webinhalte auch einwandfrei funktionieren, wenn diese Technologien deaktiviert sind oder nicht zur Verfügung stehen (Priorität 1).
Bewegte (Priorität 2) oder blinkende (Priorität 1) Elemente eines Webinhalts können bei manchen Menschen
epileptische Anfälle auslösen. Eine möglichst ruhige Gestaltung der Webinhalte ist daher zu bevorzugen.
29
Webinhalte sollten geräteunabhängig und für eine Bedienung über die Tastatur ausgelegt sein (Priorität 1).
Popup-Fenster dürfen nur nach vorheriger Information (z.B. Hinweis im Alt-Text „Popup-Fenster“) des Benutzers geöffnet werden (Priorität 2).
Webinhalte sollten auf W3C-Standards (z.B. HTML und CSS) aufbauen (Priorität 2).
Navigationselemente sollten in konsistenter Weise verwendet werden (Priorität 2).
Textblöcke sollten kurz gehalten und durch Überschriften gegliedert werden (Priorität 1).
Fabasoft eGov-Forms verwendet zur Darstellung von Online-Formularen eine spezielle Anwendungssteuerung
(Dispatcher). Diese Anwendungssteuerung (Details dazu sind im Buch „Softwareentwicklung mit der Fabasoft
VAPP-Technologie“ [KlWi04] beschrieben) liefert einen barrierefreien Inhalt nach den Richtlinien des W3C und
kann gemäß den Anforderungen des Betreibers an das Corporate Design der Behörde (des Unternehmens) angepasst werden. Im Zuge dieser Anpassung ist der Entwickler für die Einhaltung der WAI-Richtlinien im Hinblick auf
die Gestaltung der Textblöcke und Überschriften sowie die Gliederung der darzustellenden Daten verantwortlich.
Da eine Anwendungssteuerung für sämtliche Online-Formulare einer Behörde verwendet werden kann, besteht
die Möglichkeit, Änderungen in Bezug auf Corporate Design an einer zentralen Stelle durchzuführen.
Um auch die Website einer Behörde (eines Unternehmens) barrierefrei gemäß den Richtlinien des W3C gestalten
zu können, stellt das Content-Management-System von Fabasoft die nötige Funktionalität zur Verfügung. Details
hierzu können in dem Buch „Das Fabasoft Content-Management-System“ [Hofm04] nachgelesen werden.
2.3
Digitale Signatur
Die Richtigkeit der niedergeschriebenen Angaben bei herkömmlichen Papierverträgen mit nicht vernachlässigbarem Inhalt wird in der Regel durch alle beteiligten Parteien bestätigt. Bei der Einreichung eines Formulars, was
im weitesten Sinne einem Vertragsschluss entspricht, ist dies nicht anders. Dadurch wird der Partei, die das Formular entgegennimmt, die Richtigkeit der gemachten Angaben bestätigt. Umgekehrt wird dem Einbringer durch
das Anbringen eines Eingangsstempels oder dem Aushändigen einer Kopie des Formulars die ordnungsgemäße
Übergabe quittiert.
2. Standards
2.3 Digitale Signatur
Mit dieser gegenseitigen Bestätigung wird üblicherweise der Zeitpunkt der Durchführung der Übergabe vermerkt, um Terminstreitigkeiten der beteiligten Parteien auszuschließen.
Über diese gegenseitigen Bestätigungen hinaus wird oftmals eine Legitimation der einreichenden Partei, meist
in Form eines Lichtbildausweises, verlangt.
Welche Möglichkeiten stehen aber bei Online-Formularen zur Verfügung, diese gegenseitige Bestätigung durchzuführen? Mangels der Verfügbarkeit anderer Lösungen findet man heute zahlreiche Online-Formulare, die das
Setzen eines Häkchens erzwingen, um die Daten weiterzuleiten und so zumindest ansatzweise eine Form der
Bestätigung durch den Einbringer ermöglichen. In Wahrheit kann dies aber nur dann als ausreichend anerkannt
werden, wenn einerseits der Streitwert vernachlässigbar ist, und andererseits dem Ausfüllenden keinerlei Schaden durch das Senden des Formulars entstehen kann, da er ja keine Bestätigungen erhält. Genauso wenig wird
der Zeitpunkt des Absendens rechtskräftig und -verbindlich dokumentiert.
Aus diesem Grund wird eine Lösung benötigt, die technisch soweit fortgeschritten ist, dass Fälschungen nur mit
verhältnismäßig hohem Aufwand, am besten unmöglich, durchführbar sind. Weiters muss eine gesetzliche
Deckung vorhanden sein. Es würde im Streitfall nichts nützen, wenn zwar ein technisch einwandfreier Unterschriftenersatz verwendet wird, dieser aber vom Gesetz nicht als Unterschrift anerkannt wird.
Zu diesem Zweck wurde am 19.01.2000 im Amtsblatt der Europäischen Gemeinschaften (ABl. L 13 vom
19.01.2000, S. 12) die Richtlinie 1999/93/EG des Europäischen Parlaments und des Rates über gemeinschaftliche Rahmenbedingungen für elektronische Signaturen veröffentlicht. Die Richtlinie musste in allen Mitgliedstaaten bis zum 19.07.2001 umgesetzt werden (siehe [RTRG05]).
Als derzeit in allen Mitgliedsstaaten anerkannte technologische Umsetzung dieser elektronischen Signatur gilt
die digitale Signatur.
Wie funktioniert die digitale Signatur?
Alle heute bekannten Umsetzungen von digitalen Signaturen verwenden asymmetrische oder Public-Key Verschlüsselungs-Verfahren. Dies bedeutet, dass ein kryptographisches Verfahren angewandt wird, das nicht auf
31
einem geheimen Schlüssel basiert, sondern auf einem Schlüsselpaar. Ein Schlüssel bleibt dabei geheim und ist
im Idealfall nicht einmal dem Besitzer selbst direkt zugänglich, wohingegen der andere öffentlich und für jedermann frei verfügbar ist.
Dieses Schlüsselpaar ist aufeinander abgestimmt, man kann aber niemals oder nur mit enormen rechnerischem
Aufwand von einem Schlüssel auf den anderen schließen. Die beiden Schlüssel ergänzen sich, indem jeweils
einer als Argument einer mathematischen Funktion verwendet werden kann, und zum Ausführen der Umkehrfunktion der andere Schlüssel als Argument benötigt wird. Das heißt, wird mit einem Schlüssel eine Verschlüsselungsoperation durchgeführt, so kann diese ausschließlich mit dem anderen Schlüssel des Paars, und keinem
sonst, wieder umgekehrt werden.
Diese Kryptoverfahren werden auf binäre Daten angewandt, im Falle eines Online-Formulars beispielsweise auf
eine XML-Repräsentation der Formulardaten. Würde nun das gesamte Dokument mit dem privaten Schlüssel des
Formularsenders codiert, so könnte jeder mit dem öffentlichen Schlüssel jederzeit das Originaldokument wiederherstellen. Somit ist gewährleistet, dass nur der Besitzer des privaten Schlüssels dieses Dokument verschlüsselt haben kann.
Da asymmetrische Verschlüsselungsverfahren aber sehr rechenintensiv sind und somit durchaus einige Zeit in
Anspruch nehmen können, wird in der Regel nicht das gesamte Dokument, das signiert werden soll, verschlüsselt, sondern nur ein Digest oder Hashwert des Dokuments. Dies hat aber auch zur Folge, dass aus dem verschlüsselten Ergebnis, das die digitale Signatur darstellt, wiederum mit dem öffentlichen Schlüssel nur der
Digest zurückerrechnet werden kann. Um nun erfolgreich feststellen zu können, ob die Signatur gültig ist oder
nicht, sind die Originaldaten nötig. Daraus kann dann ebenso der Digest des Dokuments berechnet werden und
mit dem zuvor entschlüsselten Digest verglichen werden. Im Regelfall reicht diese Digest-basierte Variante der
digitalen Signatur aus, um die oben erwähnten Aspekte abzudecken.
Anhand der Abbildungen 11 und 12 wird das Erstellen und Verifizieren einer digitalen Signatur grafisch veranschaulicht.
2. Standards
Abbildung 11
Digitale Signatur erstellen
Abbildung 12
Digitale Signatur verifizieren
33
Die folgende Liste zeigt die wichtigsten Digest-Algorithmen in diesem Zusammenhang auf.
MD2 (Message Digest 2)
Der Digest-Algorithmus MD wurde von Ronald Rivest entwickelt, die verbesserte Variante wurde von ihm MD2
genannt. Der MD2-Algorithmus produziert einen 128-bit breiten Digest aus einem beliebigen Datenstrom.
MD5 (Message Digest 5)
Mehrere Versuche von Ronald Rivest, den MD2-Algorithmus hinsichtlich der Laufzeit zu verbessern, endeten schließlich im MD5-Algorithmus. Dieser produziert ebenfalls einen 128-bit Wert aus einem beliebigen
Datenstrom.
SHA-1 (Secure Hash Algorithm)
Der von der Krypto-Community heute am ehesten empfohlene Algorithmus ist SHA-1. Auch hier war Ronald
Rivest sehr stark am Entwurf beteiligt. Der große Vorteil gegenüber den MD-Algorithmen ist die Breite des
Digests von 160-bit. Die Wahrscheinlichkeit, ausgehend von einem bestehenden Dokument ein zweites zu
finden, das den gleichen Digest ergibt, wurde nochmals um den Faktor 232 verringert.
Da, wie der bekannte Kryptologe Bruce Schneier schon seit längerer Zeit erwartet hat, der SHA-1-Algorithmus
am 15. Februar 2005 [Schn05] von einem chinesischen Forscherteam gebrochen wurde, wird man in absehbarer
Zeit auf alternative Algorithmen zur Hashwertbildung wie SHA-256 bzw. SHA-512 umsteigen müssen.
Kryptoverfahren, die bei der digitalen Signatur zum Einsatz kommen, sind folgende:
RSA (Rivest Shamir Adleman)
RSA ist nach wie vor der ungeschlagene Favorit bei den Kryptographie-Verfahren, obwohl der Algorithmus
bereits Ende der 70er-Jahre entwickelt wurde. Vor allem weil er seit Jahren gründlich analysiert werden
konnte, gilt er, bei ausreichender Schlüssellänge, als sicher. Die Sicherheit beruht auf der Schwierigkeit,
sehr große Zahlen zu faktorisieren. Der benötigte Rechenaufwand, große Zahlen zu faktorisieren, lässt sich
recht präzise abschätzen. RSA steht für die drei Anfangsbuchstaben der Namen der Erfinder des Algorithmus, Ronald Rivest, Adi Shamir und Leonard Adleman.
2. Standards
DSA (Digital Signature Algorithm)
DSA ist eigentlich kein Krypto-Verfahren. In diesem Fall wird nicht, wie in Abbildung 11 dargestellt, der verschlüsselte Digest als Signatur herangezogen, sondern das Ergebnis einer mathematischen Funktion basierend auf dem diskreten Logarithmus.
ECDSA (Elliptic Curves Digital Signature Algorithm)
Das ECDSA-Verfahren beruht auf dem gleichen Prinzip wie schon das DSA-Verfahren, nur basiert die verwendete Mathematik auf elliptischen Kurven.
Schnittstelle – Security-Layer 1.2
Der Security-Layer ist eine von der Stabsstelle IKT-Strategie des österreichischen Bundes ausgearbeitete
Schnittstellendefinition, die vorrangig dazu dient, Online-Applikationen die Plattform-unabhängige digitale Signatur von Dokumenten zu ermöglichen. Zu diesem Zweck kommuniziert die im Browser laufende Applikation
über Hyper Text Transport Protocol (HTTP) / Hyper Text Transport Protocol Secure (HTTPS) mit einer
lokal laufenden Anwendung, der sogenannten Bürgerkartenumgebung.
Diese Bürgerkartenumgebung führt die Signatur durch und leitet die signierten Daten entweder direkt oder indirekt über ein Webservice zurück zum Browser. Die Bürgerkartenumgebung stellt einen Secure-Viewer zur Verfügung, der die zu signierenden Daten vor dem Durchführen der Signatur unverfälscht visualisiert.
Die digitale Signatur erfolgt in diesem Falle entweder gemäß CMS (Cryptographic Message Syntax) bzw. gemäß
der XMLDSIG-Spezifikation.
Fabasoft eGov-Forms unterstützt mit dem Schritt „Zusammenfassung anzeigen“ (FSCFORMS@1.1001:
ShowSummaryStep) eine digitale Signatur nach XMLDSIG der zusammengefassten Formulardaten gemäß
Security-Layer-Spezifikation der Version 1.2.
Dieser Schritt visualisiert die vom Benutzer eingegebenen Formulardaten und führt beim Auslösen der auf der
Zusammenfassungsseite vorhandenen „Signieren“-Schaltfläche, die analog zu den anderen verfügbaren
Schaltflächen frei definierbar ist, eine HTTP bzw. HTTPS-POST-Anfrage zur zuvor ausgewählten Bürgerkartenumgebung durch.
35
Die Bürgerkartenumgebung wird in der Anfrage angewiesen, die signierten Daten zum Formularserver weiterzuleiten und gibt die Antwort des Formularservers direkt an das Browserfenster zurück.
Auf Wunsch können die signierten Daten am Formularserver sofort über ein konfigurierbares MOA-SPSS-Service verifiziert werden. Schlägt die Verifikation fehl, so wird der Grund dem unterschreibenden Benutzer dargestellt, und er erhält nochmals die Möglichkeit die Signatur durchzuführen. Eine ungültige Signatur wird nicht
akzeptiert. Verläuft die Verifikation fehlerlos, so werden die signierten Daten in der Eigenschaft Signierter
Inhalt (FSCDIGSIG@1.1001:sigcont) abgelegt und stehen somit zur weiteren Verwendung bereit.
Schnittstelle – CAPICOM
CAPICOM ist eine COM-Schnittstelle zur Verwendung des Microsoft CryptoAPI. Diese COM-Schnittstelle stellt
Objekte für den Cryptographic Service Provider (CSP)-basierten Zugriff auf die in Windows-Betriebssysteme integrierte Kryptographie- und Signaturfunktionalität zur Verfügung. Auf Grund der COM-Architektur kann diese
Schnittstelle nur von Microsoft Internet Explorer basierten Web-Browsern aus verwendet werden.
Fabasoft eGov-Forms stellt den Antragsschritt mit Graphical User Interface (GUI) Mit FSC-WebSigner
signieren (FSCFORMS@1.1001:SignWebSignerStep) zur Verwendung dieser Schnittstelle zur
Verfügung.
Dieser Schritt visualisiert den Hauptinhalt des Antrags als Formularseite und bietet neben den bei allen Antragsschritten mit GUI verfügbaren Schaltflächen auch eine „Signieren“-Schaltfläche, die analog zu anderen frei
benannt werden kann.
Betätigt der Anwender diese Schaltfläche, so wird ein Dialog dargestellt, in dem alle im aktuellen Benutzerkontext verfügbaren Zertifikate dargestellt werden. Der Benutzer wählt sein Signaturzertifikat aus. Anschließend
werden die zu signierenden Daten an CAPICOM übergeben. CAPICOM führt die Signatur durch und liefert – je
nach Einstellung – entweder die Originaldatei mit der Signaturinformation oder nur die Signaturinformation als
binäre PKCS#7-konforme Daten zurück. Diese Daten werden beim Antrag in der Eigenschaft Signierter Inhalt
(FSCDIGSIG@1.1001:sigcont) abgelegt. Es wird hierbei eine serverseitige Verifikation durchgeführt.
2. Standards
2.4. Elektronische Zahlung
Das Ergebnis der Verifikation wird in der Eigenschaft digitale Signaturen (FSCDIGSIG@1.1001:
digsignatures) festgehalten.
2.4
Elektronische Zahlung
In den vergangenen Jahren haben Banken zusammen mit Handel, Industrie und öffentlichen Verwaltungen große Bemühungen unternommen, um das Bezahlen im Internet sicher und ohne Medienbruch, also durchgehend
elektronisch, umzusetzen. Hierzu wurden internationale und nationale Initiativen gestartet, die sich mit der Ausarbeitung diesbezüglicher Standards beschäftigen.
In Österreich wurde beispielsweise von der bankenübergreifenden Studiengesellschaft für Zusammenarbeit im
Zahlungsverkehr [STUZ05] der eps e-payment standard erarbeitet. Dieser Standard ermöglicht Bankkunden eine
Abwicklung ihres Zahlungsverkehrs bei Einkäufen oder Vergebührungen im Internet. Bei der Ausarbeitung dieses Standards machte man sich die Vertrautheit des Bürgers mit den bestehenden Internet Banking Systemen
und deren Sicherheitsstandards zunutze.
Festzuhalten ist jedoch, dass es sich bei dem eps e-payment standard nicht um ein eigenständiges Produkt, sondern um eine offene, normierte Schnittstelle für Online Zahlungssysteme handelt, die in der Version 2.1.1
[Geis04] auf folgenden Grundlagen beruht:
ECBS Bankenstandard für den electronic Payment Initiator (ePI ~ elektronischer Zahlschein)
Initiative der österreichischen Banken: eps e-payment standard (Version 1)
E-Government: elektronische Zahlungsbestätigung
37
Ein typischer Ablauf einer Zahlung via eps e-payment standard wird in Abbildung 13 dargestellt.
Fabasoft eGov-Forms unterstützt mit dem Schritt „eps2-Zahlung“ eine elektronische Zahlung über den eps2-Standard.
Dieser Schritt visualisiert dem Antragsteller den zu zahlenden Betrag und führt beim Auslösen der auf der Zahlungsseite vorhandenen „Bezahlen“-Schaltfläche, die analog zu den anderen verfügbaren Schaltflächen frei definierbar ist, eine HTTP bzw. HTTPS-POST-Anfrage zur konfigurierten eps2-Zahlstelle aus.
Der Antragsteller wird über einen Redirect mit dem Banksystem verbunden und kann dort nach erfolgter Identifikation die ausgefüllte Überweisung bestätigen. Im Anschluss bestätigt das Bank-System die Zahlung gegenüber Fabasoft eGov-Forms und löst beim Antragsteller abermals einen Redirect auf den Antrag aus.
Nach positivem Abschluss der Zahlung erhält der Antragsteller eine Bestätigung durch den Schritt „eps2-Zahlung“.
Abbildung 13
Ablauf bei eps e-payment
standard nach [Jung04]
2. Standards
2.4. Elektronische Zahlung
Zusammenfassung
Abbildung 14
Standards
39
3
41
3 architektur
Fabasoft eGov-Forms ist als verteilte Webanwendung implementiert. Die Kommunikation erfolgt
einerseits interaktiv über eine grafische Benutzeroberfläche, wobei für die Darstellung ein Webbrowser-Client genutzt wird und andererseits programmatisch über Web-Services. Die Auflistung
und Beschreibung der dazu nötigen Hard- und Softwarearchitektur auf Betreiber- und auf Bürgerseite stellt den Inhalt dieses Kapitels dar.
3.1
Betreiber
Am Beispiel von E-Government vom Antrag bis zur Zustellung (siehe Abbildung 1) wird klar, dass aufgrund des
Nutzenversprechens im Bereich der Kommunikation mit dem Bürger der Bedarf an einem hochverfügbaren
Betrieb von 24 Stunden an allen Tagen des Jahres (7x24-Betrieb) besteht. Der Betreiber einer Fabasoft eGovForms Installation hat somit in Bezug auf Hochverfügbarkeit, Skalierbarkeit und Managebarkeit hohe Ansprüche.
Daraus ergibt sich die im Folgenden beschriebene Referenzarchitektur für Fabasoft eGov-Forms als Ableitung der
Fabasoft Referenzarchitektur.
Hardwarearchitektur
Die Fabasoft Referenzarchitektur bietet dem Betreiber eine optimale Möglichkeit, die gewünschten Anforderungen gemäß den definierten und geforderten Service Levels zu gewährleisten. Das Buch „Die Fabasoft Referenzarchitektur im Microsoft Windows-Umfeld“ [FAHJ04] beschreibt die notwendige Hardwarearchitektur auf
Betreiberseite im Detail (Überblick siehe Abbildung 15).
Ausgehend von der Fabasoft Referenzarchitektur beschreibt die folgende Liste die für Fabasoft eGov-Forms notwendigen Komponenten:
WAN
Netzwerkanbindung zwischen dem Internet und dem Anschaltknoten im Rechenzentrum. Im Unterschied zur
Fabasoft Referenzarchitektur handelt es sich hier nicht um eine Schnittstelle zwischen Arbeitsplatz-LAN und
dem Rechenzentrum, sondern zwischen Internet und Rechenzentrum.
Abbildung 15
Fabasoft Referenzarchitektur
[FAHJ04]
Anschaltknoten
Der Anschaltknoten ist der Übergabepunkt für die Anwendung und der Messpunkt für den Service-Level.
Firewall
Die Server-Firewall soll das Rechenzentrum vor Angriffen aus dem WAN (dem Internet) schützen.
Lastverteiler (Load-Balancer, Content-Switch)
Der Lastverteiler verteilt die eintreffenden Anfragen der Benutzer auf die Webserver-Farm und damit auf die
Fabasoft Components Services.
Frontend-LAN
Das Frontend-LAN verbindet den Lastverteiler mit der Webserver-Farm.
3. Architektur
3.1 Betreiber
Webserver-Farm
Die Webserver-Farm besteht aus jenen Servern, auf welchen die Fabasoft Components Webservices (Verarbeitungslogik der Anwendung und Generierung der Darstellung) ablaufen.
Backend-LAN
Das Backend-LAN verbindet die Webserver mit den Backendserver-Clustern und den Konvertierungsservern
sowie die Backendserver-Cluster mit den Datenbankserver-Clustern. Darüber hinaus verbindet das BackendLAN als Backbone auch die Server für die Basisdienste mit den anderen Servern.
Konvertierungsserver-Farm (Conversionserver-Farm)
Die Konvertierungsserver-Farm besteht aus jenen Servern, auf welchen die Fabasoft Components Konvertierungsservices (Formatkonvertierungen für Dokumente) ablaufen. Im Zusammenhang mit Online-Formularen
werden diese Services für die Konvertierung der Schlussansicht in ein druckbares Format (z.B. PDF) verwendet. Eine weitere Möglichkeit besteht darin, dem Antragsteller eine finale Form seines ausgefüllten
Antrags zur Verfügung zu stellen.
AT-Server (Automated Tasks)
Am AT-Server laufen die Fabasoft Components AT-Services für die Durchführung automatischer Aufgaben im
Kontext eines Benutzers ohne Benutzerinteraktion ab. Im Zusammenhang mit Fabasoft eGov-Forms könnten
diese Server den regelmäßigen Abtransport der Daten in die elektronische Akten- und Vorgangsbearbeitung
übernehmen.
Backendserver-Cluster
Der Backendserver-Cluster erledigt die Datenhaltung (Persistenz) für die Geschäftsobjekte im Zuge der Fabasoft Components COO-Services für die strukturierten Daten (in relationalen Datenbanken) und im Zuge der
Fabasoft Components MMC-Services für die unstrukturierten Daten (Dokumente, Bilder, Multimediadaten
im Dateisystem).
Datenbankserver-Cluster
Das auf dem Datenbankserver-Cluster laufende relationale Datenbanksystem (z.B. Microsoft SQL Server)
speichert die strukturierten Daten für jedes Fabasoft Components COO-Service in je einer Datenbank.
43
Storage Area Network (SAN)
Das SAN verbindet die Backend-Cluster (Speicherung von Dokumenten im Dateisystem) sowie die Datenbank-Cluster (Speicherung der Datenbankdateien) mit dem Storagesystem.
Storagesystem
Das Storagesystem ist ein großer Festplattenspeicher.
Server für Basisdienste
Domaincontroller
Mailserver
Managementserver
Backupserver
MOA-ID-Server
Der MOA-ID-Server übernimmt die Identifikation des Benutzers in Österreich gemäß der Spezifikation der
Stabsstelle IKT-Strategie des Bundes [ScKM03].
MOA-SPSS-Server
Der MOA-SPSS-Server übernimmt die Signaturprüfung der Bürgersignatur gemäß der Spezifikation der
Stabsstelle IKT-Strategie des Bundes in Österreich [ScMo03].
Softwarearchitektur
Das Buch „Die Fabasoft Referenzarchitektur im Microsoft Windows-Umfeld“ [FAHJ04] liefert bereits mögliche Softwarekonfigurationen. Diese können ebenfalls für eine Installation von Fabasoft eGov-Forms verwendet werden. Die
Identifikations- und Signaturverfahren sind weitgehend länderspezifisch. Somit ist beispielsweise bei einem Betreiber
in Österreich zusätzlich die Installation der MOA-ID und MOA-SPSS-Services notwendig. Diese beiden Module für
Online-Anwendungen sind sowohl für Organisationseinheiten der öffentlichen Verwaltung als auch für die Privatwirtschaft (fast) kostenfrei zugänglich und können bei der Stabsstelle IKT-Strategie des Bundes in Österreich beantragt werden. Die kostenfreie Verfügbarkeit bezieht sich alleine auf die Nutzungsrechte der Module. Für die Nutzung durch die
Privatwirtschaft bestehen Einschränkungen hinsichtlich einiger von den Modulen genutzten Basisbibliotheken [Stab05].
3. Architektur
3.1 Betreiber
3.2 Administrator
3.3 Bürger
Konfigurationsmöglichkeiten und Setupanleitungen sind im Package enthalten. Kapitel 9 erläutert die Einbindung in Fabasoft eGov-Forms.
3.2
Administrator
Der Administrator in einem Fabasoft eGov-Forms Umfeld greift über einen Web-Schreibtisch auf die Administrationsmöglichkeiten von Fabasoft eGov-Forms zu. In der Fabasoft Referenzarchitektur kann der Administrator als
Benutzer eines Arbeitsplatzes gesehen werden. Das Buch „Die Fabasoft Referenzarchitektur im Microsoft Windows-Umfeld“ [FAHJ04] stellt dazu eine Beispielkonfiguration dar.
3.3
Bürger
Auf Seiten des Bürgers (des Antragstellers) stellt das Produkt Fabasoft eGov-Forms keine besonderen Anforderungen, da grundsätzlich reines HTML mit Javascript als Output des Produktes generiert wird. Installationen auf
Seiten des Bürgers sind somit nicht nötig.
Hardwarearchitektur
Der Bürger als Benutzer des Systems muss zumindest einen internetfähigen PC inkl. Zugang zum Internet besitzen,
um Online-Formulare ausfüllen zu können. Sofern in Verbindung mit der Antragstellung auch eine digitale Signatur
durchgeführt werden soll, muss der Bürger über einen Smartcard-Reader inkl. dazugehöriger Smartcard verfügen.
Betrachtet man die digitale Signatur in Österreich, so muss der Benutzer über eine Bürgerkarte und ein geeignetes Chipkartenlesegerät oder eine Bürgerkarte light und dazugehöriges Mobiltelefon verfügen.
Softwarearchitektur
Der Bürger benötigt folgende Software für den Zugriff auf die Online-Formulare von Fabasoft eGov-Forms:
HTML 4.0-konformer Web-Browser
45
Zum Ausführen der digitalen Signatur ist in Österreich eine der folgenden Bürgerkartenumgebungen nötig:
trust-desk von IT-Solution [ITSo05]
hot.sign von BDC [BDCE05]
A1 SIGNATUR von mobilkom austria [Mobi05]
Andere digitale Signaturen können über einen Crypto Service Provider sowie dessen Software abgewickelt werden. Zusätzlich benötigt der Bürger die passende Treiber-Software für den verwendeten Smartcard-Reader.
Bürgerkarte in Österreich
Durch die Verwendung einer digitalen Signatur mit einer Bürgerkarte (elektronische Identitätskarte) wird in
elektronischen Geschäftsbeziehungen die Echtheit eines Dokuments einer Person bestätigt.
Um elektronische Dokumente digital signieren zu können, wird eine Bürgerkarte oder eine Handysignatur (Signatur über Mobiltelefon), auch „Bürgerkarte light“ genannt, benötigt. Beide Signatureinrichtungen werden nur
von staatlich anerkannten Betreibern zur Verfügung gestellt.
Verschlüsselung
Zusätzlich bietet die digitale Signatur die Möglichkeit, Dokumente mit Hilfe eines Public-Key-Systems zu verschlüsseln. Hierfür benötigt der Bürger ein gültiges Zertifikat einer zentralen Stelle, um ein Dokument mit seinem öffentlichen Schlüssel verschlüsseln zu können. Ist ein Dokument mit einem Public-Key (Öffentlicher Schlüssel) verschlüsselt, so kann dieser nur mit dem persönlichen Private-Key (Geheimer Schlüssel) entschlüsselt werden.
Des Weiteren kann die Signaturkarte zur Authentifizierung bei diversen Online-Diensten verwendet werden.
Auf der Signaturkarte sind persönliche Daten sowie persönliche Identifikationsnummern gespeichert.
Bürgerkarte
Die digitale Signatur mit der Bürgerkarte setzt ein Kartenlesegerät und eine Signaturkarte voraus. Hier wird der
Antrag mit der Eingabe einer Signatur-PIN und der Signaturkarte digital signiert. Seit Anfang 2005 sind alle neu
3. Architektur
3.1 Bürger
ausgegebenen Maestro-Karten (Bankomatkarten) bürgerkartentauglich. Alternativ dazu kann über A-Trust eine
persönliche, dem österreichischen Signaturgesetz entsprechende Signaturkarte mit Bürgerkartenfunktionalität
bestellt werden.
Zur Verwendung der Bürgerkarte am PC benötigt man als Signaturumgebung ein Kartenlesegerät mit der dazugehörigen Treiber-Software, die a.trust-Software „a.sign client“ und für die sichere Signatur in einer E-Government-Anwendung den so genannten „Security-Layer“. Dieser kann entweder bei A-Trust für A-Trust Karteninhaber oder bei der Stabsstelle IKT-Strategie des Bundes gratis heruntergeladen werden.
Weitere Informationen findet man unter www.A-Trust.at [Atru05].
Handy-Signatur (Bürgerkarte light)
Bei der Handy-Signatur wird die digitale Signatur über das Internet mit dem Handy Login und SMS durchgeführt.
Derzeit wird die Signatur mit Handy nur von mobilkom austria unter dem Namen A1 SIGNATUR angeboten. Man
muss jedoch kein A1 Handy besitzen, sondern kann diesen Dienst auch nutzen, wenn man Kunde eines anderen
österreichischen Mobilfunkbetreibers ist.
Weitere Informationen findet man unter www.A1.net/signatur [Mobi05].
47
Zusammenfassung
Abbildung 16
Architektur
3. Architektur
3.1 Bürger
49
4
fabasoft
4 formulardesigner
In diesem Kapitel soll das in Kapitel 1.2 dargestellte Formular für die „Hundeanmeldung“ mit dem
Formulardesigner der Fabasoft eGov-Suite entwickelt werden. Anhand dieses praxisnahen Beispiels wird Schritt für Schritt auf die zentralen Elemente des Formulardesigners eingegangen.
Die Formularentwicklung mit Fabasoft Standardprodukten gliedert sich in die Entwicklung und den Ablauf von
Online-Formularen. Der Formulardesigner als Bestandteil der Fabasoft eGov-Suite ist ein geeignetes Instrument,
um Online-Formulare intuitiv und kostengünstig zu gestalten. Fertiggestellte Online-Formulare werden nach ausführlichen Tests aus dem Entwicklungssystem in das Runtime-System übertragen und somit für Bürger und Kunden zur Verfügung gestellt.
4.1
Zielgruppe und Beweggründe
Die Entwicklung von Online-Formularen bedeutet häufig, eine Spezifikation auf Basis von verfügbaren PapierFormularen durchführen zu müssen und anschließend für die Umsetzung IT-Fachkräfte zu beauftragen. Besser
und kostensparender wäre es jedoch, wenn Mitarbeiter der Fachabteilungen nicht Formulare spezifizieren, sondern diese gleich in einem Web-Interface modellieren könnten. Lediglich der letzte Schliff des Online-Formulars
und die Produktivsetzung müsste von einer IT-Fachkraft durchgeführt werden.
Die Zielgruppe, Mitarbeiter einer Fachabteilung innerhalb der Behörde, stellen ganz besondere Anforderungen
im Hinblick auf Einfachheit, Übersichtlichkeit und Schnelligkeit an die Entwicklung von Online-Formularen.
Fabasoft hat diese Überlegung aufgenommen und den Anforderungen dieser Zielgruppe in der Entwicklung des
Formulardesigners der Fabasoft eGov-Suite Rechnung getragen. Der Formulardesigner bietet eine abstrakte
Sicht auf das generische Interface zur projektorientierten Entwicklung von Online-Formularen für Fabasoft eGovForms. Dem Anwender werden die Details der Modellierung wie zum Beispiel Schrittdefinitionen oder Typdefinitionen abgenommen. Dies ermöglicht dem Formularersteller die Konzentration auf wesentliche Punkte wie die
Gestaltung der Formularblöcke und die Aufteilung auf Formularseiten.
51
4.2
Aufbau und Elemente
Der Formulardesigner ermöglicht eine projektorientierte Entwicklung von Online-Formularen auf Basis einer
intuitiven, grafischen Web-Oberfläche. Die Web-Oberfläche ist als Portal gestaltet und enthält folgende Elemente (siehe Abbildung 17):
Antragsprojekt
Antragsformulare
Formularseiten
Formularelemente
Formularschaltflächen
Formularblöcke
Formularblockelemente
Plausibilitätsprüfungen
Die Entwicklung von Online-Formularen kann bottom-up (vom Formularblockelement zum Antragsformular)
durchgeführt werden. Die Entwicklung auf Basis des bottom-up-Ansatzes fordert den Formularersteller auf, sich
das Formular auf unterster Ebene (Formularblockelemente) zu überlegen und erst später die Kombination in Formularblöcke und Formularseiten vorzunehmen. In vergangenen Projekten stellte sich heraus, dass besonders die
Wiederverwendung von Elementen bei Verwendung des bottom-up-Ansatzes erhöht wurde und so schlankere
Datenstrukturen entstanden.
Die folgenden Unterkapitel erläutern die Möglichkeiten und den Sinn der einzelnen Elemente des Formulardesigners und folgen dem bottom-up-Ansatz.
4. Fabasoft Formulardesigner
4.2 Aufbau und Elemente
Abbildung 17
Struktur des
Formulardesigners
Antragsprojekt
Ein Antragsprojekt (siehe Abbildung 17) stellt das Wurzelobjekt im Formulardesigner dar und ermöglicht die
Zusammenfassung von mehreren Antragsformularen. Somit wäre die Gliederung der Antragsformulare in Themengebiete möglich.
Alternativ dazu können Antragsprojekte als Vorlagensammlung für weitere Antragsprojekte dienen, indem
behördenspezifische Standardelemente (Formularblöcke, Formularelemente, Formularseiten, Formularblockelemente,…) in einem Antragsprojekt definiert und dieses Antragsprojekt in weiteren Antragsprojekten referenziert werden. Ziel ist es, sämtliche Antragsformulare einer Behörde mit denselben Elementen und Blöcken darzustellen. Ein Bürger findet sich somit leichter zurecht.
53
Der Benutzer des Formulardesigners kann ein Antragsprojekt erstellen, benennen und einem Workflow zuordnen. Daher kann die Erstellung eines Online-Formulars über die Workflow-Komponente der Fabasoft eGov-Suite
gesteuert werden. Die Zugriffsrechte auf das Antragsprojekt innerhalb des Workflows werden durch ein Rollenkonzept definiert. Für den Fabasoft Formulardesigner sind folgende Rollen verfügbar:
Forms Designer/Forms Autor
Forms Redakteur
Forms Tester
Forms Administrator
Hinter einem Antragsprojekt verbirgt sich im generischen Interface eine Softwarekomponente, die aus der Entwicklungsumgebung in eine Test- bzw. eine Produktivumgebung übertragen werden kann.
Ein Antragsprojekt ermöglicht die Definition folgender Metadaten:
Eindeutige Bezeichnung
Wie bereits erwähnt, verbirgt der Formulardesigner die nötigen Aktivitäten auf generischer Seite. Es ist dennoch nötig, eine Referenz für die zu erzeugende Softwarekomponente anzugeben.
Name
Neben der eindeutigen Bezeichnung des Antragsprojekts ist es möglich, einen sprechenden Namen für das
Projekt zu definieren.
Standardanwendungssteuerung
Diese Anwendungssteuerung dient zur Darstellung der Testansicht und der Modellierungsansicht innerhalb
dieses Projektes. Um die Online-Formulare einer Behörde in einem einheitlichen Design zur Verfügung zu
stellen, empfiehlt es sich, für alle Online-Formulare dieselbe Anwendungssteuerung zu verwenden. Die
detaillierten Aufgaben einer Anwendungssteuerung können in [KlWi04] nachgelesen werden.
Softwarekomponenten für Blöcke von Vorlagen
Über diese Liste von Softwarekomponenten können Standardblöcke eingebunden werden. Die Softwarekomponente FSCFORMSAT im Produkt Fabasoft eGov-Forms enthält bereits eine Reihe von vordefinierten
Standardblöcken.
Sammlungen von verwendbaren Elementen
Hier ist die Referenzierung von Antragsprojekten möglich. Elemente, die in den referenzierten Antragsformularen enthalten sind, können direkt in diesem Projekt verwendet werden. Somit besteht eine weitreichende Möglichkeit der Wiederverwendung.
Formularkopf-Vorlage
Der Formulardesigner spezifiziert eine Vorlage für die Formularköpfe in den Antragsformularen dieses Projektes. Abgeleitet von diesem Template können Formularköpfe für die einzelnen Antragsformulare modelliert
werden.
Formularfuß-Vorlage
Wie bei der Formularkopf-Vorlage dargestellt, besteht beim Formularkopf ebenfalls die Möglichkeit ein Template zu spezifizieren.
Kommentar
Das Kommentar-Feld ist innerhalb des Formulardesigners in jedem Element enthalten und ermöglicht dem
Benutzer einen beliebigen Kommentar zu hinterlassen. Dieser Kommentar dient ausschließlich der Dokumentation.
Dokumentation
Die Objektliste „Dokumentation“ dient als Ablage für beliebige Dokumente. Hier können beispielsweise der
Projektauftrag und diverse Protokolle abgelegt werden.
Beispiel – Hundeanmeldung – Antragsprojekt
Als Basis für die bottom-up-Umsetzung des Beispiels „Hundeanmeldung“ muss zuerst ein Antragsprojekt
erstellt werden. Das aktuell bearbeitete Antragsprojekt im Formulardesigner wird geschlossen und ein
Neues erzeugt. Die Abbildung 18 enthält die dazu nötigen Einstellungen.
55
Abbildung 18
Antragsprojekt
Formularblockelemente
Das Formularblockelement ist die kleinste Einheit bei der Gestaltung eines Online-Formulars (siehe Abbildung
17) und entspricht den einzelnen Eingabefeldern. Der Formulardesigner stellt folgende Typen von Formularblockelementen zur Verfügung:
Boolescher Wert
Kann als Checkbox oder als Radio-Group dargestellt werden.
Datum
Automatisch wird ein Kalendersymbol zum Suchen des Datums eingeblendet.
Datum/Uhrzeit
Entspricht dem Typ „Datum“, jedoch wird zusätzlich ein Eingabefeld für die Uhrzeit angezeigt.
Ganzzahliger Wert
Die Anzahl der Ziffern kann konfiguriert werden.
Gleitkommawert
Die Konfiguration der Vor- und Nachkommastellen ist möglich.
HTML-Fragment
Hiermit können statische HTML-Fragmente definiert und in ein Formular eingebettet werden.
PLZ/Ort
Stellt zwei Eingabefelder zur Eingabe bzw. Suche von PLZ/Ort-Kombinationen zur Verfügung. PLZ/Ort ist in
der Softwarekomponente FSCFORMSAT enthalten und kann daher nur verwendet werden, wenn diese
Softwarekomponente in der Fabasoft eGov-Forms Installation vorhanden ist.
Trennlinie
Werteliste
Ermöglicht die selektive Auswahl eines Wertes mittels Dropdown oder Radio-Group. Der Formularentwickler kann bei der Werteliste eine Initialisierung definieren.
Zeichenketten
Können einzeilig oder mehrzeilig dargestellt werden und dienen der Eingabe von Freitexten und Kommentaren.
Formularblockelemente können im Ordner „Formularblockelemente“ erzeugt bzw. bearbeitet werden. Alle Formularblockelemente besitzen folgende Metadaten:
Mehrsprachiger Name
Der Name des neuen Elements. Aufgrund dieses Namens soll das Element vom Benutzer erkannt werden.
Der mehrsprachige Name wird zusätzlich als Bezeichnung des Formularblockelements im fertigen Antragsformular verwendet.
57
Diese Bezeichnung muss innerhalb des Antragsprojektes eindeutig sein und entspricht im generischen Interface der Referenz des neuen Formularblockelements.
Typ
Der Typ wird bereits bei der Erzeugung des Formularblockelements festgelegt.
Kommentar
Das Kommentar-Feld ist innerhalb des Formulardesigners in jedem Element enthalten und ermöglicht
dem Benutzer einen beliebigen Kommentar zu hinterlassen. Dieser Kommentar dient der Dokumentation
des Projektes.
Beispiel – Hundeanmeldung – Formularblockelemente
Bei der Umsetzung des Beispielformulars „Hundeanmeldung“ wird auf ein Maximum an Wiederverwendbarkeit geachtet. Daher können viele Formularblöcke und Formularblockelemente aus Sammlungen von
Standardelementen bezogen werden.
Dazu kommen Formularblockelemente, die spezifisch für das Beispielformular relevant sind. Folgende
Angaben zum Hund (siehe Tabelle 2):
„Rufname“
„Geburtsjahr“
„Rasse“
„Farbe“
„Datum der Übernahme des Hundes“
„Wie haben Sie den Hund erhalten?“
Da sich die Erzeugung von unterschiedlichen Formularblockelementen nicht oder nur wenig unterscheidet,
wird hier nur auf die Erzeugung eines Formularblockelements eingegangen.
Das Formularblockelement „Wie haben Sie den Hund erhalten?“ stellt in der oben angeführten Liste eine
Ausnahme dar, da es sich hierbei um eine Werteliste handelt. Nach dem Wechsel in den Ordner „Formularblockelemente“ im Formulardesigner klickt man die Schaltfläche „Erzeugen“ und erhält anschießend
eine Auswahl der zur Verfügung stehenden Formularblockelement-Typen (siehe Abbildung 19).
Nach Auswahl des Formularblockelement-Typs „Werteliste“ und Klick auf „Weiter“ erhält man die Aufforderung die notwendigen Metadaten einzugeben (siehe Abbildung 20). Über die Darstellung kann beispielsweise die gewünschte optische Aufbereitung ausgewählt werden. In der Liste „Wertelisteneinträge“ werden die gewünschten Einträge „Kauf“, „Wurf“, „Geschenk“ und „Anderes“ eingetragen.
Vergleichbare Vorgehensweisen sind für die Erstellung der restlichen Formularblockelemente nötig.
59
Abbildung 19
Formularblockelement –
Auswahl
Abbildung 20
Formularblockelement –
Werteliste
Plausibilitätsprüfungen
Im Gegensatz zu Papierformularen bietet ein Online-Formular die Möglichkeit, Eingaben des Benutzers sofort zu
überprüfen und gegebenenfalls eine Fehlermeldung darzustellen. Dies erhöht nicht nur die Qualität der erhaltenen Formulardaten, sondern reduziert zudem den nötigen Administrationsaufwand im Falle einer Falschangabe.
Plausibilitätsprüfungen wie die Überprüfung nach Datentyp (z.B. Text, Zahl) oder der Form der Eingabe (z.B.
Datumsformat) werden automatisch vom Produkt Fabasoft eGov-Forms übernommen. Zusätzlich kann der Formularentwickler über den Formulardesigner benutzerdefinierte Plausibilitätsprüfungen erstellen. Diese Fehlerüberprüfungen können einem oder mehreren Formularblockelementen zugeordnet werden.
Der Formulardesigner der Fabasoft eGov-Suite stellt drei Typen von Plausibilitätsprüfungen zur Verfügung:
Numerischer Wertebereich
Es besteht die Möglichkeit einen Wertebereich zu definieren, in dem der eingegebene Wert liegen darf.
Boolescher Wert
Diese Plausibilitätsprüfung ermöglicht die Überprüfung des Wertes auf „wahr“ oder „falsch“. In der Regel
wird diese Eigenschaft im Online-Formular durch ein Kontrollkästchen oder durch eine Optionsgruppe
(Radio-Group) angezeigt. Sinn macht dieser Typ der Plausibilitätsprüfung, wenn der Antragsteller einen dargestellten Text explizit akzeptieren muss (Wert muss „Ja“ sein).
Fabasoft Components Expression (Ausdruck) [KlWi04]
Diese Plausibilitätsprüfung kann auf jedes beliebige Formularblockelement angewendet werden. Es muss
ein Ausdruck in Form einer Fabasoft Components Expression eingegeben werden.
Ergibt die Auswertung der Plausibilitätsprüfung „falsch“, so kann ein benutzerdefinierter Fehlertext ausgegeben
werden.
61
Beispiel – Hundeanmeldung – Plausibilitätsprüfung
Da im Beispielformular „Hundeanmeldung“ das Feld „Geburtsjahr“ als ganzzahliger Wert mit 4 Ziffern definiert ist, sollte eine numerische Eingabeüberprüfung auf Werte zwischen 1980 und 2005 prüfen.
Dazu klickt man auf die Schaltfläche „Erzeugen“ im Ordner „Plausibilitätsprüfungen“ und wählt die in Abbildung 21 sichtbaren Einstellungen aus.
Zusätzlich muss das Formularblockelement „Geburtsjahr“ zum Bearbeiten geöffnet werden. In der Liste für
Plausibilitätsprüfungen kann für dieses Formularblockelement die eben erstellte Plausibilitätsprüfung eingefügt werden.
Abbildung 21
Plausibilitätsprüfung
Formularblöcke
Formularblöcke fassen mehrere Formularblockelemente zu einer logischen Einheit zusammen (z.B. Antragsteller).
Bei der Erstellung der Formularblöcke wird klar zwischen der Datenstruktur und der Formatierung eines Formularblocks unterschieden. Im Zuge des Anlegens eines Formularblocks wird der Benutzer nach den gewünschten
Formularblockelementen gefragt.
Davon ausgehend erstellt der Formulardesigner automatisiert eine Standardformatierung. Der Formularentwickler hat die Möglichkeit diese Standardformatierung abzuändern und/oder eine beliebige Anzahl von zusätzlichen
Formatierungen zu diesem einen Formularblock hinzuzufügen. Die Gestaltung der Formatierung erfolgt im
WYSIWYG-Verfahren und ermöglicht somit beste Ergebnisse.
Formularblöcke können im Formulardesigner über den Ordner „Formularblöcke“ erstellt, gelesen und bearbeitet
werden. Alle Formularblöcke besitzen folgende Metadaten:
Mehrsprachiger Name
Der Name des neuen Formularblocks. Aufgrund dieses Namens soll der Formularblock vom Benutzer erkannt
werden. Der mehrsprachige Name wird zusätzlich als Überschrift des Formularblocks im fertigen Antragsformular verwendet.
Diese Bezeichnung muss innerhalb des Antragsprojektes eindeutig sein und entspricht im generischen Interface der Referenz des neuen Formularblocks.
Typ
Der Typ wird bereits bei der Erzeugung des Formularblocks festgelegt und im Bearbeitungsmodus des Formularblocks read-only dargestellt.
Musseingabe
Legt fest, ob dieser Formularblock beim Ausfüllen des Formulars ausgefüllt werden muss. Falls dieser vom
Antragsteller nicht ausgefüllt wird, folgt eine dementsprechende Fehlermeldung.
63
Kommentar
Benutzer einen beliebigen Kommentar zu hinterlassen. Dieser Kommentar dient der Dokumentation des
Projektes.
Der Formulardesigner der Fabasoft eGov-Suite stellt drei unterschiedliche Typen von Formularblöcken zur
Verfügung:
Daten
Der Formularentwickler kann mit Hilfe dieses Typs individuelle Formularblöcke für die Eingabe von Daten definieren. Im Zuge dessen legt er die Datenstruktur und das Layout fest.
Ein Formularblock vom Typ „Daten“ kann auch als Listenblock dargestellt werden (siehe Abbildung 21). Der
Antragsteller hat somit die Möglichkeit, den Formularblock mehrmals auszufüllen. Nötige Schaltflächen für „Eintrag erzeugen“ und „Löschen“ stehen standardmäßig zur Verfügung.
Beispiel – Hundeanmeldung – Formularblock – Daten
Das Beispielformular „Hundeanmeldung“ beinhaltet insgesamt 8 Formularblöcke. Davon sind drei Formularblöcke keine Standardblöcke und müssen somit direkt vom Formularentwickler modelliert werden. Beispielhaft wird hier die Erzeugung des Formularblocks „Angaben zum Hund“ beschrieben.
Der Formularentwickler klickt auf die Schaltfläche „Erzeugen“ im Ordner „Formularblöcke“. Anschließend
wählt er den Formularblocktyp „Daten“ aus und klickt auf „Weiter“.
Abbildung 22 zeigt die Metadaten, die im Rahmen der Datenstruktur für diesen Formularblock eingegeben
werden müssen bzw. können. Zu sehen ist, dass z.B. das Formularblockelement „Geschlecht“ aus dem Projekt „Sammlung von Standardelementen“ wieder verwendet wurde.
Zusätzlich möchte der Formularentwickler die automatisch generierte Standardformatierung abändern. Er
wählt dazu den Formularblock aus der Liste der Formularblöcke aus und sieht im unteren Bereich der Darstellung eine Liste von Formatierungen. Durch Klick auf einen Eintrag dieser Liste wird die Vorschau auf diese Formatierung geöffnet und der Formularentwickler kann durch Betätigen der Schaltfläche „Bearbeiten“
mit der Bearbeitung der Formatierung beginnen.
Abbildung 23 zeigt das Ergebnis der Formatierung. Beim Formularblockelement „Farbe“ ist deutlich zu
sehen, dass jedes einzelne Formularblockelement per Drag & Drop verschoben werden kann.
Die Formularblöcke „Vorbesitzer“ und „Bezahlung“ können analog erstellt werden.
65
Abbildung 22
Formularblock (Daten)
erzeugen
Abbildung 23
Formularblock-Formatierung
bearbeiten
Daten (Kopie von Vorlage)
Basierend auf Standardblöcken (z.B. behördeninternen Standardblöcken oder Styleguides) kann der Formularentwickler einen eigenen Formularblock instanziieren. Die Datenstruktur bzw. eine oder mehrere Formatierungen für
diesen Formularblock sind bereits vorhanden und der Formularentwickler hat nur mehr Einfluss auf die Anordnung der Formularblockelemente im Rahmen einer vorgegebenen Formatierung. Typische Beispiele für diesen
Typ von Formularblock wären der „Antragsteller“, „Kontaktinformationen“, etc.
Analog zum Formularblock vom Typ „Daten“ kann auch ein Formularblock vom Typ „Daten (Kopie von Vorlage)“
als Listenblock verwendet werden.
Beispiel – Hundeanmeldung – Formularblock – Daten (Kopie von Vorlage)
Das Beispielformular „Hundeanmeldung“ beinhaltet 8 Formularblöcke. Der Großteil davon sind Standardblöcke. Beispielhaft wird hier die Erstellung des Standardblocks „Antragsteller“ beschrieben.
Der Formularentwickler wechselt in den Ordner „Formularblöcke“ und wählt die Schaltfläche „Erzeugen“.
Im anschließenden Dialog wählt er den Formulartyp „Daten (Kopie von Vorlage)“ und klickt auf „Weiter“.
Abbildung 24 zeigt die Metadaten, die für diesen Typ von Formularblock definiert werden können. Wichtig in diesem Zusammenhang ist die richtige Auswahl der Vorlage. Es werden alle möglichen Vorlagen,
die in den eingebundenen Softwarekomponenten des Antragsprojektes zur Verfügung stehen, angezeigt.
Der Formularentwickler wählt den Eintrag „– Natürliche Person – Standardblock“ aus und schließt die
Bearbeitung ab.
Die weiteren Standardblöcke für das Beispielformular können analog erzeugt werden.
67
Abbildung 24
Formularblock
(Daten (Kopie von Vorlage))
Beilagen
Beilagen stellen einen weiteren Typ des Formularblocks dar. Mit Hilfe dieses Typs hat der Formularentwickler
die Möglichkeit, Beilagen-Uploads in sein Online-Formular einzubinden.
Beim Anlegen eines Formularblocks vom Typ „Beilagen“ hat der Formularentwickler die Möglichkeit zu definieren, welche Beilagen der Antragsteller dem Formular anfügen kann. Jede dieser Beilagendefinitionen entspricht
im Formular einer Beilagenzeile. Um mehrere Beilagen in einem Block unterbringen zu können, müssen auch
mehrere Beilagendefinitionen erstellt werden. Hierbei ist es jedoch egal, ob sich die Beilagendefinitionen innerhalb eines Formularblocks befinden oder über mehrere Formularblöcke hinweg im gesamten Antragsformular
verteilt sind. Bei jeder Beilagendefinition muss die Anzahl der erlaubten Dateien definiert werden. Der Formulardesigner stellt hierbei folgende Einstellungen zur Verfügung:
Abbildung 25
Formularblock
(Beilagen)
Genau eine Datei muss beigelegt werden
Bei dieser Einstellung muss der Antragsteller genau eine Datei hinzufügen. Es wird also diese Beilage als
Mussbeilage definiert.
Maximal eine Datei darf beigelegt werden
Bei dieser Einstellung kann der Antragsteller genau eine oder keine Datei hinzufügen. Es ist also keine
Pflichtbeilage.
Mindestens eine Datei muss beigelegt werden
Bei dieser Einstellung muss der Antragsteller mindestens eine Datei hinzufügen, optional kann er aber auch
mehrere Dateien beilegen.
69
Eine beliebige Anzahl von Dateien darf beigelegt werden
Bei dieser Einstellung kann der Antragsteller eine beliebige Anzahl von Dateien hinzufügen, muss aber nicht.
Zusätzlich wird über den Formulardesigner definiert, ob der Antragsteller die Beilage auch später abseits
dieser Antragstellung nachreichen kann. Abbildung 25 zeigt die unterschiedlichen Beilagendefinitionen im
fertigen Formular.
Ein Online-Formular benötigt diverse Formularschaltflächen, um dem Antragsteller die Navigation zwischen den
einzelnen Formularseiten zu erlauben. Der Formulardesigner erstellt beim Anlegen eines Antragsprojektes standardmäßig drei Formularschaltflächen, diese können über den Ordner „Formularschaltflächen“ abgerufen werden.
Jede Formularschaltfläche hat einen Typ, dieser legt die Funktion dieser Schaltfläche fest. Folgende Typen stehen im Formulardesigner zur Verfügung:
Weiter – wechselt auf die nächste Seite im Antragsformular.
Zurück – wechselt auf die vorherige Seite im Antragsformular.
Abbrechen – bricht die Antragstellung ab und führt die Liste der Abbruchsschritte aus.
Signieren – löst das Signieren des Antragsformulars aus.
Download – konvertiert die Schlussübersicht in ein Format ohne externe Referenzen (z.B. PDF) und löst den
Befehl „Speichern“ des Browsers aus.
Ausdruck – konvertiert die Schlussübersicht in ein druckbares Format (z.B. PDF) und löst den Befehl „Drucken“ des Browsers aus.
Die Formularschaltflächen „Signieren“, „Download“ und „Ausdruck“ stehen nur in einer Seite des Typs „Zusammenfassung anzeigen“ zur Verfügung.
Beispiel – Hundeanmeldung – Formularschaltflächen
Um den Beispielantrag „Hundeanmeldung“ auf der Seite „Zusammenfassung anzeigen“ signieren zu können, muss der Formularentwickler im Ordner „Formularschaltflächen“ des Formulardesigners eine neue Formularschaltfläche erstellen. Hierzu klickt er auf „Erzeugen“ und definiert einen mehrsprachigen Namen
(Text der Schaltfläche) sowie den Typ „Signieren“.
Auf eine gleiche Art und Weise könnte der Formularentwickler auch Formularschaltflächen für den Download und den Ausdruck der Formularzusammenfassung definieren.
Formularelemente
Über den Ordner „Formularelemente“ des Formulardesigners können Kopf- und Fußzeilen modelliert werden. Der
Formulardesigner bietet die Möglichkeit, Kopf- und Fußzeilen von den Vorlagen, die beim Antragsprojekt angegeben wurden, zu initialisieren und anschließend zu bearbeiten. So wird eine konsistente Formularstruktur und
grafische Aufbereitung möglich. Der österreichische E-Government-Styleguide 1.3 [MiWi04a] gibt die Grundform
dieser Elemente, wie beispielsweise die des Formularkopfes, vor. Alternativ dazu können beliebige Vorlagen für
den Seitenkopf und Seitenfuß definiert werden.
Beim Erzeugen eines Formularelements wird dessen Typ abgefragt. Hier stehen folgende beiden Typen zur
Auswahl:
Seitenkopf – kann in weiterer Folge im Antragsformular als Kopfzeile verwendet werden. Die Initialisierung erfolgt aufgrund der Vorlage für den Formularkopf.
Seitenfuß – kann in weiterer Folge im Antragsformular als Fußzeile verwendet werden. Die Initialisierung
erfolgt aufgrund der Vorlage für den Formularfuß.
Für die Bearbeitung der Formularelemente steht ein HTML-Editor zur Verfügung. Dieser Editor ermöglicht neben
der Gestaltung und Bearbeitung von Texten auch das Einfügen von dynamischen Werten über Fabasoft Compo-
71
nents Expressions. Der Formulardesigner der Fabasoft eGov-Suite zeigt im mitgelieferten Beispielformularkopf
für die Einbettung von Formulartitel, Formularbeschreibung sowie den Link auf eine Informationsseite bereits
beispielhaft die Anwendung derartiger logischer Ausdrücke. Im HTML-Editor sind diese Fabasoft Components
Expressions dezent blau hinterlegt (siehe Abbildung 26).
Beispiel – Hundeanmeldung – Formularkopf
Der Formularentwickler wechselt in den Ordner „Formularelemente“ und klickt auf die Schaltfläche „Erzeugen“. Um einen Seitenkopf für das Beispielformular „Hundeanmeldung“ zu erzeugen, gibt er einen mehrsprachigen Namen für den Seitenkopf ein und klickt auf „Von Vorlage initialisieren“. Im HTML-Editor
erscheint eine Kopie des Seitenkopfes, die der Formularentwickler nach seinen Vorgaben abändern kann
(z.B. Adressat).
Das Ergebnis dieser Bearbeitung ist in Abbildung 26 zu sehen. Auf dieselbe Art und Weise kann der Formularentwickler den Seitenfuß erstellen bzw. bearbeiten.
Im endgültigen Online-Formular werden die folgenden dynamischen Werte in den Seitenkopf eingerechnet:
Formulartitel
Einleitungstext
Infolink
Abbildung 27 zeigt den Seitenkopf nach erfolgter Berechnung der dynamischen Werte.
Abbildung 26
Formularelement (Seitenkopf) erzeugen
Abbildung 27
Formularelement (Seitenkopf) im Formular
73
Formularseiten
Formularseiten können im Formulardesigner über den Ordner „Formularseiten“ erstellt, gelesen und bearbeitet
werden. Alle Formularseiten besitzen folgende Metadaten:
Mehrsprachiger Name
Der Name der neuen Formularseite. Dieser Name wird in der Titelzeile des Browsers dargestellt.
Diese Bezeichnung muss innerhalb des Antragsprojektes eindeutig sein und entspricht im generischen Interface der Referenz der neuen Formularseite.
Typ
Der Typ wird bereits bei der Erzeugung der Formularseite festgelegt und bei der Bearbeitung der Formularseite read-only dargestellt.
In dieser Liste können die gewünschten Formularschaltflächen angegeben werden. Die Reihenfolge innerhalb dieser Liste ist unerheblich, da aufgrund der Einheitlichkeit im Formular die Reihung der Schaltflächen
von Fabasoft eGov-Forms gemäß den Vorschriften des Styleguides übernommen wird.
Kommentar
Benutzer einen beliebigen Kommentar zu hinterlegen. Dieser Kommentar dient der Dokumentation des
Projektes.
Nachdem in den vorherigen Schritten bereits Formularblockelemente und Formularblöcke erstellt wurden, ist der
nächste Schritt der Formularentwicklung die Zusammenstellung von Formularseiten. Der Formulardesigner stellt
vier unterschiedliche Typen von Formularseiten mit unterschiedlichen Zielsetzungen zur Verfügung:
Dateneingabe
Formularseiten vom Typ „Dateneingabe“ ermöglichen die Anzeige von Formularblöcken. Die hier angegebenen Formularblöcke werden in der bestehenden Reihenfolge im Online-Formular wiedergegeben.
Die Zusammenstellung der einzelnen Formularblöcke erfolgt nach dem WYSIWYG-Verfahren. Im Zuge dessen kann die Darstellung des Formularblocks geändert werden, indem man die beim Formularblock gespeicherten Formatierungen auswählt.
Information anzeigen
Formularseiten vom Typ „Information anzeigen“ enthalten grundsätzlich einen statischen HTML-Text, der
über den HTML-Editor eingegeben werden kann. Auch hier besteht die Möglichkeit, dynamische Werte über
Fabasoft Components Expressions in die Formularseite einzubetten.
Bürgerkarte auswählen
Wenn der Antrag digital signiert werden soll, dann muss vor der Formularseite des Typs Zusammenfassung anzeigen – oder auch schon zu einem früheren Zeitpunkt – eine Formularseite des Typs „Bürgerkarte auswählen“ ausgeführt werden. Dem Antragsteller wird hiermit ermöglicht, die von ihm bevorzugte Bürgerkarte oder Bürgerkarte light (A1 SIGNATUR der mobilkom austria) auszuwählen.
Zusammenfassung anzeigen
Eine Formularseite dieses Typs wird typischerweise am Ende eines Antragsformulars eingefügt. Gemäß den
Einstellungen dieser Seite kann eine digitale Signatur der eben eingegebenen Antragsdaten erforderlich,
optional oder überhaupt nicht notwendig sein. Die Zusammenfassung wird vom Produkt Fabasoft eGovForms automatisch generiert und zeigt dem Antragsteller die eingegebenen Antragsdaten in einer read-only
Darstellung.
Eingangsbericht anzeigen
Formularseiten vom Typ „Eingangsbericht anzeigen“ ermöglichen die Darstellung eines Eingangsberichts für
den Antragsteller. Dieser Bericht enthält folgende Informationen, die über ein Stylesheet optisch aufbereitet werden können:
Empfänger
Jeder Antrag wird an eine definierte Behörde gestellt. Die postalische Adresse, die Telefonnummer,
eine E-Mail-Adresse und der Uniform Ressource Locator (URL) des Online-Formulars werden im
Kontext des Empfängers dargestellt.
75
Logo
Jedem Bericht ist auch das Logo der empfangenden Behörde zugeordnet.
Eingangsnummer
Die Eingangsnummer besteht aus der Formularkennung (diese kann über das Antragsformular definiert
werden) und einer laufenden Nummer.
Datum und Zeit
Hier wird der Zeitpunkt des Einlangens des Antrags festgehalten. Optional besteht die Möglichkeit, den
Eingangszeitpunkt von einem Zeitstempeldienst bestätigen zu lassen.
Signaturprüfung und Zertifikatsprüfung
Die Prüfungsergebnisse für die Signatur und das Zertifikat sind ebenfalls in der Eingangsbestätigung
enthalten.
Antragsteller
Da in weiterer Folge der gesamte Antrag nochmals in der Empfangsbestätigung enthalten ist, wird unter
dem Antragsteller nur der Name dargestellt.
Betreff
In diesem Attribut ist der Titel des Antragsformulars enthalten.
Beilagen
Eine Auflistung sämtlicher dem Antrag beigelegten Dokumente mit den Angaben „Bezeichnung“,
„Dateiendung“ und „Hashwert“ bildet den letzten Punkt der Empfangsbestätigung.
Neben diesen Daten steht dem Antragsteller über die Formularseite „Empfangsbestätigung anzeigen“ auch
der gesamte Antrag zum Download zur Verfügung.
Beispiel – Hundeanmeldung – Formularseite
Das Beispielformular „Hundeanmeldung“ besteht aus 5 Formularseiten, wobei die ersten beiden Seiten
vom Typ „Dateneingabe“, die dritte vom Typ „Bürgerkarte auswählen“, die vierte vom Typ „Zusammenfassung anzeigen“ und die letzte vom Typ „Empfangsbestätigung anzeigen“ ist. Beispielhaft wird im Folgenden beschrieben, wie eine Formularseite zur Dateneingabe modelliert werden kann.
Der Formularentwickler wechselt in den Ordner „Formularseiten“ und klickt auf die Schaltfläche „Erzeugen“. Anschließend wählt er den Typ „Dateneingabe“ aus und setzt die Bearbeitung mit „Weiter“ fort. Im
oberen Teil dieser Ansicht erhält der Formularentwickler eine Vorschau auf die fertige Formularseite (aktuell sind hier noch keine Formularblöcke enthalten). Im unteren Teil stehen die verfügbaren Elemente für die
Formularseite zur Verfügung. Durch Drag & Drop der Elemente an die gewünschte Stelle der Vorschau kann
die Formularseite zusammengestellt werden.
Will der Formularentwickler ein Element wieder aus der Formularseite entfernen, dann zieht er es per Drag
& Drop auf das Recycle-Icon in der Vorschau.
Wird etwa der Formularblock „Antragsteller“ nicht in der richtigen Formatierung dargestellt, wählt der Formularentwickler mit Hilfe des kleinen Kontext-Menü-Icons die gewünschte Formatierung (z.B. N-PERS2) aus.
Über die Registerkarte „Eigenschaften“ legt der Formularentwickler einen mehrsprachigen Namen für diese Formularseite, z.B. „Seite 1 – Dateneingabe“, fest. Dieser mehrsprachige Name wird im fertigen
Antragsformular in der Titelzeile des Browsers dargestellt.
Das Ergebnis der Bearbeitung ist in Abbildung 28 zu sehen.
77
Abbildung 28
Formularseite
erzeugen/bearbeiten
Antragsformulare
Ein Online-Formular entspricht im Rahmen des Formulardesigners einem Antragsformular. Im Antragsformular
werden die Formularseiten angegeben, die im Laufe der Antragstellung angezeigt werden sollen. Die hier definierte Reihenfolge der Formularseiten bestimmt den Ablauf der Seiten im Online-Formular.
Neben den Formularseiten kann festgelegt werden, welcher Formularkopf bzw. welcher Formularfuß bei diesem
Antragsformular angezeigt werden soll. In den Metadaten des Antragsformulars kann eine Formularbeschreibung, ein Infolink und ein Formulartitel definiert werden. Der Infolink verweist den Antragsteller auf allgemeine
Informationen zum Online-Formular und kann pro Online-Formular vom Anwender definiert werden. Der Infolink
und weitere Metadaten kommen als dynamische Werte, die über eine Fabasoft Components Expression in den
Formularkopf bzw. den Formularfuß geschrieben werden können, zur Anwendung.
Der Formularentwickler hat die Möglichkeit sich das Online-Formular in einer Vorschau anzeigen zu lassen. Diese Vorschau enthält bereits alle Funktionalitäten, die im Online-Formular eingebaut wurden, und stellt somit eine
vollständige Testversion des fertigen Online-Formulars zur Verfügung.
Beispiel – Hundeanmeldung – Antragsformular
Zum Abschluss der Modellierung eines Online-Formulars wird im Ordner „Antragsformular“ über die Schaltfläche „Erzeugen“ ein neues Antragsformular erstellt und die möglichen Metadaten werden eingegeben.
Zusätzlich werden zur Liste der Formularseiten (Registerkarte „Seiten für neuen Antrag“) – innerhalb des
Antragsformulars – die gewünschten Seiten hinzugefügt (siehe Abbildung 29) und anschließend die Bearbeitung abgeschlossen.
Um sicherzustellen, dass das fertige Online-Formular tatsächlich den Anforderungen entspricht, wird die
Schaltfläche „Antragsformular testen“ ausgewählt.
79
Abbildung 29
Antragsformular erstellen
4.3 Projektorientierter Ansatz und
Einbindung des Workflows
4.3
Projektorientierter Ansatz und Einbindung des Workflows
Wie bereits eingangs erwähnt, ermöglicht der Formulardesigner der Fabasoft eGov-Suite die projektorientierte
Entwicklung von Online-Formularen auf Basis einer intuitiven, grafischen Web-Oberfläche. Im Zuge der Entwicklung kann ein Antragsprojekt von einem Benutzer des Formulardesigners erstellt, benannt und einem Workflow
zugeordnet werden. So besteht die Möglichkeit, die Erstellung eines Online-Formulars über die Workflow-Komponente der Fabasoft eGov-Suite zu steuern. Die Zugriffsrechte auf das Antragsprojekt innerhalb des Workflows
werden durch ein Rollenkonzept gesteuert.
Der Formulardesigner stellt folgende Rollen zur Verfügung:
Forms Designer
Ein Formularentwickler mit dieser Rolle hat die grundsätzliche Aufgabe das Antragsformular zu modellieren.
Forms Redakteur
Ein Formularentwickler mit dieser Rolle hat zusätzlich zu den Rechten eines Forms Designers das Recht, ein
Antragsprojekt zu erstellen und somit die Umsetzung eines Antragsformulars in Gang zu setzen.
Forms Tester
Ein Formularentwickler mit dieser Rolle hat keine Bearbeitungsrechte innerhalb des Antragsprojektes. Er
kann lediglich die im Antragsprojekt enthaltenen Antragsformulare in einer Testansicht ausführen und Änderungsanmerkungen hinzufügen (siehe Abbildung 30).
Forms Administrator
Ein Formularentwickler mit dieser Rolle hat ausschließlich das Recht, ein Antragsprojekt zu extrahieren und
in eine Test- bzw. Produktionsumgebung zu laden.
Der projektorientierte Ansatz bei der Formularentwicklung ist auch im Rahmen der Wiederverwendung von Elementen (Formularseiten, Formularblöcken, Formularblockelementen, etc.) unerlässlich. So könnte man etwa in
einem Projekt mit der Bezeichnung „Sammlung von Standardelementen“ behördenspezifische Standardelemente entwickeln, die dann sämtlichen Formularentwicklern zur Verfügung stehen. Ein einheitliches Aussehen der
behördeneigenen Online-Formulare wird somit gefördert.
81
Abbildung 30
Review-Ansicht
Um das Aussehen der Online-Formulare weiter zu vereinheitlichen, können Standardbausteine für Formularblöcke in Form einer Softwarekomponente mitgeliefert werden.
4.4
Übertragung auf den Formularserver
Ausgehend von den in Kapitel 1.3 dargestellten Gesichtspunkten, im Hinblick auf die Trennung von Entwicklungs-, Test- und Produktionsumgebung, stellt die Entwicklungsumgebung für Online-Formulare die Funktionalität zum Extrahieren eines Antragsprojektes zur Verfügung. Die daraus entstehende Datendatei kann in die Testumgebung kopiert und dort über die Funktionalität zum Laden einer Softwarekomponente in das Testsystem
geladen werden.
4.3 Projektorientierter Ansatz und
Einbindung des Workflows
4.4 Übertragung auf den Formularserver
Um Tests möglichst nah am Produktivsystem zu gewährleisten, sei darauf hingewiesen, dass es sich beim Testsystem um eine Runtime von Fabasoft eGov-Forms handeln sollte. Nach Abschluss der Tests kann die Datendatei im Produktionssystem geladen werden. Somit steht das Online-Formular für den Antragsteller im Internet zur
Verfügung.
Zusammenfassung
Abbildung 31
Formulardesigner
83
5
formularentwicklung
5 im generischen interface
In diesem Kapitel soll das bereits aus vorangegangenen Kapiteln bekannte Hundeanmeldungsformular mit dem generischen Zugang ohne Unterstützung durch den Formulardesigner entwickelt
werden. Anhand dieses praxisnahen Beispiels wird Schritt für Schritt auf die zentralen Elemente,
die die Fabasoft eGov-Forms Runtime dafür zur Verfügung stellt, eingegangen, und somit ein Jumpstart in die fortgeschrittene Formularentwicklung geboten.
Fabasoft eGov-Forms stellt aus technischer Sicht eine sehr effiziente Anwendungsentwicklungs- und Laufzeitumgebung dar, die speziell für das Erstellen und Servicieren von hochverfügbaren Onlineformularen konzipiert ist.
Zu diesem Zweck setzt das Produkt gänzlich auf der bewährten Fabasoft VAPP-Technologie, die ausführlich in
[KlWi04] erläutert wird, auf. Dies hat zur Folge, dass das Produkt Fabasoft eGov-Forms äußerst flexibel und
erweiterbar ist. Es wird aber auch bereits eine umfangreiche Sammlung wiederverwendbarer Elemente zur Verfügung gestellt, um dem Formularentwickler ein höchst effizientes Werkzeug zum Erstellen von Onlineformularen in die Hand zu geben.
Die Fabasoft eGov-Forms Laufzeitumgebung dient einerseits dazu, bereits bestehende Formulare zu betreiben,
ist aber auch gleichzeitig die Basis für den Erstellungsprozess neuer Formulare, unabhängig davon, ob dies im
Formulardesigner oder im generischen Interface geschieht.
Für eine Vielzahl von Formularen wird durch den Einsatz des Formulardesigners diese Form der Low-Level-Entwicklung nicht mehr notwendig sein. Soll jedoch der Output des Formulardesigners um spezielle Features erweitert werden, so ist es durchaus hilfreich, wenn dem Formularentwickler das verwendete Werkzeug detailliert
bekannt ist und er über die existierenden Möglichkeiten Bescheid weiß. Aus diesem Grund wird in den nachfolgenden Abschnitten die Fabasoft eGov-Forms Laufzeitumgebung im Detail beleuchtet.
85
Die Modellierung eines Formulars mit Fabasoft eGov-Forms erfolgt in der Regel auf den folgenden konzeptionellen Ebenen:
Datenmodell
Visuelle Repräsentation (GUI)
Ablaufsteuerung
Betrieb des Formulars
Weiterbearbeitung der erhaltenen Daten
Für jede dieser Ebenen stellt das Produkt Fabasoft eGov-Forms bereits die benötigten Komponenten zur Verfügung, um innerhalb kürzester Entwicklungszeit das gewünschte Formular in Betrieb nehmen zu können.
Die nachfolgenden Abschnitte dieses Kapitels erläutern die ersten vier dieser Ebenen und zeigen deren Anwendung mit dem Produkt Fabasoft eGov-Forms anhand der Umsetzung des Beispielformulars „Hundeanmeldung“.
Der letzten Ebene, der Weiterverarbeitung der empfangenen Daten, widmet sich Kapitel 6.
5.1
Datenmodell eines Formulars
Die Definition eines Onlineformulars erfolgt in Fabasoft eGov-Forms durch ein spezielles Komponentenobjekt der
Klasse Objektklasse für Anträge (FSCFORMS@1.1001:SolicitationClass). Dadurch ist gewährleistet, dass die Laufzeitumgebung die Attribute, die zur Ausführung des Formulars benötigt werden, vorfindet.
Die am häufigsten verwendeten Eigenschaften sind:
Seitenkopf
Seitenfuß
Formulartitel
Eindeutige Formularkennung
Formularbeschreibung
5. Formularentwicklung im
generischen Interface
5.1 Datenmodell eines Formulars
Für neuen Antrag auszuführende Schritte
Dynamische Werte
Dieses Objekt, selbst wieder eine Objektklasse, erhält als Basisklasse (COOSYSTEM@1.1:
classsuperclass) die Objektklasse Antrag (FSCFORMS@1.1001:Solicitation). Die Basisklasse stellt die nötigen Attribute für die einzelnen Instanzen dieser Klasse (den tatsächlich mit Werten befüllbaren Formulardatenbehältern) die allgemeinen Eigenschaften, die nahezu jedes Formular benötigt, bereit.
87
Folgende Liste zeigt die am häufigsten verwendeten Attribute:
Hauptinhalt
XSL-Inhalt
Antragsstatus
Beilagen
Signierter Inhalt
Dieser neuen Objektklasse werden der Reihe nach alle Attribute (COOSYSTEM@1.1:classattributes)
zugeordnet, die speziell für dieses Formular benötigt werden (beispielsweise „Informationen über den Hund“ im
bereits bekannten Hundeanmeldeformular). Um möglichst effektiv mit Fabasoft eGov-Forms zu arbeiten, ist
bereits an dieser Stelle eine Gruppierung der Daten zu logischen Einheiten in Form von Aggregaten anzustreben.
Datentypen
Als mögliche Datentypen für Eigenschaften stehen alle Basisdatentypen von Fabasoft Components zur freien
Verfügung. Da die Basisdatentypen bereits ausführlich in [KlWi04] beschrieben sind, wird an dieser Stelle nur
mehr eine kurze Auflistung zur schnellen Übersicht angeführt.
Ganzzahl
Boolescher Wert
Gleitkommazahl
Datum/Uhrzeit
Zeichenkette
Inhalt
Objektverweis
Aufzählung
Zusammengesetzter Typ
Darüber hinaus definiert die Softwarekomponente FSC Forms Base (FSCFORMS@1.1001) als weiteren
Datentyp die Beilageneigenschaft (FSCFORMS@1.1001:AttributeAttachmentDef), die speziell für Onlineformulare entworfen wurde. Diese Eigenschaft bietet spezielle Möglichkeiten, auf die unterschiedlichsten Varianten von Datei-Uploads in Onlineformularen einzugehen.
Eine Beilageneigenschaft erlaubt die Angabe einer Liste von Objekten der Klasse Beilagendefinition
(FSCFORMS@1.1001:AttachmentDefinition) in der Eigenschaft Definition der erlaubten
Beilagen (FSCFORMS@1.1001:allowedattachdefs).
Jede dieser Beilagendefinitionen beschreibt über die nachfolgend angeführten Eigenschaften eine Zeile in der
Liste des daraus entstehenden Formularblocks.
Mehrsprachiger Name
Der mehrsprachige Name dient als Führungstext der betreffenden Zeile im Formularblock.
Anzahl der erlaubten Dateien
Über diese Eigenschaft kann eingestellt werden, ob genau eine, maximal eine bzw. mindestens eine Datei
beigelegt werden muss oder ob die Anzahl der angeführten Dateien zu dieser Beilage vom Benutzer frei
bestimmbar ist.
Beilagenvorlage
Wird eine Beilagenvorlage hinterlegt, so ermöglicht das Beilagen-Control [KlWi04], das zur Visualisierung
von Eigenschaften dieses Typs benutzt wird, den Download dieser Vorlage.
Maximal erlaubte Beilagengröße
Hier kann optional die maximale Größe der akzeptierten Dateien festgelegt werden. Die Angabe erfolgt in
Bytes. Eine Überschreitung dieser Angabe führt dazu, dass die Datei nicht angenommen wird und der Benutzer eine visuelle Rückmeldung erhält.
Erlaubte MIME-Typen
Über erlaubte MIME-Typen können Einschränkungen bzgl. des Typs der erlaubten Dateien definiert werden.
Nicht den angeführten Regeln entsprechende Dateien werden vom Formularsystem automatisch mit einem
visuellen Feedback an den Benutzer zurückgewiesen.
89
Später beilegen erlauben
Mit der Eigenschaft später beilegen erlauben wird dem Benutzer des Onlineformulars über eine Checkbox die Möglichkeit gegeben, erforderliche Beilagen speziell zu kennzeichnen. Das Formularsystem vermerkt
diese Beilage beim Antrag als noch ausständig und erlaubt dem Benutzer mit dem Ausfüllen fortzufahren.
Zu jedem Zeitpunkt sind alle in den Beilageneigenschaften befindlichen Inhalte gesammelt über die Antragseigenschaft Beilagen (FSCFORMS@1.1001:allattachments) verfügbar.
Wiederverwendung von Datenstrukturen – Standardblöcke
Aufgrund der Objektorientiertheit von Fabasoft Components und dem wiederkehrenden Vorkommen ähnlicher
bzw. identischer Datenstrukturen in Formularen stellt sich die Frage nach der Konzeption von wiederverwendbaren Einheiten sogenannten Standardblöcken. Auch im österreichischen E-Government-Styleguide für Onlineformulare [MiWi04a] wurde bereits eine breite Sammlung von Blöcken, die häufig in Formularen zu finden sind,
definiert. Deren Verwendung wird empfohlen, um die Flut an Onlineformularen für den Bürger einigermaßen normieren zu können und ihm so deren Benutzung zu vereinfachen. Im Produkt Fabasoft eGov-Forms wird diese Empfehlung in Form von Eigenschaften und Typen der Komponente FSC Forms AT (FSCFORMSAT@1.1001)
abgebildet.
Für die Verwendung von Standardblöcken mit Fabasoft eGov-Forms stehen die folgenden Varianten zur Verfügung:
Verwendung einer bestehenden Eigenschaft
Die Verwendung von bestehenden Eigenschaften ist dann sinnvoll, wenn der Block in einem Formular nur
einmal verwendet wird, sofern er nicht um weitere Eigenschaften ergänzt wird. Grundsätzlich stellt Fabasoft Components zwar die Möglichkeit der Erweiterung von zusammengesetzten Typen durch fremde Softwarekomponenten zur Verfügung, allerdings sollte hierbei beachtet werden, dass die Datenstruktur durch
eine unkontrollierte Erweiterung rasch unübersichtlich werden kann. Hier muss im Einzelfall entschieden
werden, ob die Erweiterung auch für andere Formulare genutzt werden kann, dann wäre diese Variante ein
durchaus sinnvoller Weg.
Verwendung eines bestehenden Typs
Wird ein Standardblock mehrmals auf einem Formular verwendet, so kann dies nicht über eine Eigenschaft
abgebildet werden. Die Wiederverwendung muss hier auf Ebene des Typs angesetzt werden. Eine Eigenschaft ist für jede weitere Verwendung des Blocks selbst anzulegen.
Verwendung der (Sub-)Eigenschaften eines bestehenden Typs
Erweitert der gewünschte Block den Standardblock um nicht allgemein nutzbare Eigenschaften, so sollte neben
einer Eigenschaft auch noch ein neuer zusammengesetzter Typ angelegt werden, wobei die bestehenden
Eigenschaften genutzt werden können. Die ergänzenden Eigenschaften müssen ohnehin neu erzeugt werden.
Datenmodellierung anhand eines Beispiels
In den nachfolgenden Beispielen soll gezeigt werden, wie das Datenmodell des Hundeanmeldeformulars mit
Hilfe von Fabasoft eGov-Forms definiert wird.
Vorbereitend wird für die Umsetzung des Beispiels eine Softwarekomponente benötigt, da wie bereits zuvor
beschrieben wurde, die Definition des Formulars gänzlich über Komponentenobjekte erfolgt.
91
Beispiel
Um eine Softwarekomponente erzeugen zu können, wird zuerst ein neues Verwaltungswerkzeug
(COOSYSTEM@1.1:AdministrationTool) angelegt. In diesem Verwaltungswerkzeug wird nun
die neue Softwarekomponente erstellt. Als Referenz (COOSYSTEM@1.1:reference) der Softwarekomponente wird HUNDEANM gewählt.
Unter der Annahme, dass die Formularentwicklung in der Fabasoft Components Domäne mit der DomänenID 1.555 erstellt wird, ergibt sich daraus die vollständige Softwarekomponentenreferenz
HUNDEANM@1.555.
Die Eigenschaftswerte, die für das Erzeugen der Softwarekomponente nötig sind, können der Tabelle 6 entnommen werden.
EIGENSCHAFTSNAME
EIGENSCHAFTSWERT
Referenz
HUNDEANM
Versionsnummer
601
Copyright
© 2005
Zustand
In Entwicklung
Name
Formular zur Hundeanmeldung
Tabelle 6: Eigenschaften der Softwarekomponente Hundeanmeldung
Im Rahmen dieser Softwarekomponente werden nun alle weiteren Komponentenobjekte erzeugt. Dazu muss in den
jeweils zu erzeugenden Komponentenobjekten das Attribut Softwarekomponente (COOSYSTEM@1.1:
component) gesetzt werden.
Beispiel
Zuerst wird ein neues Objekt der Klasse FSCFORMS@1.1001:SolicitationClass angelegt
und die in Tabelle 7 angeführten Attributswerte werden festgelegt.
EIGENSCHAFTSNAME
EIGENSCHAFTSWERT
Softwarekomponente
HUNDEANM@1.555
Referenz
HundeanmForm
Name
Hundeanmeldung
Basisklasse
FSCFORMS@1.1001:Solicitation
Tabelle 7: Eigenschaftswerte der Objektklasse HundeanmForm
Der erste Block des Formulars, der Antragsteller, entspricht bereits dem Standardblock „N_PERS2“ des EGovernment-Styleguides für Onlineformulare. Da dieser Block bereits Bestandteil der Softwarekomponente
FSCFORMSAT@1.1001 ist, kann dieser unter Anwendung der zuvor angestellten Überlegungen im Formular benutzt werden.
Es ist eine Erweiterung um ein Feld „Hundeanzahl“ nötig, welche nicht von allgemeinem Nutzen für eine Reihe von Formularen ist. Aus diesem Grund wird die neue Eigenschaft (HUNDEANM@1.555:
antragsteller) und ebenso der neue Typ (HUNDEANM@1.555:Antragsteller) erzeugt.
Allerdings werden die Subeigenschaften des Typs FSCFORMSAT@1.1001:Person_nat wiederverwendet.
93
Beispiel
Der Typ Antragsteller wird wie folgt zusammengesetzt. Es ist lediglich erforderlich eine neue ganzzahlige
Eigenschaft HUNDEANM@1.555:hundeanzahl zu erstellen.
REFERENZ
FSCFORMSAT@1.1001:familienname
FSCFORMSAT@1.1001:akad_grad_cd
FSCFORMSAT@1.1001:vorname
FSCFORMSAT@1.1001:geschlecht_cd
FSCFORMSAT@1.1001:geburt_datum
HUNDEANM@1.555:hundeanzahl
Tabelle 8: Der Typ Antragsteller
Der Adressblock enthält keine Felder, die nicht bereits im Standardblock ADR1 enthalten wären. Aus diesem
Grund kann hier der Typ FSCFORMSAT@1.1001:Adresse ohne Modifikation verwendet werden.
Beispiel
Es ist in diesem Fall nur nötig eine zusammengesetzte Eigenschaft dieses Typs anzulegen. Die Referenz
wird folgendermaßen gewählt:
HUNDEANM@1.555:adresse
Der Block Kontakte entspricht dem Standardblock KONT2, weshalb dieser über den bereits existierenden Typ
FSCFORMSAT@1.1001:Kontakte abgebildet werden kann.
Beispiel
Angelegt wird wiederum nur eine zusammengesetzte Eigenschaft des Typs FSCFORMSAT@1.1001:
Kontakte mit der Referenz HUNDEANM@1.555:kontakt.
Bei „Angaben zum Hund“ handelt es sich um den ersten Block, der nicht als Standardblock zur Verfügung steht.
Aus diesem Grund wird ein neuer Typ benötigt.
95
Beispiel
Der neue Typ HUNDEANM@1.555:AngabenZumHund und die dazugehörige Eigenschaft
HUNDEANM@1.555:angabenzumhund werden mit den dafür benötigten Subeigenschaften laut
Tabelle 9 erstellt.
NAME / REFERENZ
TYP
Rufname (HUNDEANM@1.555:rufname)
COOSYSTEM@1.1:STRING
Geschlecht
(HUNDEANM@1.555:geschlecht)
FSCFORMSAT@1.1001:Geschlecht_cd
Geburtsjahr
(HUNDEANM@1.555:geburtsjahr)
COOSYSTEM@1.1:INTEGER
Rasse (HUNDEANM@1.555:rasse)
Farbe (HUNDEANM@1.555:farbe)
Datum der Übernahme des Hundes
(HUNDEANM@1.555:uebernahmedatum)
COOSYSTEM@1.1:DATETIME
Wie haben Sie den Hund erhalten?
(HUNDEANM@1.555:artdeserhalts)
HUNDEANM@1.555:ArtDesErhalts
Tabelle 9: Der Typ Angaben zum Hund
Der zu erstellende Aufzählungstyp HUNDEANM@1.555:ArtDesErhalts soll die folgenden Aufzählungswerte umfassen:
Kauf
Wurf
Geschenk
Anderes
Der Block Bezahlung entspricht ebenfalls keinem Standardblock, somit sind ein zusammengesetzter Typ und die
zugehörigen Eigenschaften zu erstellen.
Beispiel
Der zusammengesetzte Typ HUNDEANM@1.555:Bezahlung und die zugehörige zusammengesetzte Eigenschaft HUNDEANM@1.555:bezahlung sind laut Tabelle 10 zu erstellen.
NAME / REFERENZ
TYP
Zahlungsart
(HUNDEANM@1.555:Zahlungsart)
HUNDEANM@1.555:Zahlungsart
Abgaben und Gebühren in EUR
(HUNDEANM@1.555:abgaben)
COOSYSTEM@1.1:FLOAT
Tabelle 10: Der Typ Bezahlung
Der Aufzählungstyp HUNDEANM@1.555:Zahlungsart soll die folgenden Aufzählungswerte
umfassen:
Erlagschein
Bar bei Abholung
Der letzte Block Anmerkungen zum Antrag besteht nur aus einer mehrzeiligen Zeichenkette als Anmerkungsfeld.
97
Beispiel
Der zusammengesetzte Typ HUNDEANM@1.555:Anmerkungen wird laut Tabelle 11 angelegt.
NAME / REFERENZ
TYP
Zahlungsart
(HUNDEANM@1.555:anmliste)
COOSYSTEM@1.1:STRINGLIST
Tabelle 11: Der Typ Anmerkungen
Zuletzt wird eine zusammengesetzte Eigenschaft mit der Referenz HUNDEANM@1.555:
anmerkungen dieses neuen Typs erzeugt.
Die in den vorangegangenen Abschnitten erstellten Eigenschaften werden nun der Antragsobjektklasse über das
Attribut Eigenschaften (COOSYSTEM@1.1:classattributes) zugeordnet.
Mit diesem letzten Schritt ist die Gestaltung des Datenmodells abgeschlossen.
5.2 Visuelle Repräsentation eines Formulars
5.2
Visuelle Repräsentation eines Formulars
Formularsystem
Die einzelnen Seiten eines Online-Formulars in Fabasoft eGov-Forms werden über Formularseiten zum Bearbeiten und Suchen von Objekten (COOATTREDIT@1.1:FormPage) modelliert.
Zu diesem Zweck werden die auf der betroffenen Formularseite gewünschten Eigenschaften als Elemente der
Formularseite (COOATTREDIT@1.1:formpageitems) eingetragen.
Um die Anordnung der Subeigenschaften innerhalb eines Blocks zu gestalten, ist es nötig, zu jedem dieser Element-Einträge ein Subelement zu definieren. An dieser Stelle kann das Layout jedes einzelnen Subelements
definiert werden.
Hier stehen folgende Möglichkeiten zur Definition der Anordnung zur Verfügung:
Neue Zeile beginnen
Abstand vor Führungstext
Abstandsbreite
Führungstext
Platzierung des Führungstextes
Textbreite
Textausrichtung
Platzierung des Eingabefeldes
Feldbreite
Wenn die Formularseite nach den individuellen Vorstellungen modelliert wurde, wird ein Schritt „Formularseiten bearbeiten“ (FSCFORMS@1.1001:EditFormPagesStep) instanziert und die Formularseite
als Seite in der Liste Seiten zur Dateneingabe (FSCFORMS@1.1001:editpages) eingetragen.
99
Abbildung 32
Ansicht Layout
Dies kann beliebig oft fortgesetzt werden, bis die gewünschte Aufteilung der benötigten Formularblöcke auf einzelne Seiten erreicht ist.
Dynamische Inhalte
Dieses Kapitel widmet sich der Einbettung von dynamischen HTML-Inhalten in Fabasoft eGov-Forms-Formulare.
An allen Stellen, an denen in Fabasoft eGov-Forms HTML-Inhalte angegeben werden können, wird ein Konzept
verfolgt, das als dynamische Inhalte bezeichnet wird. Typische Anwendungen für dynamische Inhalte sind z.B.
Formularkopf/-fuß und E-Mail-Body.
Ein dynamischer Inhalt ist eine Vorlage, die vor der endgültigen Einbettung in den HTML-Code der jeweiligen
Formularseite einer Reihe von textuellen Substitutionen unterworfen wird, um so situationsbedingte Elemente
in das Formular einbinden zu können.
Die Grundstruktur dieser Vorlage ist XHTML. Es sollte allerdings kein vollständiges XHTML-Dokument verwendet werden, da das um die kontextabhängigen Elemente angereicherte Dokumentenfragment direkt in die umgebende XHTML-Seite eingebettet wird.
Dynamische Elemente in diesen Vorlagen werden über Fabasoft Components Expressions realisiert. Es gibt zwei
grundlegend verschiedene Methoden diese Ausdrücke in die Vorlage einzubetten.
Pseudotags <%...%>
FSCDOX-Expressions
Pseudotags
Bei der ersten Variante werden die Ausdrücke über die Eigenschaft Dynamische Wert (FSCSTEPENG@1.1001:
dynamicvalues) beim jeweiligen Antragsschritt mit GUI definiert. Jeder dieser Ausdrücke wird durch einen
eindeutigen Bezeichner repräsentiert. Die Einbettung in die Vorlage erfolgt über Pseudo-HTML-Tags der Form
<%{[escape:javascript:]}Eindeutiger Bezeichner%>. Diese Pseudotags werden vor der Darstellung zur Gänze mit den korrespondierenden Werten textuell ersetzt, wobei die Verknüpfung zwischen dem
Pseudotag und dem einzusetzenden Wert über den gewählten eindeutigen Bezeichner hergestellt wird.
Ausdrücke werden nur angenommen, wenn diese auch einen Textwert repräsentieren. Der Textwert unterliegt
keiner Längenbeschränkung und kann somit durchaus auch selbst wieder eine gesamte (X)HTML-Substruktur
darstellen.
Die Verwendung der Zeichenfolge [escape:javascript] bewirkt ein automatisches Escapen des Textes vor der Substitution. Dieses Escapen kann unter Umständen für dynamische Werte innerhalb von HTMLAttributen nützlich sein.
101
Als Beispiel für die Verwendung der Pseudotag-Substitution soll hier das Einbetten eines dynamischen Hyperlinks angeführt werden.
Im HTML-Fragment wird folgender Pseudo-Tag verwendet:
...
<%[escape:javascript]hyperlink%>
...
Der Eintrag in den dynamischen Werten sieht wie folgt aus:
hyperlink “http://www.fabasoft.com
Quelltext 1: Beispiel für Pseudotags
FSC Documents Expressions
Die zweite Variante bedient sich einer Methodik der Softwarekomponente FSC Documents
(FSCDOX@1.1001). Diese Komponente, ebenfalls Bestandteil des Produktes Fabasoft eGov-Forms, basiert
auf den Fabasoft Active Reports. Grundsätzlich liegen dieser Variante ebenfalls Fabasoft Components Expressions zugrunde, allerdings werden diese nicht beim jeweiligen Schritt definiert, sondern über spezielle Tags
gekennzeichnet und direkt in die Vorlage eingebettet.
Die Kennzeichnung von eingebetteten Expressions erfolgt in FSC Documents-Expressions über das HTML-Element span. Des Weiteren müssen sowohl das Attribut class mit dem Wert „FSCDOX_Expr“ und das Attribut
fscexpr mit dem Wert „4.0“ angeführt werden. Nur dann werden die Tags als FSC Documents Expressions
erkannt und auch evaluiert. Der zwischen dem öffnenden und dem schließenden Tag (</span>) befindliche
Text wird als Fabasoft Components-Expression interpretiert und bewertet. Anschließend wird das gesamte Konstrukt mit dem eben berechneten Wert substituiert. Auch hier gilt, dass nur Zeichenkettenwerte tatsächlich substituiert werden können.
Als Beispiel soll hier der bereits eingegebene Name des Antragstellers in den Header der nächsten Seite eingebettet werden.
...
<SPAN class=”FSCDOX_ExprSelected” fscexpr=”4.0”>
!COOSYSTEM@1.1:STRING(::object.HUNDEANM@1.1013:
antragsteller.HUNDEANM@1.1013:vorname + “, “ +
::object.HUNDEANM@1.1013:antragsteller.HUNDEANM@1.1013:nachname )
</SPAN>
...
Quelltext 2: Beispiel für FSC Documents Expression
Ausdrücke für dynamische Inhalte
Da in [KlWi04] bereits ausführlich auf die Fabasoft Expressions eingegangen wurde, soll an dieser Stelle nur auf
die spezifischen Merkmale im Rahmen von Ausdrücken in dynamischen Inhalten hingewiesen werden.
Die wichtigste Information für die Verwendung von Ausdrücken ist, welche Werte unmittelbar angewandt werden können (Scope). Grundsätzlich sind alle Bezeichner in Ausdrücken für dynamische Inhalte über einen globalen Scope verfügbar, d.h. die Dereferenzierung erfolgt jeweils über den Scope-Operator „::“. Unter dem speziellen Bezeichner ::this kann das Werteverzeichnis, das den globalen Scope bildet, als gesamte Einheit
angesprochen werden. Über this ist jeweils das aktuelle Antragsobjekt, die gerade in Bearbeitung befindliche Instanz, verfügbar.
103
Die Tabelle 12 gibt Aufschluss über die verfügbaren Schlüssel im Werteverzeichnis:
BEZEICHNER
BESCHREIBUNG
object
Antragsobjekt, das gerade vom Benutzer ausgefüllt wird.
isnew
Boolescher Wert, der anzeigt, ob der soeben in Bearbeitung befindliche Antrag neu
erzeugt wurde oder ob dieser bereits zu einem früheren Zeitpunkt erstellt wurde.
iscomplete
Boolescher Wert, der anzeigt, ob der Antrag bereits vollständig eingebracht ist.
guiidx
Index des soeben dargestellten GUI-Schritts
Tabelle 12: Verfügbare Bezeichner in Ausdrücken
Definition für dynamische Inhalte
Die Definition von dynamischen Inhalten erfolgt über die Auswahl eines Objektes der folgenden Objektklassen:
Formularseitenelement (statisch) (COOATTREDIT@1.1:DisplayElement)
Sprachabhängiger Inhalt (COOSYSTEM@1.1:LanguageContent)
Beide Objektklassen verfügen über einen multilingualen Inhalt. Dabei wird jeweils der Inhalt für die gerade dargestellte Sprache als Ausgangsbasis für die Substitution herangezogen. Somit ist gewährleistet, dass selbst
HTML-Inhalte in Formularen mehrsprachig ausgelegt werden können.
Formularkopf und Formularfuß
Erforderliche Elemente jedes Onlineformulars sind ein standardisierter Formularkopf (Header) und Formularfuß
(Footer), die die Corporate Identity des Formularbetreibers widerspiegeln.
Diese beiden Elemente können in Fabasoft eGov-Forms pro Formular eingestellt werden, indem bei der Antragsobjektklasse die Eigenschaften Seitenkopf (FSCSTEPENG@1.1001:rootpageheader) und Seitenfuß (FSCSTEPENG@1.1001:rootpagefooter) als dynamischer Inhalt definiert werden.
Wie bereits im vorangegangenen Kapitel ausführlich erläutert, können somit auch in den statisch definierten
Formularelementen dynamische Werte verwendet werden. Dies kann beispielsweise in Bezugnahme auf bereits
eingegebene Daten besonders nützlich sein.
Das nachfolgende Beispiel veranschaulicht einen personalisierten Formularkopf für ein Hundeanmeldeformular.
...
<hr/>
Hundeanmeldung von <%anrede%>,
an die Gemeinde <%gemeinde%>.
<hr/>
...
Quelltext 3: Beispiel für Formularkopf
105
Formularlayout anhand eines Beispiels
Die Layout-Modellierung des Hundeanmeldeformulars wird im folgenden Beispiel gezeigt.
Beispiel
Zu diesem Zweck wird, wie bereits zuvor beschrieben, ein Objekt der Klasse Formularseite zum Bearbeiten
und Suchen von Objekten (COOATTREDIT@1.1:FormPage) benötigt. Als Referenz (COOSYSTEM@1.1:
reference) wird „HundeanmSeite“ gewählt. Als Elemente der Formularseite werden alle im Kapitel Datenmodellierung erstellten Eigenschaften eingetragen und mit den notwendigen Angaben zum Layout versehen.
SEITENELEMENT
SUBELEMENTE
HUNDEANM@1.1013:antragsteller
HUNDEANM@1.1013:AntragstellerFmt
HUNDEANM@1.1013:adresse
FSCFORMSAT@1.1001:adr1
HUNDEANM@1.1013:angabenzumhund
HUNDEANM@1.1013:AngabenZumHundFmt
HUNDEANM@1.1013:bezahlung
HUNDEANM@1.1013:BezahlungFmt
HUNDEANM@1.1013:anmerkungen
HUNDEANM@1.1013:AnmerkungenFmt
Tabelle 13: Seitenelemente
Des Weiteren wird der Schritt „Formularseiten bearbeiten“ (FSCFORMS@1.1001:
EditFormPagesStep) instanziert und als Seite zur Dateneingabe die soeben erstellte Formularseite
eingetragen.
Somit ist die visuelle Modellierung des Hundeanmeldungsformulars abgeschlossen.
5.3 Ablaufsteuerung in Formularen
5.3
Ablaufsteuerung in Formularen
Ein zentrales Merkmal von Fabasoft eGov-Forms ist die Verwendung von modularen Bausteinen, den sogenannten Anwendungsschritten, um Abläufe in Formularen modellieren zu können. Ein Anwendungsschritt repräsentiert einen häufig wiederkehrenden, in sich geschlossenen Teil einer Anwendung, der sich nur durch eine
bestimmte Menge von Parametern von einem gleichwertigen Schritt einer anderen Anwendung unterscheidet.
Dieses Schrittkonzept wird zu einem großen Teil über die Softwarekomponente FSC Step Processing Engine
(FSCSTEPENG@1.1001) bereitgestellt, in der auch die nötigen Objektklassen und Standardanwendungen
angesiedelt sind.
Jeder Anwendungsschritt ist eine Instanz einer bestimmten Objektklasse, die diese Kapselung definiert. Die
Parametrierung erfolgt über das Bearbeiten der Eigenschaften dieses Schritts.
Die Basisklasse aller Anwendungsschritte ist die abstrakte Klasse FSCSTEPENG@1.1001:AppStep.
Davon leiten sich die folgenden, wiederum abstrakten Klassen ab:
Anwendungsschritt mit GUI (FSCSTEPENG@1.1001:GUIStep)
Anwendungsschritt ohne GUI (FSCSTEPENG@1.1001:NoGUIStep)
Anwendungsschritt zur Ablaufsteuerung (FSCSTEPENG@1.1001: FlowControlStep)
Die Klasse Antragsschritt mit GUI (FSCFORMS@1.1001:SolicitationGUIStep) stellt eine
Ableitung der Klasse Anwendungsschritt mit GUI dar, mit der antragsspezifische Funktionen wie Formularheader und -footer ermöglicht werden.
Die beiden Komponenten FSCSTEPENG@1.1001 und FSCFORMS@1.1001 stellen bereits eine Reihe
von Schritten zur Verfügung, mit deren Hilfe eine Vielzahl an Formularen ohne jeglichen Programmieraufwand
umgesetzt werden kann.
Eine umfassende Auflistung der wichtigsten, im Produkt Fabasoft eGov-Forms verfügbaren Schritte und deren
detaillierte Beschreibung findet sich in Kapitel 10. Im Folgenden soll auf die speziellen Eigenschaften und Unterschiede der verschiedenen Kategorien von Schritten eingegangen werden.
107
Anwendungsschritte mit GUI
Allen Anwendungsschritten mit GUI ist gemeinsam, dass sie über folgende Parametriermöglichkeiten verfügen:
Schaltflächenlabel für „Nächster Schritt“
Schaltflächenlabel für „Schritt zurück“
Schaltflächenlabel für „Abbrechen“
Inhalt für Seitenkopf
Inhalt für Seitenfuß
Dynamische Werte für Inhalte
Die Schaltflächen können sowohl als Objekte der Klasse Formularschaltfläche (FSCSTEPENG@1.1001:
FormButton) als auch als Zeichenkette angeführt werden, wobei bei einer doppelten Eingabe die Objektangabe höher priorisiert behandelt wird. Wird keine der beiden Möglichkeiten genutzt, so erscheint bei der Formularausführung die betreffende Schaltfläche nicht.
Als Seitenkopf und Seitenfuß sind, wie bereits bei der Objektklasse des Antrags beschrieben wurde, entweder
statische Formularseitenelemente oder sprachabhängige Inhalte erlaubt, die als dynamische Inhalte interpretiert
werden.
Anwendungsschritte ohne GUI
Anwendungsschritte ohne GUI werden, wie der Name schon sagt, nicht dargestellt. Es handelt sich dabei um
Elemente, die ohne Benutzerinteraktion durchgeführt werden können, aber trotzdem bedeutende Bestandteile in
vielen Formularen sind.
Zu dieser Art von Anwendungsschritt gehört zum Beispiel der Schritt „SMTP-Mail versenden“.
Schrittsequenzen
Mit Hilfe dieser Schritte können nun Sequenzen formuliert werden, die in bestimmten Situationen ausgeführt
werden sollen. Die Standard-Schrittsequenz, die immer dann ausgeführt wird, wenn ein neuer Antrag auszuführen ist, wird bei der Eigenschaft Für neuen Antrag auszuführende Schritte (FSCFORMS@1.1001:
solsteps) definiert.
Es gibt eine Reihe von weiteren Eigenschaften, um Schrittsequenzen für unterschiedlichste Kontexte definieren
zu können. Als Beispiel sei hier die Schrittsequenz zur Fehlerbehandlung genannt.
Jeder Schritt verfügt über eine sogenannte Ausführungsbedingung (FSCSTEPENG@1.1001:
execcondition), eine Fabasoft Components Expression, mit deren Hilfe bestimmt wird, ob der jeweils
aktuelle Schritt nun tatsächlich ausgeführt wird oder nicht.
Abbildung 33
Ausführen einer Sequenz
von Schritten
109
Die Laufzeitumgebung
Die Laufzeitumgebung von Fabasoft eGov-Forms verwendet ausschließlich die bewährte Fabasoft VAPP-Technologie. Die Liste der Schritte, die für einen Antrag definiert wurden, wird von einer virtuellen Anwendung
(FSCVAPP@1.1001:Application) abgearbeitet.
Anwendungsscope
Virtuellen Anwendungen liegt üblicherweise ein Werteverzeichnis zugrunde, in dem alle Parameter der VAPP
über eindeutige Bezeichner enthalten sind. Dieses Werteverzeichnis kann über Fabasoft Components Expressions dann als sogenannter Scope ausgelesen und verändert werden.
Der Fabasoft eGov-Forms Laufzeitumgebung liegt ebenfalls ein derartiges Werteverzeichnis während der Ausführung eines Formulars zugrunde. Dieses wird mit Werten, die die Laufzeitumgebung benötigt, ausgestattet. Es
kann aber ebenso mit formularspezifischen Werten, wie beispielsweise über den Schritt „Parameter setzen“,
befüllt werden. Der wichtigste Aspekt ist allerdings, dass in allen Ausdrücken innerhalb von dynamischen Inhalten auf eben diesen Scope zugegriffen werden kann.
Implementierung von Schritten
Ein Schritt ist abstrakt betrachtet ein in sich geschlossener Teil einer Online-Applikation.
Ein Schritt kann entweder als Fabasoft Components Aktion (COOSYSTEM@1.1:Action) oder als Anwendung (FSCVAPP@1.1001:Application), kurz VAPP, implementiert werden.
Die Laufzeitumgebung kommuniziert mit der ausführenden Einheit über die in Tabelle 14 angeführten Argumente.
NAME
TYP
RICHTUNG
BESCHREIBUNG
currentstep
COOSYSTEM@1.1:OBJECT
in
Der aktuell
auszuführende Schritt
stepindex
in
Index des aktuell auszuführenden Schritts
params
COOSYSTEM@1.1:
OBJECTLIST
in
Abzuarbeitende Liste von
Schritten
stepsinfo
COOSYSTEM@1.1:
DICTIONARY
inout
Scope für Ausdrücke
command
inout
Richtung, in der der Anwendungsschritt verlassen wird
0: Abbruch der gesamten
Sequenz
n: n Schritte vor
-n: n Schritte zurück
Tabelle 14: Argumentliste für Schritte
Fehlerbehandlung
Tritt während der Ausführung einer Schrittsequenz ein nicht behandelbarer Fehler auf (z.B. Fehler beim Verbindungsaufbau zum Backoffice), so wird dieser von der Fabasoft eGov-Forms Laufzeitumgebung abgefangen. Um
nicht den Endbenutzer mit einem Fehler zu konfrontieren, der für ihn ohnehin nutzlos wäre, wird der Fehler in
jedem Fall in das am Formularservice verfügbare Ereignisprotokoll eingetragen.
Darüber hinaus wird eine in der Eigenschaft Im Fehlerfall auszuführende Schritte (FSCFORMS@1.1001:
solerrsteps) der Antragsobjektklasse definierbare Liste von Schritten ausgeführt. Hier kann beispielsweise
111
dem Benutzer eine allgemeine Mitteilung über das Auftreten eines Fehlers angezeigt werden und automatisch
eine E-Mail an den zuständigen Administrator versandt werden.
In dieser Sequenz kann jeder verfügbare Schritt verwendet werden. Es liegt im Ermessen des Formularentwicklers, wie auf einen auftretenden Fehler reagiert werden soll.
Parameter für Schritte
Vor der Ausführung jedes einzelnen Schritts wird von der Fabasoft eGov-Forms Laufzeitumgebung die Aktion
Argumente des Schritts als Dictionary ermitteln (FSCFORMS@1.1001:GetStepParams) auf den
Schritt ausgeführt. Die Implementierung bei der jeweiligen Schrittklasse stellt mehr oder weniger komplexe
Parameterberechnungen an, und legt alle Werte in einem Werteverzeichnis (COOSYSTEM@1.1:
DICTIONARY) ab. Dieses Werteverzeichnis ist neben dem Anwendungsscope ein weiteres Argument für die
Implementierung der Logik jedes Schritts.
Ablaufmodellierung anhand eines Beispiels
Im nachfolgenden Beispiel wird das Hundeanmeldeformular nun durch Definieren des Ablaufs fertig gestellt.
5.4 Betrieb des Formulars
Beispiel
Nun wird der zuvor erstellte Schritt „Formularseiten anzeigen“ in der Antragsobjektklasse
HUNDEANM@1.1013:HundeanmForm in die Liste der für neue Anträge auszuführenden Schritte
eingetragen.
Da das Formular aus nur einer Seite besteht, ist nur die Schaltfläche „Nächster Schritt“ mit der Zeichenkette „Absenden“ zu definieren.
Da die Ausführungsbedingung für alle neuen Schritte mit dem Ausdruck „true“ vorbelegt ist, ist dessen
Ausführung gewährleistet und muss nicht explizit abgeändert werden.
Durch diese abschließenden Ergänzungen ist das Hundeanmeldeformular nun betriebsbereit.
5.4
Betrieb des Formulars
Starten aus einem Webbrowser
Fabasoft eGov-Forms basiert gänzlich auf der Fabasoft Components VAPP-Technologie [KlWi04], daher besteht
die Laufzeitumgebung aus einer Reihe von virtuellen Anwendungen mit unterschiedlichsten Aufgaben. Eine dieser Anwendungen ist Neuen Antrag starten (FSCFORMS@1.1001:DoNewSolicitation). Diese
Anwendung dient dazu, ein beliebiges im System vorhandenes Formular in einem Webbrowser auszuführen.
Der URL zum Ausführen einer Anwendung sieht schematisch folgendermaßen aus:
http[s]://[hostname]/[virtualdirecory]/fscasp/content/bin/fscvext.dll?[urlargs]
Quelltext 4: Schematischer Formular-URL
wobei die Liste der erforderlichen und optionalen Argumente für die Anwendung Neuen Antrag ausführen
(FSCFORMS@1.1001:DoNewSolicitation) (oben urlargs) der Tabelle 15 entnommen werden kann.
113
BEZEICHNUNG
OPTIONAL
BESCHREIBUNG
ax
Nein
Muss den Objektadresswert COO.1.1001.1.83288, welcher die
Anwendung zum Starten eines neuen Antrags repräsentiert,
beinhalten.
dx
Ja
Bestimmung der zu verwendenden Anwendungssteuerung über
deren Objektadresse.
sol_createclass
Nein
Objektadresse der Antragsobjektklasse, die das Formular
beschreibt, das gestartet werden soll.
customargs
Ja
URL-codierte Zeichenkette mit beliebigen Argumenten. Die
Argumente werden unverändert an die Formularlaufzeitumgebung propagiert, um in einer Reihe von Fabasoft Components
Expressions während der Formularausführung verfügbar zu sein.
autologout
Ja
Boolescher Wert, der ein automatisches Benutzer-Logout nach
Verlassen des letzten Formularschritts erzwingt.
frmtarget
Ja
Objektadresse eines Formularziels (FSCFORMS@1.1001:
FormTarget), das nähere Angaben über den Empfänger
des Formulars enthält (z.B. Empfängeranschrift, Beschreibung
von Backoffice-Schnittstellen, etc).
ru
Ja
Return-URL, der nach Ende des Formulars annavigiert werden
soll.
lx
Ja
Sprachkürzel, z.B. de für Deutsch oder en für Englisch.
Tabelle 15: Argumente des Formular-URL
5.4 Betrieb des Formulars
5.5 Einbindung von PDF-Forumularen
Um das fertig gestellte Beispielformular nun auch tatsächlich ausführen zu können, kann der folgende URL direkt
in einem Webbrowser eingegeben werden:
http://localhost/fsc/fscasp/content/bin/fscvext.dll?ax=COO.1.1001.1.83288&
dx=COO.1.1001.1.83191&sol_createclass=COO.1.555.1.985
Quelltext 5: Beispiel für Start-URL des Formulars
5.5
Einbindung von PDF-Formularen
Um der Forderung nach Integration von einer Vielzahl bereits bestehender PDF-Formulare gerecht zu werden,
stellt Fabasoft eGov-Forms als Alternative zu den reinen HTML-Formularen auch die Möglichkeit zur Einbindung
von bestehenden PDF-Formularen zur Verfügung.
Die Integration von PDF-Formularen erfolgt über den Schritt „PDF-Formular bearbeiten“
(FSCFORMS@1.1001:EditPDFFormStep). Dieser Schritt visualisiert das ihm als Argument angegebene PDF-Formular (FSCFORMS@1.1001:PDFForm).
Bei der Erstellung von PDF-Formularen müssen aufgrund deren Architektur notwendige Einschränkungen berücksichtigt werden. Der Submit-Button muss sich beispielsweise innerhalb des PDF-Formulars befinden, um die Formulardaten zurück an den Webserver senden zu können.
Um das Formular in einer dynamischen Webanwendung verwenden zu können, muss der zugehörige Submit-URL
ebenfalls dynamisch gestaltet werden. Zu diesem Zweck wird anstelle eines statischen URL die Zeichenkette
<%fscurl%> verwendet. Diese Zeichenkette wird vor dem Download mit dem jeweils aktuell gültigen URL
substituiert, um den weiteren Ablauf des Antrags zu gewährleisten.
115
PDF-Formulare geben die eingegebenen Daten via XML an die Applikation zurück. Um die Daten in Fabasoft
eGov-Forms sinnvoll weiterverarbeiten zu können, muss nun eine Zuordnung zu Fabasoft Components Eigenschaften erfolgen. Dies ist über die Liste Formularfeldzuordnung beim Schritt möglich.
Die Zuordnung erfolgt für jeden Formularwert über einen Pfad zum zugehörigen Attribut. Dieser wird durch einen
XML-Knoten mit einem bei der Formularerstellung frei definierbaren Namen repräsentiert.
Zusammenfassung
Abbildung 34
generisches Interface
5.5 Einbindung von PDF-Forumularen
117
6
weiterbearbeitung
6 eingebrachter formulare
In diesem Kapitel wird der Transfer des vom Bürger fertig ausgefüllten Formulars bis auf den
Schreibtisch des zuständigen Sachbearbeiters beschrieben. Fabasoft eGov-Forms stellt für diesen
Transport des Formulars einige unterschiedliche Varianten zur Verfügung, um den individuellen
Anforderungen des Formularbetreibers bestmöglich gerecht zu werden.
Ein Formular wurde vom Bürger ausgefüllt und liegt auf dem Formularserver zur Weiterbearbeitung bereit. Was
mit den Formulardaten weiter geschehen soll, ist aber dennoch eine organisatorische Entscheidung, in die eine
Vielzahl von Überlegungen einfließt.
Neben der Organisationsgröße spielen sicherlich auch Aspekte wie Standortwahl der beteiligten Systeme (nicht
nur physisch, sondern auch in Bezug auf die Organisation) und Aufwand für die Integration in den regulären,
betrieblichen Ablauf eine zentrale Rolle.
Die erste Wahl bildet unbestritten eine lose Kopplung des Formularsystems und des Backoffice-Systems über
eine möglichst flexible SOAP-Schnittstelle. In diesem Fall bieten sich zwei verschiedene Varianten in Bezug auf
die Transportrichtung an:
Das Formularsystem übergibt die Daten an das Backoffice (Push-Verfahren).
Das Backoffice holt sich die Daten vom Formularsystem (Pull-Verfahren).
In den beiden nachfolgenden Kapiteln wird jeweils eines der Verfahren und deren mögliche Umsetzung mit Fabasoft eGov-Forms bzw. der Fabasoft eGov-Suite dargestellt.
119
Sicherheitsaspekte
Bei den im Folgenden vorgestellten Kommunikationsszenarien ist es notwendig, den betrieblichen Anforderungen gerecht zu werden und entsprechende Maßnahmen zu ergreifen, um das transportierte Gut, in diesem Fall
persönlichen Daten der Kunden, zu schützen.
Die eingesetzten Transportprotokolle stellen bereits sehr brauchbare Schutzmechanismen zur Verfügung. In beiden
Szenarien erfolgt der Transport der Daten über HTTP. Durch HTTP-Encryption (HTTPS) wird der gesamte Transport
verschlüsselt abgewickelt und bietet somit den bestmöglichen Schutz vor Man-In-The-Middle Angriffen.
Durch die Verschlüsselung der Daten können aber Denial of Service (DoS)-Angriffe nicht verhindert werden.
DoS-Angriffe nutzen in der Regel einen offenen Port, um die betroffenen Services mit unzähligen „sinnlosen“
Anfragen zu beschäftigen und somit das System lahm zu legen. Um sich vor Angriffen dieser Art vorbeugend zu
schützen, ist zumindest eine Authentisierung auf Webserver-Level nötig. Dadurch können Anfragen von unbekannten Absendern bereits sehr früh in der Bearbeitung, nämlich gleich beim Eintreffen, ausgeschieden werden.
Grundsätzlich gilt, je eingeschränkter der Zugriff auf den Dienst konfiguriert wird, umso höher ist der Schutz vor
potentiellen Angriffen. Der Zugriff kann soweit eingeschränkt werden, dass eine erfolgreiche Anmeldung nur
über zertifikatsbasierte Authentisierung und nur von einem bestimmten IP-Adressbereich aus erlaubt ist.
Als Grundvoraussetzung für den sicheren Betrieb eines Webservers gilt das Ausstatten mindestens aller Dienstprogramme und des Betriebssystems mit den aktuellsten Sicherheitspatches des jeweiligen Herstellers. Ein
Großteil der erfolgreichen Angriffe auf HTTP-Server erfolgt durch das Ausnutzen bekannter Exploits in den
Dienstprogrammen bzw. des darunterliegenden Betriebssystems.
Trotz allem wird manchmal ein Öffnen von Ports für den Zugriff von außerhalb in ein Backoffice-System bereits
als Sicherheitsrisiko eingestuft. In solchen Fällen ist der Pull-Betrieb vorzuziehen, da hier die Verbindungsaufnahme sowie die gesamte nachfolgende Kommunikation vom Backoffice-System gesteuert werden.
Will man aber die Weiterleitung der Formulardaten synchron in den Ablauf des Antrags einbetten, so ist der
Push-Betrieb trotz der bekannten Sicherheitseinwände zu bevorzugen. Zusätzlich sollte durch hinreichende Systempflege das Risiko eines Angriffs minimiert werden.
6. Weiterbearbeitung
eingebrachter Formulare
6.1 Push-Verfahren
6.1
Push-Verfahren
Dieser Abschnitt widmet sich den Möglichkeiten, die Fabasoft eGov-Forms bietet, um die Formulardaten vom
Formularserver initiiert an ein Backoffice-System zu übergeben (Push).
Diese Variante überzeugt vor allem durch die trotz der Vielzahl von Einsatzmöglichkeiten geringe Komplexität bei
der Anwendung. Der Abtransport der Daten erfolgt synchron am Ende der Formularschrittsequenz und dem
Antragsteller kann unmittelbar Feedback über den Erfolg der Übergabe gegeben werden.
Mit Hilfe der Abbildung 35 wird der technische Ablauf einer Abtransport-Anfrage mittels Push-Verfahren
skizziert.
Abbildung 35
Ablauf Push-Verfahren
121
In den nächsten Kapiteln wird detailliert auf die Einstellungen und Maßnahmen eingegangen, die auf beiden
Serverumgebungen benötigt werden, um die Formulardaten vom Formularserver automatisiert an die Fabasoft
eGov-Suite weitergeben zu können.
Um eine ebenfalls mögliche programmatische Bedienung der beteiligten Web-Services zu ermöglichen, wird das
Transportprotokoll im Detail beleuchtet.
Formularserver
Am Formularserver muss der Abtransport bei der Formulardefinition explizit aktiviert werden. Es muss für jedes
spezifische Formular bekannt sein, welches Webservice das Ziel des Transportes sein soll, welche Authentisierung etc. erforderlich ist.
All diese Einstellungen erfolgen über ein Objekt der Klasse Formularziel (FSCFORMS@1.1001:
FormTarget), das beim Starten eines Antrags als URL-Argument mitgegeben wird. Zur tatsächlichen Durchführung des Abtransportes steht der „Schritt mit GUI“ Formulardaten an Backoffice senden
(FSCFORMS@1.1001:Post2BackOfficeStep) zur Verfügung.
Dieser Schritt erstellt die Anfrage unter Verwendung der zu diesem Zeitpunkt bereits existierenden XML-Daten
und des dazugehörigen Stylesheets. Sollten die Daten zu diesem Zeitpunkt nicht verfügbar sein, werden sie
implizit vor der Ausführung des Schritts erstellt. Im Anschluss wird ein SOAP-Aufruf gegen das im Formularziel
definierte Web-Service durchgeführt.
Abhängig von der Antwort des SOAP-Aufrufes setzt der Schritt die Bearbeitung mit unterschiedlichen Tätigkeiten fort. Im Falle einer positiven Antwort wird eine etwaige im Response enthaltene Annahmebestätigung visualisiert und der Benutzer beendet den Ablauf manuell über definierbare Schaltflächen. Ist die Antwort negativ, so
wird dem Benutzer ein Hinweistext dargestellt und die Möglichkeit geboten, den Transport erneut auszulösen.
6.1 Push-Verfahren
Backoffice
Die Fabasoft eGov-Suite stellt mit der Softwarekomponente FSCFRMTR@1.1001 die Funktionalität zur effizienten Übernahme von Formulardaten über eine SOAP-Schnittstelle zur Verfügung. Diese Schnittstelle wurde
mittels der SOAP-Aktion Formular entgegennehmen (FSCFRMTR@1.1001:TakeForm) implementiert,
und wird in diesem Abschnitt eingehend erläutert.
Datenübernahmekonfiguration
Der Ablauf einer SOAP-Anfrage kann über Einstellungen in einem Objekt der Klasse Forms Datenübernahme
Konfiguration (FSCFRMTR@1.1001:FormsTransferConfiguration) beeinflusst werden.
Die aktuell gültige Konfiguration ist in der Eigenschaft Forms-Datenübernahme-Konfiguration
(FSCFRMTR@1.1001:clientcfg) in der aktuellen Domäne zu hinterlegen. Wie bei allen mandantenfähigen Konfigurationen kann auch die Formularübernahmekonfiguration hierarchisch aufgebaut werden. Die Wurzel aller Konfigurationen muss die von der Softwarekomponente mitgelieferte FSCFRMTR@1.1001:
DefaultConfiguration sein, um einen komplikationslosen Ablauf zu gewährleisten.
Jede Eigenschaft der Konfiguration wird in deren Hierarchie akkumuliert ausgelesen. Das bedeutet, dass eine
Einstellung aus einer der aktuellen Konfiguration übergeordneten herangezogen wird, wenn in der aktuellen
Konfiguration diese Einstellung nicht angegeben wird.
Die Forms Datenübernahmekonfiguration sieht folgende Einstellmöglichkeiten vor:
Parameter in der Anfrage zulassen
Default Anfrageparameter
Anfrageparameter für spezifische Formulare
Zuordnungstabelle von MIME-Typen zu Objektklassen
Beilagen mit unbekanntem MIME-Typ annehmen
123
In der Einstellung Anfragespezifische Parameter zulassen wird bestimmt, ob grundsätzlich Parameter in der
Anfrage angenommen und verwendet werden oder nicht. Der Standardwert für eine neu erstellte Konfiguration
ist „nein“. Wird diese Eigenschaft auf den Wert „ja“ gesetzt, so werden die optional in der Anfrage enthaltenen
Parameter bevorzugt verwendet.
Die Eigenschaft Default Anfrageparameter definiert die Standardwerte für die Parametrierung. Diese Werte
werden immer dann verwendet, wenn weder in der Anfrage spezifische Parameter enthalten sind, noch für das
übertragene Formular ein spezielleres Set von Parametern in der Eigenschaft Parameter für Formulare definiert ist.
Mit der Eigenschaft Parameter für Formulare kann für jedes Formular ein spezifisches Set von Anfrageparametern definiert werden und die Verarbeitung der Anfrage somit gezielt auf die individuellen Bedürfnisse jedes einzelnen Formulars angepasst werden. Der Schlüssel zur Identifikation eines Formulars ist dessen eindeutige Formularkennung, die in der XML-Struktur der Anfrage optional enthalten ist. Wird auf die Angabe der eindeutigen
Formularkennung verzichtet, so ist eine Auswertung von formularspezifischen Anfrageparametern nicht möglich.
Über die Eigenschaft Zuordnungstabelle von MIME-Typen zu Objektklassen wird eine eindeutige Zuordnung von Inhalts-Objektklassen zu MIME-Typen definiert, auf deren Basis werden die Objekte für die in der
Anfrage enthaltenen Beilagen erzeugt.
Die Eigenschaft Beilagen mit unbekanntem MIME-Typ annehmen definiert, ob Beilagen, für die in der obigen Zuordnungstabelle kein spezieller Eintrag vorzufinden ist, zurückgewiesen oder trotzdem angenommen werden sollen. Der Standardwert für diese Eigenschaft ist „nein“, d.h. ist eine Beilage mit einem nicht spezifizierten MIME-Typ in der Anfrage enthalten, so wird die gesamte Anfrage zurückgewiesen. Wird für diese Eigenschaft der Wert „ja“ gewählt, so führt dies dazu, dass für Beilagen, die nicht zugeordnet werden können, jeweils
ein Inhaltsobjekt der Objektklasse Inhalt (GENCONT@1.1:Content) instanziert wird.
6.1 Push-Verfahren
Ablauf einer Anfrage
Wie der Abbildung 36 zu entnehmen ist, wird jede eingehende Anfrage in den folgenden Schritten abgearbeitet:
Ermitteln der Anfrageparameter
Erzeugen des Hüllenobjekts
Beilagenobjekte anlegen und dem Hüllenobjekt zuordnen
Workflow initialisieren
Sonstige Initialisierungen durchführen
Für jeden dieser Einzelschritte sind über die bereits ausführlich behandelte Datenübernahmekonfiguration eine
Reihe von Einstellungen möglich, um deren Verhalten steuern.
Abbildung 36
Anfrageablauf
125
In den nachfolgenden Abschnitten wird jeweils auf die Details der Einzelschritte und deren Einstellungsmöglichkeiten in Bezug auf den Gesamtablauf eingegangen.
Ermitteln der Anfrageparameter
Anfrageparameter werden in diesem Kontext als definierte Sammlung von Werten verstanden, die unmittelbar
Einfluss auf den weiteren Verlauf der Anfrage haben.
Anfrageparameter können an drei unterschiedlichen Stellen definiert werden:
Direkt im XML der Anfrage
Als formularspezifische Werte in der Datenübernahmekonfiguration
Als Default-Werte in der Datenübernahmekonfiguration
Die obige Reihenfolge stellt gleichzeitig auch die Priorisierung bei der Ermittlung der Parameter für die
Anfrage dar. Zuerst werden die definierten Parameter im XML der Anfrage verwendet, sofern diese erlaubt
sind. Sind in der Anfrage keine Parameter enthalten, so wird versucht, die Parameter aus der formularspezifischen Konfiguration zu ermitteln. Sollte auch hier keine passende Definition vorhanden sein, so werden
die Default-Werte aus der Konfiguration herangezogen. Wurden auch hier keine ausreichenden Einstellungen vorgenommen, so wird die Anfrage mit dem Fehler „Dieser Dienst ist nicht zur Verwendung konfiguriert“
zurückgewiesen.
Die Anfrageparameter umfassen Werte für die folgenden Einstellungsmöglichkeiten je nach Ort der Definition
entweder in Form von Eigenschaften (in der Konfiguration) oder als XML-Struktur (in der Anfrage). Die folgende
Liste definiert die verfügbaren Parameter:
Zu instanzierende Objektklasse
Eigenschaft zur Ablage von Beilagen
Objekteigentümer
Gruppe des Objekts
6.1 Push-Verfahren
Workflowparameter (optional, nur wenn in der Domäne eine gültige Softwareproduktlizenz für das Softwareprodukt Fabasoft Components Workflow existiert)
Als erster Anfrageparameter wird die zu instanzierende Objektklasse (FSCFRMTR@1.1001:
envelopeclass) für das Hüllenobjekt angegeben. Diese Angabe ist nötig, um eine Anfrage korrekt abarbeiten zu können. Mit dieser Einstellung wird die Objektklasse des Objekts, das als Container für alle Beilagen
dienen soll, definiert. Hierbei ist die einzige Einschränkung, dass die Objektklasse über eine Listeneigenschaft
verfügen muss, in die Beilagenobjekte abgelegt werden können.
Die Eigenschaft zur Ablage von Beilagen stellt den nächsten Anfrageparameter dar. Dabei muss eine Attributsdefinition angegeben werden, welche die Objektzeigerliste ausreichend spezifiziert.
Die beiden Parameter Objekteigentümer und Gruppe des Objekts werden bei allen im Zuge der Anfrage neu
erzeugten Objekten auf die gleichnamigen Attribute der Softwarekomponente COOSYSTEM@1.1 weiterpropagiert.
Die Workflowparameter umfassen eine Liste von Initialisierungsprozessen und die Definition der Prozessverantwortung.
Erzeugen eines Hüllenobjektes
Wurde die Ermittlung der Anfrageparameter erfolgreich durchgeführt, so ist der nächste Schritt im Ablauf
der Anfragebearbeitung das Erstellen eines Objektes, das als Hülle für die Metadaten und die Beilagen dienen soll.
Die dafür zu verwendende Objektklasse wird über den Anfrageparameter Zu instanzierende Objektklasse
definiert. Die einzige Einschränkung bei der Wahl der Objektklasse ist, dass eine Objektlisteneigenschaft zur
Aufnahme der Beilageninhalte darauf definiert sein muss.
Ein neues Objekt dieser Klasse wird erzeugt und dessen Name (COOSYSTEM@1.1:objname) wird auf
den in der Anfrage enthaltenen Formulartitel gesetzt.
127
Der Objekteigentümer (COOSYSTEM@1.1:objowner) und die Gruppe des Objektes (COOSYSTEM@1.1:
objowngroup) werden von den Werten der Anfrageparameter übernommen.
Beilagenobjekte anlegen und dem Hüllenobjekt zuordnen
Als nächster Teilschritt werden die in der Anfrage enthaltenen Beilagen ausgelöst und in Form von neuen Objekten dem zuvor erzeugten Hüllenobjekt zugeordnet.
Die eigentlichen Formulardaten nehmen hier einen besonderen Stellenwert ein. Die rohen XML-Daten werden
immer als Beilage angesehen. Dadurch verfügt jedes durch eine TakeForm-Anfrage erzeugte Container-Objekt
über mindestens eine Beilage – den Antrag selbst.
Abhängig davon, ob die Antragsdaten auf dem Formularsystem digital signiert wurden oder nicht, werden die XMLDaten als Hauptinhalt eines Objektes der Klasse Signiertes XML-Dokument (FSCDIGSIG@1.1001:
SignedXMLDocument) bzw. als Hauptinhalt eines Objektes der Klasse Unsigniertes XML-Dokument
(FSCFRMTR@1.1001:UnsignedXMLDocument) abgelegt.
In beiden Fällen wird das ebenfalls transportierte XSL-Stylesheet dazu verwendet, um beim Öffnen des Dokuments die rohen XML-Daten zu transformieren und in einer für den Benutzer ansprechenden Form zu visualisieren. Beim signierten XML-Dokument wird hier zusätzlich am Ende des Dokuments die digitale Signatur dargestellt (siehe Abbildung 37).
Der Name dieses XML-Dokuments ist – wie schon bei dem Containerobjekt – der Titel des Formulars. Auch für
dieses Objekt werden der Eigentümer und die Gruppe des Objekts mit den in den Anfrageparametern enthaltenen Werten belegt.
Für jede weitere Beilage wird gemäß den Einstellungen der Datenübernahmekonfiguration je ein Objekt instanziert und der Beilageninhalt als Hauptinhalt des neu erzeugten Objektes abgelegt. Der Name dieser Instanzen
ergibt sich aus der Anfrage, in der für jede Beilage auch ein Name enthalten ist. Wie bereits beschrieben, wird
auch für diese Beilagenobjekte der Objekteigentümer und die Gruppe des Objektes mit den in den Anfrageparametern enthaltenen Werten belegt.
6.1 Push-Verfahren
Abbildung 37
Digital signiertes
XML-Dokument
Abschließend werden Objektzeiger aller Beilagen, inklusive dem XML-Dokument, in die Beilagenlisteneigenschaft des Containerobjektes, die in den Anfrageparametern definiert ist, eingefügt.
Workflow initialisieren
In diesem Teilschritt wird versucht, mit den Mitteln von Fabasoft Components Workflow einen Prozess auf das
soeben erstellte Hüllenobjekt zu starten. Zu diesem Zweck kann eine Liste von Prozessdefinitionen
(COOWF@1.1:ProcessDefinition) in den Anfrageparametern definiert werden, welche als Initialisierungsprozesse verwendet werden.
129
Weiters ist es möglich, in den Anfrageparametern die Prozessverantwortung in Form einer zusammengesetzten Eigenschaft vom Typ COOWF@1.1:WorkFlowParticipant zu definieren, die an jeden der instanzierten Prozesse angebracht wird.
Sonstige Initialisierungen durchführen
Sind über diesen Standardablauf hinaus noch weitere Initialisierungen nötig, kann dies durch das Implementieren von Methoden der folgenden Aktionen, die beide auf das Hüllenobjekt aufgerufen werden, geschehen:
FSCFRMTR@1.1001:InitializeEnvelope
FSCFRMTR@1.1001:MapApplicant
Die Aktion FSCFRMTR@1.1001:InitializeEnvelope erhält zu diesem Zweck als Argumente den
Inhalt der gesamten Anfrage und ein Werteverzeichnis mit nötigen, diese Anfrage betreffenden Schlüsselwerten. Der Aktion FSCFRMTR@1.1001:MapApplicant werden als Argumente der Inhalt der XML-Struktur FormApplicant und ebenfalls das Werteverzeichnis mit Anfrageinformationen weitergegeben.
Eine Implementierung der Aktion FSCFRMTR@1.1001:MapApplicant wird produktseitig bereits für
die Objektklasse COOELAK@1.1001:SubFile zur Verfügung gestellt, die basierend auf den Antragstellerdaten einen Adressaten (COOELAK@1.1:Addressee) im Sinne der Fabasoft eGov-Suite beim jeweiligen Geschäftsstück platziert.
XML-Schema
Wie bei Webservices üblich, kann das zugrunde liegende XML-Schema per WSDL-Abfrage erfragt werden. Die
WSDL-Abfrage wird in Fabasoft Components mit folgendem schematischen URL durchgeführt:
http://<servername>/<virtual-directory>/fscdav/wsdl?Actions=<soap-actionidentification>
Quelltext 6: Schematischer WSDL-URL
6.1 Push-Verfahren
Beim konkreten Webservice handelt es sich um die Aktion FSCFRMTR@1.1001:TakeForm. Als Servername wird „localhost“ angenommen, wodurch sich folgender URL ergibt:
http://localhost/fsc/fscdav/wsdl?Actions=FSCFRMTR_1_1001_TakeForm
Quelltext 7: Beispiel für WSDL-URL
Der im obigen Beispiel angeführte URL liefert folgendes Ergebnis:
Abbildung 38
WSDL-Anfrage
131
Basierend auf diesem Dokument können mit Hilfe von Codegeneratoren, wie den in Microsoft Visual Studio .NET
oder Java J2EE enthaltenen, Proxyklassen zur programmatischen Bedienung des Webservices generiert werden.
Die Aktion FSCFRMTR@1.1001:TakeForm implementiert vollständig eine automatisierte Entgegennahme von Formulardaten über SOAP. Das WSDL-Schema wurde bereits über einen Webbrowser abgefragt und das
Ergebnis in Abbildung 38 dargestellt.
Im nachfolgenden Teil wird auf die XML-Datenstruktur, die beim Transport verwendet wird, im Detail eingegangen. Alle beschriebenen XML-Strukturen liegen im XML-Namensraum:
urn:schemas-fabasoft-com:forms-transfer:TakeForm
Quelltext 8: XML-Namensraum
Nur die Datenstrukturen, welche die Antragstellerdaten festhalten, stammen aus dem folgenden Namensraum:
http://reference.e-government.gv.at/namespace/persondata/20020228#
Quelltext 9: XML-Namensraum für Antragstellerdaten
Der Wurzelknoten in der XML-Anfrage lautet TakeFormRequest. Die folgenden XML-Knoten sind als
Hauptknoten direkt unter dem Wurzelknoten eingehängt:
RequestParams
FormDescription
FormApplicant
FormData
FormAttachments
6.1 Push-Verfahren
Als Antwort liefert das Webservice FSCFRMTR@1.1001:TakeForm eine XML-Struktur mit dem Wurzelelement TakeFormResponse. Darunter befindet sich unmittelbar entweder das Element Success
Response mit einer strukturierten Beschreibung der durchgeführten Aktivitäten oder FailureResponse
mit einer detaillierten Fehlerbeschreibung.
RequestParams
Der Abschnitt RequestParams ermöglicht eine Übersteuerung der normalerweise in der aktuellen Datenübernahmekonfiguration getätigten Einstellungen des Verhaltens von außen. Diese Form der Übersteuerung
muss allerdings explizit in der Konfiguration aktiviert werden.
Die folgenden Einstellungen können im Request mitgegeben werden:
zu instanzierende Objektklasse für das Hüllenobjekt
Listeneigenschaft für die Ablage von Beilagen
Besitzer aller neu erzeugten Objekte
Gruppe aller neu erzeugten Objekte
Workflowinitialisierungen wie Startprozesse und Prozessverantwortung
133
...
<tf:RequestParams
xmlns:tf=”urn:schemas-fabasoft-com:forms-transfer:TakeForm”>
<tf:EnvelopeClass>COO.1.1001.1.13133</tf:EnvelopeClass>
<tf:AttachmentsView>COO.1.1001.1.13600</tf:AttachmentsView>
<tf:Owner>COO.1.555.2.912</tf:Owner>
<tf:Group>COO.1.555.1.885</tf:Group>
<tf:WorkFlow>
<tf:ProcessDefinitions>
<tf:ProcessDefinition>...</tf:ProcessDefinition>
</tf:ProcessDefinitions>
<tf:ProcessResponsible>
<tf:User>...</tf:User>
<tf:Position>...</tf:Position>
<tf:Group>...</tf:Group>
<tf:OrgUnitType>...</tf:OrgUnitType>
</tf:ProcessResponsible>
</tf:WorkFlow>
</tf:RequestParams>
...
Quelltext 10: Beispiel für XML-Struktur – RequestParams
FormDescription
Der Abschnitt FormDescription enthält informative Elemente über das übertragene Formular wie den
Formulartitel und eine eindeutige Formularkennung.
...
<tf:Title
Hundeanmeldung
</tf:Title>
<tf:Id>TESTFORMULAR-HUNDEANMELDUNG</TF:Id>
...
Quelltext 11: Beispiel für XML-Struktur – FormDescription
6.1 Push-Verfahren
FormApplicant
In diesem Abschnitt werden die persönlichen Daten des Antragstellers transportiert, da dies ein in jedem Formular wiederkehrender Teil ist und somit allgemein behandelt werden kann. Die Datenstrukturen zur Beschreibung von Personendaten basieren auf der Spezifikation [ReHo02].
...
<tf:FormApplicant
xmlns:tf=”urn:schemas-fabasoft-com:forms-transfer:TakeForm”
xmlns:pd=”http://reference.e-government.gv.at/namespace/persondata/20020228#”>
<pd:CompactPhysicalPerson>
<pd:CompactName>
<pd:GivenName>Max</pd:GivenName>
<pd:FamilyName>Mustermann</pd:FamilyName>
</pd:CompactName>
...
</pd:CompactPhysicalPerson>
<pd:InternetAddress>
<pd:Address>max.mustermann@fabasoft.com</pd:Address>
</pd:InternetAddress>
<pd:CompactPostalAddress>
...
</pd:CompactPostalAddress>
</tf:FormApplicant>
...
Quelltext 12: Beispiel für XML-Struktur – FormApplicant
FormData
Der Abschnitt FormData enthält die im Formular ausgefüllten Daten des Antragstellers.
Dieser Teil variiert von Formular zu Formular und ist deshalb nur auf oberster Ebene im Detail spezifiziert. Auf
oberster Ebene wird zwischen signierten und unsignierten Daten unterschieden. Somit wird dem System die
Möglichkeit gegeben, dies bereits an dieser Stelle unterscheiden zu können.
135
In jedem Fall wird ein XSL-Stylesheet mitgegeben, um die XML-Daten auch im Backoffice-System aufbereiten
zu können.
...
<tf:SignedData
<sl11:CreateXMLSignatureResponse
xmlns:sl11=”http://www.buergerkarte.at/namespaces/securitylayer/20020831#”>
<dsig:Signature Id=”signature-13122004180602872”
xmlns:dsig=”http://www.w3.org/2000/09/xmldsig#”>
...
...
</dsig:Signature>
</sl11:CreateXMLSignatureResponse>
</tf:SignedData>
...
Quelltext 13: Beispiel für XML-Struktur – FormData
6.1 Push-Verfahren
FormAttachments
Im Abschnitt FormAttachments befindet sich eine Liste von Beilagenknoten mit den jeweils zugehörigen
notwendigen Metadaten wie MIME-Typ und ursprünglicher Dateiname.
...
<tf:FormAttachments
<tf:FormAttachment>
<tf:Title>Signaturzertifikat</tf:Title>
<tf:Extension>cer</tf:Extension>
<tf:MIMEType>application/x-x509-ca-cert</tf:MIMEType>
<tf:Content>
MIIFNzCCBB+gAwIBAgICc/kwDQYJKoZIhvcNAQEFBQAwgaExCzAJBgNVBAYTAkFUMUgwRgYDVQ
QKEz9BLVRydXN0IEdlcy4gZi4gU2ljaGVyaGVpdHNzeXN0ZW1lIGltIGVsZWt0ci4gRGF0ZW52
ZXJrZWhyIEdtYkgxIzAhBgNVBAsTGmEtc2lnbi1URVNULVByZW1pdW0tU2lnLTAxMSMwIQYDVQ
QDExphLXNpZ24tVEVTVC1QcmVtaXVtLVNpZy0wMTAeFw0wNDA0MjYxMzM4MDlaFw0wNzA0MjYx
MzM4MDla
...
</tf:Content>
</tf:FormAttachment>
<tf:FormAttachment>
<tf:Title>Geburtsurkunde</tf:Title>
<tf:Extension>pdf</tf:Extension>
<tf:MIMEType>application/pdf</tf:MIMEType>
<tf:Content>
...
</tf:Content>
</tf:FormAttachment>
...
</tf:FormAttachments>
...
Quelltext 14: Beispiel für XML-Struktur – FormAttachments
137
Zusammenfassung
Abbildung 39
Push-Verfahren
6.1 Push-Verfahren
6.2 Pull-Verfahren
6.2
Pull-Verfahren
Im Gegensatz zum soeben beschriebenen Push-Verfahren soll in diesem Kapitel der Einsatz des Pull-Verfahrens
zwischen der Fabasoft eGov-Suite und dem Fabasoft eGov-Forms Formularserver dargestellt werden.
Hierzu wird die eGov-Suite zyklisch aktiv und holt vom Formularserver die verfügbaren, vollständig eingebrachten Anträge über eine lose gekoppelte SOAP-Schnittstelle ab.
Im Gegensatz zum Push-Verfahren sind in diesem Fall aufgrund der Asynchronität des Pull-Verfahrens für jeden
abzuholenden Antrag mindestens zwei SOAP-Verbindungsaufnahmen nötig. Darüber hinaus wird eine weitere
Verbindung pro Service aufgebaut, um alle neu verfügbaren Anträge aufzulisten.
Eine vereinfachte Darstellung der Kommunikation ist in Abbildung 40 zu sehen.
Abbildung 40
Ablauf Pull-Verfahren
139
Auslösen des Transports in der Fabasoft eGov-Suite
Das Abholen von fertig gestellten Anträgen vom Formularserver erfolgt durch die Aktion
FSCGOVFORMS@1.1001:FetchCompletedSolicitations. In der Regel wird diese durch
einen Automated Task, der bei Bedarf einzurichten ist, in regelmäßigen Abständen ausgelöst. Als optionales
Argument wird eine Liste mit Servicedefinitionen übergeben und ein ebenfalls optionales Objekt der Klasse
Protokoll (FSCLOG@1.1001:Log).
Erhält die Aktion keine Liste mit Servicedefinitionen, so wird in der aktuell eingestellten Step-Engine-Konfiguration versucht, eine entsprechende Liste zu finden. Es wird ein neues Protokoll-Objekt erzeugt, falls keines übergeben wurde.
Das Protokoll-Objekt zeichnet alle durchgeführten Aktivitäten auf, um die Nachvollziehbarkeit zu gewährleisten.
Die Einträge erfolgen in Form von XML-Daten, wodurch eine automatisierte Auswertung möglich ist. Bei der Darstellung des Protokoll-Objektes wird allerdings eine implizite XSL-Transformation durchgeführt, um die Daten für
den Bearbeiter lesbar aufzubereiten.
Ablauf des Transports
Die Aktion FSCGOVFORMS@1.1001:FetchCompletedSolicitations iteriert über alle verfügbaren Servicedefinitionen und führt bei jedem einzelnen Service die SOAP-Anfrage QueryCompleted durch.
Die Anfrage enthält eine Liste von Objektklassen, für die am Formularserver eine Suche abgesetzt werden soll.
Diese Liste stammt aus der Service-Definition. Dort kann für jedes Service eine Liste von Objektklassen, entweder per Objektzeiger oder über deren Objektadresse, hinterlegt werden. Somit ist sichergestellt, dass nur Anträge angefragt werden, die auch verarbeitet werden können.
Die Antwort auf diese Anfrage enthält eine Liste der neuen Anträge – gruppiert nach den angeforderten Objektklassen – die bereits den Status „vollständig eingebracht“ aufweisen.
Nun wird für jeden Eintrag der Ergebnisliste eine separate Anfrage beim zugehörigen Service durchgeführt, um
die tatsächlichen Daten abzuholen. Zu diesem Zweck wird in der Servicedefinition neben jeder Objektklasse eine
6.2 Pull-Verfahren
Abbildung von XML-Elementen auf Eigenschaften (COOXML@1.1:XMLElementMapping) angeführt, die in dieser nachfolgenden Anfrage mitgegeben wird.
Die Abbildung ist jene, mit der am Formularserver die XML-Serialisierung mit Hilfe der Aktion
COOXML@1.1001:DumpToXML des Antragsobjektes durchgeführt wird, nachdem auf das betroffene
Objekt eine Sperre angebracht wurde. Dieses XML-Dokument wird in einen generischen Transport-Umschlag
verpackt und stellt somit die Antwort auf die Anfrage dar.
Es werden nun die Rohdaten wieder aus dem Transport-Umschlag ausgepackt und an die ebenfalls in der Servicedefinition anzuführenden Datenübernahme-Aktion in Form einer SOAP-Aktion als Anfrage weitergegeben.
Die Fabasoft eGov-Suite stellt im Rahmen der Softwarekomponente FSCGOVXML@1.1001 eine sehr flexible Implementierung einer solchen Aktion (FSCGOVXML@1.1001:SOAPCreateSolicitationEx)
zur Verfügung.
Abschließend wird ein weiterer SOAP-Aufruf zum Formularserver durchgeführt, in dem das Ergebnis aller durchgeführten Aktivitäten übermittelt wird. Ist das Ergebnis positiv, so wird der Status des Antrages auf „Vollständig eingebracht und zur Bearbeitung weitergeleitet“ umgesetzt.
Die im ersten Aufruf angebrachte Sperre auf den Antrag wird wieder entfernt und somit ist die Kommunikation
diesen Antrag betreffend abgeschlossen und es wird beim nächsten Antrag dieser Liste fortgefahren.
Sind alle Einträge der Antwort einer Anfrage abgearbeitet, so wird bei der nächsten Servicedefinition fortgesetzt.
Zwischenzeitlich wird im Protokoll jeder der durchgeführten Schritte aufgezeichnet und mit dem zugehörigen
Ergebnis versehen.
141
Abbildung 41
Ablauf des Pull-Jobs
Ablauf der Datenübernahme in der eGov-Suite
Die zuvor beschriebene Übernahme-Aktion kann nach Belieben implementiert werden. Allerdings stellt die Fabasoft eGov-Suite hierfür bereits die nötige Funktionalität Out of the Box zur Verfügung.
Die SOAP-Aktion FSCGOVXML@1.1001:CreateSolicitationEx wurde über die Methodendefinition
FSCGOVXML@1.1001:CreateSolicitationExMethod auf der Objektklasse COOSYSTEM@1.1:
Object implementiert.
6.2 Pull-Verfahren
Da diese SOAP-Aktion vielfach als Schlüssel für weitere Konfigurationseinstellungen herangezogen wird, ist es
empfehlenswert, für verschiedene Arten von Anträgen je eine solche SOAP-Aktion im Rahmen einer lokalen
Software-Komponente zur Verfügung zu stellen und die Konfigurationen für jede Antragsart einzeln vorzunehmen, um Seiteneffekte durch Konfigurations-Überschneidungen zu vermeiden.
Die eigentliche Datenübernahme, welche durch diese Aktion gesteuert wird, verläuft in drei Schritten:
Erzeugen des Antrags aus den übergebenen XML-Daten
In diesem Schritt wird aus den XML-Daten das Antragsobjekt rekonstruiert. Das Produkt stellt hierzu zwei
Aktionen zur Verfügung, mit denen das Antragsobjekt entweder als XML-Dokument oder als spezielle
Objektklasse erzeugt wird. Das XML-Dokument kann zur Anzeige mit Hilfe eines XSL-Stylesheets in ein
benutzerfreundliches Zielformat – in der Regel HTML – transformiert werden.
Erzeugen eines Geschäftsstücks
Damit der Antrag in der Fabasoft eGov-Suite bearbeitet werden kann, wird ein Geschäftsstücksobjekt erzeugt,
dem dieser Antrag zugeordnet wird. Die Art des Geschäftsstücks (in der Regel ein Eingangsstück) kann konfiguriert werden. Zusätzlich wird das Geschäftsstück mit Metadaten aus dem XML-Antrag initialisiert.
Initialisierung des Workflows
Abhängig von der Objektklasse wird eine Aktivitätsdefinition auf das erstellte Geschäftsstück initialisiert.
Dadurch wird das Geschäftsstück seinem Eigentümer vorgeschrieben und erscheint in dessen Arbeitsvorrat.
Jeder dieser Schritte wird von einer eigenen Aktion ausgeführt, die über fix vorgegebene Parameter verfügt.
Sämtliche Einstellungsmöglichkeiten der nachfolgenden Abschnitte können in der aktuell verwendeten eGovKonfiguration auf der Registerkarte Schemata/Berichte getätigt werden.
Erzeugen des Antragsobjekts
Zum Erzeugen eines Antragsobjekts wird jene Aktion verwendet, welche unter dem Auslöser
FSCGOVXML@1.1001:SOAPCreateSolicitationEx und dem Kontext FSCGOVXML@1.1001:
SolCreateSolicitationCtx in der Eigenschaft Konfiguration für SOAP-Schritte der eGov-Konfiguration hinterlegt ist.
143
Das Produkt stellt zwei Standard-Aktionen für diesen Schritt zur Verfügung:
Die Aktion FSCGOVXML@1.1001:CreateSolicitationAsXML erzeugt ein XML-Dokument aus den Antragsdaten und weist diesem eine XSL-Transformation für eine benutzerfreundliche Darstellung zu.
Die Aktion FSCGOVXML@1.1001:CreateSolicitationFromDatapump instanziert eine beliebige, konfigurierbare Objektklasse und befüllt die Eigenschaften mit Daten aus dem XML-Antrag (Einbringer, Fremdzahl, etc.).
Zusätzlich werden der Objekteigentümer und die Access Control List (ACL) des Antrags anhand der Einstellungen in der Eigenschaft Objekteigentümer und ACL gesetzt.
Erzeugen des Geschäftsstücks
Zum Erzeugen des Geschäftsstücks, das den Antrag enthält, wird jene Aktion verwendet, welche unter dem Auslöser FSCGOVXML@1.1001:SOAPCreateSolicitationEx und dem Kontext FSCGOVXML@1.1001:
SolCreateSubFileCtx der eGov-Konfiguration hinterlegt ist.
Das Produkt stellt eine Standard-Aktion für diesen Schritt zur Verfügung.
Die Aktion FSCGOVXML@1.1001:CreateSubFileFromDatapump erzeugt ein Geschäftsstück
gemäß den Einstellungen in den Datenstromdefinitionen und befüllt die Metadaten des Geschäftsstücks mittels einer konfigurierbaren XML-Abbildung mit Daten aus dem XML-Antrag (Einbringer, Fremdzahl, etc.).
Zusätzlich werden der Objekteigentümer und die ACL des Geschäftsstücks anhand der Einstellungen in der
Eigenschaft Objekteigentümer und ACL gesetzt.
Initialisierung des Workflows
Um das Geschäftsstück mit einer Aktivitätsdefinition zu initialisieren, damit es im Arbeitsvorrat eines Benutzers aufscheint, wird jene Aktion verwendet, welche unter dem Auslöser FSCGOVXML@1.1001:
SOAPCreateSolicitationEx und dem Kontext FSCGOVXML@1.1001:SolInitializeWorkflowCtx
hinterlegt ist.
6.2 Pull-Verfahren
Das Produkt stellt zwei Standard-Aktionen für diesen Schritt zur Verfügung:
Die Aktion FSCGOVXML@1.1001:InitializeSolicitationWorkflow ermittelt aus der
eGov-Konfiguration die in der Eigenschaft Einzufügende Aktivitätsdefinitionen hinterlegte Aktivitätsdefinition, die für die Objektklasse des Antrags und die Gültigkeit Startaktivität für XML-Antrag hinterlegt
ist. Das Geschäftsstück wird mit dieser Aktivitätsdefinition dem Eigentümer des Geschäftsstücks vorgeschrieben und scheint somit in dessen Arbeitsvorrat auf.
Die Aktion FSCGOVXML@1.1001:InitializeWorkflowViaXML ermittelt aus der Eigenschaft Workflow-Einstellungen für SOAP-Aktionen die einzufügende Aktivitäts- bzw. Prozessdefinition
und den Workflow-Teilnehmer. Das Geschäftsstück wird dem Workflow-Teilnehmer mit der angegebenen
Aktivitätsdefinition vorgeschrieben. Zum Ermitteln dieser Daten können XPath-Ausdrücke angegeben werden, die auf das XML-Dokument angewandt werden.
Konfigurationen für das Erzeugen eines Antrags
Für das Erzeugen von Antragsobjekten in der Fabasoft eGov-Suite aus dem XML-Antrag werden vom Produkt die
beiden Aktionen FSCGOVXML@1.1001:CreateSolicitationAsXML und FSCGOVXML@1.1001:
CreateSolicitationFromDatapump bereitgestellt.
Für beide Aktionen müssen weitere Konfigurationseinstellungen getroffen werden, damit aus den verschiedenen XML-Anträgen die gewünschten Antragsobjekte erzeugt werden können.
FSCGOVXML@1.1001:CreateSolicitationAsXML
Diese Aktion erzeugt aus dem XML-Antrag ein XML-Dokument (FSCGOVXML@1.1001:XMLDocument),
welches das gesamte XML-Dokument des XML-Antrags enthält. Zusätzlich wird bei dem XML-Dokument eine
XSL-Transformation hinterlegt, welche die XML-Daten beim Öffnen des XML-Dokuments in eine für Benutzer
lesbare Form bringt (z.B. in ein HTML-Dokument).
Die für den XML-Antrag geeignete XSL-Transformation muss in der eGov-Konfiguration in der Eigenschaft
Datenstromdefinitionen hinterlegt sein.
145
Es wird versucht, den Objektnamen des XML-Dokument-Objekts aus dem XML-Antrag zu ermitteln. Dazu wird
auf der gleichen Seite in der eGov-Konfiguration in der Eigenschaft XPath-Ausdrücke für Operationen jene
Zeile ermittelt, die als Auslöser die Steueraktion (FSCGOVXML@1.1001:SOAPCreateSolicitationEx)
und den Verwendungsstring Solicitation-Name eingetragen hat.
Der Wert des XML-Elements, welches in dem XPath-Ausdruck angegeben ist, wird für den Namen des XMLDokuments verwendet.
FSCGOVXML@1.1001:CreateSolicitationFromDatapump
Diese Aktion ermittelt in der eGov-Konfiguration auf der Seite Schemata/Berichte aus der Aggregatsliste
Datenstromdefinitionen die Objektklasse, welche den XML-Antrag repräsentieren soll. Mit der ebenfalls dort
hinterlegten XML-Abbildung werden die Eigenschaften dieses Objekts mit den Daten des XML-Antrags initialisiert.
Als Auslöser wird die Aktion herangezogen. Durch Angabe von XPath-Ausdrücken können unterschiedliche XMLAnträge anhand ihrer XML-Datenstruktur eindeutig unterschieden werden. Die zu erzeugende Objektklasse wird
in der Eigenschaft Objektklasse hinterlegt. Die XML-Abbildung, mit der die Daten des XML-Antrags auf das
erzeugte Objekt abgebildet werden, ist in der Eigenschaft Element-Abbildung einzutragen.
Da abhängig davon, ob der XML-Antrag signiert oder unsigniert übermittelt wurde, der Startknoten für die XMLAbbildung unterschiedlich sein kann, muss dieser in der Aggregatsliste XPath Ausdrücke für Operationen definiert werden.
Dazu werden zwei Einträge in der Aggregatsliste benötigt. Der Auslöser ist in beiden Fällen die Steueraktion
(FSCGOVXML@1.1001:SOAPCreateSolicitationEx). Für die Verwendung ist einmal der
String Signed-XML-Data-Node und einmal der String Unsigned-XML-Data-Node einzutragen. Die XPath-Ausdrücke geben jeweils den Knoten des XML-Antragdokuments an, der als Wurzelknoten zum Anwenden der XMLAbbildung darstellt.
6.2 Pull-Verfahren
Konfigurationen für das Erzeugen des Geschäftsstücks
Die Aktion FSCGOVXML@1.1001:CreateSubFileFromDatapump erzeugt aus dem XML-Antrag
ein Geschäftsstück, dem das Antragsobjekt zugeordnet wird. Dazu wird anhand von XPath-Audrücken aus der
Aggregatsliste Datenstromdefinitionen die dem XML-Antrag zugeordnete Objektklasse des Geschäftsstücks
und eine XML-Abbildung zum Befüllen von Metadaten des Geschäftsstücks ermittelt. Als Auslöser ist hierzu die
Aktion FSCGOVXML@1.1001:CreateSubFileFromDatapump eingetragen. Die XPath-Ausdrücke
sind so zu formulieren, dass unterschiedliche XML-Anträge identifiziert werden können. In der Eigenschaft
Objektklasse ist die Objektklasse für das Geschäftsstück einzutragen. Die Element-Abbildung enthält schließlich jene XML-Abbildung, welche die Metadaten des Geschäftsstücks mit den Daten des XML-Antrags befüllt.
Konfiguration für das Initialisieren des Workflows
Um einen Start-Workflow auf das Geschäftsstück zu initialisieren, werden vom Produkt die beiden Aktionen
FSCGOVXML@1.1001:InitializeSolicitationWorkflow und FSCGOVXML@1.1001:
InitialiazeWorkflowViaXML zur Verfügung gestellt. Für beide Aktionen müssen Konfigurationseinstellungen getroffen werden, damit die Geschäftsstücke passend vorgeschrieben werden können.
FSCGOVXML@1.1001:InitializeSolicitationWorkflow
Die Aktion FSCGOVXML@1.1001:InitializeSolicitationWorkflow ermittelt eine Aktivitätsdefinition aus der eGov-Konfiguration und schreibt das Geschäftsstück mit dieser Aktivitätsdefinition dem
Eigentümer des Geschäftsstücks vor.
Die Konfiguration der einzufügenden Aktivitätsdefinition wird in der eGov-Konfiguration auf der Seite Workflow
in der Aggregatsliste Einzufügende Aktivitätsdefinitionen vorgenommen.
FSCGOVXML@1.1001:InitializeWorkflowViaXML
Die Aktion FSCGOVXML@1.1001:InitializeWorkflowViaXML ermittelt aus den Einstellungen
in der Aggregatsliste Workflow-Einstellungen für SOAP-Aktionen der eGov-Konfiguration einen Workflow-
147
Teilnehmer und eine Aktivitätsdefinition bzw. Prozessdefinition. Um hierbei möglichst flexibel zu sein, kann dazu
eine Liste von XPath-Ausdrücken angegeben werden. Nur wenn alle XPath-Ausdrücke zu nichtleeren Knotenmengen führen, wird der Konfigurationseintrag herangezogen.
Konfiguration der Objekteigentümer-Einstellungen
Die Aktionen FSCGOVXML@1.1001:CreateSolicitationAsXML, FSCGOVXML@1.1001:
CreateSolicitationFromDatapump und FSCGOVXML@1.1001:CreateSubFileFromDatapump
setzen bei den erzeugten Objekten die Eigenschaften Eigentümer und ACL. Dazu wird die Aktion
FSCGOVXML@1.1001:ApplyObjectOwnerSettings verwendet. Der Aufruf der Aktion ist nicht
vom Benutzer steuerbar. Wichtig in diesem Zusammenhang ist allerdings die Konfiguration der Einstellungen,
welche zum Bestimmen des Objekteigentümers und der ACL herangezogen werden. Dazu wird die Aggregatsliste Objekteigentümer und ACL auf der Seite Schemata/Berichte der eGov-Konfiguration herangezogen.
In den Eigenschaften Objektklasse und Aktion sind die Objektklasse des betroffenen Objekts und die betroffene Aktion einzutragen. Weiters lassen sich optional XPath-Ausdrücke angeben, die eine zusätzliche Filterung
anhand der XML-Struktur des übermittelten XML-Antrags zulassen. Unter den Eigenschaften Eigentümer
(Benutzer) und Eigentümer (Gruppe) können Zuordnungsschlüssel für einen Benutzer oder eine Gruppe hinterlegt werden. Diese Zuordnungsschlüssel identifizieren auf eindeutige Art und Weise einen Benutzer oder eine
Gruppe. Die Eigenschaft ACL enthält die ACL, die dem jeweiligen Objekt nach dem Erzeugen zugeordnet werden soll.
6.2 Pull-Verfahren
Zusammenfassung
Abbildung 42
Pull-Verfahren
149
7
schnittstelle für
7 automatisierte antragstellung
Die Formularserverlösung Fabasoft eGov-Forms stellt eine Schnittstelle zur Verfügung, um einerseits eventuell vorhandene Formularlösungen möglichst rasch integrieren zu können, aber auch
um die Möglichkeit zu bieten, bereits bestehende Business-Lösungen auf einfache Art und Weise anzubinden. Diese Schnittstelle zur automatisierten Antragstellung wird in den folgenden
Abschnitten behandelt.
Wie schon die Schnittstelle zum Back-Office ist auch die Schnittstelle für die automatisierte Antragstellung
SOAP-basiert. Dies bedeutet, sämtliche Möglichkeiten Antragsdaten von außen an Fabasoft eGov-Forms zu
übergeben werden über Fabasoft SOAP-Aktionen abgebildet.
Eine dieser Möglichkeiten wird über die Aktion Antrag mit XML-Inhalt erzeugen (FSCFORMS@1.1001:
CreateXMLSolicitation) zur Verfügung gestellt. Diese Aktion erzeugt einen Antrag einer in der SOAPAnfrage definierbaren Objektklasse, setzt dessen Hauptinhalt und legt die optional in der Anfrage enthaltenen
Beilagen bei diesem neu erstellten Antragsobjekt ab.
Der Vorteil dieser Variante ist, dass die weitere Behandlung des Antrags mit den Standardmitteln von Fabasoft
eGov-Forms erfolgen kann. So ist beispielsweise die Weiterleitung ins Backoffice, die Vernichtung der Antragsdaten, die erneute Verbindungsaufnahme des Antragstellers zu den Formulardaten (über die Liste der Schritte
für vollständige Anträge), etc. möglich.
Ein weiterer Vorteil ist durch den Umstand gegeben, dass ein und dieselbe Schnittstelle für beliebige Anträge
verwendet werden kann. Somit kann mittels einer Schnittstelle über Fabasoft eGov-Forms eine Reihe von Anträgen, Online-Formularen, etc. nach dem Store-And-Forward-Prinzip realisiert werden, anstatt eine Reihe von
unterschiedlichen Schnittstellen für jedes Formular bzw. jeden einzelnen Antrag zu implementieren.
151
Die Rolle von Fabasoft eGov-Forms als Store-And-Forward-Provider wird in der nachfolgenden Abbildung 43
veranschaulicht.
Abbildung 43
Technischer Ablauf
XML-Antrag
7. Schnittstelle für
automatisierte Antragstellung
7.1 XML-Schema
7.1
XML-Schema
In diesem Abschnitt soll das Schema der Aktion FSCFORMS@1.1001:CreateXMLSolicitation
genauer betrachtet werden.
Der XML-Namensraum der Anfrage sowie der Antwort ist urn:schemas-fabasoft-com:
forms:CreateXMLSolicitation. Das Wurzelelement der Anfrage lautet request, das Wurzelelement der Antwort response.
Dem Anfrage-Wurzelknoten sind die folgenden Knoten in erster Ebene untergeordnet:
createclass
xmldata
attachments
Im Knoten createclass wird die Objektklasse des zu erzeugenden Antragsobjekts über dessen Objektadresse definiert. Der Knoten xmldata enthält eine beliebige XML-Struktur, die die eigentlichen Antragsdaten repräsentieren.
Der Knoten attachments enthält eine beliebige Anzahl von attachment-Subknoten, von denen jeder
einzelne eine Beilage zum übertragenen Antrag darstellt.
Ein attachment-Knoten besteht aus folgenden Subknoten:
data
fileext
doctitle
mimetype
Der Knoten data enthält die eigentlichen Daten der Beilage in Base-64-codierter Form. Die Metadaten der beigelegten Datei sind in den Knoten fileext (Dateierweiterung), doctitle (Textuelle Bezeichnung der Beilage) und mimetype (MIME-Typ der Dateidaten) enthalten.
153
Nachfolgend wird ein Auszug eines Beispiel-Anfrage-Dokuments dargestellt.
...
<cs:request
xmlns:cs=”urn:schemas-fabasoft-com:forms:CreateXMLSolicitation”>
<cs:createclass></cs:createclass>
<cs:xmldata>
<ha:hundeanmeldung xmlns:ha=”urn:www.hundeanmeldung.com/hundeanmeldung0815.htm”>
...
</ha:hundeanmeldung>
</cs:xmldata>
<cs:attachments>
<cs:attachment>
<cs:data>
MIIFNzCCBB+gAwIBAgICc/kwDQYJKoZIhvcNAQEFBQAwgaExCzAJBgNVBAYTAkFUMUgwRgYDVQ
QKEz9BLVRydXN0IEdlcy4gZi4gU2ljaGVyaGVpdHNzeXN0ZW1lIGltIGVsZWt0ci4gRGF0ZW52
ZXJrZWhyIEdtYkgxIzAhBgNVBAsTGmEtc2lnbi1URVNULVByZW1pdW0tU2lnLTAxMSMwIQYDVQ
QDExphLXNpZ24tVEVTVC1QcmVtaXVtLVNpZy0wMTAeFw0wNDA0MjYxMzM4MDlaFw0wNzA0MjYx
MzM4MDla
...
</cs:data>
<cs:fileext>pdf</cs:fileext>
<cs:toctitle>Kaufvertrag</cs:doctitle>
<cs:mimetype>application/pdf</cs:mimetype>
</cs:attachment>
</cs:attachments>
</cs:request>
...
Quelltext 15: Beispiel für XML-Struktur
7.2
Ablauf
Der Ablauf der Anfragebearbeitung stellt sich wie folgt dar. Zuerst wird ein Objekt der im Knoten
createclass übergebenen Objektklasse instanziert.
7. Schnittstelle für
automatisierte Antragstellung
7.1 XML-Schema
7.2 Ablauf
Anschließend werden die eigentlichen Antragsdaten (das Subdokument unterhalb des Knotens xmldata) in
eine Datei separiert und als Hauptinhalt des Antrags abgelegt.
Es werden eine Reihe von Antragsbeilagen (FSCFORMS@1.1001:FormAttachment) erstellt, mit
dem jeweiligen Inhalt belegt und deren Objektzeiger in der Eigenschaft Externe Beilagen
(FSCFORMS@1.1001:externalattachments) abgelegt.
Zusammenfassung
Abbildung 44
automatisierte
Antragstellung
155
8
schnittstellen zu weiteren
8 fabasoft produkten
Mit dem Produkt Fabasoft eGov-Forms stellt die Fabasoft Produktpalette eine Reihe von Werkzeugen zur Erstellung und Publikation von Online-Formularen zur Verfügung. In diesem Kapitel sollten
darüber hinaus noch zwei Aspekte im Hinblick auf die Benutzerführung (Fabasoft eGov-Suite/WBT)
und die Publikation auf einer Website (Fabasoft CMS) beleuchtet werden.
8.1
Fabasoft eGov-Suite/WBT
Fabasoft eGov-Suite/WBT (Web Based Training) ist Teil der Fabasoft Produktfamilie und dient der Umsetzung
einer interaktiven Online-Hilfe für Online-Formulare und Internet-Dienste. Vergleichbare Überlegungen hierzu
sind auch beim Styleguide für Online-Formulare in Österreich angedacht.
E-Government Online-Dienste sind möglicherweise komplex und können unter anderem schwer verständlich
sein. Mit der interaktiven Online-Hilfe von Fabasoft erhalten Bürger und Unternehmen bei Bedarf die nötige
Unterstützung für das korrekte und vollständige Einreichen von Online-Anträgen. Dies beugt fehlerhaften Anträgen und Missverständnissen während des Verwaltungsverfahrens vor und führt somit zu einer schnelleren
Abwicklung der Anträge.
Die interaktive Online-Hilfe zeigt das gleiche Formular als Muster und unterscheidet sich in keinster Weise vom
originalen Online-Formular und bietet daher ein identisches „Look-and-feel“. Die Benutzeroberfläche ist rein
HTML-basiert und benötigt aus diesem Grund keine starren Screenshots.
Für die interaktive Ausfüllhilfe müssen zusätzlich zur Eingabe der Hilfetexte auch die Positionierung des Agenten, die Vertonung, etc. definiert werden. Aus diesem Grund bietet Fabasoft im Rahmen des Dienstleistungsangebotes die Umsetzung von interaktiven Ausfüllhilfen mit Fabasoft eGov-Suite/WBT an.
Das Web Based Training von Fabasoft wurde durch die hohe Qualität, Anwenderfreundlichkeit und Realitätsnähe mit dem World Summit Award 2003 [WSAw03] zu einem der fünf weltweit besten E-Learning Lösungen ausgezeichnet.
157
Abbildung 45
Vorteile von Fabasoft
eGov-Suite/WBT
Abbildung 46
Beispiel-WBT –
Hundeanmeldung
8. Schnittstellen zu weiteren
Fabasoft Produkten
8.1 Fabasoft eGov-Suite/WBT
8.2 Fabasoft CMS
Beispiel – WBT – Hundeanmeldung
Im Zuge der Entwicklung eines Online-Formulars hat der Formularentwickler die Möglichkeit, eine interaktive Online-Hilfe für einzelne Formularblockelemente und/oder Formularblöcke anzufertigen und diese im
Formular zur Verfügung zu stellen. Abbildung 46 zeigt einen möglichen Einsatz des Fabasoft eGovSuite/WBT. In der Mitte der Abbildung ist deutlich der Agent „Fabi“ mit der Sprechblase zu erkennen.
Schlussendlich erleichtert Fabasoft eGov-Suite/WBT das Befüllen und Einreichen von Online-Formularen und
dient somit auch der Reduktion der „Digitalen Kluft“.
8.2
Fabasoft CMS
Das Fabasoft CMS ist eine komplette, ganzheitliche Content-Management-Lösung, die speziell auf Anforderungen von Behörden und öffentlichen Verwaltungen zugeschnitten ist. Als Teil der Fabasoft Produktfamilie versteht
sich das Fabasoft CMS als prozess- und systemtechnisch integriertes Dokumenten- und Content-ManagementSystem, das die beiden Bereiche Dokumentenmanagement und Content-Management in einer homogenen
Lösung verschmelzen lässt. Detaillierte Informationen über das Fabasoft CMS liefert das Buch „Das Fabasoft
Content-Management-System“ [Hofm04].
Um auch Online-Formulare über das Content-Management publizieren zu können, wurde auf Seiten des Produktes Fabasoft eGov-Forms eine SOAP-Aktion implementiert, die auf Anfrage alle aktuell installierten und zur Verfügung stehenden Online-Formulare liefert. Die anfragende Applikation – in diesem Fall das Fabasoft CMS –
kann mit den erhaltenen Daten einen URL zum Aufruf eines Online-Formulars erzeugen und in die publizierte
Web-Site einbinden. Diese lose Kopplung der beiden Produkte, Fabasoft eGov-Forms und Fabasoft CMS, ermöglicht maximale Flexibilität beim Einsatz in der Praxis.
159
SOAP-Aktion auf Seiten von Fabasoft eGov-Forms
Wie bei Webservices üblich, kann das zugrunde liegende XML-Schema per WSDL-Abfrage angerufen werden.
Die WSDL-Abfrage wird in Fabasoft eGov-Forms mit folgendem schematischen URL durchgeführt:
http://<servername>/<virtual-directory>/fscdav/wsdl?Actions=<soap-actionidentification>
Quelltext 16: Schematischer WSDL-URL
Beim konkreten Webservice handelt es sich um die Aktion FSCFORMS@1.1001:QueryInstalled
FormsInfo wodurch sich – als Servername wird „localhost“ angenommen – folgender URL ergibt:
http://localhost/fsc/fscdav/wsdl?Actions=FSCFORMS_1_1001_QueryInstalledFormsInfo
Der Aufruf dieses URL ist in Abbildung 47 zu sehen.
Quelltext 17: Beispiel für WSDL-URL
Die Aktion FSCFORMS@1.1001:QueryInstalledFormsInfo liefert auf Anfrage mit dem Wurzelelement
request eine XML-Struktur, die dem Wurzelelement response entspricht. Im nachfolgenden Teil wird auf die
XML-Datenstruktur, die beim Response verwendet wird, im Detail eingegangen. Alle beschriebenen XML-Strukturen
liegen im XML-Namensraum urn:schemas-fabasoft-com:forms:QueryInstalledFormsInfo.
Der Wurzelknoten des Response lautet response. Die folgenden XML-Knoten sind direkt unter dem Wurzelknoten eingehängt:
appstartnew
In diesem XML-Knoten wird die eindeutige Adresse (COO-Adresse) der Anwendung zum Start des OnlineFormulars angegeben
Fabasoft Produkten
8.2 Fabasoft CMS
Abbildung 47
WSDL-Anfrage im
Web-Browser
baseurl
In diesem XML-Knoten wird ein URL in der Form http://<server>/<virtual-directory>
angegeben. Unter diesem URL ist der Formularserver erreichbar.
installedforms
In diesem XML-Knoten werden alle installierten Online-Formulare aufgelistet. Zu jedem
Online-Formular werden die eindeutige Adresse (COO-Adresse) der Objektklasse form/address und
die Adressen der verfügbaren Dispatcher form/applicationdispatcher/basic und
form/applicationdispatcher/wai angegeben.
161
Einbindung auf Seiten von Fabasoft CMS
Der Ressourcenassistent von Fabasoft CMS kann die beschriebene Aktion FSCFORMS@1.1001:
QueryInstalledFormsInfo zur Abfrage der aktuell verfügbaren Online-Formulare am konfigurierten
Fabasoft eGov-Forms-Server verwenden. Aus den erhaltenen Daten kann das Fabasoft CMS URLs definieren, die
der Autor bei der Erstellung einer Website zur Verfügung hat. Die standardmäßige Einbindung von Online-Formularen in Webinhalte der Behörde setzt somit keine detaillierten Kenntnisse der URL-Parameter eines Formularaufrufs voraus.
Zusammenfassung
Abbildung 48
Schnittstellen
Fabasoft Produkten
8.2 Fabasoft CMS
163
9
module für
9 online-applikation
Für sichere Online-Verfahren in Österreich werden von der Stabsstelle IKT-Strategie des Bundes
Basisdienste im Bereich der Authentifizierung und der elektronischen Signatur zur Verfügung
gestellt [Stab05]. Hierzu gehören die in Fabasoft eGov-Forms berücksichtigten Module MOA-ID und
MOA-SP/SS.
Im Zusammenhang mit sicheren Online-Verfahren ist die Einbindung der elektronischen Signatur sowie Authentisierung und Identifikation des Kommunikationspartners (Antragsteller) notwendig. Die Stabsstelle IKT-Strategie des Bundes hat dazu Servermodule entwickelt. Diese Servermodule lehnen sich an das Konzept der Bürgerkarte an und bilden das Gegenstück auf Seite der Verwaltung zur sogenannten Bürgerkartenumgebung des Bürgers [Stab05]. Folgende Servermodule werden derzeit von Fabasoft eGov-Forms verwendet:
Modul für Online Anwendungen – Identifikation und Authentisierung (MOA-ID),
Modul für Online Anwendungen – Signaturprüfung und Serversignatur (MOA-SP/SS)
9.1
MOA-ID
Das Modul MOA-ID dient zur Authentifikation des Bürgers mittels Bürgerkarte gegenüber einer Online-Anwendung. Dieses Servermodul übernimmt grundsätzlich die Überprüfung der Identität des Antragstellers und gibt
diese Informationen an die Online-Anwendung weiter. Zusätzlich wird eine bereichsspezifische Personenkennung (bPK) für den angegebenen Verfahrensbereich berechnet (siehe [EGov04]). Diese bPK wird durch ein mathematisches Verfahren (HASH) aus der auf der Bürgerkarte enthaltenen Stammzahl und dem jeweils zugeordneten
Verfahrensbereich berechnet. Eine bPK ist auf den Bereich beschränkt, dem die Anwendung zugeordnet ist. Die
bPK kann nicht auf die Stammzahl rückgeführt oder für andere Bereiche umgerechnet werden.
Das Modul MOA-ID ist nicht Bestandteil von Fabasoft eGov-Forms, sondern als Fremdanbieter-Produkt über definierte Schnittstellen in das Standardsoftwareprodukt Fabasoft eGov-Forms eingebunden.
Die Konfiguration der MOA Integration erfolgt über Angaben in einer Administrations-Konfiguration, die auf
FSCCONFIG@1.1001:Configuration basiert.
165
Folgende Angaben werden benötigt:
URL zum Authentifizieren
Webservice-URL zum Überprüfen des SAML-Artefakts
URL für die Rückkehr nach Abmeldung
Gruppe für neue Benutzer
Einstellungen in der Administrations-Konfiguration
Folgende Schritte sind zur Konfiguration von MOA-ID durchzuführen:
Erzeugen einer Administrations-Konfiguration zur Sicherstellung der Update-Fähigkeit der Einstellungen.
Als Basis dieser Konfiguration ist auf der Registerkarte „Konfiguration“ der Wert
FSCCONFIG@1.1001:Configuration einzutragen.
Weiters ist eine Referenz und eine Softwarekomponente auf der Registerkarte „Komponentenobjekt“ zu
definieren.
Schlussendlich sind auf der Registerkarte „MOA“ die MOA-ID-spezifischen Parameter zu setzen (siehe
Abbildung 49). Hierzu zählen:
URL zum Authentisieren
Dieser Typ definiert den URL, unter der der MOA-ID-Server die Authentisierung durchführt. Hier sind
zugleich die aufrufenden URL-Parameter zu definieren. Eine detaillierte Beschreibung der Parameter und
deren Bedeutung kann in der Dokumentation zu MOA-ID nachgelesen werden (siehe [ScKM03]).
Folgender Beispiel-URL wäre denkbar:
https://<moa-server>/moa-id-auth/StartAuthentication?Target=Antrag&OA=
http%3A//<eGov-Forms-Server>/fsc/fscasp/content/bin/fscvext.dll%3Fax=
COO.1.1001.1.32498%26dx=COO.1.1001.1.134446
Webservice-URL zum Überprüfen des SAML-Artefakts
Dieser Typ definiert den URL, unter der das Produkt Fabasoft eGov-Forms das erhaltene SAML-Artefakt
verifizieren kann.
9. Module für Online-Applikationen
9.1 MOA-ID
http://<moa-server>/moa-id-auth/services/GetAuthenticationData
URL für die Rückkehr nach Abmeldung
Dieser Typ definiert den URL, welche nach erfolgter Abmeldung vom System aufgerufen werden soll.
http://www.fabasoft.com
Da jeder neue Antragsteller im Sinne der Personalisierung als Antragsteller im Produkt Fabasoft eGov-Forms
angelegt wird, muss zusätzlich eine Gruppe hierfür angegeben werden.
Damit die eben getroffenen Einstellungen auch Anwendung finden, ist die Eintragung der eigenen Administrations-Konfiguration in der Komponenten-Konfiguration der aktuellen Domäne bzw. des Mandanten durchzuführen.
Abbildung 49
AdministrationsKonfiguration – MOA-ID
167
Aufruf des MOA-ID-Logins
Der Aufruf des MOA-ID-Logins hängt von der verwendeten Anwendungssteuerung und dem Status der Authentifikation des Antragstellers ab. Im Zuge des Zugriffs auf ein Online-Formular über eine definierte Anwendungssteuerung wird der Antragsteller automatisiert an das konfigurierte MOA-ID-Service weitergeleitet (Ablauf siehe Abbildung 50). Entsprechend muss der Antragsteller dort seine Identifikationsdaten bekannt geben bzw.
unterzeichnen. Nach erfolgreicher Identifikation des Antragstellers am MOA-ID-Service kehrt dieser wieder an
die Fabasoft eGov-Forms Umgebung zurück. Fabasoft eGov-Forms erkennt den Redirect aus dem MOA-ID-Service und versucht eine Zuordnung des Antragstellers.
Abbildung 50
Identifikation
mittels MOA-ID
9. Module für Önline-Applikationen
9.1 MOA-ID
9.2 MOA-SP/SS
9.2
MOA-SP/SS
Der Teil MOA-Signaturprüfung des Moduls MOA-SP/SS prüft digitale Signaturen, die mit Hilfe der Bürgerkarte
über das Protokoll Security-Layer angefertigt wurden. In diesem Zusammenhang sind zwei Szenarien denkbar.
Als erstes Szenario gilt es, die digitalen Signaturen des Antragstellers zu überprüfen. Damit kann beispielsweise die Authentizität von Anträgen hinsichtlich Inhalt und Ursprung durch die Behörde geprüft werden. Das
zweite Szenario umfasst die Prüfung der elektronischen Unterschrift einer anderen Behörde. Damit kann die
Authentizität von Schriftstücken hinsichtlich Inhalt und Ursprung durch die Behörde geprüft werden.
Das Modul MOA-SP/SS ist nicht Bestandteil von Fabasoft eGov-Forms, sondern als Fremdanbieter-Produkt über
definierte Schnittstellen in das Standardsoftwareprodukt Fabasoft eGov-Forms eingebunden.
Im Kontext von Fabasoft eGov-Forms wird das Modul MOA-Signaturprüfung zur Überprüfung der digitalen Signatur des Antragstellers verwendet. Hierzu wird der mittels Bürgerkarte fertig signierte Antragsinhalt an eine
MOA-Signaturprüfungsinstanz mit den nötigen Parametern übermittelt. Falls die Signaturprüfung ein Problem
mit der digitalen Signatur aufzeigt, wird dieses sofort dem Antragsteller dargestellt.
Konfiguration für die Signaturprüfung
Das Produkt Fabasoft Components/Base stellt eine Aktion (Referenz: FSCMOASS@1.1001:
VerifySignature) zur Überprüfung von digitalen Signaturen mit Hilfe von MOA-Signaturprüfung zur Verfügung. Das Standardsoftwareprodukt Fabasoft eGov-Forms bedient sich dieser Funktionalität und ermöglicht
die nötige Konfiguration in der Step Engine Konfiguration. Folgende Schritte sind zur Konfiguration von MOASignaturprüfung durchzuführen:
Erzeugen einer Step Engine Konfiguration zur Sicherstellung der Update-Fähigkeit der Einstellungen.
Als Basis dieser Konfiguration ist auf der Registerkarte „Konfiguration“
FSCSTEPENG@1.1001:DefaultConfiguration einzutragen.
der
Wert
Weiters ist eine Referenz und eine Softwarekomponente auf der Registerkarte „Komponentenobjekt“ zu
definieren.
169
Schlussendlich sind auf der Registerkarte „FSC Forms Base“ die für MOA-Signaturprüfung spezifischen
Parameter zu setzen (siehe Abbildung 51). Hierzu zählen:
URL des MOA_SP-Services
Dieser URL definiert, unter welcher Adresse das MOA-Service erreichbar ist. Folgender Bespiel-URL
wäre denkbar:
http://<moa-server>/moa-spss/services/SignatureVerification
Trust Profile ID des MOA_SP-Services
Dieser Parameter definiert die Trust Profile ID, welche zur Signaturprüfung verwendet werden soll.
Abbildung 51
Step Engine Konfiguration –
MOA-Signaturprüfung
9. Module für Önline-Applikationen
9.2 MOA-SP/SS
Aufruf der Signaturprüfung
Nach dieser Art der Einrichtung wird die Signaturprüfung im Kontext von Fabasoft eGov-Forms nach jeder erfolgten digitalen Signatur mittels Bürgerkarte automatisiert aufgerufen.
Zusammenfassung
Abbildung 52
MOA
171
10
173
10 funktionsbeschreibung
Ziel dieses Kapitels ist es, einen kleinen Überblick über die wichtigsten Elemente, die zum Erstellen von Onlineformularen mit Fabasoft eGov-Forms benötigt werden, zu bieten. Es werden überblicksweise die am häufigsten verwendeten Schritte des Produkts Fabasoft eGov-Forms erläutert.
10.1
Anwendungsschritte mit GUI
Editorseite anzeigen
Der Anwendungsschritt Editorseite anzeigen (FSCSTEPENG@1.1001:DisplayFormPageStep)
dient dazu, eine Formularseite zum Bearbeiten und Suchen von Objekten (COOATTREDIT@1.1:
FormPage) des Fabasoft Components Formularsystems bzw. eine Anwendungssicht (FSCVAPP@1.1001:
ApplicationView) darzustellen.
Als erster Parameter muss in der Eigenschaft Seite (FSCSTEPENG@1.1001:formpage) die gewünschte darzustellende Einheit (konkrete Formularseite oder Anwendungssicht) eingestellt werden.
Weiters ist es möglich in der Eigenschaft Editorseite nur lesend darstellen (FSCSTEPENG@1.1001:
displayreadonly) anzugeben, ob die Darstellung nur lesend oder bearbeitend erfolgen soll.
Lesen und Akzeptieren
Dieser Anwendungsschritt ermöglicht es, einen beliebigen HTML-Inhalt auf einer Seite anzuzeigen.
Dazu wird als Parameter in der Eigenschaft dargestellte Information (FSCSTEPENG@1.1001:
infocontent) ein sprachabhängiger Inhalt (COOSYSTEM@1.1:LanguageContent) bereitgestellt.
Der Inhalt wird auf gleiche Weise wie auch bei Header und Footer beschrieben als dynamischer Inhalt verwendet, d.h. es erfolgt die textuelle Substitution von Pseudotags bzw. FSCDOX-Expressions vor der tatsächlichen
Darstellung.
10.2
Antragsschritte mit GUI
Bürgerkarte auswählen
Dieser Anwendungsschritt dient dazu, dem Benutzer des Onlineformulars eine Liste der Bürgerkartenumgebungen zur Auswahl vorzulegen. Dabei werden als System-Default alle suchbaren Objekte der Klasse Definition
einer Bürgerkartenumgebung (FSCDIGSIG@1.1001:CitizenCardDefinition) dargestellt.
Dieses System-Default kann aber über die Eigenschaft Auswählbare Bürgerkartenumgebungen des
Schritts auf die gewünschten Umgebungen reduziert werden.
Die Objektklasse Definition einer Bürgerkartenumgebung erlaubt die Konfiguration der für die Signatur mit
einer Bürgerkartenumgebung nötigen Einstellungen wie den Data-URL.
Formularseiten bearbeiten
Der Schritt „Formularseiten bearbeiten“ (FSCFORMS@1.1001:EditFormPagesStep) unterscheidet sich in der Möglichkeit mehrere Formularseiten innerhalb eines tatsächlichen Schritts darstellen zu können
vom Anwendungsschritt Editorseite anzeigen (FSCSTEPENG@1.1001:DisplayFormPageStep).
Innerhalb dieser einzelnen Seiten kann über zwei separate Schaltflächen nächste Seite und Seite zurück
navigiert werden.
Vollständigen Antrag anzeigen
Dieser Schritt visualisiert den vollständig ausgefüllten Antrag, so wie er eingereicht wurde. Optional kann hier die
Schaltfläche „Status downloaden“ aktiviert werden, die dann den Download eines Status-XML-Dokuments übernimmt. Das Dokument wird durch die Inhaltseigenschaft XML Status (FSCFORMS@1.1001:statusdoc)
dargestellt. Vor dem Download wird eine XML-Transformation mit einem pro Antragsklasse einstellbarem XMLStylesheet durchgeführt. Das Stylesheet ist durch den Inhalt der Eigenschaft Transformation für Statusbericht
(FSCFORMS@1.1001:statustransformation) bei der Antragsobjektklasse zu definieren.
10. Funktionsbeschreibung
10.2 Antragsschritte mit GUI
Zusammenfassung anzeigen
Mit diesem Schritt wird dem Benutzer des Online-Formulars eine automatisch generierte Zusammenfassung
aller bisher dargestellten Formularseiten vorgelegt. Vor der Anzeige wird eine Zusammenfassung der Daten in
Form von XML generiert und in der Eigenschaft Hauptinhalt (COOSYSTEM@1.1:content) abgelegt. Es
wird ein XSL-Stylesheet, das zur Transformation dieser XML-Daten in eine HTML-Seite verwendet werden kann,
generiert und im Attribut XSL-Inhalt (FSCFORMS@1.1001:xslcont) persistiert.
Optional kann diese Zusammenfassungsseite als Ausgangspunkt für die digitale Signatur des Antrags benutzt
werden. Zu diesem Zweck kann in der Eigenschaft Art der Signatur zwischen den Werten „Nur anzeigen (ohne
Unterschrift)“ und „Signatur mit Bürgerkarte“ gewählt werden.
Soll das Signieren ermöglicht werden, so muss zuvor eine verfügbare Bürgerkartenumgebung festgelegt werden.
Dies kann entweder programmatisch oder über den Schritt „Bürgerkarte auswählen“ erfolgt sein. Wesentlich ist, dass im Attribut Auswahl der Bürgerkartenumgebung (FSCFORMS@1.1001:ccard) des
Antrags eine gültige Definition einer Bürgerkartenumgebung gesetzt wurde. Weiters muss eine Signaturschaltfläche in der Eigenschaft Schaltfläche „Signieren“ definiert worden sein. Sind alle diese Vorbedingungen erfüllt, so wird auf Betätigen der neuen Schaltfläche der für das Security-Layer-Protokoll nötige XMLRequest aus dem zuvor generierten XML-Dokument und dem zugehörigen XSL-Stylesheet gebildet und an den
in der Bürgerkartendefinition eingestellten Security-Layer-URL gepostet.
Der Schritt „Zusammenfassung anzeigen“ ermöglicht darüber hinaus den Download der HTML-Zusammenfassung, die durch die oben genannte Transformation gebildet werden kann, sofern ein Wert in der zugehörigen
Eigenschaft Schaltfläche „Download“ angeführt wurde.
175
10.3
Anwendungsschritte ohne GUI
Argument setzen
Mit diesem Schritt kann eine Reihe von Fabasoft Expressions bewertet werden und diese Werte im Werteverzeichnis der Laufzeitumgebung unter definierten Bezeichnern abgelegt werden, um diese zu einem späteren
Zeitpunkt wieder abrufen zu können.
Ausdruck auswerten
Mit dem Schritt „Ausdruck auswerten“ kann eine beliebige Fabasoft Components Expression zur Auswertung gebracht werden. Als lokaler Scope (this) steht das gerade in Bearbeitung befindliche Antragsobjekt zur
Verfügung. Als globaler Scope ist hier das Scope-Werteverzeichnis der Fabasoft eGov-Forms-Laufzeitumgebung
verfügbar. Die Verwendung von Fabasoft Components Expressions ist umfassend in [KlWi04] beschrieben.
SMTP-Mail versenden
Dieser Schritt wird benutzt, um eine automatische E-Mail zu generieren und via SMTP zu versenden.
Zu diesem Zweck muss der E-Mail-Body in der Eigenschaft E-Mail-Inhalt als dynamischer Inhalt konfiguriert
werden. Die Einstellung des Betreffs, des Absenders und des Empfängers der E-Mail ist in den Eigenschaften
des Schritts einstellbar.
Ebenso können eine Reihe von E-Mail-Beilagen über die Eigenschaft Ausdruck zur Ermittlung der Beilageninhalte
definiert werden. In diesem Ausdruck wird eine Liste von Inhalten (COOSYSTEM@1.1:CONTENT) erwartet.
10. Funktionsbeschreibung
10.3 Anwendungsschritte ohne GUI
10.4 Anwendungsschritt für Ablaufkontrolle
10.4
Anwendungsschritt für Ablaufkontrolle
Anwendung ausführen
Dieser Schritt führt eine beliebige virtuelle Anwendung aus. Damit kann auf simple Art und Weise der Funktionsumfang von Fabasoft eGov-Forms beliebig erweitert werden.
177
11
179
11 ausblick
Die Fabasoft Produktpalette ermöglicht die rasche und professionelle Umsetzung von Online-Formularen. Der
Formulardesigner stellt als Bestandteil der Fabasoft eGov-Suite eine intuitive, grafisch orientierte Web-Oberfläche zur Entwicklung von Online-Formularen zur Verfügung.
Benötigt eine Behörde zusätzlich zu den Möglichkeiten des Formulardesigners erweiterte Entwicklungsfunktionalität, so können Online-Formulare auch mit Hilfe des generischen Interface von Fabasoft eGov-Forms umgesetzt werden. Hierbei hat der Entwickler zusätzlich folgende Möglichkeit der
Einbindung von Web-Services
erweiterten Ablaufsteuerung
erweiterten Gestaltungsmöglichkeiten
In Verbindung mit Online-Formularen, die ein Bürger ausfüllen kann, steht auch der Abtransport der eingegebenen
Daten an die elektronische Akten- und Vorgangsbearbeitung der Behörde zur Verfügung. Das Standardsoftwareprodukt Fabasoft eGov-Forms bietet, wie in Kapitel 6 dargestellt, diverse Schnittstellen zu diesem Zweck an.
Dieses Buch hat sich grundsätzlich mit der Thematik von Online-Formularen und deren Umsetzung mittels der
Fabasoft Softwareprodukte auseinandergesetzt. In diesem Zusammenhang sind jedoch Überlegungen im Hinblick auf eine organisatorische Umstrukturierung der öffentlichen Verwaltung anzustellen. Diese organisatorischen Themen sollten jedoch nicht Thema dieses Buches sein, sondern von Vertretern der öffentlichen Verwaltung analysiert werden.
Fabasoft verfolgt laufend diese Überlegungen und definiert davon ausgehend Anforderungen an die eigene Softwareproduktpalette.
12
181
12 glossar
Access Control List (ACL) ________________________________________________________144
Zugriffsliste, die festlegt, welcher Benutzer welche Zugriffsmöglichkeiten auf ein bestimmtes Objekt hat. Jedem
Objekt in Fabasoft ist eine ACL zugewiesen.
Authentifizierung ________________________________________________________________46
Die Authentifizierung (auch Authentifikation) bezeichnet den Vorgang, die Identität einer Person oder eines Programms an Hand eines bestimmten Merkmals, zum Beispiel mit dem Fingerabdruck oder einem beliebigen anderen Identitätsmerkmals, zu überprüfen [Wiki05].
Authentizität __________________________________________________________________169
Die Authentizität von Unterlagen ist dann gegeben, wenn bewiesen werden kann, dass diese Unterlagen unversehrt und unverändert das wiedergeben, was sie zu belegen beanspruchen. Authentizität von Unterlagen findet
ihren Niederschlag in einer Summe von äußeren und inneren Merkmalen, dem Nachweis des Kontexts ihrer Entstehung und Wirkung sowie der Art und Weise ihrer Verwahrung. Ein Dokument ist authentisch, wenn gezeigt
werden kann, das es noch genau dasselbe ist wie zu dem Zeitpunkt, als es an das Archiv übertragen wurde.
Authentizität ist ein Teilaspekt der Revisionssicherheit.
Backoffice ____________________________________________________________________13
Als das Backofficesystem wird das Aktenverwaltungsprogramm einer Behörde gesehen. An dieses System werden alle eingebrachten Daten geschickt. In weiterer Folge wird die komplette Aktenbearbeitung in einem Backofficesystem durchgeführt.
Bürgerkarte ____________________________________________________________________46
Siehe Elektronische Identitätskarte
Bürgerkarte light ________________________________________________________________45
Signatur bzw. Personifizierung über ein Mobiltelefon in Österreich. Rechtlich ist die Bürgerkarte light der Bürgerkarte gleichgestellt.
Business to Government (B2G, B-to-G) ______________________________________________11
Abwicklung von Geschäften zwischen der Öffentlichen Verwaltung und Privatwirtschaft, die ausschließlich mit
elektronischen Medien durchgeführt werden.
Cascading Style Sheets (CSS) ______________________________________________________30
Enthalten Formatvorlagen, mit denen die einfache und allgemeine Formatierung einer Website möglich wird.
Dadurch wird ein effektiveres Gestalten und Umgestalten von Dokumenten möglich.
Citizen to Government, Customer to Government (C2G, C-to-G) ____________________________11
Abwicklung von Geschäften zwischen der Öffentlichen Verwaltung und Bürger, die ausschließlich mit elektronischen Medien durchgeführt werden.
Corporate Identity ______________________________________________________________20
Beschreibt ein unternehmensweit einheitliches Erscheinungsbild einer Organisation nach außen.
Demilitarisierte Zone (DMZ) ______________________________________________________182
Teil eines Netzwerks, der sich zwischen interner und externer Firewall (siehe Firewall) befindet. In dieser Zonen
stehen die Server, die von außen erreichbar sein müssen (Webserver, Formularserver,…).
Denial of Service (DoS) __________________________________________________________120
Als DoS-Angriff (Denial of Service attack, etwa: Dienstverweigerungsangriff) bezeichnet man einen Angriff auf
einen Host (Server) mit dem Ziel, einen oder mehrere seiner Dienste arbeitsunfähig zu machen. In der Regel
geschieht das durch Überlastung. Erfolgt der Angriff koordiniert von einer größeren Anzahl anderer Systeme aus,
so spricht man von einem DDoS (Distributed Denial of Service). Normalerweise werden solche Angriffe nicht per
Hand sondern mit Backdoor-Programmen oder Ähnlichem durchgeführt, welche sich von alleine auf anderen
Rechnern im Netzwerk verbreiten, und dadurch dem Angreifer weitere Wirte zum Ausführen seiner Angriffe bringen.
183
Digitale Signatur ________________________________________________________________13
Die digitale Signatur ist eine elektronische "Unterschrift", die mit Hilfe von Verfahren der asymmetrischen Kryptographie erstellt wird. Die digitale Signatur ist der mit dem privaten Signaturschlüssel des Signators verschlüsselte Hash-Wert des zu signierenden Dokuments. Sie ist daher für verschiedene Dokumente immer anders, beim
identischen Dokument (und demselben Verfahren zur Hash-Wertberechnung) immer gleich.
Dispatcher (Anwendungssteuerung) ________________________________________________30
Wesentlicher Bestandteil für die Ausführung eines Onlineformulars. Es wird die optische Zusammensetzung des
Onlineformulars bestimmt und kann durch die Verwendung in einem URL (siehe URL) aufgerufen werden.
Drag&Drop ____________________________________________________________________65
Verschieben einer Datei ausschließlich mit der Maus. Durch einfaches Klicken und Ziehen mit der Maus können
so Dokumente in an andere Orte verschoben werden.
E-Government __________________________________________________________________11
Die Durchführung von behördlichen Aktivitäten mit Hilfe elektronischer Medien, wie zum Beispiel das Internet.
Elektronische Identitätskarte ______________________________________________________46
Chipkarte ähnlich einer EC-Karte oder Kredit-Karte und speichert persönliche Daten einer Person. Mit Hilfe einer
elektronischen Identitätskarte kann die Identität einer Person festgestellt werden, wodurch eine Digitale Signierung von elektronischen Daten erfolgen kann. Die Verwendung der Identitätskarte ist durch einen PIN, einem
vierstelligem Zahlencode, geschützt.
Extensible Markup Language (XML) ________________________________________________11
Eine Sprache, mit der die Struktur von Dokumenten beschrieben wird (eine sog. Metasprache). XML wurde von
der W3C als Datenformat festgelegt, um die einfache Implementierung in bestehende Software und die einfache Kommunikation zwischen mehreren Softwareprodukten zu gewährleisten.
Fabasoft Components Webservice __________________________________________________35
Die am Webserver eintreffenden Benutzeranfragen werden von der eingesetzten Webserver-Software (z.B. Apache HTTP Server 2.0 oder Microsoft Internet Information Service) an das Fabasoft Components (Thread-Pool des
Web-Tiers der verteilten Anwendung; ISAPI-Erweiterung des Microsoft Internet Information Services) Webservice weitergereicht und unter Verwendung des Fabasoft Components Kernels verarbeitet.
Firewall ______________________________________________________________________42
Software oder eine Hardware, die den Netzwerkverkehr zwischen zwei oder mehreren Netzwerken regelt und
ggf. blockt.
Government to Government (G2G, G-to-G) ____________________________________________11
Abwicklung von Geschäften zwischen Behörde zu Behörde mit Hilfe von elektronischen Medien.
Graphical User Interface (GUI) ____________________________________________________36
Eine grafische Benutzeroberfläche, die ein Benutzer verwendet, um seine Arbeit mit einer Software durchführen
zu können.
Hashwert ______________________________________________________________________32
Prüfsumme über ein Dokument, die zur Kontrolle herangezogen wird, ob sich ein Dokument im Laufe der Zeit verändert hat.
Hypertext Transfer Protocol (HTTP)__________________________________________________35
Wird von Webbrowsern verwendet um auf Webserver zuzugreifen.
Internet ________________________________________________________________________11
Das Internet, auch World Wide Web bezeichnet, ist die Verbindung aller weltweiten Netze zu einem gesamten
Netzwerk, in dem jeder mit jedem kommunizieren kann. Die Rückgrade (Backbones) des Internets sind diverse
Knotenrechner, die miteinander verbunden sind. Diese Knotenrechner müssen immer Online sein, um eine
schnelle Kommunikation gewährleisten zu können.
185
Intranet ________________________________________________________________________20
Ist das interne Netz eines Unternehmens. Es ist vom Internet durch mindestens eine Firewall getrennt.
Konvertierung __________________________________________________________________43
Überführung einer Datei in ein anderes Dateiformat.
Link __________________________________________________________________________17
Verweis innerhalb eines elektronischen Dokumentes oder einer HTML-Seite auf ein anderes Dokument oder eine
andere HTML - Seite.
Metadaten ____________________________________________________________________54
Daten, die Bedeutung, Beschaffenheit, Struktur und den Aufbau anderer Daten beschreiben. Metadaten sind
strukturierte oder teilweise unstrukturierte Information, die zum Beispiel den Prozess der Entstehung und Wirkung (Nutzung) von Unterlagen, ihren Aufbau sowie ihre Verwaltung und Verwahrung nachvollziehbar machen.
MOA-Module __________________________________________________________________13
Dienen der Schaffung von sicheren Online-Verfahren und setzen sich aus MOA-ID für die Personenauthentisierung, aus MOA-SP für Signaturprüfung und aus MOA-SS für die Serversignatur zusammen. Diese drei Module
sind seit Juli 2003 fertiggestellt und können von Unternehmen kostenlos lizenziert werden.
Objektklasse __________________________________________________________________87
Jedes Objekt ist eine Instanz einer Objektklasse. Objektklassen sind immer von genau einer Objektklasse abgeleitet und erben von dort alle Eigenschaften und Methoden. Objektklassen sind in einem Baum angeordnet, der
genau eine Wurzel Objekt (COOSYSTEM@1.1:Object) hat.
Pull-Verfahren __________________________________________________________________14
Spezielle Kommunikation zwischen zwei Rechnern, bei der der Zielrechner vom Quellrechner die benötigten
Informationen anfordert. Der Quellrechner übermittelt diese Informationen an Zielrechner. Hier geht die Startinitiative vom Zielrechner aus.
Portal ________________________________________________________________________52
Steht führ einen Internetauftritt, der sehr viel Informationen und weitere Online-Dienste zur Verfügung stellt und
kann, zwecks der Übersichtlichkeit, in mehrer Portalseiten untergliedert werden.
Private Key (Geheimer Schlüssel) __________________________________________________46
Ein Private-Key ist ein geheimer Schlüssel der zur Entschlüsselung von verschlüsseltem Text in Klartext verwendet wird. Der Schlüssel ist nur jenen Personen bekannt, die eine Nachricht entschlüsseln und lesen dürfen.
Public Key (Öffentlicher Schlüssel) ________________________________________________46
Der öffentliche Schlüssel ist der Allgemeinheit bekannt und dient zur Verschlüsselung von Klartext in verschlüsselten Text. Der verschlüsselte Text kann nach der Verschlüsselung nur über einen Private-Key entschlüsselt werden.
Push-Verfahren ________________________________________________________________14
Spezielle Kommunikation zwischen zwei Rechnern, bei der der Quellrechner dem Zielrechner die nötigen Informationen übermittelt. Der Zielrechner verarbeitet die erhaltenen Daten.
Ressourcenassistent ____________________________________________________________162
Ein Assistent zur Unterstützung des Benutzers beim Einfügen von Ressourcen in den Editor.
Security Layer __________________________________________________________________13
Eine vom CIO Office spezifizierte Schnittstelle, die eine Applikation verwenden muss, um auf die Funktionen der
Bürgerkarte zuzugreifen. Unter diesen Funktionen sind auch die Erstellung einer elektronischen Signatur und das
Auslesen der Daten der Bürgerkarte.
Simple Object Access Protocol (SOAP) ______________________________________________11
Ein Standard für die plattformunabhängige Kommunikation zwischen verteilten Systemen, basierend auf den
XML-Standards. SOAP dient zum Austausch von strukturierten Informationen in einer dezentralen Netzwerkumgebung. Um eine möglichst hohe Flexibilität zu erreichen wird für die Datenübergabe das Dateiformat XML verwendet.
187
Transaktion ____________________________________________________________________13
Eine Abfolge von mehreren Operationen, die entweder alle oder gar nicht durchgeführt werden müssen. Passiert
in einer Operation ein Fehler, müssen alle zuvor durchgeführten Änderungen wieder rückgängig gemacht werden. Werden alle Operationen ohne Fehler durchgeführt, werden alle Änderungen übernommen.
Uniform Ressource Locator (URL) __________________________________________________75
Eine Adresse zu einer Website oder zu einer Datei, welche durch einen Webserver zur Verfügung gestellt wird.
Einheitliche (Internet-)Ressourcenadresse, der oder die, die häufigste Form einer URI, die zur Lokalisierung von
Rechner und Speicherort einer Datei im Internet dient. [Broc03]
Use-Case ______________________________________________________________________14
Ist die Beschreibung eines in Schritte untergliederten Anwendungsfalles eines Anwenders.
WBT ________________________________________________________________________157
Das Fabasoft WBT (Web based Training) ist ein web-basiertes E-Learning -System.
Web __________________________________________________________________________81
Der Begriff Web kommt vom Begriff World Wide Web, auch WWW abgekürzt und Bezeichnet die Technologie
der Datendarstellung über Internet, Extranet oder Intranet.
Web Accessible Initiaitive (WAI) __________________________________________________11
Eine Vereinigung des W3C, die es sich zum Ziel gemacht hat, das Internet auch für Personen mit besonderen
Bedürfnissen erreichbar zu machen. Erklärtes Ziel des W3C ist es hierbei, das WWW möglichst vielen Menschen
"barrierefrei" zugänglich zu machen.
Webbrowser __________________________________________________________________41
Software für den Zugang zum Internet bzw. für das Einsehen von Internetseiten (Webseiten)
What You See Is What You Get (WYSIWYG) __________________________________________63
Die Darstellung von Inhalten auf dem Bildschirm genauso wie sie schließlich im Ausgabemedium erscheinen.
Workflow ______________________________________________________________________54
Ist ein Prozess (alternativ Geschäftsvorfall oder allgemein Vorgang), der aus einzelnen Aktivitäten aufgebaut ist,
die sich auf Teile eines Geschäftsprozesses oder andere organisatorische Vorgänge beziehen. [Wiki05]
World Wide Web (WWW) ________________________________________________________11
Siehe Internet
World Wide Web Consortium (W3C) ________________________________________________28
Entwickelt Lösungen, um die Möglichkeiten des Internets voll ausschöpfen zu können. Diese Lösungen beinhaltet Spezifikationen, Richtlinien, Software und diverse Tools.
Zeitstempel ____________________________________________________________________76
In den Erläuterungen zu § 7 SigG steht: "Ein Zeitstempel ist eine elektronisch signierte Bescheinigung eines Zertifizierungsdiensteanbieters, dass (ihm) bestimmte elektronische Daten zu einem bestimmten Zeitpunkt vorgelegen sind. […]." Man unterscheidet zwischen einem öffentlichen Zeitstempeldienst und dem internen Zeitstempel des Trust Centers.
Zeitstempeldienst ______________________________________________________________76
Es handelt sich um eine amtlich anerkannte Bestätigung, dass ein Dokument zu einer bestimmten Zeit vorgelegen hat. Beispiel: Die Angebote bei einer Ausschreibung sind digital einzureichen. Der Anbieter sendet sein
Angebot zu einem Trust Center. Das Trust Center hängt diesem Dokument einen Zeitstempel an und signiert das
Angebot und den Zeitstempel digital. Anschließend wird das Dokument - signiert und mit einem Zeitstempel versehen - an den Anbieter zurückgesandt.
189
13
191
13 abbildungsverzeichnis
Abbildung 1
Abbildung 2
Abbildung 3
Abbildung 4
Abbildung 5
Abbildung 6
Abbildung 7
Abbildung 8
Abbildung 9
Abbildung 10
Abbildung 11
Abbildung 12
Abbildung 13
Abbildung 14
Abbildung 15
Abbildung 16
Abbildung 17
Abbildung 18
Abbildung 19
Abbildung 20
Abbildung 21
Abbildung 22
Abbildung 23
Abbildung 24
Abbildung 25
Abbildung 26
Abbildung 27
Abbildung 28
Durchgängiges E-Government ______________________________________12
E-Government Gütesiegel __________________________________________12
Fertiges Beispielformular (Seite 1) ____________________________________15
Abtransport ins Backoffice – Grundsätzliches Zusammenspiel ________________20
Entwicklungs-, Test- und Produktiv-Umgebung __________________________22
Einleitung ____________________________________________________23
E-Government Styleguide __________________________________________26
Digitale Signatur erstellen __________________________________________33
Digitale Signatur verifizieren ________________________________________33
Ablauf bei eps e-payment standard nach [Jung04] ________________________37
Standards ____________________________________________________39
Fabasoft Referenzarchitektur [FAHJ04] ________________________________42
Architektur ____________________________________________________48
Struktur des Formulardesigners ______________________________________53
Antragsprojekt __________________________________________________56
Formularblockelement – Auswahl ____________________________________60
Formularblockelement – Werteliste __________________________________60
Plausibilitätsprüfung ______________________________________________62
Formularblock (Daten) erzeugen ______________________________________66
Formularblock-Formatierung bearbeiten ________________________________66
Formularblock (Daten (Kopie von Vorlage)) ______________________________68
Formularblock (Beilagen) __________________________________________69
Formularelement (Seitenkopf) erzeugen ________________________________73
Formularelement (Seitenkopf) im Formular ______________________________73
Formularseite erzeugen/bearbeiten __________________________________78
Abbildung 29
Abbildung 30
Abbildung 31
Abbildung 32
Abbildung 33
Abbildung 34
Abbildung 35
Abbildung 36
Abbildung 37
Abbildung 38
Abbildung 39
Abbildung 40
Abbildung 41
Abbildung 42
Abbildung 43
Abbildung 44
Abbildung 45
Abbildung 46
Abbildung 47
Abbildung 48
Abbildung 49
Abbildung 50
Abbildung 51
Abbildung 52
Antragsformular erstellen __________________________________________80
Review-Ansicht ________________________________________________82
Formulardesigner ________________________________________________83
Ansicht Layout ________________________________________________100
Ausführen einer Sequenz von Schritten________________________________109
generisches Interface ____________________________________________116
Ablauf Push-Verfahren __________________________________________121
Anfrageablauf ________________________________________________125
Digital signiertes XML-Dokument ____________________________________129
WSDL-Anfrage im Webbrowser ____________________________________131
Push-Verfahren ________________________________________________138
Ablauf Pull-Verfahren ____________________________________________139
Ablauf des Pull-Jobs ____________________________________________142
Pull-Verfahren __________________________________________________149
Technischer Ablauf XML-Antrag ____________________________________152
automatische Antragtellung________________________________________155
Vorteile von Fabasoft eGov-Suite/WBT ________________________________158
Beispiel-WBT – Hundeanmeldung __________________________________158
WSDL-Anfrage ________________________________________________161
Schnittstellen __________________________________________________162
Administrations-Konfiguration – MOA-ID ______________________________167
Identifikation mittels MOA-ID ______________________________________168
Step Engine Konfiguration – MOA-Signaturprüfung ______________________170
MOA ________________________________________________________171
193
14
195
14 literaturverzeichnis
[Atru05]
A-Trust: "a-sign premium". URL: http://www.atrust.at/info.asp?node=337&lang=GE&ch=1
[Stand: 19.02.2005].
[ASIT05]
A-SIT Zentrum für sichere Informationstechnologie – Austria: "Die österreichische
Bürgerkarte". URL: http://www.buergerkarte.at [Stand: 06.01.2005].
[BDCE05]
BDC EDV-Consulting GmbH: "HotSign". URL: http://www.bdc.at [Stand: 19.02.2005].
[Bund05]
Bundeskanzleramt: "Statistisches: Feedback und Reaktionen zu Help". URL:
http://www.help.gv.at/Content.Node/73/Seite.731300.html [Stand: 02.01.2005].
[EGov04]
Verordnung des Bundeskanzlers, mit der staatliche Tätigkeitsbereiche für Zwecke der
Identifikation in E-Government-Kommunikationen abgegrenzt werden (E-GovernmentBereichsabgrenzungsverordnung – E-Gov-BerAbgrV), BGBl. II Nr. 289/2004.
[FAHJ04]
Fallmann, Helmut/Albl, Oliver/Hell, Robert/Jerschitz Christioph: Die Fabasoft Referenzarchitektur im Microsoft Windows-Umfeld. Linz: Fabasoft Press, 2004.
[Geis04]
Geisler, Joachim: eps e-payment standard – Technische Beschreibung Version 2.1.1.
Wien: Studiengesellschaft für Zusammenarbeit im Zahlungsverkehr, 2004.
[GrAr04]
Grimm, Dominik/Arnold, Stefan: E-Government mit Fabasoft: Vom Antrag bis zur
Zustelung. Linz: Fabasoft Press, 2004.
[Hofm04]
Hofmann, Andreas: Das Fabasoft Content-Management-System. Linz: Fabasoft Press,
2004.
[ITSo05]
IT Solution GmbH: "trustDesk standard". URL: http://www.itsolution.at [Stand:
19.02.2005].
[Jung04]
Jung, Walter: Der eps e-payment standard für Online-Zahlungen im E-Government.
Wien: Erste Bank, 2004.
[Kast05]
Kastner, Christian: Elektronische Zustellung mit Fabasoft. Linz: Fabasoft Press, 2005.
[KlWi04]
Klein, Gerfried/ Wimmer, Christian: Softwareentwicklung mit der Fabasoft VAPP-Technologie. Linz: Fabasoft Press, 2004.
[Lein05]
Leiningen-Westerburg, Alexander: "Österreichisches E-Government Gütesiegel". URL:
http://www.guetesiegel.gv.at/bearer/#fabasoft [Stand: 02.01.2005].
[MiWi04a]
Mittheisz, Johann/Wiesner, Harald: E-Government – Styleguide für E-Formulare – stg
1.3. Wien: Bund- und Länderarbeitsgruppe, 2004.
[MiWi04b]
Mittheisz, Johann/Wiesner, Harald: Standarddaten für E-Formulare – st-dat 1.2. Wien:
Bund- und Länderarbeitsgruppe, 2004.
[Mobi05]
[RTRG05]
[Schn05]
[ScKM03]
[ScMo03]
[Stab05]
[STUZ05]
[W3Co05]
[Wiki05]
[WiMi04]
[WSAw03]
Mobilkom Austria: "A1 Signatur". URL: http://www.A1.net/signatur [Stand: 19.02.2005].
Rundfunk & Telekom Regulierungs-GmbH: Signaturverordnung URL:
http://www.signatur.rtr.at/de/legal/directive.html [Stand: 02.03.2005].
Schneier Bruce: "Weblog", URL:
http://www.schneier.com/blog/archives/2005/02/sha1_broken.html [Stand: 16.03.2005].
Schamberger, Rudolf/Karlinger, Gregor/Moser, Ludwig: Spezifikation MOA-ID 1.1.
Wien: ARGE Spezifikation MOA, 2003.
Schamberger, Rudolf/Moser, Ludwig: Spezifikation MOA SP-SS 1.1. Wien: ARGE Spe
zifikation MOA, 2003.
Stabsstelle IKT-Strategie des Bundes: "MOA: Servermodule für Signatur-Basisdienste".
URL: http://www.cio.gv.at/onlineservices/basicmodules/moa/ [Stand: 09.02.2005]
STUZZA, Bankenübergreifende Studiengesellschaft für Zusammenarbeit im Zahlungsverkehr: "eps e-payment standard". URL: http://www.stuzza.at/eps.shtml [Stand:
06.01.2005].
W3C, World Wide Web Consortium: "Web Accessiblilty Initiative". URL:
http://www.w3.org/WAI [Stand: 12.02.2005].
Wikipedia: "Die freie Enzyklopädie". URL: http://www.wikipedia.org [Stand: 04.03.2005].
Wiesner, Harald/Mittheisz, Johann: E-Government – Gestaltung von Druckformularen –
druckform 1.1. Wien: Bund- und Länderarbeitsgruppe, 2004.
World Summit Award 2003: "WSA Best 03". URL: http://www.wsis-award.org [Stand:
24.02.2005].
197
modernes e-government
mit fabasoft egov-forms
Fabasoft egov-Forms

Modernes E-Government mit Fabasoft egov

Transcription

Similar documents

Dead Island PC PS3 Xbox360 EU (3er).pages

KLINOSK P - Klinikum Chemnitz