TstRprt: Berichte über den Inhalt von Aufzeichnungen erstellen

Das Utility tstRprt.exe hat als Aufgabe, Informationen zu dem Inhalt von Aufzeichnungen zu produzieren. Eine Beschreibung der möglichen Aufgaben und Protokolle finden sie weiter unten.

TstRprt [Allgemeine Optionen] <Aufgabe>
TstRprt [Allgemeine Optionen] –ex <Aufgabendatei> 

TstRprt kennt folgende Optionen:

• -a <Anwendung>
• -s <Stufe>
• -g <Auftrag>
• -lo < Log-Datei>
• -o <Protokoll-Datei>
• -view <XSL>

Die Optionen haben folgende Bedeutung:

Die Kombination von Optionen -lo und -view speichert einen XSL- Verweis in die Datei die mit -o angegeben ist. Wenn kein Logfile angegeben ist, wird die Datei ohne XSL-Verweis gespeichert und ein Browser gestartet. Dieser zeigt das Ergebnis an, welches entsteht, wenn auf die XML-Datei das XSL angewendet wird.

Die Optionen -o und -xsl können für jede Aufgabe einzeln angegeben werden. Werden die Optionen allgemein angegeben, speichert TstRprt die einzelnen Protokolle in eine Datei

Wird hingegen bei jeder Aufgabe die -o Option angegeben, erhalten Sie getrennte XML-Dateien.

TRCERR: Report über aufgetretene Fehler beim Laden und Speichern (Snap) von Aufzeichnungen.
TRCLIST: Report über vorhandene Tracedateien.
PERF: Report über die Verweildauer von Bausteinaufrufen.
FIND: Suchen nach diversen Eigenschaften in Aufzeichnungen.
INFO: Informationen über den Inhalt von Aufzeichnungen.

Die einzelnen Aufgaben werden über sog. named Arguments bestückt, die folgendermaßen aussehen: <name>=<value>.

Im TEstEdge werden aufgetretene Fehler/Probleme, die beim Laden/Speichern von Aufzeichnungen erkannt wurden, angezeigt. Das Aufzeichnungssymbol bzw. Bausteinaufruf-Symbol(e) werden dann rot angezeigt. Die Checkbox „Fehlerhaft aufgezeichnet“ ist für die betroffenen Bausteine angekreuzt. Um eine XML-Report-Datei mit den aufgetretenen Fehlern zu erstellen, dient TEstRprt mit folgender Syntax:

TRCERR aufz=<Aufzeichnung> [bsar=[<Name>][.[<Ereignis>][.[<Vorkommen>]]]] 

aufz=<Aufzeichnung>: Hiermit spezifizieren Sie die Aufzeichnung, aus welcher der Report generiert werden soll.
bsar=<Bausteinaufruf>: Hiermit spezifizieren Sie, für welchen Bausteinaufruf ein Report generiert werden soll. Geben Sie keinen Bausteinaufruf an, wird der Report für die Aufzeichnung erstellt und beinhaltet alle darin gerufenen Bausteine, bei denen ein Tracefehler auftrat.
Den Bausteinaufruf können sie mittels <Name>, <Ereignis> und <Vorkommen> identifizieren. Jede dieser drei Angaben kann weggelassen werden und wird dann von tstRprt selbst bestückt. Zum Beispiel würde die Angabe „TAASTART“ ergänzt werden zu „TAASTART.UDEF.1“, und „..1“ würde genau so ergänzt werden zu „TAASTART.UDEF.1“, vorausgesetzt „TAASTART“ ist das erste gerufene Modul, was beim Anstarten mittels taa32go/fledge etc. der Fall ist.
Wenn nur ein Aufzeichnungsname angegeben wird, werden alle Bausteinaufrufe auf das Auftreten von Fehlern beim Laden/Speichern der Aufzeichnung untersucht und nur die fehlerbehafteten in den Report mitaufgenommen. Ist zusätzlich zum Aufzeichnungsnamen noch ein Bausteinaufruf angegeben, wird nur dieser geprüft und bei Fehlererkennung in den Report aufgenommen.

