PTA_SchnittstellenProgrammierung_Einfuehrung.pdf - PTA GmbH

seit 1969 

Beratung 

Organisation 

Softwareentwicklung 

Schnittstellenprogrammierung 

Schnittstellenprogrammierung

1. Zielsetzung 

2. Schnittstellen 

2.1 Definition Schnittstellen 

Schnittstellprogrammierung 

Gliederung 

2.2 Warum überhaupt DV-Schnittstellen ? 

2.3 Schnittstellen -arten bzw. –typen 

2.4 Praktische Umsetzung 

2.5 Mögliche Probleme 

2.6 Erfordernis eigener Technik 

12.02.2007 PTA GmbH, Unternehmensberatung 2


Überblick 

3. Schnittstellenprogrammierung 

3.1 Definition 

3.2 Übersicht 

3.3 Problemlösungen 

3.3.1 Steuerung von Jobs 

3.3.1.1 Definition Job 

3.3.1.2 Job-Step oder Step = Job 

3.3.1.3 Grundlagen der Steuerung 

3.3.1.4 Single Point of Service 

3.3.1.5 Wiederanlauf von Jobs 



Überblick 

3.3.2 Steuerung und Plausibilisierung 

3.3.2.1 Steuerung Jobablauf und Recovery 

3.3.2.2 Parameter für Schnittstellenprogramme 

3.3.2.3 Strukturierte Laufergebnisse 

3.3.2.4 Regeln für Plausibilisierung 

3.3.3 Protokollierung – Monitoring 

3.3.3.1 Protokoll-Medium 

3.3.3.2 Protokoll-Einträge 

3.3.3.3 Protokoll-Sprache 

3.3.3.4 Protokollierungs-Tiefe 

3.3.3.5 Eskalierung 

3.3.3.6 Attribute 

3.3.3.7 Protokollbeispiel 

3.3.3.8 Monitoring 



Überblick 

3.3.4 Fehlerbehandlung 

3.3.4.1 Prinzip in Programmen 

3.3.4.2 Regeln, Standardisierung/Normung 

3.3.4.3 Eskalierung von Fehlern 

3.3.4.4 Protokollierung von Fehlern 

3.3.5 Fehlerhafte Daten 

3.3.5.1 Speicherung 

3.3.5.2 (Manuelle) Korrektur 

3.3.5.3 Korrekturlauf 

3.3.6 Transaktionsverarbeitung 

3.3.6.1 Definition Transaktion 

3.3.6.2 Grenzen des Transaktionshandlings 


3.3.7 Besonderheiten 

3.3.8 Wiederanlauf nach Störung 

3.3.8.1 Recovery-Maßnahmen 

3.3.8.2 Plan für “GaU” 

3.9 Betriebshandbuch 


Überblick 



Überblick 

4. Schnittstellen - Gestern, heute, morgen 

4.1 Steuerung und Verarbeitung in Quell- und Zielsystem 

4.2 Steuerung in eigenem Server – Verarbeitung in Quell- und Zielsystem 

4.3 Steuerung und Teile der Verarbeitung in eigenem Server 

4.4 Ausblick 

5. Tipps 



1. 1. Zielsetzung 

• Kenntnisse vermitteln, auffrischen und vertiefen 

• Hilfe zur Strukturierung des Sachverhaltes 

• Wege finden von der Theorie zur Praxis 

• Tipps für praktische Vorgehensweise, Bewertung und Einordnung 

• Gemeinsames Verständnis (Vereinheitlichung der Denkweise in 

Teams) 

• Was wird nicht behandelt: 

– Programmiersprachen 

– Spezielle Schnittstellen-Tools 

– Standardsoftware, z.B. SAP 

– Spezielle Schnittstellentechniken, z.B. Hardwareschnittstellen 




• Beispiele: 

Mensch Maschine, Analoges Signal digitales Signal, 

DV-System DV-System, Hardware Software. 

• Duden: „EDV: Verbindungsstelle zweier Geräte oder Anlagenteile“. 

• Internet-Suchmaschinen: Zwischen 200.000 und 400.000 Treffer. 

• Literatur: Es gibt keine zugängliche Literatur zu diesem Thema. 

• Eigene Definition einer DV-Schnittstelle: 

Austausch von Informationen über definierte Grenzen zwischen 

Systemen, die getrennt voneinander vorhanden sind. Die Grenze 

ist durch Protokoll(e) definiert. Es ist immer mindestens ein Eingang 

und mindestens ein Ausgang vorhanden. 




• Wir betrachten im Rahmen dieser Grundlagen Schnittstellen auf der 

Ebene Austausch von Informationen auf Applikationsebene. 

Applikation A Schnittstellen Applikation B 

• 

• 

• 

• 

• 

Netz-Hardware Netz-Hardware 

12.02.2007 PTA GmbH, Unternehmensberatung 10 

• 

• 

• 

• 

•

• Informationen: 

– ASCII-Files 

– Office-Dokumente 

– HTML-Dokumente 



– Bit-orientierte Files - z.B. Bilder, Exe-Files 

– EBCDIC-Files (Großrechner) 

– XML-Files 

– usw. 

• XML hat den Vorteil, dass man z.B. Datenstrukturen erweitern kann, 

nicht alle Schnittstellen ändern muss und trotzdem die Daten 

weiterleiten kann. 




• Weil man Informationen von einem System in anderes System 

übernehmen will bzw. muss. 

• Technische Gründe: 

– Getrennte Rechnersysteme. 

• Logische Notwendigkeiten: 

– Getrennte Software-Systeme, gewollt und ungewollt (evtl. auf 

gleichem Rechnersystem). 

• Im Regelfall kennt ein System nicht die Geschäftsprozesse mit den 

dahinter liegenden Informationsstrukturen des anderen Systems. 

Ausnahme sind z.B. Schnittstellen des gleichen Systemstyps, z.B. 

SAP-System SAP-System. 




• Finden Zugriffe direkt auf die Daten eines anderen (Teil)-Systems 

statt, und sind die Geschäftsprozesse und Informationsstrukturen 

bekannt, spricht man allgemein von einem “integrierten System”. 




Unterscheidung von Arten und Typen nach folgenden Kriterien: 

• Führendes System / gleichberechtigte Systeme. 

– Es gibt ein führendes System. 

z.B. ist das Löschen eines Kunden nicht in abhängigen System 

zugelassen. 

– Zwei oder mehrere gleichberechtigte Systeme. 

Jedes System darf z.B. Kunden ändern, anlegen und löschen. 

• Komplette Datenübernahme oder nur Veränderungen. 

– Es werden z.B. bestimmte Tabellen immer komplett übernommen. 

– Es werden nur die geänderten Daten übernommen 

(Änderungen, Löschungen, Neuanlagen). 




Unterscheidung von Arten und Typen nach folgenden Kriterien: 

