Allgemeines

Bei der Datenrückgabe der Backend-Programme an den oxaion JET Server gibt es verschiedene XML-Strukturen:

Außerdem können auf oberster Ebene unabhängig von der gewählten Struktur Fehler- bzw. Hinweismeldungen, Transaktion-Codes (<TCODE>), Bildschirmattribute usw. übertragen werden.

Strukturunabhängige Daten

Alle strukturunabhängigen Daten müssen vor der eigentlichen Datenstruktur übergeben werden. Eine Ausnahme stellen die Bildschirmattribute dar, die immer nach der Datenstruktur übergeben werden müssen.

Fehler

Ein evtl. aufgetretener Fehler ist über das <FCOD>-Tag zurückzugeben. Anhand des Fehlercodes in Verbindung mit den variablen Nachrichtendaten (<MDTA>) wird die Fehlermeldung ermittelt und dem Benutzer angezeigt. Wurde zusätzlich der Feldname (im Tag <FLDN>) mitgegeben, wird der Cursor in diesem Feld positioniert und die Lasche, auf der sich die Komponente befindet, in den Vordergrund geholt. Wird neben einem Fehler das <DTA>-Tag zurückgegeben, werden diese Daten auf das Panel eingestellt Natürlich nur dann, wenn die Ausgabedaten des Calls auch tatsächlich auf dem Panel abgestellt werden sollen.. Das <FCOD>-Tag muss immer vor dem <DTA>-Tag stehen.

Beispiel:

<PARM>
	<FCOD>U00001</FCOD>
	<FLDN></FLDN>
	<MDTA></MDTA>
	<DTA>
		<FELD1>Beispieldaten</FELD1>
		<FELD2>Inhalt Feld 2</FELD2>
	</DTA>
</PARM>

Hinweismeldungen

Es können beliebig viele Hinweismeldungen über das <MESSAGES>Tag ausgegeben werden. Die Hinweismeldungen werden vor den eigentlichen Daten übergeben, also z. B. vor dem <DTA> oder dem <TABLE>-Tag. Optional kann dem <MESSAGES>-Tag das Attribut TYPE mitgegeben werden. Über dieses Attribut wird gesteuert, was passieren soll, wenn der Benutzer den Hinweisdialog mit „OK" verlässt. Wird kein TYPE übergeben, wird bei „OK" die Verarbeitung fortgesetzt. Bei TYPE="AGAIN" wird der vorhergehende Call wiederholt, wenn der Hinweis-Dialog über „Abbrechen" verlassen wird, bricht die Verarbeitung sofort ab. Wird TYPE="INFO" übergeben, so erscheint ein Hinweisdialog, der ausschließlich eine Bestätigungstaste besitzt. Dieser Typ wird für Benachrichtigungen nach Abschluß einer Transaktion benutzt, bei denen ein Eingriff des Benutzers weder sinnvoll noch möglich ist.
Kurze Übersicht der 3 Messagetypen:

Beispiel:

<PARM>
	<MESSAGES TYPE="AGAIN">
		<MSG MCOD="ADR1907" MDTA="" />
		<MSG MCOD="ADR1907" MDTA="" />
		<MSG MCOD="ADR1907" MDTA="" />
		...
	</MESSAGES>
	<DTA>
		<FELD1>Beispieldaten</FELD1>
		<FELD2>Inhalt Feld 2</FELD2>
	</DTA>
</PARM>

Bildschirmattribute

Über Bildschirmattribute können Oberflächen-Komponenten zur Laufzeit verändert werden. Es ist möglich, Komponenten zu verstecken (H = hidden), zu sperren (P = protected) oder als Pflichfelder zur deklarieren (M = mandatory).
Innerhalb der Bildschirmattribut-Struktur wird der Feldname als Tag mit dem zugehörigen Bildschirmattribut übergeben.
Bildschirmattribute können entweder als einzelne Struktur oder nach der <DTA>-Struktur übergeben werden.
Ein Sonderfall der Bildschirmattribute ist das M-Attribut (=Pflichtfeld). Normalerweise werden Pflichtfelder über die UID-Verwaltung gepflegt. Nur in einigen Ausnahmefällen (z. B. Auskunftsprogramm-Treiber) steht das Pflichtfeld erst zur Laufzeit fest.
Beispiel:

<PARM>
	<DTA>
		<FELD1>Beispieldaten</FELD1>
		<FELD2>Inhalt Feld 2</FELD2>
	</DTA>
	<ATR>
		<KDNR ATR="P" />
		<FINR ATR="P" />
	<ADNR ATR="H" />
	</ATR>
</PARM>

Transaktions-Codes

Über Transaktions-Codes kann ein Backend-Programm den weiteren Verlauf einer Transaktion steuern. Z. B. könnte der vom Benutzer eingegebene Kunden-Alphamatchcode nicht eindeutig sein, worauf das Backend-Programm rückmelden muss, dass der Personenkonten-Matchcode aufgerufen werden soll. Oder das Erfassen einer Auftragsposition erfordert die zusätzliche Angabe von Sachmerkmalen. Für solche Transaktions-Steuerungen steht der Transaktions-Code (kurz T-Code) zur Verfügung. Jeder vom Backend-Programm verwendete Transaktions-Code muss in der entsprechenden XML-Datei via Transaction-Handler abgefragt werden, wenn individuell darauf reagiert werden soll. Ansonsten läuft der T-Code ins Leere. Z. B. muss in der XML-Datei definiert werden, dass bei dem Transaktions-Code „ERF-SACHMERKMAL" die Sachmerkmalsverwaltung als modaler Dialog geöffnet werden soll. Eine Ausnahme bildet der Transaktions-Code „*MC", der auch ohne explizite Angabe in der UID-XML gültig ist und einen Matchcode als modalen Dialog öffnet.
Wenn neben dem Transaktions-Code noch eine Daten-Struktur (also z. B. DTA, TABLE ...) übergeben wird, werden zuerst die dort enthaltenen Daten eingestellt bzw. allgemeiner formuliert: für die weitere Verarbeitung verwendet.
Beispiel:

<PARM>
	<TCODE>ERF_SACHMERKMAL</TCODE>
	<DTA>
		<FELD1>Beispieldaten</FELD1>
		<FELD2>Inhalt Feld 2</FELD2>
	</DTA>
</PARM>

XML Struktur DTA

Über das <DTA>-Tag kann eine Schlüssel/Wert-Sturktur an den JET-Client übergeben werden. Das <DTA>-Tag eignet sich deshalb für das Einlesen eines Datensatzes.
Besonderer Bedeutung kommt dem Tag <TITLE> zu, dessen Inhalt im Programmreiter als Titel des Programmes eingestellt wird. 

Beispiel:

<PARM>
	<DTA>
		<NAME>Beispieldaten</NAME>
		<TITLE>Beispiel für RumpfdatenXML</TITLE>
		<FLD1>Inhalt eins</FLD1>
		<FLD2>Inhalt zwei</FLD2>
		...
	</DTA>
</PARM>

XML Struktur TABLE

Über das <TABLE>-Tag können Tabellen (Daten für Auflistungen der Form Zeile/Spalte) zurückgegeben werden. Tabellen werden im Regelfall nicht komplett eingelesen, sondern bei Bedarf „nachgeladen". Der erste Lesevorgang der Tabelle muss das <HEADER>-Tag beinhalten, in dem jede Spalte definiert werden muss.
Soll die Tabelle variable Sichten enthalten, so muss für jede Zeile die Spalten aller Sichten zurückgeliefert werden.
Im <HEADER> werden die einzelnen Spalten so definiert, dass sie der XML-Notation der Komponenten aus den XML-Maskenbeschreibungen gleichen.
<TABLE>

<HEADER>

<SIGHT>

<ROW>

<KEY>

<COLUMN>
Die Bedeutung und Verwendung der Angaben einer COLUMN entspricht denen des <component>-Elementes einer XML-Maskenbeschreibung und ist dort nachzuschlagen.

Beispiel:

<TABLE>
	<HEADER NbrSights="1" Title="FRD110">
		<SIGHT>
		<COLUMN>
			<NAME>KOBENR</NAME>
			<TYPE>A(11)</TYPE>
		</COLUMN>
	</SIGHT>
	</HEADER>
	<ROW>
		<KEY>
			<CRLS>2323</CRLS>
			<CRFM>EKOPFR</CRFM>
		</KEY>
		<KOBENR>Text Spalte eins</KOBENR>
	</ROW>
	<STOP />
</TABLE>

XML Struktur TREE