Bedeutung der XML-Tags im Report.
<TrcError>: Innerhalb von <Aufz> : Der Wert ist „yes“, wenn mindestens ein Fehler beim Laden oder Speichern der Aufzeichnung aufgetreten ist.
Innerhalb von <Bsar> : Der Wert ist „yes“, wenn mindestens ein Fehler bezogen auf den Bausteinaufruf beim Laden oder Speichern der Aufzeichnung aufgetreten ist. Das Auftreten von Tracefehlern bedeutet nicht unbedingt, dass immer konkrete Fehlermeldungen innerhalb von <TrcErrors> angezeigt werden.
<Occ>: Gibt an, das wievielte mal der Baustein mit dem angegebenen Namen und Ereignis aufgerufen wurde.
<TrcErrors>: Innerhalb dieses Tags werden Fehlermeldungen angezeigt.
<LoadMessages>: Unter diesem Tag werden Fehler aufgeführt, die beim Laden der Aufzeichnung aufgetreten sind.
<SnapMessages>: Unter diesem Tag werden Fehler aufgeführt, die beim Speichern der Aufzeichnung aufgetreten sind.
<Message>: Innerhalb dieses Tags wird die Fehlermeldung angezeigt.Bedeutung der XML-Tags im Report
<TrcError>: Innerhalb von <Aufz> : Der Wert ist „yes“, wenn mindestens ein Fehler beim Laden oder Speichern der Aufzeichnung aufgetreten ist.
Innerhalb von <Bsar> : Der Wert ist „yes“, wenn mindestens ein Fehler bezogen auf den Bausteinaufruf beim Laden oder Speichern der Aufzeichnung aufgetreten ist. Das Auftreten von Tracefehlern bedeutet nicht unbedingt, dass immer konkrete Fehlermeldungen innerhalb von <TrcErrors> angezeigt werden.
<Occ>: Gibt an, das wievielte mal der Baustein mit dem angegebenen Namen und Ereignis aufgerufen wurde.
<TrcErrors>: Innerhalb dieses Tags werden Fehlermeldungen angezeigt.
<LoadMessages>: Unter diesem Tag werden Fehler aufgeführt, die beim Laden der Aufzeichnung aufgetreten sind.
<SnapMessages>: Unter diesem Tag werden Fehler aufgeführt, die beim Speichern der Aufzeichnung aufgetreten sind.
<Message>: Innerhalb dieses Tags wird die Fehlermeldung angezeigt.

Mit dieser Aufgabe kann nach Tracedateien gesucht werden, die bestimmte Kriterien erfüllen. Um eineN XML-Report-Datei mit den gefundenen Tracedateien zu erstellen, dient TstRprt mit folgender Syntax:

TRCLIST  [aufz=<Aufzeichnung>] [date=<Datum>] [wsid=<WorkstationID>] [appl=<Anwendung>] [dir=<Verzeichnis>]

aufz=<Aufzeichnung>: Hiermit spezifizieren Sie den Namen, unter dem aufgezeichnet sein sollte.
date=<Datum>: Hiermit spezifizieren Sie das Aufzeichnungsdatum zum Gevo-Start/Wiederaufnahme. Format: YYYY-MM-DD.
wsid=<WorkstationID>: Hiermit spezifizieren Sie die Workstation, auf der die aufgezeichnete Anwendung gestartet wurde.
appl=<Anwendung>: Hiermit spezifizieren Sie zu welchem Anwendungssystem der aufgezeichnete Ablauf gehören soll.
dir=<Verzeichnis>: Hiermit spezifizieren Sie mindestens ein Verzeichnis in dem die Tracedateien gesucht werden. Mehrere Verzeichnisse müssen durch Semikolon getrennt werden.

Es werden hier nur die Dateien berücksichtigt, deren Name dem von TAA standardmäßig erzeugten Namen für Tracedateien enspricht, also keine Dateien, die aus irgendeinem Grund anders benannt wurden, auch wenn sie mit einem entsprechenden Suffix enden.