• Einzel-Entität oder prozessorientiert. 

– Es wird in einer Schnittstelle nur eine Entität, z.B. „Kunden“ bearbeitet. 

– Mehrere Entitäten werden in einer Schnittstelle bearbeitet, d.h. es 

werden z.B. ganze Geschäftsprozesse ausgelöst. 

• Permanenter Online-Betrieb oder „Batch-Fenster“ möglich. 

– 24 Stunden Online-Betrieb der Datenbank. 

– Online-freie Zeit (Batch-Fenster) täglich möglich. 




• Je Aktion eigene Datei oder Zusammenfassung von Daten. 

– Jede Aktion im Quellsystem, die schnittstellenrelevant ist, erzeugt eine 

Schnittstellendatei. 

– Viele Aktionen im Quellsystem werden zu einer Schnittstellendatei zusammengefasst. 

• Steuerungs- und Verarbeitungs-Orte. 

– Steuerung und Verarbeitung nur in Quell- und Zielsystem. 

– Steuerung in eigenem Server, Verarbeitung in Quell- und Zielsystem. 

– Steuerung und Teile der Verarbeitung in eigenem Server. 




• Führendes System / gleichberechtigte Systeme. 

– z.B. Kundendaten. 

Projekt: „Energiebedarfsprognose“. 

Branche: Stromhandel. 

Hier werden die Kundendaten in einem SAP/R3-Umfeld durch den 

Bereich erfasst, der den ersten Kundenkontakt hat. Im Regelfall ist dies 

der Vertrieb. Nur im SAP-Umfeld werden Kunden neu angelegt und evtl. 

auch wieder gelöscht. In der Energiebedarfsprognose werden keine 

neuen Kunden erfasst oder welche gelöscht. 

– z.B. Adressen von Mitgliedern. 

Projekt: „Adressverwaltung“. 

Branche: Partei. 

Jede Kreisgeschäftsstelle kann in entkoppelten Systemen Mitglieder 

erfassen, Adressen ändern und löschen. Auch in der Bundesgeschäftsstelle 

ist dies möglich. Dort werden dann auch die Adressen aller Mitglieder 

nochmals zentral geführt. Hohe technische Komplexität und Aufwand 

Dubletten zu erkennen und zu korrigieren. 




• Komplette Datenübernahme oder nur Veränderungen. 



– z.B. Netze (Grids). 

Täglich wurden alle in einem anderen System enthaltenen Netze und 

ihre Hierarchie komplett übernommen. 

– z.B. 1/4-stündliche Messdaten. 

Hier wurden nur die Messreihen übernommen, die sich in einem 

bestimmten Zeitraum geändert hatten oder neu hinzukamen. 

• Einzel-Entität oder prozessorientiert 



– siehe oben - Einzel-Entität = 1/4-stündliche Messreihen 

– Änderungen in Netzen löst z.B. den Prozess Korrektur Kundendaten 

und Korrekturen in bereits erstellten Bedarfsprognosen aus. 




• Permanenter Online-Betrieb oder „Batch-Fenster“ möglich 

– z.B. 1/4-stündliche Messdaten. 



Das System ist im dauernden Online-Betrieb. Da die Messdaten 

sofortigen Einfluss aus die Prognosen haben, muss in der 

Prognoseerstellung dies berücksichtigt werden. 

– z.B. Erteilte Patente. 

Projekt: „Erfindervergütungen“. 

Branche: Pharma. 

Das System muss nur von 6.00 Uhr bis 22.00 Uhr zur Verfügung 

stehen, deshalb war die Schnittstelle von einem System „Patente“ im 

Batch-Fenster für Sicherungen und Batch-Läufe in dieser Zeit 

durchführbar. 




• Je Aktion eigene Datei oder Zusammenfassung von Daten 

– Keine eigene Projekterfahrung. 

So funktionieren jedoch viele Internet-Projekte. Im Client werden die 

Informationen je Aktion (z.B. Bestellung abschicken) zusammengefasst 

und zum Server übertragen, um dort sofort ausgeführt zu werden. Man 

erhält dann z.B. eine Bestellnummer zurück. 

– z.B. Erteilte Patente. 

Projekt: „Erfindervergütungen“. 


Alle in einer definierten Zeit neu erteilten Patente werden in einer Datei 

zusammengefasst und in das System „Erfindervergütungen“ übernommen. 




• Steuerungs- und Verarbeitungs-Orte 

z.B. Diverse Informationen. 

Projekt: „Generalschnittstelle“. 


Wird ausführlich in Kapitel 4 behandelt. 




Applikation A Schnittstellen 

Applikation B 

Was kann passieren ? 

Erfahrung aus 26 DV-Jahren: 

Alles Erdenkliche und vieles, an das man noch nie gedacht 

hat ! Und immer dann, wann es am unangenehmsten ist ! 




• Abbruch der Verarbeitung. 

– Hardware, Betriebssystem, Datenbank 

• Daten nicht plausibel. 

– in sich, z.B. Fehler in Quellsystem 

– gegenüber Zielsystem 

• Daten in falscher Reihenfolge. 

– Innerhalb einer Datei 

– Dateien 

• Daten nicht komplett oder mehrfach. 

• Lauf zur falschen Zeit, Lauf wird doppelt gestartet. 

• Organisations- oder Programmfehler 

in Quellsystem/Zielsystem. 

• Fehler bei evtl. Fehlerbehebung, z.B. 

nach Abbruch der Verarbeitung. 


• Abbruch der Verarbeitung 



– Hardware, Betriebssystem, Datenbank 

• Fehler beim Wiederaufsetzen 

• Daten nicht plausibel 

– in sich, z.B. Fehler in Quellsystem 

– gegenüber Zielsystem 

• Daten in falscher Reihenfolge 

– Innerhalb einer Datei 

Protokollierung 

Steuerung 

Wiederanlauf 

Fehlerhafte Daten 

Schnittstellenprogrammierung, 

Transaktionsverarbeitung 

– Dateien 

• Daten nicht komplett oder mehrfach 

• Organisations- oder Programmfehler 

in Quellsystem/Zielsystem Fehlerbehandlung 



2.6 Erfordernis eigener Technik 

• Die Einbindung aller vorher aufgeführten Lösungsansätze in eine 

spezielle Programmierung erfordert eine eigene Technik ! 

• Die Aspekte einer solchen speziellen Programmierung (natürlich 

gehört hierzu auch die entsprechende Organisation und 

Systemanalyse) werden im folgenden Kapitel ausführlich behandelt. 

Schnittstellenprogrammierung (SP) 



3.1 Definition 

• Schnittstellenprogrammierung ist eine Technik, die neben der 

eigentlichen Umsetzung der Informationen von einem System in ein 

anderes System alle Aspekte des Umfeldes mit seinen Problemen 

abdeckt. Insbesondere werden darin folgende Inhalte abgedeckt: 

