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 nächsten Version von eXTra (Version 1.5) wird es zwei wesentliche Erweiterungen geben: Zum einen die Möglichkeit, das Transportgut auf der untersten eXTra-Ebene zu strukturieren. Zum anderen ist eine Erweiterung um die neue Standardnachricht "RepeatResponseRequest" geplant. 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 zukünftig 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, dass zu einer fachlichen Nachricht auch Funktionen (Komprimierung, Verschlüsselung, Signatur) definiert und über PlugIns weitere Metadaten (wie bisher mit den PlugIns DataTransforms, DataSource und Contacts sowie jetzt zusätzlich mit dem neuen PlugIn BusinessProcess) mit gegeben 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.