Bedeutung der XML-Tags im Report:
<SearchCriteria>: Die Angaben (Suchkriterien) mit denen Tracedateien gesucht werden.
<TraceFile>: Eine Tracedatei die die Kriterien erfüllt. Durch den Diffname „Trace“ ist ein RATING des Reports möglich.
<Guid>: Die Guid der Tracedatei. Diese benötigt z.B. tstSnap, um eine Aufzeichnung zu erstellen.
<Aufz>: Name unter dem aufgezeichnet wurde. Unter diesem Namen würde der Trace als Aufzeichnung gespeichert werden. (falls Sie sich bei tstSnap/tstEdge nicht für einen anderen Namen entscheiden)
<Date>: Datum an dem der Ablauf gestartet wurde.
<WSID>: Workstation auf der der Ablauf gestartet wurde.
<Appl>: Anwendungssystem zu dem der Ablauf gehört.
<Modl>: Das erste Modul das sich registriert hat. (Das Modul TAASTART wird ignoriert)

Das Element <TraceFiles> hat einen der folgende DiffNamen:
DiffName: Beschreibung
NotTraced: Es wurden keine Tracefiles gefunden.
Traced: Es wurden Tracefiles gefunden.

Syntax:

 PERF aufz=<Aufzeichnung> [bsar=[<Name>][.[<Ereignis>][.[<Vorkommen>]]]] ["opts=<opts>"]   

aufz=<Aufzeichnung>: Hiermit spezifizieren Sie die Aufzeichnung, aus welcher der Report generiert werden soll.
bsar=<Bausteinaufruf>: Hiermit spezifizieren Sie, für welchen Bausteinaufruf ein Report generiert werden soll. Geben Sie keinen Bausteinaufruf an, wird der Report für die Aufzeichnung erstellt und beinhaltet alle darin gerufenen Bausteine.
opts=<opts>: Hiermit spezifizieren Sie Optionen, die spezifisch für diesen Report sind.

Den Bausteinaufruf können sie mittels <Name>, <Ereignis> und <Vorkommen> identifizieren. Jede dieser drei Angaben kann weggelassen werden und wird dann von tstRprt selbst bestückt. Zum Beispiel würde die Angabe „TAASTART“ ergänzt werden zu „TAASTART.UDEF.1“, und „..1“ würde genau so ergänzt werden zu „TAASTART.UDEF.1“, vorausgesetzt „TAASTART“ ist das erste gerufene Modul, was beim Anstarten mittels taa32go/fledge etc. der Fall ist.

Der Report kennt folgende Optionen:
-et Bstn: Der Report gruppiert die Verweildauer per Bausteinname.
-et Evnt: Der Report gruppiert die Verweildauer per Bausteinname und ausgelöstem Ereignis.
-et BstnType: Der Report gruppiert die Verweildauer per Bausteintyp.
-i[0|1]: Die Angabe -i bedeutet „IgnoreInteraction“. Hiermit wird gesteuert, ob die Verweildauer von Interaktionen mit berücksichtigt werden soll oder ob diese rausgerechnet werden soll. -i0 berücksichtigt die Interaktionen. Dies ist der Default, wenn nichts angegeben wird, -i1 ignoriert die Interaktionen.

Bedeutung der XML-Tags im Report
<Calls> Wie oft wurde der Baustein aufgerufen. Auf oberster Ebene (Aufzeichnung) alle Aufrufe eines Bausteins während der Anwendung, auf tieferer Ebene (Baustein) nur die von diesem Baustein direkt erfolgten Aufrufe.
<TimeTotal>: Zeit in Millisekunden vom Zeitpunkt wo sich der Baustein registriert hat, bis zu dem Zeitpunkt des Unregister. Darin sind auch die Zeiten enthalten, die gebraucht wurden, um aufgerufene Bausteine auszuführen.
<PercentTotal>: Zeitanteil in Prozent, entweder von der Gesamtaufzeichnung oder von der Ausführungszeit des aufrufenden Bausteins. Da immer auch die Zeiten der aufgerufenen Bausteine enthalten sind und diese zusätzlich selbst aufgeführt sind, kann die Summe der %-Werte über 100% sein.
<TimeFunc>: Zeit in Millisekunden, die tatsächlich in diesem Baustein verbracht wurde. In diesem Wert sind die Zeiten, während der die Verarbeitung in gerufenen Bausteinen ablief, nicht enthalten.
<PercentFunc>: Zeitanteil in Prozent, entweder von der Gesamtaufzeichnung oder von der Ausführungszeit des aufrufenden Bausteins. Da die Zeiten der aufgerufenen Bausteine hier nicht enthalten sind, kann die Summe der %-Werte nie über 100% sein.
<TimeTotalPerCall>, <TimeFuncPerCall>: Zeit im Baustein geteilt durch die Anzahl der Aufrufe dieses Bausteins. Ergibt eine durchschnittliche reine Verweildauer pro vorkommenden Baustein.

