Im CTV-Laufzeitsystem stehen neue Operationen zur Erstellung von XML-Dokumenten zur Verfügung. Die erstellten Dokumente können archiviert, versandt oder anderweitig benutzt werden. Diese Operationen können zur Zeit nur mittels des CTV-Wizards in ControlEdge genutzt werden („Bestehendes Schriftgut als XML-Dokument archivieren“).

Zur Zeit ist im CTV-Wizard die Archivierung des Schriftguts als XML-Dokument über das iXOS-Archiv unterstützt. Man beachte, daß die Archivierung eines Schriftgutobjektes analog dem Ausdruck desgleichen auch das anschließende Entfernen dieser Instanz aus der Laufzeitstruktur beinhaltet.

Die Ausgabe eines XML-Dokumentes zum Ergebnis eines Bausteins kann auch ohne Eingriff in den Code einer bestehenden Anwendung vorgenommen werden. Dazu ist allerdings eine Neugenerierung bestimmter Ressourcen notwendig.

Es besteht die Möglichkeit, einem Baustein einen Vermerk zu geben, der besagt, daß dieser Baustein begleitet wird von einer CTV-Komponente. Dieser Begleiter (oder Kumpel, auf englisch: „Buddy“) wird immer dann aktiviert, wenn der Baustein, den er begleitet, abgeschlossen wird. Die Aktivierung der Buddy-CTV-Komponente besteht in der Instanzierung, Auswertung, XML-Ausgabe und Entsorgung desgleichen. Im nachfolgenden sind die Details einzeln erläutert. Zunächst noch zwei Warnungen:

• Man beachte, daß die BuddyCTV-Eigenschaft nur bei solchen Bausteinen benutzt werden kann, die im Prozesskontext riner GeVo-Steuerung ablaufen. Die CTV-Engine ist nur in diesem Prozess nutzbar. Versuche, diese Eigenschaft in Bausteinen von anderen Prozessen zu nutzen, werden mit einer Oops-Meldung „Unsupported feature“ quittiert.
• Es ist vorgesehen, dass in Zukunft das Ergebnis des CTV-Buddy-Schriftguts nur dann archiviert wird, wenn das oberste Schriftgut-Objekt den Zustand „OK“ liefert. Zur Zeit wird dieser Zustand noch nicht ausgewertet, und das XML-Dokument immer archiviert. Es wäre dennoch gut Praxis, diesen Zustand bereits heute korrekt zu setzen.

Um einen TAA-Baustein für die automatische Begleitung mit einer CTV-Komponente zu markieren, wird in der Konfigurationsbeschreibung eine allgemeine Einstellung mit dem Namen BuddyCTV eingetragen. Der Wert dieser Einstellung kann aus bis zu vier Werten bestehen: Name, Typ, Anwendung und Ereignis. Der Name muß mindestens eingetragen sein, alle sonstigen Angaben sind optional.

Abb. 1: Definition von BuddyCtv in KonfEdge Wenn die Typangabe fehlt, wird SSBS angenommen. Wenn die Anwendungsangabe fehlt, wird angenommen, dass die CTV-Komponente sich in der gleichen Anwendung wie die des einbindenden Bausteins befindet. Wenn keine Angabe über das auszulösende Ereignis angegeben wird, wird das Ereignis UDEF ausgelöst. Die Angaben aus dem vorigen Bild wären also vollständig (ohne Defaults): BuddyCTV=PG-TEST-BUDDYCTV;SSBS;TEST;UDEF.

Der CTV-Begleiter wird wie jede normale CTV-Komponente definiert. Sie kann jeden beliebigen Typ haben, d.h. sie kann Schriftsatz, Schriftstück, Bausteingruppe oder Baustein sein. Die Struktur des Schriftguts wird bei der Ablage in XML-Format berücksichtigt.

Die Parameterobjekte des CTV-Begleiters sollten, müssen aber nicht, denen des zu begleitenden Bausteins entsprechen. Die Zuweisung der Argumente erfolgt zur Laufzeit auf Basis von Namensgleichheit. Parameterobjekte, zu denen keine namentliche Übereinstimmung gefunden werden kann, werden zur Laufzeit mit leeren Dummy-Objekten bestückt.

Der CTV-Begleiter kann mehrere Ereignisse haben. Falls mehr als ein Ereignis definiert wurde, sollte das auszulösende Ereignis in der BuddyCTV-Einstellung eingetragen werden (bspw.: BuddyCTV=HG-TEST-BUDDYCTV;;PRODVAR). Falls kein explizites Ereignis angegeben ist, wird versucht, das Ereignis UDEF auszulösen. Sollte das Ereignis UDEF nicht vom CTV-Begleiter unterstützt werden, wird dies zur Laufzeit mit einem sog. Oops gemeldet, und der CTV-Begleiter wird nicht ausgeführt. Standardmäßig besitzen alle CTV-Komponenten bei Anlage das Ereignis UDEF.

Die Struktur des erzeugten XML-Dokumentes entspricht der Struktur des aus der CTV-Komponente erzeugten Schriftguts. Die Dokumentstruktur kann mit diesem DTD oder XML Schema überprüft werden. Im nachfolgenden Bild ist die Struktur ebenfalls dargestellt. Abb. 2: Dokumentstruktur

Man beachte, dass in der Darstellung des Bildes nicht der Tatsache Rechnung getragen wird, dass innerhalb eines ctrTxtk-Elementes die Elemente ctrTxtf, ctrTxtp und ctrTxtl in beliebiger Reihenfolge vorkommen. Die DTD ist daher exakter. Außerdem sind in der DTD auch die Attribute der einzelnen Elemente ersichtlich.

