Wie geht's weiter?

eXTra hat sich in der Praxis bewährt und kommt insbesondere in komplexen Datenaustauschsystemen mit Massendaten zum Einsatz. Neben der Pflege, Weiter- und Neuentwicklung der Schemadateien (Nachrichten, Plug-Ins und Profilkonfiguration) besteht eine wesentliche Aufgabe in der Unterstützung potentieller Anwender, z.B. durch entsprechende Werkzeuge. Da eXTra ein konsequent offener Standard ist, werden Wünsche und Anforderungen gerne entgegengenommen.

In der neuen Version von eXTra (Version 1.5) gibt es zwei wesentliche Erweiterungen : Zum einen die Möglichkeit, das Transportgut auf der untersten eXTra-Ebene zu strukturieren. Zum anderen ist eine Erweiterung um die neue Standardnachricht "RepeatResponseRequest" eingefügt. Mit dieser wird eine vereinfachte Implementierung des vollautomatischen Betriebs für den Fall eröffnet, dass in einem eXTra-Sendeprozess die eXTra-Response der Serverseite mittels Acknowledgement ausgeblieben ist.

Die neue Strukturierungsmöglichkeit des Transportguts

Auf der untersten eXTra-Ebene (Transport-, Paket- oder Nachrichten-Ebene) kann man jetzt nicht nur eine einzige fachliche Nachricht übermitteln, sondern in einem DocumentSet beliebig viele Dokumente in beliebigem Format. Ob dabei die Dokumente eines DocumentSet in einer spezifischen Beziehung zueinander stehen, wie z.B. bei einem Hauptdokument mit seinen Anhängen, oder lediglich eine gewisse Ansammlung von Dokumenten darstellen, bleibt dem jeweiligen Datenübermittlungsverbund überlassen. Das bisherige Konstruktionsmerkmal, das zu einer fachlichen Nachricht auch Funktionen (Komprimierung, Verschlüsselung, Signatur) definiert und mit dem über PlugIns weitere Metadaten (wie bisher mit den PlugIns DataTransforms, DataSource und Contacts sowie jetzt zusätzlich mit dem neuen PlugIn BusinessProcess) mitgegeben werden können, wird verallgemeinert und auf jedes Dokument eines DocumentSet ausgedehnt.

Die neue Standardnachricht RepeatResponseRequest 

Mit dieser neuen eXTra-Standardnachricht geht eine Vereinfachung sowohl für die Client- als auch die Server-Seite einher. Die Clientseite muss nicht mehr den gesamten RequestTransportHeader vorhalten, um eine Wiederholung der ausgebliebenen eXTra-Response von der Server-Seite anzufordern, sondern kann jetzt - analog zur Standardnachricht DataRequest - über eine Query den unvollständigen Vorgang z.B. mittels RequestID definieren. Die Serverseite ihrerseits muss jetzt ebenfalls nicht mehr den kompletten RequestTransportHeader aufbewahren und zurückliefern, sondern nur noch - im Datenteil der eXTraResponse - die Pflichtteile des ursprünglichen RequestTransportHeaders, zusammen mit den ResponseDetails der ausgebliebenen Response.