Mit dieser Aufgabe kann gezielt nach Bausteinaufrufen gesucht werden, die bestimmte Kriterien erfüllen. Um eine XML-Report-Datei mit den gefundenen Bausteinaufrufen zu erstellen, dient TstRprt mit folgender Syntax:

FIND aufz=<Aufzeichnung> [bsar=[<Name>][.[<Ereignis>][.[<Vorkommen>]]]] search=<String> ["opts=<opts>"] 

aufz=<Aufzeichnung>: Hiermit spezifizieren Sie die Aufzeichnung, aus welcher der Report generiert werden soll.
bsar=<Bausteinaufruf>: Hiermit spezifizieren Sie, welcher Bausteinaufruf als Einstiegspunkt für die Suche dienen soll.
search=<String>: Hiermit spezifizieren Sie die Kriterien, nach denen Sie suchen möchten. Die einzelnen Kriterien werden später erläutert.
opts=<opts>: Hiermit spezifizieren Sie Optionen, die spezifisch für diesen Report sind. Den Bausteinaufruf können sie mittels <Name>, <Ereignis> und <Vorkommen> identifizieren. Jede dieser drei Angaben kann weggelassen werden und wird dann von tstRprt selbst bestückt. Zum Beispiel würde die Angabe „TAASTART“ ergänzt werden zu „TAASTART.UDEF.1“, und „..1“ würde genau so ergänzt werden zu „TAASTART.UDEF.1“, vorausgesetzt „TAASTART“ ist das erste gerufene Modul, was beim Anstarten mittels taa32go/fledge etc. der Fall ist.
Wenn nur ein Aufzeichnungsname angegeben wird, werden alle Bausteinaufrufe durchsucht.

Der Report kennt folgende Optionen:
-case[0|1]: Die Angabe -case bedeutet: Groß/Kleinschreibung berücksichtigen. -case0 berücksichtigt keine Groß/Kleinschreibung (Default), -case1 berücksichtigt die Groß/Kleinschreibung.
-word[0|1]: Die Angabe -word bedeutet: nur ganze Wörter suchen. -word0 sucht nicht nur nach ganzen Wörtern (Default). -word1 sucht nur ganze Wörter.
-up[0|1]: Die Angabe -up gibt an, dass vom Einstiegspunkt aus nach oben gesucht werden soll bis zum Anfang der Aufzeichnung. -up0 bedeutet, nicht nach oben suchen (Default). -up1 durchsucht auch alle Bausteinaufrufe, die vor dem Einstiegspunkt vorhanden sind.
-down[0|1]: Die Angabe -down gibt an, dass vom Einstiegspunkt bis zum Ende der Aufzeichnung gesucht werden soll. -down0 bedeutet, nicht nach unten suchen (Default). -down1 durchsucht auch alle Bausteinaufrufe, die hinter dem Einstiegspunkt vorhanden sind.
-change[0|1] Die Angabe -change gibt an, ob nur nach Änderungen gesucht wird. Diese Option gilt nur für Objekte. -change0 bedeutet, nicht nur nach Änderungen suchen (Default). -change1 sucht nur nach Änderungen.

Ein Suchangabe hat folgende Form:

<Eigenschaft>={[<Operator>]<Wert>[;[<Operator>]<Wert>]}. 

Mögliche Operatoren sind: „<“, „>“, „!“,„~“ und „=“. Sie haben folgende Bedeutung:

Wird kein Operator angegeben, so wird der Operator „~“ genommen und nach einem Teilstring gesucht.

Durch Angabe mehrerer Werte für eine Eigenschaft oder mehrfache Angabe einer Eigenschaft erreicht man eine „Oder“-Suche für diese Eigenschaft.