Aus den vorigen Angaben ist erkennbar, dass durch die Definition der CTV-Komponentenstruktur die Hierarchie der ctrSgut-Elemente beeinflußt werden kann. Die ctrVari-Angaben werden aus den vordefinierten Variablen der einzelnen Schriftgutobjekte abgeleitet. Eine Anpassung ist nur durch Anpassung der Sgpv-Tabelle in der EDB möglich. Die Elemente unterhalb von ctrTxtk entstehen aus den Platzhalter-Angaben der Textblöcke der CTV-Bausteine. Die Texte der CTV-Bausteine erscheinen selbst nicht im XML-Dokument. Wenn eine CTV-Komponentenstruktur zur Verwendung als CTV-Begleiter erstellt wird, dürften die Texte in den Bausteinen im allgemeinen nur aus Platzhaltern bestehen. Im Pseudocode der einzelnen Komponenten werden dann die Parameterobjekte formatiert und in die Platzhalter übertragen.

Abb. 3: Pseudocode in KnowlEdge Abb. 4: Bausteintext in KnowlEdge

	<ctrSgut name="PG-TEST-BUDDYCTV" type="SSBS" appl="TWONLY"
	      shortname="0091" date="20141021113511" op="" seqid="S_0x00000008">
	   <title> Test für BuddyCTV (zu PG-NFUN-TEST) </title>
	   <desc>BuddyCTV</desc>
	   <ctrTxtk name="TXTK-PG-TEST-BUDDYCTV.CTI" date="" shortrname="">
	      <ctrTxtp name="TestPlatzhalter" pos="2169" fmt=""> What's up Doc?</ctrTxtp>
	         <ctrTxtp name="Datum" pos="2300" fmt="D1"> 28.10.2014</ctrTxtp>
	   </ctrTxtk>
	</ctrSgut>

Das DoxInfo-Element ist nur dann Bestandteil des XML-Dokumentes, wenn die XML-Datei an das iXOS-Archiv übertragen werden soll. Dies wird gesteuert über das CompanySetting iXOSArchive. Die Angaben für das DoxInfo-Element werden aus den Eigenschaften des GeVos abgeleitet. Einige dieser Eigenschaften werden von der TAA Infrastruktur gepflegt, andere können im CTV-Pseudocode über das vordefinierte Objekt ctvGevo gemacht werden. Im folgenden Pseudocode-Ausschnitt werden die anwendungsseitig zu bestückenden GeVo-Eigenschaften für das DoxInfo-Element beispielhaft gesetzt:

sample.ps

ctvGevo.Prop("VermittlerNr") = DFVB07I.VB4-VMI-ID
ctvGevo.Prop("VermittlerName") = DFVB07I.VB4-VMI-NAM
Get First LPTGESL Where LPTGESL.X2Y-PGO-ZR-BZ = "Versicherungsnehmer"
ctvGevo.Prop("KundenNr") = LPTGESL.PARTNER-KEY
ctvGevo.Prop("KundenName") = LPTGESL.PTN-NNAM-TL1 & ", " & LPTGESL.NAT-VNAM

Die folgende Tabelle zeigt die einzelnen Unterelemente des DoxInfo-Elementes, sowie deren Herkunft.

Die XML-Dokumente werden standardmäßig in dem TEMP-Verzeichnis abgelegt. Wenn als CompanySetting jedoch iXOSArchive gesetzt ist, werden die Dateien anschließend aus dem TEMP-Verzeichnis in das passende Datenverzeichnis gemäß Konventionen für die Übernahme in das iXOS Archiv (DOX) verschoben.

Das Hauptverzeichnis für die Übernahme der XML-Dokumente wird zunächst als Data_Dir Zeichenfolge im Abschnitt XMLReporting unter dem Config-Abschnitt der TAA-Registry gesucht. Falls hier keine Angabe gemacht wurde, wir in der Hive HKEY_LOCAL_MACHINE ein Eintrag Software\iXOS\iXOS-Archive\Codb\2.0\Data_Dir gesucht, und der Wert dieses Eintrags übernommen. Falls auch hier kein Eintrag gefunden wird, wird das aktuelle TEMP-Verzeichnis als Hauptverzeichnis für die Datenübergabe genutzt.

Unterhalb des Hauptverzeichnisses werden gezielt Unterbäume angelegt für die unterschiedlichen Dokumenttypen.Die folgende Tabelle bietet eine Übersicht der zur Zeit unterstützten Dokumenttypen:

Nachfolgend ist ein Beispiel für Registry-Einträge dargestellt, bei der XML-Dokumente der Art Dok-Verweise in einem Unterverzeichnis typ1 abgestellt werden, alle anderen bekannten Dokumenttypen in einem Unterverzeichnis typ2 landen:

[HKEY_CURRENT_USER\Software\TAA\Company]
"iXOSArchive"=hex:01

[HKEY_CURRENT_USER\Software\TAA\Config\XMLReporting]
"Data_Dir"="d:\work\dox"
"DataDir:Doc"="typ1"
"DataDir:Bc"="typ2"
"DataDir:Bp"="typ2"
"DataDir:Ctr"="typ2"
"DataDir:Stme"="typ2"

Das angegebene Hauptverzeichnis muss existieren. Sollte ein benötigtes Unterverzeichnis nicht vorhanden sein, wird es angelegt. In dem jeweiligen Unterverzeichnis wird, entsprechend den iXOS-Konventionen, ein Verzeichnis pro Dokument angelegt, in welchem das XML-Dokument als eine Datei mit dem Namen data abgelegt wird. Zusätzlich wird, nach erfolgreicher Ablage, eine leere Datei mit dem Namen log kreiert, zum Zeichen, dass die Ablage abgeschlossen ist. Die Namen der Unterverzeichnisse werden aus dem GeVo-GUID und einer innerhalb des GeVos eindeutigen Nummer gebildet.