– Fehlerbehandlung 

– Protokollierung 

– Steuerung/Plausibilisierung 

– Fehlerhafte Daten 

– Transaktionsverarbeitung 

– Job-Steuerung 

– Wiederanlauf nach Störung 

– Besonderheiten 


Quellsystem 

Schnittstelle 

Wiederanlauf 

Transaktionen 


3.2 Übersicht 

Schnittstellenservices 

Jobs 

Fehlerbehandlung 

Steuerung 

(Jobs) 

Besonderheiten 

Daten 

• Steuerung 

• Plausibilität 

• Protokoll 

• Fehlerhafte 

Daten 

Schnittstelle 

Zielsystem 



3.3.1 Steuerung von Jobs 

• Was versteht man unter Jobsteuerung ? 

Für das Verständnis ist wichtig: 

– Was ist ein Job (Definition) ? 

– Was sind Steps in einem Job ? 

– Wie kann man Jobs steuern ? 

– Was geschieht, wenn ein Job abbricht ? 



3.3.1.1 Definition Job 

• Die Definition „Job“ stammt aus der Zeit, bevor es Dialogverarbeitung 

gab. Gemeint war damals eine sogenannte Stapelverarbeitung, 

d.h. es wurden mehr als ein Datensatz des gleichen Typs (ganzer 

Stapel) verarbeitet. 

• Heute gibt es immer noch Jobs. Jetzt sind damit Prozesse gemeint, 

die asynchron zu Dialogprozessen ablaufen. 

• Jobs werden immer dann eingesetzt, wenn der entsprechende 

Prozess im Dialog zu lange laufen würde, d.h., wenn das Window 

des Anwenders zu lange blockiert wäre und asynchrone Verarbeitung 

möglich ist oder die Interaktion von Anwendern nicht notwendig 

oder nicht erwünscht ist. 

z.B.: 

– Energiebedarfsprognose für alle Kunden für bestimmten Zeitraum 

– Monatsabschluß einer Buchhaltung 

– und natürlich Schnittstellen .... 



3.3.1.2 Job-Step oder Step = Job 

• In einem Job können mehrere Prozesse bzw. Programme 

hintereinander laufen. 

z.B.: 

– Gehaltsabrechnung durchführen, 

– alle Gehaltsabrechnungen drucken, 

– Datenträgeraustausch-Dateien für Überweisung erstellen. 

• Jeder dieser Einzelprozesse kann ein „Step“ eines Jobs sein. 

Bei Einsatz von Steps müssen diese steuerbar sein, Protokoll. 

• Man kann jedoch auch je Prozess bzw. Step einen eigenen Job 

anlegen und diese Jobs dann gesteuert ablaufen lassen. Wichtig ist 

hierbei, die Reihenfolge zu steuern. 

• Jobs kann man auch vernetzen, wenn z.B. Jobs parallel zueinander 

laufen können. In obigen Beispiel können die Gehaltsabrechnungen 

parallel zum Erstellen der Datenträgeraustausch-Dateien gedruckt 

werden. 



3.3.1.3 Grundlagen der Steuerung 

• Der Start eines Jobs kann nach verschiedenen Gesichtspunkten 

erfolgen: 

– Zeitgesteuert. 

Bei Erreichen einer bestimmten Zeit wird der Job automatisch gestartet. 

– Ereignisgesteuert. 

Nach Eintreten eines bestimmten Ereignisses wird der Job automatisch 

gestartet. 

Ereignisse sind z.B.: 

• Vorhandensein einer Datei. 

• Beendigung eines anderen Jobs 

– Manuell. 

Der Job wird sofort gestartet. 

– Kombinationen, 

in der Regel aus Zeitsteuerung und Ereignissteuerung. 

z.B.: Job soll nach 20.00 Uhr starten, wenn bestimmte Datei vorhanden 

ist und ein definierter anderer Job erfolgreich beendet ist. 



3.3.1.4 Single Point of of Service 

• In heterogen Rechner- und Systemwelten strebt man natürlich an 

alle Jobs, und damit auch alle Schnittstellen, zentral zu definieren 

und zu steuern. 

• Damit kommt man dem „Single Point of Service“ schon näher. 



3.3.1.5 Wiederanlauf von Jobs 

• Bricht ein einzelner Job ab, ist der Wiederanlauf im voraus genau zu 

definieren. 

• Gehen wir von folgendem einfachen Beispiel aus: 

– eine komplette Tabelle wird in ein System eingespielt. 

Step 1 - Prüfen 

Datei, ob Daten 

komplett 

Step 2 - Löschen 

Tabelle in DB 

Step 3 - 

Einpflegen in DB 

aus Datei 

Step 4 - Index 

anlegen 

Index Löschen 


Quellsystem 

Schnittstelle 

Wiederanlauf 

Transaktionen 


Übersicht 


Jobs 


Steuerung 

(Jobs) 


Daten 

• Steuerung 


• Protokoll 


Daten 

Schnittstelle 

Zielsystem 



3.3.2 Steuerung und Plausibilisierung 

• Für die Steuerung der Jobabläufe sowie evtl. Recovery-Maßnahmen 

sind Informationen notwendig, die von der eigentlichen Jobsteuerung 

angezogen werden. 

• Steuerparameter werden von den Schnittstellenprogrammen 

benötigt. Dies sind z.B. Verarbeitungszeiten (von-bis Datum). 

• Die Schnittstellenprogramme haben die Notwendigkeit strukturiert 

bestimmte Laufergebnisse abzulegen. Dies sind z.B. Satzzähler. 

• Regeln für die nachträgliche Plausibilisierung von Schnittstellenläufen 

werden zentral abgelegt. 




• Grundlage einmalige Definition je Prozess: 

– Hier wird detailliert definiert, welche Jobs für einen bestimmten Prozess 

bzw. bestimmte Schnittstelle in welcher Reihenfolge durchgeführt 

werden müssen. 

– Für jeden Job sind die Recovery-Maßnahmen zu definieren. 