Werden unterschiedliche Eigenschaften angegeben, so werden diese als „AND“-Bedingung gesehen.

Durch mehrere „FIND“-Aufrufe in einer „-ex“-Datei können Sie eine Art „Oder“ für mehrere Eigenschaften erreichen. Das Ergebnis beinhaltet u.U. die gleiche Bausteinaufrufe mehrmals.

Statt alle Eigenschaften auf der Kommandozeile anzugeben, können Sie auch eine sogenannte „Responsedatei“ (@Dateiname) nutzen. Beispiel:

 tstrprt.exe find aufz=<name> @c:\work\Kriterien.txt -oc:\work\findrprt.xml 

In der Textdatei „Kriterien.txt“ können Sie z.B. öfters wiederkehrende Kriterien ablegen. In der Kombination mit der „-ex“-Angaben müssen Sie öfters wiederkehrende Suchen nicht jedes mal eintippen.

Folgende Suchkriterien können angegeben werden:

BsarType=EFUN
Sucht alle Bausteinaufrufe, in denen der gerufene Baustein eine elementare Funktion ist.
CallType=EFUN
Sucht alle Bausteinaufrufe, in denen der gerufene Baustein seinerseits eine elementare Funktion aufruft.
CndSev=warning;severe;fatal
Sucht alle Bausteinaufrufe, in denen Conditions mit einer Severity „warning“, „severe“ oder „fatal“ gesetzt sind.
„OopsErr⇒0“
Sucht alle Bausteinaufrufe, in denen ein Oops aufgetreten ist, der einen ErrorCode größer 0 hat. Hiermit finden Sie also alle Oopse, die aufgetreten sind.
„CndCode=<100“
Sucht alle Bausteinaufrufe, in denen eine Condition gesetzt ist mit einer Meldungsnummer kleiner als 100. NB: Da es maximal 99 Meldungen pro Gruppe geben kann, finden Sie alle Conditions, die gesetzt worden sind. ObjType=DZUG-STRUKTUR-SNVEV
FldName=000-AEN-K
000-AEN-K=D

Sucht alle Bausteinaufrufe, in denen ein Objekt vorkommt das als Objekttype „DZUG-STRUKTUR-SNVEV“ hat worin im Feld „000-AEN-K“ ein „D“ für Delete steht.

Bedeutung der XML-Tags im Report
<SearchIn>: Hier wird angegeben, was der Einstiegspunkt für die Suche ist.
<SearchFor>: Hier wird angegeben, wonach gesucht worden ist.
<FindHit>: Ein Bausteinaufruf der gefunden wurde.
<Context>: Der Kontext, in dem etwas gefunden wurde. Diese haben alle einen Diffnamen, sodass ein RATING des Reports möglich ist. Mögliche Kontexte sind „FindBsar“, „FindCall“, „FindOops“, „FindCndOp“, „FindSchwOp“, „FindStrgVar“, „FindWflOp“ „FindNVPair“, „FindCtvRes“, „FindObject“ und „FindWflProp“.
<Description>: Angabe, in welcher Eigenschaft der Wert gefunden wurde.

Das Element <Result> hat einen der folgenden DiffNamen:
DiffName: Beschreibung
NotFound: Es wurden keine Bausteinaufrufe gefunden.
Found: Es wurden Bausteinaufrufe gefunden.

Mit dieser Aufgabe können Informationen und Inhalte aus Aufzeichnungen geliefert werden:

 INFO <Infoart> aufz=<Aufzeichnung> [bsar=[<Name>][.[<Ereignis>][.[<Vorkommen>]]]] ["opts=<opts>"]