Über das Tree-Tag kann eine Baumstruktur an den JET-Client zurückgegeben werden. Jedes Element verfügt über eine variable Sicht, einen Schlüssel und unter Umständen über Child-Elemente.
Besondere Bedeutung kommt dem Tag <KEYTYPE> innerhalb des Schlüssels zu, da über dieses Tag der Typ des Baumelementes definiert wird. In der XML-Datei kann z. B. hinterlegt werden, dass alle Baumelemente mit dem KEYTYPE „M_POS" ein spezielles Icon erhalten, bzw. welche Popup-Menüs für dieses Element gültig sind.
Das Einlesen des Baumes erfolgt im Regelfall nicht komplett sondern bei Bedarf. Zu Beginn wird das oberste Vaterelement mit einer passenden Anzahl an Kindelementen auf erster Ebene eingelesen. Scrollt der Benutzer nach unten, erfolgt ein Weiterlesen auf erster Ebene. Beim Öffnen eines Kindelementes erfolgt das Einlesen der Elemente der zweiten Ebene, wobei auch dies nicht komplett, sondern Blockweise erfolgt. Um identifizieren zu können, ob ein Baumelement Kindelemente enthält, die nur noch nicht eingelesen wurden, wird dem Element das Attribut SUBTREES="TRUE" mitgegeben.
Um Baumelementen Kindelemente zuzuordnen, wird das <CHILDREN>-Tag verwendet. Wurden alle Kindelemente der Ebene eingelesen, muss das <STOP />-Tag übergeben werden.
Der im <VASI>-Tag übergebene String wird zur Darstellung des Tree-Knotens im Client verwendet. Der Text wird dabei vom Server aus den jeweiligen EXPLORER-Sichten zusammengebaut und dem Client übergeben. Sofern die Sicht mehrere Sichtnummern hat enthält der String |-Zeichen (Pipe-Zeichen). Diese werden vom Client in Zeilenumbrüche übersetzt, wodurch es möglich ist Tree-Knoten mehrzeilig anzuzeigen.
<TREE>

<CHILDREN>

<KEY>

Beispiel:

<TREE SUBTREES="TRUE">
	<KEY>
		<KEYTYPE>A</KEYTYPE>
		<KE>001</KE>
	<KEY>
	<CHILDREN>
		<TREE>
			<KEY>
				<KEYTYPE>P</KEYTYPE>
				<FFMT>AK</FFMT>
			</KEY>
			<VASI>Informationen</VASI>
		</TREE>
		<TREE SUBTREES="TRUE"> <!—Element enthält Kindelemente,->
			<KEY> <!—die bei Bedarf eingelesen werden->
				<KEYTYPE>P</KEYTYPE>
				<FFMT>A2</FFMT>
			</KEY>
			<VASI>Informationen 2</VASI>
		</TREE>
		<TREE>
			<KEY>
				<KEYTYPE>P</KEYTYPE>
				<FFMT>A3</FFMT>
			</KEY>
			<!-- Element soll mehrzeilig angezeit werden -->
			<VASI>Information 3.1|Information 3.2</VASI>
		</TREE>
		<STOP />
	</CHILDREN>
</TREE>

XML Struktur CHART

Über das <CHART>-Tag werden Charts übergeben.
Die Struktur gliedert sich in den HEADER- und den VALUES-Bereich. Der HEADER-Bereich definiert die Punkte der Y-Achse (bzw. bei der Anzahl von Ausprägungen je X-Wert bei Multi-Charts) während im VALUES-Bereich die X-Achsen-Definition und die Ausprägungen übergeben werden. Die Position einer Merkmalsausprägung(VALUE) innerhalb eines VALUES-Abschnittes bestimmt die Zugehörigkeit. Im obigen Beispiel gilt jedes 1. VALUE für das Element Audi und jedes 2. VALUE für das Element BMW pro Gruppierung.
Das Einlesen erfolgt im Regelfall nicht komplett, sondern bei Bedarf, also z. B. wenn der Benutzer weiterscrollt. Beim ersten Lesevorgang muss das <HEADER>-Tag übergeben werden, damit die Y-Achse dargestellt werden kann.
<CHART >

<HEADER >

<VALUES >

<ELEMENT >

Beispiel:

<CHART>
	<HEADER>
		<ELEMENT>
			<LABEL>Audi</LABEL>
				<KEY>
					<KFLD>S1</KFLD>
				</KEY>
		</ELEMENT>
		<ELEMENT>
			<LABEL>BMW</LABEL>
				<KEY>
					<KFLD>S1</KFLD>
				</KEY>
		</ELEMENT>
	</HEADER>
	<VALUES>
		<LABEL>1999</LABEL>
		<VALUE>150</VALUE>
		<VALUE>300</VALUE>
		<KEY></KEY>
	</VALUES>
	<VALUES>
		<LABEL>2000</LABEL>
		<VALUE>200</VALUE>
		<VALUE>350</VALUE>
		<KEY></KEY>
	</VALUES>
</CHART>

XML Struktur GANTT

Über das <GANTT>-Tag werden Ganttdiagramme übergeben. Alle Daten des Diagramms werden von einem GANTT-Element umschlossen.
<GANTT >
Die Struktur enthält als erstes einen Header. Dieser ist bei der ersten Datenübertragung Pflicht und bei den folgenden optional. Im Header u.a. werden das Format der Daten, das Format der Skala, der Wertebereich und die Legendenelemente definiert.
Danach können beliebig viele Entity-Elemente folgen. Diese stellen eine Zeile des Diagramms dar. Innerhalb dieser Entities werden die eigentlichen Werte in den Value-Tags definiert.
Als letzte Elemente sind auf dieser Ebene <XSTOP/> und <YSTOP/>. Dieses geben jeweils an, ob in der jeweiligen Richtung noch Daten bei Bedarf nachgeladen werden müssen. Wenn die Tags nicht vorhanden sind, so wird davon ausgegangen, dass noch Daten nachzuladen sind.

<HEADER >

Im HEADER-Element werden die Rahmenparameter (Datenformat, Skala, …) des Diagramms festgelegt. Als Datenformat sind die folgenden Ausprägungen möglich:

• DATE (YYYY-MM-DD)
• MONTH (CYYMM)
• WEEK (CYYWW)
• YEAR (CYY)
• TIMESTAMP (YYYY-MM-DD-HH.MM.SS.SSS)
• NUMBER (Z.Z)

In der XML müssen dann alle Wertangaben (min, max, from, to, …) in dem angegebenen Format erfolgen.
Im SCALE-Element kann der Skalentyp angegeben werden. Dieser muss kompatibel zum Datentyp sein. Bspw. kann nicht eine „FLOAT"-Skala für Daten des Typs „WEEK" verwendet werden. Im Folgenden sind die gültigen Kombinationen aufgelistet (die Art der Skalen sollte offensichtlich sein):

Zum Beispiel sind also alle Datumsformate mit allen Datumsskalen kompatibel.
Über STEPPING und ZOOM können optional die Darstellung beeinflusst werden. Im Standard wird für jede Einheit der Skala ein Vertikaler Strich gezeichnet und bei ausreichendem Platz auch beschriftet. Eine Einheit entspricht normalerweise 40 Pixeln. D.h. bei einer Wochenskala wird alle 40 Pixel eine Linie für die nächste Woche eingezeichnet. Wenn man nun eine 2-wöchige Skala möchte, so könnte man als STEPPING 2 angeben. Wenn die Daten nun zusätzlich noch zu gestaucht (gesteckt) erscheinen, so kann man über einen ZOOM-Wert >1 (<1) die Breite einer Einheit entsprechend anpassen.
Natürlich beeinflussen diese Einstellungen nicht nur die Skalen sondern auch die Darstellung der Daten. Ein Beispiel: Ein Eintrag mit einer Dauer von 3 Wochen wird normalerweise (bei einer Wochenskala) als Balken mit 120 (3 * 40) Pixel Länge angezeigt. Um den Balken auf 60 zu verkürzen konnte entweder das STEPPING auf 2 gesetzt werden, der ZOOM-Faktor auf 0.5 festgelegt werden oder eine Kombination aus beidem (STEPPING auf 2 und ZOOM-Faktor auf 0.25).
Über die ELEMENT-Tags werden die Einträge der Legende definiert (siehe weiter unten).

<ELEMENT>
Die Element-Elemente definieren die Einträge in der Legende. Innerhalb des Elements wird die Beschriftung des Legendenelements angegeben. Das FORMAT-Attribut bestimmt die Farbe des Eintrags und sollte ein vom CmdColorPool verarbeitbarer Wert sein. Für Diagramme wurden dafür speziell die folgenden Farben definiert:

Dabei sollten innerhalb eines Diagramm idealerweise entweder Helligkeitsvariationen der selben Farbe (z.B. chartyellow0, chartyellow1 und chartyellow2) ODER verschiedene Farben innerhalb einer Helligkeitsstufe (z.B. chartyellow0, chartgreen0 und chartred0) verwendet werden. Dies sind natürlich nur Empfehlungen und je nach Diagrammtyp kann es auch sinnvoll sein andere Kombinationen zu verwenden.
Es erfolgt zwar keine Überprüfung, aber dennoch sollten in Diagramm keine Formate (sprich Farben) vorkommen, die nicht hier im Header definiert wurden, d.h. die Formate der Legendenelemente und der Balken sollte konsistent sein.

<ENTITY>

Das Entity stellt eine Zeile eines Ganttdiagramms dar. Es enthält über die VALUE-Tags die eigentlichen Werte dieser Zeile. Über das GROUP-Element können Gruppen von Balken definiert werden, die dann bei einem Verschiebevorgang auch gemeinsam verschoben werden. Das GROUP-Element selbst kann wiederum nur VALUE-Elemente enthalten.
Über LABEL kann eine Beschriftung angegeben werden und über KEY sollte ein möglichst eindeutiger Schlüssel angegeben werden. KEY selbst kann beliebige Elemente enthalten. Zwei Keys sind genau dann gleich, wenn beide genau die gleichen Elemente mit den gleichen Ausprägungen enthalten (d.h. die Schnittmenge ist gleich der Einzelmenge).

<VALUE>
Ein einzelner Wert des Diagramms. Dabei müssen in jedem Fall FROM (Startwert), TO (Endwert) und FORMAT (Farbe) angegeben werden. FROM und TO müssen in dem in HEADER spezifizierten Format sein. Das FORMAT sollte eines sein, welches im HEADER als Legendenelement spezifiziert wurde.
Eine Ausnahme bildet das Format „transparent" das verwendet werden kann um eine Beschriftung über eine Balkengruppe hinweg zu erstellen. Der Balken ist dann durchsichtig und es ist nur die Beschriftung zu sehen. Damit das funktioniert, sollte der Transparente Balken vor den Balken definiert werden die er überdecken soll.
Für den KEY gilt das gleiche wie beim ENTITIY (s.o.).

Beispiel:

<GANTT>
	<HEADER FORMAT="TIMESTAMP">
 		<MIN>{*}2003-01-02-16.00.00.000000{*}</MIN> 
		<MAX>{*}2003-01-05-00.00.00.000000{*}</MAX> 
		<SCALE>{*}HOUR{*}</SCALE> 
		<STEPPING>{*}2{*}</STEPPING> 
		<ZOOM>{*}0.6{*}</ZOOM> 
		<ELEMENT FORMAT="chartred1">{*}Bearbeitungszeit{*}</ELEMENT> 
		<ELEMENT FORMAT="chartgreen1">{*}Transportzeit{*}</ELEMENT> 
		[...] 
	</HEADER>
	<ENTITY>
		<LABEL>{*}Arbeitsplatz 1{*}</LABEL> 
  		<KEY>
			<CRLS>{*}7501{*}</CRLS> 
			<CRFM>{*}PZKPAR{*}</CRFM> 
			<SSID>{*}KHCPGM3561310001{*}</SSID> 
		</KEY>
 		<GROUP>
 			<VALUE FROM="2003-01-03-03.30.00.000000" TO="2003-01-03-06.00.00.000000" FORMAT="transparent">
				<KEY>
					<CRLS>{*}2611{*}</CRLS> 
					</KEY>
					LABEL>{*}Ein langer Testsatz{*}</LABEL> 
					<TOOLTIP>{*}&lt;HTML&gt;Ein* *Test&lt;BR &gt;Ein* *TestSATZ{*}</TOOLTIP> 
 				</VALUE>
 				<VALUE FROM="2003-01-03-03.30.00.000000" TO="2003-01-03-0<ac:structured-macro ac:name="anchor" ac:schema-version="1" ac:macro-id="da496250-0a68-4af0-b963-5ea810379f85"><ac:parameter ac:name="">_GoBack</ac:parameter></ac:structured-macro>5.00.00.000000" FORMAT="chartred1">
					<KEY>
						<CRLS>{*}1511{*}</CRLS> 
					</KEY>
					<TOOLTIP>{*}Ein Test 1{*}</TOOLTIP> 
				</VALUE>
				[...]
			</GROUP>
		</ENTITY>
	<XSTOP /> 
	<YSTOP /> 
</GANTT>