• Planung für jede Durchführung (automatisch oder manuell 

anstoßen: 

– Aus den definierten Grundlagen wird für einen speziellen Lauf die 

Ablauflogik mit allen Steuerungsparametern generiert. 

– Hierbei werden auch eindeutige Identifikationen, z.B. Job-Ids vergeben. 

– Die vorhandenen Regeln werden umgesetzt oder für „Spezialitäten“ 

angepasst. 




• Jobplanungen 

Beispiel: 

Übernahme der Rechnungspositionen aus dem Inland ins VKB 

(Ursprungssystem: INL, Datenquelle: VKB-Positionen) 

URSPRUNGS DATENQUELLE ZIELSYSTEM DEAKTIVIERT Keine Aufträge 

SYSTEM 

generieren 

INL VKB-Positionen AUDIUS Anforderungen Download 

INL VKB-Positionen VKB Vertrieb 

INL VKB-Positionen WALIS X 

• Erstellung der Jobaufträge 

Beispiel: 

Import-Job-ID: 3506 

DATENQUELLE ZIELSYSTEM URSPRUNGS 

SYSTEM 

VKB-Positionen AUDIUS Anforderungen 

Download 

IMPORT 

_JOB_ID 

IMPORT_JOB 

_ID_DATUM 

IMPORT 

_JOB_ID 

_ZEIT 

EXPORT_ 

JOB_ID 

STATUS 

INL 3506 19990618 050838 offen 

VKB-Positionen VKB Vertrieb INL 3506 19990618 050838 offen 



3.3.2.2 Parameter für Schnittstellenprogramme 

• Die Steuerparameter für Schnittstellenläufe werden in der Regel von 

den Fachbereichen, die für die betreffenden Prozesse in den Quellbzw. 

Zielsystemen verantwortlich sind, gepflegt. 

• Eine Ablage dieser Parameter in XML hat sich bewährt, da hier nicht 

für jede Schnittstelle die Struktur der Parameter in der Datenbank 

abgebildet werden muss. 

• Damit ist es auch einfacher, die Parameter in das entsprechende 

Schnittstellenprogramm zu übergeben (ein String). 

• Dieser XML-String sollte dann auch als Protokolleintrag protokolliert 

werden. Auch hierfür ist der Programmieraufwand niedrig, da dies 

vereinheitlicht werden kann. 



3.3.2.3 Strukturierte Laufergebnisse 

• Unter strukturierten Laufergebnissen versteht man: 

– Satzzähler 

– Kontrollsummen 

– Zuletzt verarbeitete ID 

– Aufsetzpunkte (für evtl. Recovery) 

– u.s.w. 

• Auch hier ist eine Ablage in XML sehr günstig, da die Strukturierungen 

für diese Laufergebnisse in der Datenbank entfallen. 




• Nach Beendigung eines Jobs oder nach Beendigung einer 

Jobabfolge wird von der Jobsteuerung automatisch die Plausibilität 

geprüft. 

• Dies könnte z.B. ein Vergleich von Satzzahlen sein (Sätze aus Job 1 

./. Sätze aus Job 3 = Sätze aus Job 5). 

• Entsprechend des Ergebnisses dieser Prüfung kann z.B. die weitere 

Job-Folge variiert oder in der Protokolldatei der Fehler-Status entsprechend 

gesetzt werden. 




• Grundlage einmalige Definition je Schnittstelle: 

– Hier werden die Plausibiltätsprüfungen definiert und die daraus 

folgenden Aktivitäten festgelegt. 

• Planung für jede Durchführung (automatisch oder manuell) 

anstoßen: 

– Die vorhandenen Regeln werden aktiviert oder für „Spezialitäten“ 

angepasst. 


Quellsystem 

Schnittstelle 

Wiederanlauf 

Transaktionen 


Übersicht 


Jobs 


Steuerung 

(Jobs) 


Daten 

• Steuerung 


• Protokoll 


Daten 

Schnittstelle 

Zielsystem 



3.3.3 Protokollierung --Monitoring Monitoring 

• Für die Protokollierung von Schnittstellen ist besonders relevant: 

– Protokollmedium 

– Protokolleinträge 

– Protokollsprache 

– Protokollierungstiefe 

– Eskalierung. 




• Unter Protokoll-Medium ist der Ort der Protokoll-Speicherung 

gemeint: 

– In der entsprechenden Datenbank. 

Dies kann zu Verlust von Protokolleinträgen führen, wenn die 

Datenbank Probleme hat. Es tritt z.B. ein Datenbankfehler auf, der nicht 

mehr in der Datenbank protokolliert werden kann. Vorsicht auch bei 

Rollback-Auslösungen, damit nicht auch die Protokolleinträge 

zurückgesetzt werden. 

– Im Filesystem des Rechners/Servers. 

Hier ist die Speicherung vollkommen unabhängig vom Transaktionshandling. 

Aufwand für Programmierung ist etwas aufwendiger. Fehlerzustände 

des Filesystems können problematisch werden. In Ausnahmezuständen 

ist evtl. eine Synchronisation zwischen Datenbank und 

Protokoll notwendig. 




– In eigenem Server, evtl. auf eigenem Rechner. 

Zu beachten ist hierbei, dass zwei Systeme gleichzeitig funktionieren 

müssen. 

Hier ist jedoch eine echter „single point of Service“ möglich, da viele 

Systeme mit einem solchen Protokoll-Server abgedeckt werden können. 

– Kombinationen. 

Üblich sind Kombinationen aus Speicherung in eigener Datenbank und 

Speicherung ins Filesystem, wobei letzteres oft nur als Ausnahmeregelung 

bei Datenbankproblemen genutzt wird. 




• Welche grundsätzlichen Informationen sollten in Protokoll 

eingetragen werden? 

– Fehler. 

Selbstverständlichkeit! 

Detaillierte Fehlerbeschreibung mit allen zur Verfügung stehenden 

Informationen. 

Auch evtl. Korrekturmaßnahmen und die Weiterführung des Prozesses 

sind zu protokollieren. 

Wichtig für die Eskalierung ist die Fehlerschwere, siehe auch Attribute. 

– Warnung. 

Die Trennung zwischen Fehler und Warnung hat Tücken. Als Warnung 

sollten nur Einträge deklariert werden, die nicht zum Verlust von 

Informationen führen. 

Letztendlich muss bei der Organisation der Schnittstelle und Festlegung 

der Plausibilität dies festgelegt werden. 




– Hinweise. 

z.B. Beginn - Ende der Verarbeitung. Hier können aber auch alle 

verarbeiteten Informationen (evtl. auszugsweise) protokolliert werden. 

Wenn dann noch Fallunterscheidungen protokolliert werden, ist dies als 

als wesentliche Testhilfe zu sehen. Im Produktivbetrieb natürlich 

hauptsächlich bei Fehlersituationen zu gebrauchen. 

– Korrekte Verarbeitung. 

Überschneidet sich teilweise mit Hinweisen. Zusätzlich ist aber noch 

über einen Status (siehe Attribute) die insgesamt korrekte Verarbeitung 

zu protokollieren. 



3.3.3.3 Protokoll-Sprache 

• Protokollsprache: 

– Festgelegte Projektsprache, z.B. Deutsch oder Mehrsprachigkeit über 

entsprechende Protokolltexttabellen. Siehe hierzu auch Fehlertexttabellen. 

– Abspeicherungs-Code: 

• HTML 

• XML 

• Ascii 

• ... 



3.3.3.4 Protokollierungs-Tiefe 

• Parallel zu den Protokolleinträgen (Fehler, Warnung u.s.w.) ist ein 

Protokoll-Level zu empfehlen. 

– Alle Einträge werden einem Level zugeordnet, 

z.B. Fehler Level 1, Warnung Level 2, Hinweis Level 3, Korrekte 

Verarbeitung Level 1. 

– Beim Einsehen des Protokolls kann dann durch Selektion des Levels 

die Detaillierung gesteuert werden. 

– Im Level 3 gemäß obigem Beispiel werden dann aber auch Level 1 und 

2 mit angezeigt. 

– Im Level 1 jedoch nur alle Level 1 - Einträge. 

– Level können ausgeprägter sein als die Protokolleintragsarten. 

z.B. kann unter Hinweisen ein Level für den Fachbereich und ein Level 

nur für den Programmierer eingesetzt werden. 

– Die Level sind im Projekt zu definieren. 



3.3.3.5 Eskalierung 

• Papier ist geduldig - irgend ein Eintrag in Protokolldatei ist es auch ! 

• Deshalb: 

– Mail-Versand. 

An definierte Personen wird im Fehlerfall ein Mail verschickt. 

– Alarmierung. 

Per SMS, Piepser, Automatischer Anruf, u.s.w. 

– Ampel. 

Durch Darstellung von Ampeln (rot, gelb, grün) in der Online-Ansicht 

des Protokolls kann sehr prägnant der Zustand dargestellt werden. 

– Systeme stoppen. 

Notfalls kann ein System automatisch gestoppt bzw. das Starten 

verhindert werden. 



3.3.3.6 Attribute 

• Folgende Attribute sollte ein Protokollsystem mindestens haben: 

– Bezeichnung Schnittstelle, System 

– Datum-Eintrag 

– Uhrzeit-Eintrag 

– Text 

– Status (Ampel) 

– Level 

– Protokollart 

– Fehlerschwere 

– Status Eskalation 



3.3.3.7 Protokollbeispiel 



3.3.3.8 Monitoring 

• Monitoring ist eine ausgeprägte Form des Protokolls, der 

Jobsteuerung und der Steuerung/Plausibilisierung. 

– Sehr wichtig ist eine bedienerfreundliche Oberfläche, d.h. alle Infos an 

einem Ort. 

– Planung integriert. 

– Schon während des Prozesses kann hier „beobachtet“ werden. 

– Durch Verknüpfung zur Jobsteuerung und der Steuerung/ 

Plausibilisierung ist hier der „single point of service“. 

– “Gutes Gefühl für Administrator” – nicht nur kein Fehler – sondern 

wirklich alles gelaufen und in Ordnung ! 

• Transparenz für Anwender: 

– Ist Schnittstelle bereits eingespielt ? 

Sind z.B. die Messreihen für einen Kunden bereits übertragen? 


Quellsystem 

Schnittstelle 

Wiederanlauf 

Transaktionen 


Übersicht 


Jobs 


Steuerung 

(Jobs) 


Daten 

• Steuerung 


• Protokoll 


Daten 

Schnittstelle 

Zielsystem 



3.3.4 Fehlerbehandlung 

• Fehlerarten: 

– Syntax- oder Compilierungsfehler. 

Diese Fehler sind früh zu erkennen und auszumerzen. 

– Spezielle Programmierfehler, die nicht zu Laufzeitfehlern führen. 

z.B. Endlos-Schleife, Programm scheint stehen zu bleiben, CPU- 

Auslastung sehr hoch. 

– Laufzeitfehler. 

Hier muss ein genau definierter Mechanismus angewendet werden. 

– Logische Fehler. 

Diese Fehler sind am schwersten zu finden. Evtl. nur durch gut 

organisierte Testverfahren festzustellen. 

• Im folgenden geht es hauptsächlich um Laufzeitfehler. 



3.3.4.1 Prinzip in in Programmen 

• Fehler immer entsprechend der Sprache abfangen und in geordnete 

Bahnen (einheitliches Fehlerhandling) leiten. 

• Sehr bedenklich ist z.B. in Visual Basic oder MS-Access der Befehl 

„on error resume next “ wenn nach dem nächsten Befehl keine 

Fehlerabfrage erfolgt, denn das bedeutet, dass alle Fehler einfach 

übergangen werden. 

• Sauberes Fehlerhandling z.B. in MS-Access siehe nächste Seite. 



3.3.4.1 Prinzip in in Programmen 

Public Function fkt_sys_initialisierung_projekt() 

Const CON_AKT_FKT_NAME = "fkt_sys_initialisierung_projekt" 

On Error GoTo err_fkt_sys_initialisierung_projekt 

fkt_sys_initialisierung_projekt = CON_FKT_FEHLER 

Funktionalitität 

ok_fkt_sys_initialisierung_projekt: 

fkt_sys_initialisierung_projekt = CON_FKT_OK 

exit_fkt_sys_initialisierung_projekt: 

Exit Function 

err_fkt_sys_initialisierung_projekt: 

eigene Fehlerabhandlung 

var_fkt_return_g = fkt_sys_allg_fehler(CON_AKT_FKT_NAME, Err, _ 

Err.Source & " & Err.Description) 

stop_fkt_sys_initialisierung_projekt: 

GoTo exit_fkt_sys_initialisierung_projekt 

End Function 



3.3.4.2 Regeln, Standardisierung/Normung 

• Fehlertexte in entsprechender Tabelle speichern. Damit ist auch 

relativ problemlos eine mehrsprachige Lösung zu erreichen. 

• In die Fehlertexte sollten aus dem Programmcode heraus Variable 

eingestreut werden können. Hierfür sind in den Fehlertexten 

Platzhalter vorzusehen. 

• Eine einheitliche Abhandlung der Fehler in eigenem Fehlermodul ist 

erstrebenswert. 

• Bei Aufruf von Funktionen ist mit Return-Codes zu arbeiten um 

Fehler in unteren Funktionen nach „oben“ weiter zu melden. 

• So gelangen Fehlerzustände bis in die höchste Steuerungsebene 

der Programme. 

• Diese Festlegungen am besten in einem entsprechenden 

Framework hinterlegen. 



3.3.4.3 Eskalierung von Fehlern 

• Eine Eskalierung von bestimmten systemweit relevanten Fehlern ist 

unerlässlich. 

• Dies kann zum Abbruch des momentan laufenden Programms 

führen und 

• geht evtl. bis zum Stopp des Gesamtsystems. 



3.3.4.4 Protokollierung von Fehlern 

• Bei Anwendung eines Frameworks bzw. einem eigenen 

Fehlermodul ist es sehr einfach, eine einheitliche Protokollierung 

aller Ausnahmezustände zu erreichen. 

• Fehler, die nicht protokolliert werden, sind in der Regel nicht mehr 

nachzuvollziehen. 

• Näheres “Protokollierung”. 


Quellsystem 

Schnittstelle 

Wiederanlauf 

Transaktionen 


Übersicht 


Jobs 


Steuerung 

(Jobs) 


Daten 

• Steuerung 


• Protokoll 


Daten 

Schnittstelle 

Zielsystem 



3.3.5 Fehlerhafte Daten 

• Alle von Schnittstellen als fehlerhaft abgewiesenen Informationen 

müssen gesichert gespeichert werden. 

• Eine (manuelle) Korrektur bzw. das Löschen dieser falschen Daten 

ist zu ermöglichen. 

• Eine Nachverarbeitung der korrigierten Fehler (Korrekturlauf) muss 

über die Jobsteuerung erfolgen. 



3.3.5.1 Speicherung 

• Die Speicherung der fehlerhaften Daten ist möglich in: 

– Dateien in Filesystem eines Servers. 

Hier ist darauf zu achten die Rechte so einzuschränken, dass 

Manipulationen nicht möglich sind. Die Konsistenz dieser Daten ist zu 

gewährleisten (z.B. entsprechende RAID-Systeme). 

– Datenbank. 

Hier ist ein sehr sicherer Ablageort. Der Speicherbedarf und das evtl. 

entstehende Logging ist abzuwägen. 



3.3.5.2 (Manuelle) Korrektur 

• Die fehlerhaften Daten müssen per Funktionalität von Programmen 

oder durch manuelle Korrektur korrigiert werden. 

• Eine Korrektur kann auch durch Verbesserungen im Quellsystem 

und erneutes versenden über die betreffende Schnittstelle erfolgen. 

Dieser Vorgang ist zu automatisieren und eine Löschung der 

fehlerhaften Daten zu ermöglichen. 

• Eine direkte Korrektur ist durch entsprechende Programme zu 

ermöglichen. Der Aufbau der Schnittstellendaten muss dies bereits 

berücksichtigen: 

– Spaltentrennung durch Trennzeichen, dann ist Korrektur z.B. durch 

EXCEL sehr leicht möglich. 

– Weitergehende Möglichkeiten durch XML. 



3.3.5.3 Korrekturlauf 

• Durch die Jobsteuerung ist ein Korrekturlauf der vorher 

korrigierten Daten zu ermöglichen. Dies kann zu einem festgelegten 

Zeitpunkt oder mit dem nächsten regulären Schnittstellenlauf durch 

Datenzusammenführung erfolgen. 

Manchmal ist es auch richtig die fehlerhaften Daten aus dem 

vorherigen Lauf (egal ob korrigiert oder nicht) wieder im neuen Lauf 

mitzuverarbeiten. Es entsteht dadurch nur ein „Fehlertopf“. 

• Es kann auch notwendig sein, dass die Schnittstelle erst wieder 

starten kann, nachdem alle fehlerhaften Daten korrigiert und 

verarbeitet sind, d.h. Fehlertopf ist leer. 

• Auch aus einem Korrekturlauf müssen evtl. weiterhin fehlerhafte 

Daten wieder gespeichert werden, das Spiel geht von vorne los. 


Quellsystem 

Schnittstelle 

Wiederanlauf 

Transaktionen 


Übersicht 


Jobs 


Steuerung 

(Jobs) 


Daten 

• Steuerung 


• Protokoll 


Daten 

Schnittstelle 

Zielsystem 



3.3.6 Transaktionsverarbeitung 

• Auch bei Schnittstellenverarbeitung können Transaktionsmechanismen, 

die durch die verwendeten Datenbanken angeboten 

werden, sehr hilfreich sein. 

• Dies ist besonders dann notwendig, wenn für die Schnittstellenläufe 

kein sogenanntes „Batch-Fenster“ zur Verfügung steht und die 

eingespielten Daten auch Online verändert werden können. 



3.3.6.1 Definition Transaktion 

• Eine Transaktion kapselt die Veränderung an Daten gegenüber 

anderen Prozessen für einen definierten Zeitraum. 

• Warum ist dies notwendig ? 

Prozess A: 

Änderung 

Änderung 

Änderung 

Zurücksetzen 

Zurücksetzen 

Ende Prozess 

Tabelle X 

Zeile 1 

Zeile 2 

Zeile 3 

Zeile 4 

Zeile 5 

Zeile 6 

Zeile 7 

Zeile 8 

Prozess B: 

Änderung 

Änderung 

Ende Prozess 

12.02.2007 PTA GmbH, Unternehmensberatung 68 

t


3.3.6.2 Grenzen des Transaktionshandlings 

• Damit eine Datenbank Transaktionen abbilden kann, muss in einer 

Log-Datei die Zeile jeweils vor und nach einer Änderung gespeichert 

sein. Die Größe der Log-Datei ist deshalb u.a. eine Grenze für das 

Transaktionshandling. 

• Die geänderten Zeilen müssen in einem Zwischenbereich bis zum 

Ende der Transaktion gespeichert sein, da sie erst dann in die 

Datenbank geschrieben werden. Dieser Zwischenbereich ist 

natürlich auch begrenzt. 

• Bei vielen Änderungen in einer Transaktion sind auch viele Zeilen 

gesperrt, dies kann natürlich einen Performanceverlust der 

Datenbank bedeuten. 


Quellsystem 

Schnittstelle 

Wiederanlauf 

Transaktionen 


Übersicht 


Jobs 


Steuerung 

(Jobs) 


Daten 

• Steuerung 


• Protokoll 


Daten 

Schnittstelle 

Zielsystem 




• Alle vorgenannten Aspekte müssen in SP berücksichtigt werden, 

deshalb ist Fehleranfälligkeit hier sehr hoch und schmerzhaft. 

• Beliebtes Thema: 

Sollen bereits in Vorsystemen verifizierte Daten nochmals verifiziert 

werden? Aus langjähriger Erfahrung: Ein klares „Ja“. 

Sie werden erstaunt sein, wie oft sich dies in der Praxis bewährt. 

• Logisch oder physisch löschen? 

Es kann auch Fälle geben, in den ein sofortiges physisches Löschen 

notwendig ist. Wenn es sich vermeiden lässt, bitte logisch löschen. 

Stellen Sie sich folgendes Szenario vor: 

Vorsystem kennt logisches Löschen. Aus „Versehen“ werden im 

Vorsystem durch Anwender Informationen gelöscht. Über die 

Schnittstelle kommt Löschanweisung. Löschung wird durchgeführt. 

Fehler wird im Vorsystem erkannt, kein Problem „Wiederaufleben 

lassen“. Und Ihr System - kennt es Wiederaufleben lassen ? 




Noch Noch besser ist ist natürlich, sie haben ein sauberes Historienkonzept. 

Hiermit ist es z.B. möglich, irgend einen Stand Stand aus der der 

Vergangenheit zu rekonstruieren. 

z.B.: Energiebedarfsprognose für für bestimmtes Netz für 

Januar/Vorjahr. 

• Wie löst man Schnittstellen im Quellsystem aus? 

Beliebt ist es, diese über Trigger auszulösen. Es finden dann in den 

Datenbanken richtige „Trigger-Feuerwerke“ statt. Der Anwender 

weis dann oft gar nicht, was er mit einem Tastendruck in Folgesystemen 

auslöst. 

Da Trigger zeilenbezogen sind, müsste zumindest im Trigger geprüft 

werden, ob schnittstellenrelevante Spalten verändert wurden. 

Außerdem sollte nicht jede Änderung einen Schnittstellensatz auslösen. 

Für bestimmten Zeitraum sollte auch bei mehreren Änderungen 

nur eine Sammeländerung über die Schnittstelle gehen. 




• Die falsche Reihenfolge und die Vollständigkeit von Daten oder das 

Erkennen mehrfach vorkommender Daten ist oft mit ganz einfachen 

Mitteln sicherzustellen: 

– Fortlaufende Nummer. 

Wird in Quellsystem vergeben und im Zielsystem wird verifiziert, ob 

Daten in richtiger Reihenfolge, lückenlos oder evtl. mehrfach vorhanden 

sind. 

– Timestamp. 

Auch hier wieder Prüfung in Zielsystem. Die Lückenlosigkeit ist hier 

schon problematisch. Bei Datenaufkommen von mehreren Tausend pro 

Sekunde (z.B. Überwachung von kerntechnischen Anlagen) ist auch die 

Reihenfolge nicht mehr per Timestamp zu erreichen. 

Erinnert sei hier auch an die Problematik, dass es einen Tag im Jahr mit 

23 Stunden (shortday) und einen Tag mit 25 Stunden (longday) gibt. 


Quellsystem 

Schnittstelle 

Wiederanlauf 

Transaktionen 


Übersicht 


Jobs 


Steuerung 

(Jobs) 


Daten 

• Steuerung 


• Protokoll 


Daten 

Schnittstelle 

Zielsystem 



3.3.8 Wiederanlauf nach Störung 

• Abgrenzung: Hier geht es nicht um Jobs - sondern um die Störung 

der Schnittstellenservices. 

• Beispiel für Störung: 

Quellsystem 

Steuerung 

Steuerung 

(Fortschritt) 

Zielsystem 

Onlinebetrieb 




• Problem: Steuerungsinformationen für Schnittstellenservices sind 

nicht mehr parallel zu den durchgeführten Änderungen im 

Zielsystem, d.h. es ist nicht mehr aufgezeichnet, welche 

Schnittstellendaten bereits eingespielt sind. 

• Dieses Problem kann entschärft werden, wenn z.B. das Zielsystem 

so ausgelegt ist, daß Schnittstellendaten problemlos mehrfach 

eingespielt werden können. 

• Auch eine Lösung wäre, die Steuerungsinformationen mit im 

Zielsystem abzulegen und diese Informationen mitzuverarbeiten. 

• Wichtig: Bei Konzeption von Systemen müssen solche Probleme 

organisatorisch und technisch bedacht und gelöst werden. 




• Bei Standardsoftware, die nicht selbst erstellt wurde, gibt es keinen 

Einfluss auf das Schnittstellendesign und die Integration ins 

Gesamtsystem. 

• D.h.: Recovery-Maßnahmen müssen so geplant werden, dass sie 

abgestimmt sind auf alle Schnittstellen des Gesamtsystems. 

• Der „größte anzunehmende Unfall“ (GaU) muss bedacht, geplant 

und verifiziert sein. 

• Als GaU in der Datenverarbeitung kann man den Verlust von Daten 

bezeichnen. 

• GaU kann auf dem Quell-, Ziel- oder Steuerungssystem vorkommen. 



3.3.8.2 Plan für „GaU“ 

• Alle Recovery-Maßnahmen sind in einem entsprechenden Betriebshandbuch 

zu definieren. 

• Unter vielem anderen muss darin festgelegt sein: 

– Kriterien für die einzelnen Schnittstellen, insbesondere für Recovery- 

Maßnahmen. 

– Zuständigkeiten/Verantwortungen und Befugnisse (incl. Vertretungsregelungen): 

• technisch 

• fachlich 


Quellsystem 

Schnittstelle 

Wiederanlauf 

Transaktionen 


Übersicht 


Jobs 


Steuerung 

(Jobs) 


Daten 

• Steuerung 


• Protokoll 


Daten 

Schnittstelle 

Zielsystem 



3.9 Betriebshandbuch 

• Dass Schnittstellenservices ohne Betriebshandbuch nicht betrieben 

und gesteuert werden können, dürfte unumstritten sein. 

• Hervorzuheben ist, dass es in einem heterogenen Umfeld ein 

Betriebshandbuch, in dem alle Schnittstellen zusammengefasst 

sind, geben sollte. Es kann nicht angehen, dass erst bei einem 

Problem mit einer Schnittstelle in mehreren Handbüchern die 

Informationen gesucht werden müssen. Vielleicht findet man Sie 

dann auch unter Zeitdruck, evtl. auch nicht. 



3.9 Betriebshandbuch (Beispiel) 

1 Abkürzungen ........................................................................................................ 4 

2 Einleitung.............................................................................................................. 5 

3 Configuration Management .................................................................................. 6 

3.1 Systemhardware............................................................................................. 6 

3.2 Systemsoftware .............................................................................................. 6 

3.3 Verzeichnisse, Freigaben und FTP-Zugriffsmöglichkeiten.............................. 7 

3.4 Schnittstellen-User und deren Berechtigungen............................................... 7 

3.5 Benutzergruppen innerhalb der Applikation.................................................... 7 

3.6 ODBC - Datenquellen ..................................................................................... 9 

3.7 Netzwerkanbindung ...................................................................................... 10 

3.8 Bestehende Verfahren Configuration Management...................................... 10 

3.9 Zuständigkeiten Configuration Management ................................................ 10 

4 Operation Management...................................................................................... 11 

4.1 Datacenter .................................................................................................... 11 

4.2 Fachbereich.................................................................................................. 12 

4.3 Bestehende Verfahren Operation Management ........................................... 13 

4.4 Zuständigkeiten Operation Management:..................................................... 13 

5 Performance Management ................................................................................. 14 

5.1 Mittel der Performanceüberwachung ............................................................ 14 

5.2 Wartungsarbeiten / -fenster .......................................................................... 15 

5.3 Ungeplante Ausfälle...................................................................................... 15 

5.4 Bestehende Verfahren Performance Management....................................... 15 

5.5 Zuständigkeiten Performance Management: ................................................ 15 

6 Problem Management ........................................................................................ 16 

6.1 Problem Management - Workflow................................................................. 16 

6.2 Fehlerprioritäten............................................................................................ 16 

6.3 Zuständigkeiten Problem Management ........................................................ 17 

7 Assets Management........................................................................................... 18 

7.1 Sicherheit auf Betriebssystemebene (NT) .................................................... 18 

7.2 Sicherheit auf Datenbankebene (MSSQL-Sever) ......................................... 18 

7.3 Sicherheit auf Applikationsebene (Clarify) .................................................... 18 

7.4 Datenschutz.................................................................................................. 19 

7.5 Zuständigkeiten Assets Management........................................................... 19 

8 Change- und Release Management................................................................... 20 

8.1 Change Management ................................................................................... 20 

8.2 Release Management................................................................................... 21 

9 Literaturverzeichnis............................................................................................. 22 



4. 4. Schnittstellen --Gestern, Gestern, heute, morgen 

• An drei Beispielen soll die Vergangenheit (bei vielen noch 

Gegenwart) und die heute eingesetzte Technik dargestellt werden: 

– Steuerung und Verarbeitung in Quell- und Zielsystem. 

– Steuerung in eigenem Server – Verarbeitung in Quell- und Zielsystem. 

– Steuerung und Teile der Verarbeitung in eigenem Server 

• Ein Blick in die berühmte Glaskugel. 



4.1 Steuerung und Verarbeitung in in Quell- und 

Zielsystem 

• Die Verarbeitung und die Steuerung der Schnittstellen wird 

ausschließlich im Quell- bzw.. im Zielsystem durchgeführt. 

• Zwischen den Systemen werden ausschließlich Daten übergeben: 

– Eigentliche Rohdaten, z.B. Überweisung mit entsprechenden Feldern, 

– Steuerinformationsdaten wie z.B. Anzahl Überweisungen, Checksummen. 

Quellsystem: 

Erstellt DTA - 

File 

(Überweisungen, 

Steuerinfos) 

Zielsystem bei 

Bank: 

Verarbeitet DTA - 

File 



4.2 Steuerung in in eigenem Server – Verarbeitung in in 

Quell- und Zielsystemen 

• Die Steuerung findet in einem eigenen Server statt. 

• Beliebig viele Quell- und Zielsysteme (auch unterschiedliche 

Architekturen) können gesteuert werden. 

• Die Verarbeitung der Schnittstellen wird ausschließlich in Quellbzw. 

im Zielsystemen durchgeführt (auch Plausibilität ). 

• Zwischen den Systemen werden ausschließlich Daten übergeben: 

– Eigentliche Rohdaten, z.B. Überweisung mit entsprechenden Feldern, 

– Steuerinformationsdaten wie z.B. Satzzahlen, Checksummen. 

• Steuerung registriert nur den Erfolg der Verarbeitungsdurchführung 

(Job-Returncode). 



4.2 Steuerung in in eigenem Server – Verarbeitung in in 

Quell- und Zielsystemen 

MVS-System Unix-System 

NT-System 



4.3 Steuerung und Teile der Verarbeitung in in eigenem 

Server 

• Die Steuerung findet in einem eigenen Server statt. 

• Teile der Verarbeitung finden durch den Steuerungsserver statt. 

• Beliebig viele Quell- und Zielsysteme (auch unterschiedliche 

Architekturen) können angeschlossen sein. 

• Steuerung prüft neben der Kontrolle des Erfolgs der Verarbeitungsdurchführung 

(Job-Returncode) auch Kontroll-Plausibilitäten. 

• Beispiel: 

– Projekt: „Generalschnittstelle“. 

– Branche: Pharma, Baden Württemberg. 



4.3 Steuerung und Teile der Verarbeitung in in eigenem 

Server --Beispiel Beispiel 

Generalschnittstelle 

Inland 

ORACLE- 

Datenbank 

SAP R/3 – Inland 

Aufträge 

Lieferungen 

Rechnungen 

Export zu verschiedenen Systemen ... 

Rechnungen 

SAP R/2 – Ausland 

z. Z. nur 

Rechnungen 

Generalschnittstelle 

Ausland 

Stammdaten 

Werk 1 Werk 2 Import von verschiedenen 

Systemen ... 



4.4 Ausblick 

• Schnittstellenrechner übernehmen Geschäftsprozesssteuerung von 

Systemen. 

Voraussetzung: Atomare/granulare Schnittstellengestaltung. 

– Business-Objekte (OO) können hierbei sehr hilfreich sein. 

• Business to Business (B2B) - Verbindungen: 

– Vom Papier, 

– über EDI zu 

– Web-Services. 

Schauen Sie selbst in die Glaskugel !!! 



5. 5. Tipps 

• Führendes System bestimmen. 

• Bei gleichberechtigten Systemen über Replikation der 

entsprechenden Tabellen nachdenken. 

• Bei kleineren Datenmengen über kpl. Übernehmen nachdenken. 

• Wenn möglich „Batch-Fenster“ für Schnittstellen einsetzen. 

• Nach Möglichkeit Steuerung außerhalb Quell- und Zielsystem. 

• Jobs möglichst als Single-Step definieren und lieber Job-Netze 

aufbauen. Damit sind auch parallele Schritte möglich. 

• Ereignisgesteuerte Jobs sind rein zeitgesteuerten Jobs vorzuziehen. 

• „Single Point of Service“ und Monitoring anstreben. 

• KIS - Keep it simple. 

• Für jeden Job Recovery-Maßnahme definieren. 

• Schnittstellenservices einrichten. 



5. 5. Tipps 

• Wenn möglich XML benutzen. 

• Plausibilisierungsschritte definieren. 

• Protokollierung einsetzen. 

• Level für Protokollierung nutzen. 

• Eskalierung bei Fehlern aufsetzen. 

• Fehlerbehandlung standardisieren. 

• Framework für Entwicklung aufsetzen. 

• Konzept für fehlerhafte Daten entwickeln. 

• Transaktionsverarbeitung sinnvoll einsetzen. 

• Wenn möglich Daten verifizieren. 

• Logische Löschung bevorzugen. 

• Historienkonzept in Betracht ziehen. 

• Konzept für Auslösung von Schnittstellen, nicht alles in Trigger 

packen. 



5. 5. Tipps 

• Störung der Schnittstellenverarbeitung einplanen. 

• GaU-Behebung planen. 

• Betriebshandbuch erstellen und pflegen. 

• Behebung von Störungen testen. 

• Schnittstellen möglichst atomar anlegen. 

• System-Stopp-Möglichkeit implementieren, Spezialisten haben noch 

Zugriff. 

• Rücknahme von Änderungen und Löschungen sind als 

Recoverymaßnahme evtl. notwendig - analysieren! 

• Transparenz über Datenstand (ist Schnittstelle gelaufen ?) für 

Anwender herstellen, d.h. solche Fragen in Gesamtsystem 

integrieren. 

• Prüfen, ob DB-Snapshots zur Lösung in Frage kommen 



Geschafft ! 

!

PTA_SchnittstellenProgrammierung_Einfuehrung.pdf - PTA GmbH

Erfolgreiche ePaper selbst erstellen

Template löschen?

Als Template speichern?