<Infoart>: Hiermit spezifizieren Sie, welche Informationen geliefert werden sollen.
aufz=<Aufzeichnung>: Hiermit spezifizieren Sie die Aufzeichnung, aus welcher der Report generiert werden soll.
bsar=<Bausteinaufruf>: Hiermit spezifizieren Sie, für welchen Bausteinaufruf ein Report generiert werden soll. Geben Sie keinen Bausteinaufruf an, wird der Report für die Aufzeichnung erstellt und berücksichtigt alle darin gerufenen Bausteine.
opts=<opts>: Hiermit spezifizieren Sie Optionen, die spezifisch für diesen Report sind. Die allgemeinen Optionen -o (Outputdatei) und -v (Stylesheet) können übersteuert werden. Den Bausteinaufruf können sie mittels <Name>, <Ereignis> und <Vorkommen> identifizieren. Jede dieser drei Angaben kann weggelassen werden und wird dann von tstRprt selbst bestückt. Zum Beispiel würde die Angabe „TAASTART“ ergänzt werden zu „TAASTART.UDEF.1“, und „..1“ würde genau so ergänzt werden zu „TAASTART.UDEF.1“, vorausgesetzt „TAASTART“ ist das erste gerufene Modul, was beim Anstarten mittels taa32go/fledge etc. der Fall ist.

Wenn nur ein Aufzeichnungsname angegeben wird, werden alle Bausteinaufrufe berücksichtigt. Ist zusätzlich zum Aufzeichnungsnamen noch ein Bausteinaufruf angegeben, wird nur dieser berücksichtigt.

Verfügbare „Infoarten“:

Informationen über den Inhalt von Aufzeichnungen 8.02 Mit dieser Aufgabe können Informationen und Inhalte aus Aufzeichnungen geliefert werden: Syntax INFO <Infoart> aufz=<Aufzeichnung> [bsar=[<Name>][.[<Ereignis>][.[<Vorkommen>]]]] [„opts=<opts>“] <Infoart> Hiermit spezifizieren Sie, welche Informationen geliefert werden sollen. aufz=<Aufzeichnung> Hiermit spezifizieren Sie die Aufzeichnung, aus welcher der Report generiert werden soll. bsar=<Bausteinaufruf> Hiermit spezifizieren Sie, für welchen Bausteinaufruf ein Report generiert werden soll. Geben Sie keinen Bausteinaufruf an, wird der Report für die Aufzeichnung erstellt und berücksichtigt alle darin gerufenen Bausteine. opts=<opts> Hiermit spezifizieren Sie Optionen, die spezifisch für diesen Report sind. Die allgemeinen Optionen -o (Outputdatei) und -v (Stylesheet) können übersteuert werden. Den Bausteinaufruf können sie mittels <Name>, <Ereignis> und <Vorkommen> identifizieren. Jede dieser drei Angaben kann weggelassen werden und wird dann von tstRprt selbst bestückt. Zum Beispiel würde die Angabe „TAASTART“ ergänzt werden zu „TAASTART.UDEF.1“, und „..1“ würde genau so ergänzt werden zu „TAASTART.UDEF.1“, vorausgesetzt „TAASTART“ ist das erste gerufene Modul, was beim Anstarten mittels taa32go/fledge etc. der Fall ist. Wenn nur ein Aufzeichnungsname angegeben wird, werden alle Bausteinaufrufe berücksichtigt. Ist zusätzlich zum Aufzeichnungsnamen noch ein Bausteinaufruf angegeben, wird nur dieser berücksichtigt.

Verfügbare „Infoarten“: COUNTS Liefert die Anzahlen der enthaltenen Elemente in der Aufzeichnung oder eines Bausteinaufrufs. ENVS Liefert die enthaltenen Umgebungen in der Aufzeichnung. OOPSE Liefert die enthaltenen Oopse in der Aufzeichnung oder eines Bausteinaufrufs. CNDOPS Liefert die enthaltenen Condition-Operationen in der Aufzeichnung oder eines Bausteinaufrufs. WFLOPS Liefert die enthaltenen Workflow-Operationen in der Aufzeichnung oder eines Bausteinaufrufs. SCHWOPS Liefert die enthaltenen Schwebe-Operationen in der Aufzeichnung oder eines Bausteinaufrufs. TRXOPS Liefert die enthaltenen Transaktions-Operationen in der Aufzeichnung oder eines Bausteinaufrufs. WFLPROPS Liefert die gesetzten Workflow-Eigenschaften in der Aufzeichnung oder eines Bausteinaufrufs und die eingehenden und ausgehenden Workflow-Eigenschaften für einen Bausteinaufruf. STRGVARS Liefert die enthaltenen Steuerungs-Variablen in der Aufzeichnung oder eines Bausteinaufrufs. STARTREQS Liefert die enthaltenen Start-Requests in der Aufzeichnung oder eines Bausteinaufrufs. NVPAIRS Liefert die enthaltenen Name/Wert-Paare (Name/Value-Pairs) in der Aufzeichnung oder eines Bausteinaufrufs. SGUT Liefert das enthaltene Schriftgut in der Aufzeichnung oder eines Bausteinaufrufs. OBJECTS Liefert die eingehenden und ausgehenden Objekte für einen Bausteinaufruf.

Bedeutung der XML-Tags im Report für „COUNTS“:
<EnvCount>: Anzahl Umgebungen.
<CtxCount>: Anzahl Kontexte.
<BsarCount>: Anzahl Bausteinaufrufe.
<OopsCount>: Anzahl Oopse.
<CndOpCount>: Anzahl Condition-Operationen.
<WflOpCount>: Anzahl Workflow-Operationen.
<WflPropCount>: Anzahl Workflow-Eigenschaften.
<SchwOpCount>: Anzahl Schwebe-Operationen.
<TrxOpCount>: Anzahl Transaktions-Operationen.
<StrgVarCount>: Anzahl Steuerungs-Variablen.
<StartReqCount>: Anzahl Start-Requests.
<NVPairCount>: Anzahl Name/Wert-Paare (Name/Value-Pairs).
<SnapMsgCount>: Anzahl Snap-Meldungen.
<LoadMsgCount>: Anzahl Lade-Meldungen
<CalleeCount>: Anzahl gerufener Bausteine eines Bausteinaufrufs.
<ObjInCount>: Anzahl eingehender Objekte eines Bausteinaufrufs.
<ObjOutCount>: Anzahl ausgehender Objekte eines Bausteinaufrufs.
<WflPropInCount>: Anzahl eingehender Workflow-Eigenschaften eines Bausteinaufrufs.
<WflPropOutCount>: Anzahl ausgehender Workflow-Eigenschaften eines Bausteinaufrufs.

Bedeutung der XML-Tags im Report für „ENVS“:
<Appl>: Anwendung
<ApplAbbr>: Anwendungskürzel
<Version>: Version
<Company>: Firmenkürzel
<ComponentPath>: Komponentenpfade
<AddOnApps>: Suchen in Anwendungen
<Variant>: Variante
<DebugAllowed>: Debuggen erlaubt
<SearchOrder>: Suchreihenfolge
<WarnLevel>: Warnstufe
<CfgUnit>: ConfigUnit

Bedeutung der XML-Tags im Report für „OOPSE“:
<Message>: Meldung
<File>: Datei
<Line>: Zeile
<Code>: Eindeutige Kennung

Bedeutung der XML-Tags im Report für „CNDOPS“:
<Operation>: Name der Operation
<ID>: Eindeutige Kennung
<Code>: Meldungsgruppe mit Meldungsnummer in Klammern
<Message>: Meldungstext
<Severity>: Severity Code (Gewichtung)
<Title>: Titel
<Impl>: Technische Implementierung des Moduls, wo der Laufzeitzustand gesetzt wurde
<Line>: Zeilenummer in dem Modul, wo der Laufzeitzustand gesetzt wurde
<RemoteTs>: Datum und Uhrzeit, wann der Laufzeitzustand auf anderem System (Host, andere Workstation) gesetzt wurde

Bedeutung der XML-Tags im Report für „WFLOPS“:
<BpState>: Arbeitsgang-Zustand
<BpID>: Arbeitsgang-ID (Eindeutige Kennung)
<BpName>: Arbeitsgang-Name
<BpTitle>: Arbeitsgang-Titel
<BpCheckDays>: Prüfen nach (Tage)
<BpCheckDate>: Termin für Wiedervorlage
<BpRespOE>: Wechsel der Organisations-Einheit
<OEKey> : Schlüssel der verantwortlichen Organisations-Einheit
<OEName>: Name der verantwortlichen Organisations-Einheit
<OETitle>: Titel der verantwortlichen Organisations-Einheit
<OEUserID>: ID des Arbeitsgang-Verantwortlichen (Eindeutige Kennung)
<OEUserName>: Name des Arbeitsgang-Verantwortlichen

Bedeutung der XML-Tags im Report für „SCHWOPS„
<Operation>: Name der Operation
<SchwebeName>: Name der Schwebe
<SchwebeKz>: Schwebekennzeichen
<Objects>: Darunter werden die mit der Schwebe verbundenen Objekte aufgelistet

Bedeutung der XML-Tags im Report für „TRXOPS“:
<Operation>: Name der Operation
<Result>: Ergebnis (Nur bei Operation „End“)

Bedeutung der XML-Tags im Report für „WFLPROPS“:
<Input>: Darunter werden die eingehenden Workflow-Eigenschaften aufgelistet
<Output>: Darunter werden die ausgehenden Workflow-Eigenschaften aufgelistet
<Set>: Darunter werden die gesetzten Workflow-Eigenschaften aufgelistet
<Name>: Name der Workflow-Eigenschaft
<Value>: Wert der Workflow-Eigenschaft

Bedeutung der XML-Tags im Report für „STRGVARS“:
<Name>: Name der Steuerungs-Variable
<Value>: Wert der Steuerungs-Variable

Bedeutung der XML-Tags im Report für „STARTREQS“:
<Modl>: Modulname\? <Operation>: Auszulösende Operation
<Appl>: Anwendung
<Type>: Modultyp
<CfgUnit>: ConfigUnit
<ModlDefDate>: Moduldefinition (Datum)
<CheckDate>: Wiedervorlagedatum
<GevoType>: Geschäftsvorfall-Typ
<GevoTitle>: Geschäftsvorfall-Titel
<RegisterOnly>: Geschäftsvorfall nur registrieren
<GevoID>: ID des zu startenden Geschäftsvorfalls (Eindeutige Kennung)
<ParentGevoID> : ID des aufrufenden Geschäftsvorfalls (Eindeutige Kennung)
<GevoOE> : Verantwortliche Organisations-Einheit für den Geschäftsvorfall
<GevoUser>: Verantwortlicher Sachbearbeiter für den Geschäftsvorfall
<CurrOE>: Aktuell verantwortliche Organisations-Einheit
<CurrUser>: \ Aktuell verantwortlicher Sachbearbeiter
<Category>: Ordnungsbegriff
<Agent>: Vermittlernummer
<Client>: Partnernummer
<CheckDays>: Prüfen nach (Tage)
<StateOK>: Bei Erfolg diesen Zustand setzen
<StateError>: Bei Fehler diesen Zustand setzen
<SubmittedSuccessfully>: Erfolgreiche Request-Einstellung
<Sguts>: Darunter wird das (aktuell selektierte) Schriftgut aufgelistet
<WflProps>: Darunter werden die Workflow-Eigenschaften aufgelistet

Bedeutung der XML-Tags im Report für „NVPAIRS“:
<Name>: Name des Name/Wert-Paars
<Value>: Wert des Name/Wert-Paars

Bedeutung der XML-Tags im Report für „SGUT“:
<ctrSgut>: Darunter wird die Struktur des Schriftguts aufgelistet

Bedeutung der XML-Tags im Report für „OBJECTS“:
<Input>: Darunter werden die eingehenden Objekte aufgelistet
<Output>: Darunter werden die ausgehenden Objekte aufgelistet
<Name>: Name des Objekts
<DclName>: Deklarierungsname des Objekts (Name unter dem das Objekt ursprünglich als lokales Objekt angelegt wurde)
<Scope>: Deklarierungs-Baustein (Name des Bausteins, in dem das Objekt ursprünglich als lokales Objekt angelegt wurde)
<Type>: Objekttyp
<Dstr>: Datenstruktur
<Length>: Länge der Datenstruktur
<DefDate>: Datenstruktur-Definition (Datum)
<Class>: Klasse
<Role>: Rolle
<ByValue>: By Value
<ItemCount>: Anzahl enthaltene Sätze
<CurrItem>: Aktueller Satz

Wenn es für ein Element keinen Wert gibt, wird das Attribut „empty=yes“ verwendet.