Begriffserläuterung
Tasks beinhalten die Oberflächenlogik des JET Clients. Zur Oberflächenlogik zählen Funktionen, die ausschließlich grafischen Charakter besitzen, z.B. die Logik, um einen Dialog anzuzeigen.
Beim Starten des Clients werden die in der task.xml angegebenen Tasks in den Task-Pool geladen und stehen somit zum Aufruf zur Verfügung.
Der Aufruf kann zum einen programmgesteuert aus dem Client erfolgen. Zum anderen können die Tasks über die XML-Oberflächenbeschreibungen aufgerufen werden.
Beispiel: In der task.xml wird der Task „com.command_ag.jet.client.task.TestTask" mit dem Namen „TEST" registriert. Nun ist es möglich, diesen Task über eine XML-Oberflächenbeschreibung folgendermaßen anzusprechen:
<transaction id="ANWG-DROPPED">
<enabled>true</enabled>
<action type="TEST" /> <!-- Aufruf des TestTasks -->
</Transaction>
Es ist noch auf das Element <enabled> hinzuweisen. Ist dieses nicht vorhanden oder auf false gesetzt, so ist diese Transaktion für alle externen Aufrufe nicht sichtbar (z.B. werden Menüpunkte disabled). In diesem Falle kann die Transaktion nur noch durch eine <action type="run" /> erreicht werden.
XML-seitige Verwendung eines Tasks
Tasks können in einer XML-Maskenbeschreibung innerhalb einer Transaktion über das Action-Tag aufgerufen werden.
Beispiel:
<transaction id="Beispiel">
<enabled>true</enabled>
<action type="einfacher-Task" />
<action type="komplexer-Task" sourceprogram="" sourcecomponent="COMP01"
targetprogram="" targetcomponent="*">
<option name="option 1" value="wert 1" />
<option name="option 2" value="wert 2" />
</action>
</Transaction>
In seltenen Fällen kann ein Task auch als Targetprogramm zu einem call-Task angegeben werden (s. Abschnitt 13.6.1).
Java-seitige Implementierung eines Tasks
Eine Klasse gilt als Task, sobald sie das Interface com.command_ag.jet.client.task.Task implementiert. Ist diese Anforderung erfüllt, kann sie über die task.xml registriert und somit beim Starten des Clients geladen werden.
Das Task-Interface definiert die Methode „public void run(Context context, Object source)", die aufgerufen wird, sobald der Task ausgeführt werden soll. Zu beachten ist, dass Tasks keine Zustandsinformationen besitzen dürfen. Die ausgeführte Aktion muss immer in sich geschlossen sein.
Quelle und Ziel von Tasks
Viele Tasks benötigen einen Input und erzeugen einen Output. Input und Output werden über die Attribute sourceprogram / sourcecomponent für den Input und targetprogram / targetcomponent für den Output bestimmt. In der Regel sind Quelle und / oder Ziel bei den Tasks entweder zwingend erforderlich oder verboten, Kann-Regeln für die Angabe von Quelle und Ziel sind die Ausnahme.
Beispiel:
<action type="run" sourceprogram="" sourcecomponent="*" targetprogram="ALL" targetcomponent="US11200-DELETE-DATA" />
In ...component stehen i.a. Komponenten- oder Transaktions-ID, in ...program abgesehen von Sonderwerten i.a. XML-Dateien. Die gebräuchlichsten Werte für diese Attributpaare sind (nicht jeder task unterstützt alle der angeführten Werte!):
- ...program="" ...component="*": in diesem Falle sind die Felder des aktuellen XML Quelle bzw. Ziel für die Task-Daten. In dieser Konstellation kann das ...program-Attribut auch ganz weggelassen werden.
- ...program="" ...component="component-id": Hier ist eine einzelne Komponente des aktuellen XML Quelle bzw. Ziel des Task. Häufig tritt diese Konstellation in Zusammenhang mit Tabellen auf (z.B. update eines Tabellensatzes). Auch hier kann ...program entfallen
- ...program="EVENT" ...component="DATA": Quelle bzw. Ziel sind die Ereignisdaten. Diese werden meist verwandt, um Daten von einem anderen XML zu holen oder dorthin zu verbringen.
- ...program="benuterspezifischer Begriff" ...component="DATA": Quelle bzw. Ziel sind ein benutzerdefinierter Speicher. Dieser Speicher läßt sich verwenden um Daten über Transaktionsgrenzen wegzuretten. Dieser Speicher ist global, d.h. jedes Programm innerhalb eines Modus kann darauf zugreifen.
- ...program="CALLER" : Der Task bezieht sich in diesem Fall auf das das aktuelle XML aufrufende XML (Bedingung: das aktuelles XML wurde durch das aufrufende XML mit <action type="open" > geöffnet).
- ...program="VISIBLE" ...component="component-id": Der Task bezieht sich auf das auf der rechten Seite sichtbare Programm.
- ...program="IGNORE" : Nur für das Ziel möglich (targetprogram), es werden die vom Task rückgegebenen Daten komplett ignoriert. Keine Angabe einer Zielkomponente.
- ...program="ALL" ...component="transaktion": Nur für das Ziel möglich, in diesem Fall werden die Daten an die in component angegebene Transaktion in allen offenen XML gesendet. Falls in den offenen XML die Transaktion aus component vorhanden ist, so wird sie ausgeführt.
- ...program="NAVIGATION" ...component="component-id": Ziel bzw. Quelle des Task ist eine Komponente im zugehörigen Navigations-XML. Dieses kann der Explorer (rechts oben im Client) oder der steuernde MC (rechts unten im Client) sein.
- ...program="NEW": Insbesondere für den OpenTask.
- ...program="POPUP": Insbesondere für den OpenTask
- ...program="taskname": Nur für CallTask und den RunDependentTask
Optionen
In vielen Fällen übernehmen die Option-Elemente in den Tasks steuernde Funktionen. Ein Option-Element hat den allgemeinen Aufbau:
<option name="options-name" value="options-wert" />
Wenn im Folgenden von der Option xy gesprochen wird, so ist damit der options-name gemeint, und bei der Erwänung des Wertes der Option wird auf options-wert referenziert. Bei sprachenabhängigen Optionswerten kann anstelle des Attributes value auch transid stehen. In letzterem Fall wird der Wert des Attributes transid als Schlüssel für die sprachenabhängige Properties-Datei benutzt:
<option name="text" transid="X77216" />
Allgemeine Basis-Tasks
CallTask (auch bekannt als EJB-Task)
Mit dem call-Task werden oxaion Serverprogramme aufgerufen. Die Eingabedaten können von einem Programm, einer Komponente oder vom EVENT.DATA zur Verfügung gestellt werden. Zusätzlich werden die Optionen der Action als Eingabeparameter verwendet. Dabei sind die folgenden Optionen Pflichtangaben.
- program – spezifiziert das aufzurufende Serverprogramm
- method – spezifiziert die im Programm auszuführende Aktion
Die Ausgabedaten des Severprogrammes können auf ein Programm, auf eine Komponente oder in EVENT.DATA eingestellt werden. Bei targetprogram="IGNORE" werden die Ausgabedaten ignoriert.
Der Programmname wird über die Option program, die Aktion über method definiert. Über zusätzliche <option>-Tag können dem Serverprogramm weitere Parameter übergeben werden (vgl. Beispiel 2).
Beispiel 1 – Aufruf eines Serverprogrammes mit Eingabedaten aus EVENT.DATA:
<action type="call" sourceprogram="EVENT" sourcecomponent="DATA"
targetprogram="" targetcomponent="*">
<option name="program" value="US11200J" /> <!--Programm -->
<option name="method" value="*DEL" /> <!--Akto -->
</action>
Beispiel 2 – Aufruf eines Serverprogrammes mit allen Feldern eines XML, zusätzlichen Optionen und Ausgabe der Parameter auf EVENT.DATA
<action type="call" sourceprogram="" sourcecomponent="*"
targetprogram="EVENT" targetcomponent="DATA">
<option name="program" value="VK20100J" />
<option name="method" value="*EDITTEXT" />
<option name="FFMT" value="KK" />
<option name="SSID" value="*SSID*" />
</action>
Weiter können im call-Task Transaktionshandler für Ausnahmen angegeben werden. Diese ermöglichen es, dass bei Eintritt eines bestimmten Ereignisses eine bestimmte Transaktion ausgeführt wird. Ein typisches Beispiel dafür ist die Prüfung der Programmberechtigung auf dem Server beim Betreten eines neuen XML (Programm):
<transaction id="LOAD">
<action type="call" targetprogram="" targetcomponent="*">
<option name="program" value="VK20100J" />
<option name="method" value="*LOAD" />
<option name="NOHWPgm" value="VK20100" />
<option name="NoHints" value="*NoHints*" />
<transactionhandler type="04" exit="true"
transaction-ref="CANCEL" />
</action>
</transaction>
Wenn das Serverprogramm feststellt, dass eine Programmberechtigung nicht vorhanden ist, dann wird der Transaktionskode '04' zurückgeschickt, was dann die Ausführung der CANCEL-Transaktion bewirkt. Wichtig ist das Attribut exit für das <transactionhandler>-Tag, es entscheidet,darüber, ob nachfolgende Aktionen in der <transaction> noch ausgeführt werden. Im Falle von exit="true" (Unterlassungswert) wird die Transaktion abgebrochen und nur noch die Transaktion aus dem transaction-ref -Attribut ausgeführt. Für exit="false" wird zunächst die im transaction-ref-Attribut angeführte Transaktion ausgeführt und anschließend die in der ursprünglichen Transaktion noch abzuarbeitenden Aktionen. Um einer Falle vorzubeugen: die Ausführung der im transaction-ref -Attribut angegebenen Transaktion gilt schon dann als abgeschlossen, wenn innerhalb dieser Transaktion ein modaler Dialog aufgerufen wird und dieser noch nicht durch den Sachbearbeiter bearbeitet und beendet wurde. In dem Moment wo der modale Dialog aufgerufen ist und auf die Benutzereingaben wartet, werden die verbleibenden Aktionen der fehlerverursachenden Transaktion ausgeführt.
Für bestimmte Task ist es möglich, diese als Parameter zum Attribut targetprogram im call-Task anzugeben. Damit werden die Daten, die der call-Call zurückliefert gleich an den Task im Attribut targetprogram zur weiteren Verarbeitung weitergeleitet. Ein Beispiel ist z.B. der Druck der MC-Auflistung oder die Excel-Ausgabe für eine Tabelle.
Beispiel:
<action type="call" targetprogram="TASK_PRINT_TABLE" targetcomponent="*"> <option name="program" value="US63173J" /> <option name="method" value="*FIRSTLIST" /> </action>
Beim call-Task kann die Optionen mode mitgegeben werden, um zu steuern, wie das Ergebnis des Calls im Client eingestellt wird:
merge: Betrifft normale Masken (keine Bäume oder Tabellen). Es werden nur die Felder bzw. Werte ausgetauscht, die vom Server geschickt werden. Alle nichtgesendeten Felder behalten ihre alten Werte.
no-attribute-update: Betrifft normale Masken (keine Bäume oder Tabellen). Alle Bildschirmattribute der Maske bleiben erhalten, unabhängig davon, ob Attribute vom Server zurückkommen und mit welchen Inhalten.
update: Gültig für eine Zielkomponente (targetcomponent) vom Typ TABLE, TREE oder GANTT. Es werden nur die Zeilen bzw. Teilbäume in der Empfängerkomponente beeinflusst, die mit ihrem Schlüssel den Schlüsseln der empfangenen Daten entsprechen. Wird der Schlüssel der empfangenen Zeile bzw. des Teilbaumes nicht gefunden, so wird der Satz / Teilbaum ganz unten angehängt (wenn die Tabelle / der Baum bereits EOF empfangen hat) oder ganz oben eingefügt (wenn die Tabelle / der Baum noch kein EOF empfangen hat). Existiert im Falle der Tabelle der gesendete Satz bereits, so wird er komplett überschrieben. Existiert im Falle des Baumes der gesendete Teilbaum bereits, so wird die Wurzel des Teilbaumes sowie alle von der iSeries mitgegebenen Kinder überschrieben bzw. eingefügt. Kinder, die vor dem Call existierten und für die keine Information empfangen wurden, bleiben stehen. Wird im Falle des Trees im Datenstrom für einen Schlüssel <REMOVE>TRUE</REMOVE> mitgegeben, so wird der zugehörige Knoten entfernt. Dies ist der einzige Mode beim Baum, wo der zugehörige Knoten entweder aufgeklappt bleibt oder aufgeklappt wird.
remove: Betrifft Tabellen. Der angegebene Satz wird aus der Tabelle entfernt.
reset: Betrifft Tabellen. Alle Tabellenformatierungen werden auf die Unterlassungswerte zurückgesetzt, z.B. aktuelle Sicht (1. Sicht), Spaltenbreiten, Selektionen usw. Die alten Tabellensätze werden komplett entfernt und durch die neu empfangenen ersetzt.
replace: Betrifft Tabellen. Wie reset, aber die Tabellenformatierungen bleiben erhalten (z.B. auch die gerade aktuelle Sicht). Betrifft weiterhin Chart und Tree. Es werden die Daten komplett ersetzt. Beim Baum wird damit auch die Wurzel durch den Wurzelknoten in den neu übermittelten Daten ersetzt.
update-no-select: Betrifft Bäume. Wie „update" allerdings wird der neu eingefügte oder ersetzte Teilbaum nicht selektiert. Es
replace-tree Betrifft Bäume. Teilbaum wird komplett ersetzt, auch der vom Server übergebene Wurzelknoten wird ersetzt, Unterbäume werden, falls vorhanden, eingeklappt. Existiert der übergebene Wurzelknoten nicht, dann passiert nichts.
replace-children: Betrifft Bäume. Wurzel des Teilbaumes bleibt unverändert, der vom Server übergebene Wurzelknoten dient lediglich als Anker. Ansonsten ist die Wirkungsweise wie bei replace-tree.
Wird im Call keine Option mode mit einem der oben aufgeführten Werte angegeben, dann werden in der Regel alle Daten, Attribut und Formatierungsoptionen überschrieben.
Während die Option mode steuert, wie die Ergebnis-Daten eingestellt werden, kann die Option source-mode verwendet werden, um die Quell (=Input)-Daten zu ermitteln. Dabei gibt es folgende Bedeutungen:
- source-mode nicht angegeben: Die Daten aus sourcecomponent werden als <DTA>-Tag bereitgestellt. Bei Bäumen und Tabellen wird der KEY der aktuellen Zeile als <DTA>-Tag an das Server-Programm gesendet.
- source-mode=get-edited: Alle Tabellen-Zeilen einer Tabelle werden in einem <TABLE>-Objekt übertragen, wenn die Zeile vom Benutzer geändert wurde (verwaltbare Auflistung). Die <ROW> besteht aus dem Schlüssel des Satzes und den editierbaren Zellen.
- source-mode=get-selected: Alle Tabellen-Zeilen, die vom Benutzer markiert (= mit der Maus und der Shift-Taste angeklickt wurden) werden in einem <TABLE>-Objekt übertragen. Die <ROW> besteht aus dem Schlüssel des Satzes und den editierbaren Zellen.
- source-mode=get-checkmarked: Alle Tabellen-Zeilen, für die der Benutzer die checkmarkable-Checkbox aktiviert hat, werden in einem <TABLE>-Objekt übertragen. Die <ROW> besteht aus dem Schlüssel des Satzes und den editierbaren Zellen.
Beispiel:
<action type="call" sourceprogram="" sourcecomponent="TABLE"
targetprogram="EVENT" targetcomponent="DATA">
<option name="program" value="US11920J" />
<option name="method" value="*TEST" />
<option name="source-mode" value="get-selected" />
</action>
Die vom oxaion Server gesendeten Bildschirmattribute (ATR-Tag) ersetzen normalerweise alle bisher gesetzten Bildschirmattribute (siehe auch State-Bereich). Das kann man über die Option merge-attributes verhindern – dann werden nur die neuen Attribute gesetzt, die alten bleiben aber erhalten.
Über die Option activation-group kann der Serveraufruf in einer beliebigen Aktivierungsgruppe erfolgen. Vorsicht: Diese Aktivierungsgruppe wird bei Beenden des Programms nicht automatisch geschlossen. Diese Option sollte daher den Dashboards vorbehalten sein, welche hierüber alle Gadgets aus einem Programm in verschiedenen Aktivierungsgruppen ausführen können.
CallThreadTask
Dieser Task läuft völlig analog zum call-Task, jedoch in einem separaten Thread. Dadurch erhält der Benutzer schon eine Anzeige, wenn dieser Task noch arbeitet (der berühmte ganz blaue Schirm entfällt also). Mit diesem Task wird die gefühlte Performance gesteigert. Wichtig: während dieses Tasks dürfen keine anderen Aktivitäten laufen, so dass er überwiegend beim Laden der Explorer zum Programmstart eingesetzt wird.
Beispiel:
<action type="call-thread" sourceprogram="" sourcecomponent="NAVCOMP"
targetprogram="" targetcomponent="NAVCOMP">
<option name="program" value="PA11590J" />
<option name="method" value="*FIRSTLIST" />
<option name="SSID" value="*SSID*" />
</action>
UpdateTask
Der UpdateTask stellt Werte aus einer beliebigen Source in ein beliebiges Target ein. Ist das Target ein Programm oder der EVENT.DATA -Zwischenspeicher, werden die Daten additiv hinzugefügt.
Zusätzlich unterstützt der UpdateTask folgende Funktionen:
- copy: Bei Angabe von <option name="copy" value="KEY1 NEU_KEY1 KEY2 NEU_KEY2 ..." /> werden die Schlüssel-Werte Paare kopiert, in dem obigen Beispiel also KEY1 nach NEU_KEY1 und KEY2 nach NEU_KEY2
- copy-exists: wie copy, aber mit dem Unterschied, daß die Dateninhalte nur kopiert werden, wenn sie nicht leer sind.
- remove: Bei Angabe von <option name="remove" value=" KEY1 KEY2..." /> werden die Schlüssel entfernt.
- clean: Bei Angabe von <option name="clean" /> wird der UndoManager des Targetprogrammes zurückgesetzt.
- concat: Bei Angabe von <option name="concat" value=" KEY1 KEY2...KEYn" /> werden die Inhalte von KEY1, KEY2 bis zum vorletzten Feld in value zusammengekettet und unter KEYn abgelegt.
- select: Bei Angabe von <option name="select" value=" KEY1 KEY2 ..." /> werden nur die angegebenen Daten kopiert.
- Es lassen sich über den UpdateTask auch fixe Werte zu einer Source hinzufügen und auf das Target kopieren. Dazu ist eine Option mit dem Namen des Feldes und dem fixen Wert hinzuzufügen: <option name="PosKopf" value="1" />.
Mögliche Werte bei TargetProgramm sind:
„VISIBLE": für das aktuell sichtbare Programm,
„CALLER": für das aufrufende Programm
ansonsten ist auch als targetprogram/-component EVENT.DATA möglich
Beispiel 1: Daten von EVENT.DATA auf den Panel stellen
<action type="update" sourceprogram="EVENT" sourcecomponent="DATA"
targetprogram="" targetcomponent="*" />
Beispiel 2: Selektives kopieren
<action type="update" sourceprogram="" sourcecomponent="*"
targetprogram="EVENT" targetcomponent="DATA">
<option name="select" value="AUNR KEYTYPE" />
</action>
Beispiel 3: Dateninhalte kopieren
<action type="update" sourceprogram="EVENT" sourcecomponent="DATA">
<option name="copy" value="PKNR KDNR" />
</action>
Beispiel 4: Daten entfernen
<action
type="update" sourceprogram="EVENT" sourcecomponent="DATA">
<option name="remove" value="NOHWPgm" />
</action>
Beispiel 5: Fixe Daten hinzufügen (in diesem Beispiel wird EVENT.DATA um das Feld PosKopf mit dem Wert '1' erweitert. Die Gleichheit von Source und Target ist jedoch nicht zwingend)
<action type="update" sourceprogram="EVENT" sourcecomponent="DATA"
targetprogram="EVENT" targetcomponent="DATA">
<option name="PosKopf" value="1" />
</action>
CopyFormattedTask
Dieser Task kopiert den durch Inhalt des in der Option copy bezeichneten Key (hier KDNR) auf die in targetcomponent bezeichnete Komponente. Das besondere dabei ist, daß der Task dabei die spezifischen Bedürfnisse der Komponente berücksichtigt (z.B. bei der Teilenummernkomponente mit den Feldern IDNR und I_IDNR) bzw. die Werte auf die Unterfelder einer Komponente verteilt (z.B. KDNR = ‚1000002 000" wird auf die Unterfelder KOKDNR und KOFINR der Komponente AKDNR verteilt).
Beispiel:
<action type="copy-formatted" sourceprogram="EVENT" sourcecomponent="DATA"
targetprogram="" targetcomponent="AKDNR">
<option name="copy" value="KDNR" />
</action>
DataTask
Dieser Task erlaubt es eine Transaktion bedingt abzubrechen. Der Task wird vor allem beim Löschen von Datensätzen verwendet.
Wird z.B. über das Kontextmenü im Navigationsbereich auf der linken Seite von JET ein Satz gelöscht, dann muss ggf. auf der rechten Seite die Detailmaske geleert werden, wenn dort gerade der gelöschte Satz angezeigt wird. Dazu ruft der löschende Prozess (in diesem Fall der Navigationsbereich auf der linken Seite) eine Transaktion für alle offenen Programme (XML-Dateien) auf (im folgenden Beispiel ist das die Transaktion "VK20100-DELETE-DATA"). Diese Transaktion soll dafür sorgen, dass die Maske geleert wird, wenn sie gerade den gelöschten Satz anzeigt. Allerdings nur dann, wenn es sich um den gleichen Satz handelt. Diese Aufgabe wird wie folgt realisiert:
<transaction id="VK20100-DELETE-DATA">
<enabled>true</enabled>
...
<action type="data" sourceprogram="" />
<action type="switch-state" targetprogram="">
<option name="state" value="LEER" />
</action>
<action type="clear-container"
targetprogram="" targetcomponent="T00002" />
</transaction>
Die <action> vom Typ data sorgt nun dafür, dass die nachfolgenden Aktionen in der Transaktion nur dann ausgeführt werden, wenn die gesendeten Daten (das sind diejenigen aus EVENT.DATA (vgl. Abschnitt 5.7), die in diesem Fall den Schlüssel des gelöschten Satzes beinhalten) in den Daten von sourceprogram / sourcecomponent enthalten sind. Andernfalls wird die Transaktion mit dem DataTask abgebrochen und die Maske nicht geleert.
Mit der Option <option name="check" value="…" /> kann eine blankseparierte Liste der zu prüfenden (Schlüssel-)Felder angegeben werden. Damit wird der DataTask robuster gegen zufällig im EVENT.DATA stehende Felder.
CheckCallerTask
Auch der CheckCallerTask unterbricht wie der DataTask eine Transaktion, wenn eine gewisse Bedingung erfüllt ist. Die Funktionsweise soll anhand von MC-Programmen beschrieben werden. Ein MC-Programm kann entweder von einem anderen Programm bei Betätigung der F4-Taste oder stand alone aufgerufen werden. Im ersten Fall muss bei Selektion eines Satzes der selektierte Wert an das aufrufende Programm übergeben und das MC-Fenster geschlossen werden. Wenn das MC-Programm stand alone aufgerufen wurde, dann soll dies genau nicht geschehen. Mit dem CheckCallerTask kann nun genau das geprüft werden.
Beispiel:
<transaction id="selected">
<enabled>true</enabled>
<action type="check-caller" targetprogram="CALLER" />
<action type="update" sourceprogram="" sourcecomponent="NAVCOMP"
targetprogram="CALLER" targetcomponent="*" />
<action type="close" targetprogram="" />
</trnsaction>
Mit der <action> vom Typ "check-caller" wird geprüft, ob ein CALLER-Programm existiert. Nur wenn das der Fall ist, werden die restlichen Aktionen der Transaktion ausgeführt.
Es ist darüber hinaus möglich, zu prüfen, ob das rufende Programm ein genau spezifiziertes Programm ist. Das ist mit der Option xml möglich.
Beispiel:
<action type="check-caller" targetprogram="CALLER">
<option name="xml" value="vks/vk20140.xml" />
</action>
In diesem Falle wird die Transaktion nur unterbrochen, wenn es ein rufendes Programm gibt und dieses Programm vk20140.xml heißt.
Die Option xml kann auch eine mit Leerzeichen getrennte Liste von Programmen angegeben werden. Über die Option reverse wird die Liste negiert, d.h. die Transaktion wird abgebrochen, wenn es das Targetprogramm gibt und es nicht in der Liste ist.
Über die Option model kann man weiterhin einschränken, dass das Targetprogram selbst in einem Dialog dargestellt wird. Dazu muss die Option xml angegeben sein, aber nicht die Option reverse.
CheckExplorerTask
Dieser Task dient dazu, dem RPG-Serverprogramm mitzuteilen, ob das dazugehörige XML gerade in einem Explorerkontext (genauer in einer Card-Komponente) oder stand-alone läuft. Dazu wird im positiven Falle in das durch die Option field gekennzeichnete Feld (im Beispiel ist das InExplorer) der Wert TRUE gestellt und das Feld in das Target gestellt.
Beispiel:
<action type="check-explorer" sourceprogram=""
targetprogram="" targetcomponent="*">
<option name="field" value="InExplorer" />
</action>
ClearEventDataTask
Mit diesem Task ist es möglich, die Daten in EVENT.DATA zu löschen. Der Task löst das Verfahren aus 5.3 ab, in welchem mit dem ClearTask auch die Inhalte von EVENT.DATA gelöscht wurden.
Beispiel:
<transaction id="PW20100-set-key">
<action type="clear-event-data" />
...
</transaction>
Panel-bezogene Tasks
OpenTask
Mit dem OpenTask kann man Dialoge öffnen.
Häufig wird dieser Task in den Stammdatenprogrammen verwendet, um die Leitdaten- oder Kopiermaske beim Neuerfassen bzw. Kopieren eines Datensatzes aufzurufen. Über die Option xml wird die Panelbeschreibung für den Dialog bestimmt.
Beispiel:
<action type="open" targetprogram="NEW">
<option name="xml" value="ust/us11300_n.xml" />
</action>
Das neu eröffnete Fenster kann über sourceprogram/sourcecomponent mit Daten versorgt werden. Bei sourceprogram/sourcecomponent kann auch EVENT.DATA angegeben werden. Als targetprogram ist NEW, NEW-BLOCKING, FLOATING und POPUP möglich.
Der Wert NEW-BLOCKING ist besonders interessant, weil er den Ablauf in der aufrufenden Transaktion solange anhält, bis der geöffnete modale Dialog wieder geschlossen wird. Der Ablauf der aufrufenden Transaktion nach Schließen des modalen Dialoges ist dabei abhängig davon, ob der modale Dialog mit <action type="cancel" /> oder <action type="close" /> geschlossen wurde. Im letzten Fall wird die aufrufenden Transaktion normal weiter ausgeführt, im ersten Fall wird die Transaktion entweder abgebrochen oder mit einer anderen Transaktion fortgeführt (<option name="cancel-transaction" />).
Im allgemeinen ist der Aufruf mit NEW-BLOCKING demjenigen mit NEW vorzuziehen, da er Java-technisch weniger problematisch ist. NEW ist nur dann anzuwenden, wenn nach dem Eröffnen des Dialoges im Hintergrund weitere Aktionen auszuführen sind (bspw. muss explizit vom CALLER noch eine Transaktion in dem geöffneten Dialog aufgerufen werden), oder wenn sich der OpenTask in einer LOAD-Transaktion befindet. In diesem Fall ist NEW-BLOCKING verboten.
Beispiel:
<action type="open" sourceprogram="" sourcecomponent="*"
targetprogram="NEW-BLOCKING">
<option name="xml" value="ust/us13220r.xml" />
<option name="MODE" value="*SHOW" />
<option name="HIDE-EMPTY" value="*YES" />
<option name="TITLE" transid="TTTL001" />
<option name="cancel-transaction" value="doSomething" />
</action>
Normalerweise wird dem neu geöffneten Programm die gleiche Aktivierungsgruppe wie die des Aufrufers zugewiesen. Möchte man aber erreichen, dass beim Öffnen eines solchen Dialoges eine neue Aktivierungsgruppe erzeugt werden soll, muss die Option NEW_ACTG angegeben werden.
Beispiel:
<action type="open" sourceprogram="" sourcecomponent="*"
targetprogram="NEW">
<option name="xml" value="ust/us210102.xml"/>
<option name="SSID" value="*SSID*"/>
<option name="NEW_ACTG" value=""/>
</action>
Es ist möglich, den OpenTask auch ohne fest kodiertes XML (option name="xml"/>) aufzurufen. In diesem Fall muss das zu öffnende XML über sourceprogram/source component übermittelt werden. Dabei wird im Feld ANWG das Anwendungsgebiet und im Feld PGMN das zu öffnende XML (ohne die Endung .xml!) übergeben werden. Meistens wird in diesen Fällen mit einem Call mit Target EVENT.DATA das auszuführende Programm ermittelt und anschließend der OpenTask mit Sourcen EVENT.DATA ausgeführt.
Beispiel:
<action type="call" sourceprogram="EVENT" sourcecomponent="DATA"
targetprogram="EVENT" targetcomponent="DATA">
<option name="program" value="VK10100J" />
<option name="method" value="*DROPPED" />
<transactionhandler type="MATCHCODE" exit="true"
transaction-ref="VK10100-OPEN-MATCHCODE" />
</action>
<transaction id="VK10100-OPEN-MATCHCODE">
<action type="open" sourceprogram="EVENT" sourcecomponent="DATA"
targetprogram="NEW-BLOCKING" />
...
</transaction>
Das aufrufende Programm merkt sich eine Referenz auf das geöffnete Programm, wenn man die Option dependent="true" angibt. Diese kann dann bspw. von einem RunDependentTask verwendet werden, um die abhängigen Programme zu informieren.
Diese Referenzen auf geöffnete Programme, können über die Option dependent-group auch in logische Gruppen zusammengefasst werden. Wenn dann insbes. auch der RunDependentTask diese Option verwendet, dann werden nur die Programme in dieser Gruppe angesprochen – wenn er aber keine Gruppe angibt, werden alle abhängigen Programme in allen Gruppen angesprochen. Andersrum sind Programme, die in keiner Gruppe sind, nur über einen RunDependentTask ansprechbar, der selbst ebenfalls keine Gruppe angibt.
Solche Abhängigkeitsgruppen werden in komplexen Auskunftstreibern (bspw. vk20500r) verwendet, die aus unterschiedlichen Feldern heraus FLOATING Fenster öffnen und getrennt voneinander wieder schließen wollen, wenn das Feld geändert wird.
Beispiel:
<action type="open" sourceprogram="EVENT" sourcecomponent="DATA"
targetprogram="NEW-BLOCKING"
<option name="dependent" value="true" />
<option name="dependent-group" value="IDNR" />
</action>
Durch die Option decorate lässt sich dem zu öffnenden Dialog ein spezielles Aussehen verpassen. Als mögliche Ausprägung bei Auflistungsprogrammen kommt der Wert matchcode in Frage.
<action type="open" sourceprogram="EVENT" sourcecomponent="DATA" targetprogram="NEW"> <option name="decorate" value="matchcode" /></action>
CloseTask
Der CloseTask schließt das angegebene TargetProgram. Ist der Speichern-Knopf aktiv, wird zuvor über eine Dialog-Box gefragt, ob die Daten gespeichert werden sollen.
Sollte mehr als eine Referenz auf das angegebene TargetProgram zeigen, wird die Referenz entfernt, das Programm bleibt jedoch offen. Man beachte die speziellen Auswirkungen im Zusammenhang mit den Open-Task und dem targetprogram="NEW-BLOCKING".
Beispiel:
<transaction id="CLOSE">
<enabled>true</enabled>
<action type="close" targetprogram="" />
<action type="close" targetprogram="NAVIGATION" />
</transaction>
In diesem Beispiel wird zunächst das aktuelle Programm geschlossen. Im zweiten CloseTask wird dann noch der zugehörige Navigationsbereich (targetprogram) geschlossen. Dies geschieht, wie bereits einleitend erwähnt, jedoch nur dann, wenn nicht noch weitere Detailprogramme der rechten Seite im Client auf denselben Navigationsbereich auf der linken Seite referenzieren.
NewWindowTask
Mit diesem Task wird ein neues Hauptfenster aufgemacht. Über die Opition size kann seine Größe festgesetzt werden (z.B. value="700*500").
Der Task wird nur noch selten benötigt; stattdessen werden in Auskunftssystemen normalerweise fliegenden Fenstern verwendet dialog.
Beispiel:
<transaction id="FlyingNextWindow">
<action type="new-window" />
<action type="open" sourceprogram="EVENT" sourcecomponent="DATA"
targetprogram="MAIN">
<option name="dependent" value="true" />
<option name="AKS_T_SSID" value="*AKS_T_SSID*" />
</action>
</transaction>
RunDependentTask
Startet eine Transaktion in allen „abhängigen" Programmen, d.h. allen Programmen, die von diesem Programm aus mit der Option dependent = true geöffnet wurden (siehe Kapitel 13.7.1 insbes. wegen der Option dependent-group, die auch hier angegeben werden kann).
Dieser Task wird in der Regel in Auskunftsprogrammen verwendet, um abhängige (fliegende) Fenster (siehe Kapitel 7.4) mit den sich verändernden Schlüsseldaten des zugrunde liegenden Fensters zu versorgen. Zum Beispiel könnten in dem Auskunftsprogramm „Aufträge je Kunde" die abhängigen Fenster „Positionen je Auftrag" und „Lieferscheine je Auftrag" geöffnet sein. Wenn nun ein anderer Auftrag in „Aufträge je Kunde" angeklickt wird, dann wird in beiden abhängigen Fenster die Transaktion DEPENDENT mit der neuen Auftragsnummer als Schlüsselbegriff aufgerufen.
Beispiel:
<action type="update" sourceprogram="" sourcecomponent="TABLE"
targetprogram="EVENT" targetcomponent="DATA">
<option name="PGMN" value="VK30100R" />
</action>
<action type="run-dependent" sourceprogram="EVENT" sourcecomponent="DATA"
targetprogram="" targetcomponent="DEPENDENT" />
Über die Option init-transaction kann man eine Transaktion im aufrufenden Frame angeben, die vor der Transaktion in jedem abhängigen Programm aufgerufen wird.
CloseChildrenTask
Mit diesem Task kann man ganze Ketten von Aufrufprogrammen schließen. Er wird hauptsächlich im Zusammenhang mit dem Auskunftsprogramm verwendet, wo man aus einem Programm ein weiteres aufruft und aus diesem wieder ein weiteres usw. Über die Option close-target kann man erreichen (Ausprägung false), daß nur die abhängigen Programme selber geschlossen werden, jedoch nicht das Programm, welches die Anweisung ausführt. Diese Option wird üblicherweise nur im Auskunftstreiber gesetzt, während sie in normalen Auskunftsprogrammen fehlt.
Beispiel:
<action type="close-dependent" targetprogram="">
<option name="close-target" value="false" />
</action>
Der Name close-dependent ist etwas unglücklich, da es nichts mit dem dependent im Sinne des RunDependentTask zu tun hat.
CloseWindowTask
Dieser Task wird ebenfalls nur der Vollständigkeit halber angegeben, da er nur als Aufruf aus dem Menü heraus sinnvoll ist. Er schließt je nach Parametern entweder das Programm im Detail-, im MC- oder im Explorerbereich.
CancelTask
Der CancelTask arbeitet analog zum CloseTask, aber mit dem unterschiedlichen Verhalten bzgl. des OpenTask mit targetprogram="NEW-BLOCKING".
Beispiel:
<transaction id="CANCEL">
<enabled>true</enabled>
<action type="cancel" targetprogram="" />
<action type="cancel" targetprogram="NAVIGATION" />
</Transaction>
ShowTask
Der ShowTask holt die als TargetProgram übergebene Maske in den Vordergrund, falls diese von anderen Programmreitern verdeckt wird. Dies ist dann nützlich, wenn der Benutzer z. B. ein Detailfenster anklickt und daraufhin automatisch das entsprechende Matchcodefenster im Vordergrund angezeigt werden soll.
Über die Option any-case kann man erzwingen, dass das angegebene Programm auch dann nach vorne geholt wird, wenn es das gleiche wie das aufrufende ist.
Beispiel:
<transaction id="SHOW">
<enabled>true</enabled>
<action type="show" targetprogram="NAVIGATION" />
</transaction>
DesignModeTask
Mit diesem Task wechselt man in den Design-Modus für das aktuell angezeigten Programmes.
Beispiel:
<transaction id="DESIGN">
<enabled>true</enabled>
<action type="design" />
</transaction>
NormalModeTask
Mit diesem Task wechselt man aus dem aus dem Designmodus wieder in den normalen Modus des Programs. Diese Aktion wird nicht in den XML-Dateien kodiert, sondern über den Designmanager ausgeführt. Dazu muss sich der Designmanager bereits im Designmodus befinden.
SwitchStateTask
Mit dem SwitchStateTask wird in einen anderen Zustand (<state>) verzweigt (s. state-Bereich). Vor der Verzweigung in den anderen Zustand wird geprüft, ob ggf. noch Datenänderungen vorhanden sind (auf der Oberfläche dadurch erkennbar, dass die Speichertransaktion enabled ist). Wenn dies der Fall ist, wird vor der Verzweigung der Dialog für die Speicherabfrage ausgegeben. Wenn die Oberfläche „half-dirty" ist (d.h. es gibt nicht verbuchte geänderte Daten, diese Daten wurden aber nicht durch den Benutzer sondern durch das System erzeugt – z.B. bei der Neuanlage von Belegelementen, vgl. vordefinierte Transaktionen), so wird keine Speicherabfrage ausgegeben, sondern die Transaktion DEFAULT_ROLLBACK ausgeführt.
Obwohl der SwitchStateTask eine Prüfung auf unverbuchte Daten enthält, sollte er im Allgemeinen nur nach der call-Aktion in einer Transaktion ausgeführt werden, dann ist die Oberfläche „clean". Einzige Ausnahme ist die "CANCEL"-Transaktion im <state> "AENDERN". In allen anderen Fällen wird, falls erforderlich, die Prüfung auf unverbuchte Daten vor einer call-Aktion mit der CheckSaveTask (vgl. Abschnitt CheckSaveTask) durchgeführt.
Der SwitchStateTask kann mit einem Zielprogramm (Attribut targetprogram) versehen werden (auch "VISIBLE" ist möglich).
Beispiel:
<action type="switch-state" targetprogram="">
<option name="state" value="AENDERN" />
</action>
DirtyTask
Der "dirty"-Zustand besagt, dass auf einer Maske über die Tastatur Daten verändert wurden, diese aber noch nicht durch einen call-Call verbucht wurden. In diesem Fall greift z.B. beim Abbruch oder beim Wechsel des <state> die im vorherigen Abschnitt beschriebene Logik (Speicherabfrage bzw. DEFAULT_ROLLBACK).
In manchen Fällen erfolgte die Änderung von Daten aber maschinell und nicht durch Tastatureingabe. Auch in diesen Fällen muss aber ein Wechsel in den "dirty"Zustand erfolgen, um einerseits die Speichertransaktion „SAVE" zu aktivieren und andererseit die Speicher bzw. Rollback-Logik im Falle des Abbruchs zu ermöglichen. Standardmäßig wird die "dirty"-Aktion in den Stammdatenerfassungsprogramm verwendet, wenn über einen modalen Dialog (Leitdatenmaske oder Kopierformat) ein Datensatz erfaßt oder kopiert wird. Nach dem Schließen des modalen Dialoges stehen die dort eingegebenen Daten und ermittelte Unterlassungswerte noch unverbucht in der Detailmaske der rechten Seite des JET-Klienten. Der Zustand wäre aber ohne die explizite "dirty"-Aktion im XML noch "clean".
Beispiel:
<transaction id="VK10100-new">
...
<action type="dirty" targetprogram="" />
...
</transaction>
ClearTask
Mit dem ClearTask können die Felder des angegebenen Target-Programmes gelöscht werden. Außerdem wird der Undo-Manager zurückgesetzt und das Programm in den „clean"-Zustand versetzt (vgl. vorherigen Abschnitt).
Beispiel:
<transaction id="CANCEL">
...
<action type="clear" targetprogram="" />
...
</transaction>
ClearTitleTask (SetProgramTitleTask)
Die Titel der Programmreiter und Container können zur Laufzeit verändert werden. Der ClearTitleTask setzt den Titel des Programmreiters wieder in den Ursprungszustand zurück. Der ClearTitleTask arbeitet nur bei Programmen, mit UICard-Komponenten.
Beispiel:
<transaction id="ON_TOP">
<action type="clear-title" targetprogram=""/>
</transaction>
CleanTask
Mit Hilfe des CleanTasks wird der Undo-Manager des Programms zurückgesetzt, das als „targetprogram" angegebenen wurde und das dirty-flag auf false gesetzt.
Beispiel:
<transaction id="showKK">
<enabled>true</enabled>
<action type="clean" targetprogram="" />
...
</transaction>
Somit können nach Ausführung des CleanTask keine Tastatureingaben mehr per Undo und Redo rückgängig gemacht, bzw. wiederholt werden.
ClearContainerTask
Mit diesem Task ist es im Unterschied zum ClearTask möglich, nicht die gesamte Detailmaske zu leeren (inkl. Überschriftenformat), sondern nur den Maskenbereich mit den Datenfeldern. Dies ist insbesondere bei Belegverwaltungsprogrammen sinnvoll, wenn ein in der Beleghierarchie untergeordnetes Belegelement gelöscht wird, die Felder mit den Daten des Belegelementes also geleert werden, aber die Belegdaten in der Maskenüberschrift stehen bleiben sollen.
Der zu leerende Container (id) wird über das Attribut targetcomponent angegeben. Der ClearContainerTask funktioniert nur für Container mit Laschenlayout (<type>TAB<type>, vgl. Container.)
Beispiel:
<transaction id="AfterVersionChange">
<action type="switch-state" targetprogram="">
<option name="state" value="LEER" />
</action>
<action type="clear-container"
targetprogram="" targetcomponent="C00001" />
<action type="run" sourceprogram="" sourcecomponent="*"
targetprogram="" targetcomponent="LOAD" />
</transaction>
CheckSaveTask
Der CheckSaveTask prüft, ob unverbuchte Daten in der Maske vorhanden sind. Die Prüfung und die Reaktion auf unverbuchte Daten erfolgt, wie im Abschnitt über den SwitchStateTask beschrieben.
Beispiel:
<transaction id="BA10100-TableDelete">
<enabled>false</enabled>
<action type="check-save" targetprogram="VISIBLE" />
...
</transaction>
CheckVisibleProgramTask
Der CheckVisibleProgramTask prüft, ob die aktuell sichtbare Maske im Detail-Bereich der angegebenen XML-Datei entspricht. Wenn nicht, öffnet der Task automatisch die entsprechende Maske im Detail-Bereich. Dies ist z. B. dann hilfreich, wenn der Benutzer im Matchcode-Bereich einen Datensatz auswählt, im Detail-Bereich aber gerade ein anderes Programm (z. B. der Programm-Explorer) angezeigt wird. Über den CheckVisibleProgramTask kann der Matchcode-Bereich prüfen, ob sich die zu ihm gehörige Detail-Maske gerade im Vordergrund befindet und wenn nicht, diese neu laden lassen.
Beispiel:
<transaction id="OPEN">
<enabled>true</enabled>
<action type="check-visible-program" targetprogram="">
<option name="xml" value="bar/ba10100.xml" />
</action>
...
</transaction>
Mit der Option run-dropped kann man den Task entscheidend modifizieren. Ist diese Option gesetzt, so wird zunächst geschaut, ob es zu den DnD-Daten des angeklickten Satzes im Detailbereich eine passende DROPPED-Transaktion gibt. Wird eine solche gefunden, so wird sie ausgeführt, im anderen Falle wird der normale CheckVisibleProgramTask durchgeführt.
Beispiel:
<action type="check-visible-program"
sourceprogram="" sourcecomponent="NAVCOMP" targetprogram="">
<option name="xml" value="vks/vk10100.xml" />
<option name="run-dropped" value="true" />
</action>
SetFocusFirstTask
Der SetFocusFirstTask wird benutzt, um den Fokus (Cursor) auf die erste verwaltbare Komponente eines Programmes zu setzen.
Mit Hilfe des Attibute targetprogram kann das Programm spezifiziert werden, für das die Aktion durchgeführt werden soll. Wenn die Option first-tab auf true gesetzt wird, dann wird auf die erste Lasche eines Laschen-Containers gewechselt; sonst bleibt die gerade aktive Lasche vorne.
Im Allgemeinen wird der SetFocusFirstTask verwendet, wenn in den Änderungsmodus verzweigt wird (z.B. Transaktion "OPEN") oder wenn beim Kopieren / Erfassen von Datensätzen die Leitdatenmaske bzw. der Kopierdialog geschlossen wird und in die Detailmaske der rechten Seite des Klienten zurückverzweigt wird (Transaktionen "programmname-new" und "programmname-copy"). Weiter wird dieser Task in der Regel in den LOAD-Transaktionen verwendet.
Beispiel:
<transaction id="LOAD">
<action type="call" sourceprogram="EVENT" sourcecomponent="DATA"
targetprogram="" targetcomponent="*">
<option name="program" value="US13000J" />
<option name="method" value="*LOADCOPY" />
<transactionhandler type="04" exit="true"
transaction-ref="CANCEL" />
</action>
<action type="set-focus-first" targetprogram="" />
</transaction>
SetFocusTask
Der SetFocusTask arbeitet ähnlich wie der SetFocusFirstTask. Der Unterschied besteht darin, dass mit dem SetFocusTask die Komponente über ihre Id explizit bestimmt werden kann, die den Fokus erhalten soll. Häufig wird der SetFocusTask verwendet, um den Fokus nach der Beendigung der Verwaltung eines Datensatzes wieder in den Navigationsbereich zu bringen.
Beispiel:
<transaction id="SINGLE_OPEN">
<action type="set-focus"
targetprogram="" targetcomponent="NAVCOMP" />
</transaction>
SetFocusFieldTask
Dieser Task kann dazu genutzt werden, um den Focus auf ein durch den Server (RPG-Programm) bestimmtes Feld zu setzen. Dabei wird über die Option field bestimmt, wie das Feld im XML-Datenstrom heißt, welches die Id des zu fokussierenden Feldes trägt.
Beispiel:
<transaction id="PW22012-selected">
...
<action type="call" sourceprogram="EVENT" sourcecomponent="DATA"
targetprogram="" targetcomponent="*">
<option name="program" value="PW22012J" />
<option name="method" value="*READ" />
</action>
...
<action type="set-focus-field" sourceprogram="" sourcecomponent="*"
targetprogram="">
<option name="field" value="FLDN" />
</action>
</transaction>
ValidateTask
Der ValidateTask führt einfache Gültigkeitsprüfungen für Feldinhalte aus. Diese Prüfungen werden vom Klienten selber ausgeführt ohne Rückgriff auf den Server. Solche einfachen Prüfungen können z.B. die prinzipielle Gültigkeit eines Datums sein. Der ValidateTask wird i.a. vor einer call-Aktion zum verbuchen aufgerufen, d.h. mit Option method wie z.B. "*PUT" / "*PUTNEW" / "*PUTCOPY" usw.. Mit Attribut targetprogram kann das Programm für die Validierung der Felder spezifiziert werden.
Beispiel:
<transaction id="OK">
<enabled>true</enabled>
<action type="validate" targetprogram="" />
<action type="call" sourceprogram="" sourcecomponent="*"
targetprogram="" targetcomponent="*">
<option name="program" value="US11200J" />
<option name="method" value="*PUTNEW" />
<transactionhandler type="PLZMC" exit="true"
transaction-ref="CallPlzMC-OK" />
</action>
...
</transaction>
ResetErrorTask
Wenn ein Feld aufgrund der Prüfung in einem Serverprogramm oder aufgrund der Oberflächenprüfung (vgl. ValidateTask) als fehlerhaft erkannt ist, wird es entsprechend markiert. Mit dem ResetErrorTask lassen sich diese Fehlermarkierungen zurücksetzen.
Beispiel:
<transaction id="CANCEL">
<enabled>true</enabled>
<action type="switch-state" targetprogram="">
<option name="state" value="ANZEIGEN" />
</action>
<action type="reset-errorfield" targetprogram="" />
...
</transaction>
ResetScreenAttributesTask
Der ResetScreenAttributesTask setzt die von einem oxaion Programm eingestellten Bildschirmattribute einer Maske zurück. Obwohl die Bildschirmattribute bei jedem call-Task-Aufruf neu eingestellt werden und somit nicht über einen Task zurückgesetzt werden müssten, ist dieser Task in einigen wenigen Ausnahmen hilfreich. Z. B. im Auskunftsprogrammtreiber erfolgt bei Reload (F5) kein Servercall, es werden lediglich die Felderinhalte auf Blank gesetzt. Damit auch die dynamischen Pflichtfelder zurückgesetzt werden, wird der ResetScreenAttributesTask verwendet.
Beispiel:
<transaction id="RELOAD">
<enabled>true</enabled>
<action type="clear" targetprogram="" targetcomponent="*" />
<action type="reset-screen-attributes" targetprogram="" />
<action type="reset-errorfield" targetprogram="" />
...
</Transaction>
SwitchTabTask
Dieser Task bewirkt das Verzweigen auf eine andere Maskenlasche innerhalb desselben Programmes.
Beispiel:
<transaction id="OK">
<enabled>true</enabled>
<action type="switch-tab"
targetprogram="" targetcomponent="MM0002" />
</transaction>
Komponenten-bezogene Tasks
TreeTask
Der TreeTask stellt folgende Funktionen bereit:
- Bei Angabe der Option remove wird versucht, den Knoten zu finden, dessen Schlüssel eine Teilmenge der über das sourceprogram und sourcecomponent angegebenen Daten darstellt. Wird ein Knoten gefunden, wird dieser einschließlich aller Unterknoten aus der Baumstruktur entfernt.
- Bei Angabe der Option get-container wird der Schlüssel des ersten Knotens unterhalb des Wurzelknotens in den EVENT.DATA-Zwischenspeicher gestellt, der den aktuell selektieren Satzes enthält (dies ist i.d.R. der Knoten für den Beleg). Mit der Option level kann auch ein anderer als der erste Knoten geholt werden.
- Bei Angabe der Option get-parent wird der Schlüssel des unmittelbaren Vaterknotens zum aktuell selektierten Knoten in EVENT.DATA zurückgegeben.
- Bei Angabe der Option execute-selected wird für alle selektierten Sätze in dem Baum die durch den zugehörigen Optionswert (value) bestimmte Transaktion ausgeführt. Durch die zusätzliche Option „resume-on-tcode" mit den Werten „true" oder „false" kann bestimmt werden, ob im Falle eines Fehlers die Verarbeitung der selektierten Sätze fortgeführt oder unterbrochen werden soll (Unterlassungswert: „false").
- Bei Angabe der Option select wird der durch die Quelle bestimmte Satz markiert.
- Bei Angabe der Option load-if-necessary wird das initiale Laden des Baumes angestoßen, aber nur dann, wenn der Baum noch nicht geladen war. Diese Option wird im Zusammenhang mit DROPPED-Transaktionen verwendet. Im Falle von SendTo muss der Baum auf der linken Seite noch aufgebaut werden, im Falle von Drag & Drop ist dies nicht mehr nötig.
- Bei Angabe der Option get-positioning wird der Aufsetzen-Ab-Schlüssel der obersten Hierarchieebene zurückgegeben.
Beispiel (Knoten entfernen):
<transaction id="LB20090-DELETE-DATA">
<action type="tree" sourceprogram="EVENT" sourcecomponent="DATA"
targetprogram="" targetcomponent="NAVCOMP">
<option name="remove" value="" />
</action>
</transaction>
Beispiel (Schlüssel des Beleges ermitteln):
<transaction id="set-key">
<action type="clear-event-data" />
<action type="tree" targetprogram="" targetcomponent="NAVCOMP">
<option name="get-container" value="" />
</action>
<action type="run" sourceprogram="EVENT" sourcecomponent="DATA"
targetprogram="VISIBLE" targetcomponent="LB20090-set-key" />
</transaction>
Beispiel (Schlüssel des Vaterknoten ermitteln):
<transaction id="MN10192-GET-FATHER">
...
<action type="tree" targetprogram="" targetcomponent="NAVCOMP">
<option name="get-parent" value="true"/>
</action>
<action type="update" sourceprogram="EVENT" sourcecomponent="DATA"
targetprogram="MN10192-Parent" targetcomponent="DATA"/>
</transaction>
Beispiel (für das Markieren eines Satzes):
<transaction id="MN10192-REPLACE-CONT">
...
<action type="tree"
sourceprogram="MN10192-Current" sourcecomponent="DATA"
targetprogram="" targetcomponent="NAVCOMP">
<option name="select" value=""/>
</action>
</Transaction>
Beispiel (Ausführen Transaktion für markierte Sätze):
<transaction id="USKBS-multiDelete">
<enabled>true</enabled>
<icon>trash.gif</icon>
<action type="run"
targetprogram="" targetcomponent="check-any-visible"/>
<action type="tree" targetprogram="" targetcomponent="NAVCOMP">
<option name="execute-selected"
value="USKBSEntry-delete-EventData"/>
<option name="resume-on-tcode" value="true"/>
</action>
</transaction>
Beispiel (Baum nur laden, wenn noch nicht gefüllt):
<transaction id="BENR-DROPPED">
...
<action type="tree" targetprogram="NAVIGATION"
targetcomponent="NAVCOMP">
<option name="load-if-necessary" value="true"/>
</action>
</transaction>
Beispiel (Ermittlung der Schlüsseldaten für Aufsetzen-Ab auf höchster Ebene):
<transaction id="DI32090-UPDATE-CONT">
<icon>refresh16.gif</icon>
<enabled>true</enabled>
<action type="tree" targetprogram="" targetcomponent="NAVCOMP">
<option name="get-positioning" />
</action>
...
</transaction>
TableTask
Im Zusammenhang mit dem TableTask muss man zwischen Tabellen unterscheiden, deren Sätze über eine Checkbox am Anfang der Tabellenzeile selektiert werden können, und solchen, in denen die Selektion von Sätze über die Markierung der Tabellenzeile erfolgt. Alle Spielarten des TableTask mit Optionen mit einem Namensbestandteil „checkmark" beziehen sich auf die erste Art. Lautet ein Namensbestandteil dagegen „select", dann ist die Verwendung nur im Zusammenhang mit einer Tabelle der zweiten Art sinnvoll. Eine dritte Art der Auswahl von Tabellensätzen gibt es, nämlich die Auswahl von geänderten Sätzen. Die hier zugehörigen Varianten des TableTask erkennt man an dem Namensbestandteil „edited" im Optionsnamen.
Der TableTask stellt folgende Funktionen bereit:
- Bei Angabe der Option remove wird versucht, die Tabellenzeile zu finden, deren Schlüssel eine Teilmenge der über das sourceprogram und sourcecomponent angegebenen Daten darstellt. Wird sourceprogram / sourcecomponent nicht angegeben, dann wird unterlassungsmüßig EVENT.DATA für die Schlüsselfindung verwendet. Wurde eine Zeile gefunden, wird diese aus der Tabelle entfernt.
- Bei Angabe der Option get-key wird versucht, eine Tabellenzeile zu finden, deren Schlüssel eine Teilmenge des EVENT.DATA-Zwischenspeichers ist. Wurde eine Zeile gefunden, wird der Schlüssel im EVENT.DATA-Zwischenspeicher eingestellt.
- Bei Angabe der Option set-checkmarked wird versucht, die Tabellenzeile zu finden, deren Schlüssel eine Teilmenge der über das sourceprogram und sourcecomponent angegebenen Daten darstellt. Wurde eine Zeile gefunden, wird in Abhängigkeit vom value der Option die Multiselect-CheckBox (=Häckchen vor der Tabellenzeile) an- oder abgewählt.
- Bei Angabe der Option set-firstcheckmarked mit value="true" wird die selektierte (= blau hinterlegte) Tabellenzeile deselektiert.
- Bei Angabe der Option set-selected mit value="true" werden alle Sätze in der Tabelle selektiert, deren Schlüssel eine Teilmenge der über das sourceprogram und sourcecomponent angegebenen Daten darstellt.
- Bei Angabe der Option set-selected mit value="false" werden alle Sätze in der Tabelle deselektiert.
- Bei Angabe der Option set-firstselected mit value="false" wird die erste selektierte Zeile deselektiert.
- Bei Angabe der Option get-sort werden die aktuellen Sortierkriterien in den Event-Data-Zwischenspeicher gelegt. Die Sortierkriterien sind der JET iSeries Schnittstellenbeschreibung zu entnehmen.
- Bei Angabe der Option execute-checkmarked wird sequentiell für jede per Multiselect-CheckBox ausgewählte Tabellenzeile eine Transaktion aufgerufen. Als Transaktionsname dient das value-Attribut der execute-checkmarked-Option, also z. B. value="run-selection". Vor jedem Aufruf der run-selection-Transaktion wird der Schlüssel der aktuellen Tabellenzeile in den EVENT.DATA-Zwischenspeicher abgelegt. Bei commit=true werden in einer Tabelle die Häkchen erst nach erfolgreicher Verarbeitung aller markierten Sätze entfernt.
- Bei Angabe der Option execute-edited wird sequentiell für jede geänderte Tabellenzeile eine Transaktion aufgerufen, wobei der Transaktionsname über das Value-Attribut der Option ermittelt wird. Z. B. führt value="run-selection" für jede geänderte Tabellenzeile die Transaktion run-selection aus, wobei vor jedem Aufruf der Schlüssel sowie die geänderten Daten in den EVENT.DATA-Zwischenspeicher abgelegt werden.
- Bei Angabe der Option execute-selected wird sequentiell für jede selektierte Tabellenzeile (blaue Balken) eine Transaktion aufgerufen, wobei der Transaktionsname über das Value-Attribut der Option ermittelt wird. Z. B. führt value="run-selection" für jede geänderte Tabellenzeile die Transaktion run-selection aus, wobei vor jedem Aufruf der Schlüssel der aktuellen Tabellenzeile in den EVENT.DATA-Zwischenspeicher abgelegt wird.
- Bei Angabe der Option get-columntypes werden die Spaltentypen in dem Event-Data-Zwischenspeicher abgelegt.
- Bei Angabe der Option read-all werden alle Datensätze der Tabelle eingelesen, bis eof auf true steht! Zu beachten ist aber, dass dieser Vorgang bei grösseren Datenmengen zu längeren Wartezeiten führen kann.
- Bei Angabe der Option checkmark-all wird für alle geladenen Sätze einer Tabelle die Checkbox entsprechend dem in value hinterlegten Wert ein Haken gesetzt bzw gelöscht.
- Bei Angabe der Option get-header wird der komplette Tabellenkopf in XML-Form in EVENT.DATA in XML-Form zurückgegeben (<HEADER NbrSights= .../>).
- Alle sonstigen Aufrufe des TableTasks führen dazu, dass der Schlüssel der zuletzt eingelesenen Tabellenzeile zu dem EVENT.DATA-Zwischenspeicher hinzugefügt wird. Dieser Task wird z.B. mit der Option collect-last umgesetzt.
Beispiel (Entfernen einer Tabellenzeile):
<transaction id="BA10100-DELETE-DATA">
<action type="table" targetprogram="" targetcomponent="NAVCOMP">
<option name="remove" value="" />
</action>
</transaction>
Beispiel (Ermitteln des Schlüssels für einen gesuchten Satz):
transaction id="BA10100-UPDATE-DATA">
<action type="table" targetprogram="" targetcomponent="NAVCOMP">
<option name="get-key" value="" />
</action>
...
</transaction>
Beispiel (Entfernen der Selektionen):
<transaction id="OK">
<action type="validate" targetprogram="" />
<action type="table" targetprogram="" targetcomponent="NAVCOMP">
<option name="remove-selection" value="" />
</action>
...
</transaction>
Beispiel (ersten mit Checkbox selektierten Satz deselektieren):
<transaction id="LB61015-delete">
<action type="table" sourceprogram="EVENT" sourcecomponent="DATA"
targetprogram="" targetcomponent="NAVCOMP">
<option name="set-firstcheckmarked" value="false" />
</action>
...
</transaction>
Beispiel (Selektion von Sätzen):
<transaction id="GO2KEY">
<action type="table" sourceprogram="EVENT" sourcecomponent="DATA"
targetprogram="" targetcomponent="NAVCOMP">
<option name="set-selected" value="true" />
</action>
</transaction>
Beispiel (Deselektieren des ersten ausgewählten Satzes):
<transaction id="SingleDelete">
<action type="run" sourceprogram="EVENT" sourcecomponent="DATA"
targetprogram="VISIBLE"
targetcomponent="FB10400-MultiTableDelete" />
<action type="table" targetprogram="" targetcomponent="NAVCOMP">
<option name="set-firstselected" value="false" />
</action>
</transaction>
Beispiel (Ermittlung der aktuellen Sortierkriterien):
<transaction id="SORT">
<enabled>true</enabled>
<action type="table" targetprogram="" targetcomponent="NAVCOMP">
<option name="get-sort" value="true" />
</action>
...
</transaction>
Beispiel (Ausführen einer Transaktion für alle mit Checkbox markierten Sätze):
<transaction id="OK">
<enabled>true</enabled>
<action type="table" targetprogram="" targetcomponent="NAVCOMP">
<option name="execute-checkmarked" value="run-selection" />
</action>
</transaction>
Beispiel (Ausführung einer Transaktion für alle geänderten Sätze):
<transaction id="OK">
<enabled>true</enabled>
<action type="table" targetprogram="" targetcomponent="TABLE">
<option name="execute-edited" value="run-selection" />
</action>
</transaction>
Beispiel (Ausführung einer Transaktion für alle markierten Sätze):
<transaction id="MultiDelete">
...
<action type="table" targetprogram="" targetcomponent="NAVCOMP">
<option name="execute-selected" value="SingleDelete" />
</action>
</transaction>
Beispiel (alle Sätze einlesen und alle Sätze markieren):
<transaction id="select-all">
<action type="table" targetprogram="" targetcomponent="NAVCOMP">
<option name="read-all" value="true" />
</action>
<action type="table" targetprogram="" targetcomponent="NAVCOMP">
<option name="checkmark-all" value="true" />
</action>
<action type="run" targetprogram="" targetcomponent="OK" />
</transaction>
Beispiel (Tabellenkopf ermitteln):
<transaction id="LOAD-UP">
...
<action type="table" targetprogram="" targetcomponent="NAVCOMP">
<option name="get-header"/>
</action>
<action type="call" sourceprogram="EVENT" sourcecomponent="DATA"
targetprogram="EVENT" targetcomponent="DATA">
<option name="program" value="US63191J"/>
<option name="method" value="*SAVE-HDR"/>
</action>
...
</transaction>
TextAreaTask
Der TextAreaTask erlaubt es, die max. Anzahl an Zeichen pro Zeile eines mehrzeiligen Textfeld auch nach dessen Erstellung zu verändern. Dies ist nur in seltenen Fällen, z. B. bei der Textverwaltung, nötig. In der Option key-name wird der Name für das Feld angegeben, welches die gewünschte Zeilenlänge enthält.
Beispiel:
<transaction id="FIRSTTEXT">
<action type="area" sourceprogram="" sourcecomponent="TABLE"
targetprogram="" targetcomponent="TEXTAREA">
<option name="key-name" value="TXLNG"/>
</action>
...
</transaction>
EnableTask
Der EnableTask aktiviert oder deaktiviert eine Komponente, ohne in einen anderen State wechseln zu müssen. Ob aktiviert oder deaktiviert wird, entscheidet sich nach folgendem Algorithmus:
- Wenn die Source EVENT.DATA ist, dann wird enabled, wenn das über die Option name bestimmte Feld true enthält.
- Ansonsten wird aufgrund des Wertes der Option enable en/disabled.
Die Targetcomponent enthält das Feld, welches en/disabled werden soll.
Beispiel:
<action type="enable" sourceprogram="EVENT" sourcecomponent="DATA"
targetprogram="" targetcomponent="EDNARE">
<option name="name" value="ENABLE_COMPONENT" />
</action>
ChangeFieldTypesTask
Der ChangeFieldTypesTask ändert die in Targetcomponent angegebene Komponente durch die in Sourcecomponent übergebenen Typ, Länge, Formatierung usw.. Ist die Targetcomponent „*", so werden alle Komponenten im aktuellen Programm verändert.
Beispiel:
<transaction id="US14875-ChangeFieldType">
<action type="changefieldtypes"
sourceprogram="EVENT" sourcecomponent="DATA"
targetprogram="" targetcomponent="QPSLTV" />
<action type="changefieldtypes"
sourceprogram="EVENT" sourcecomponent="DATA"
targetprogram="" targetcomponent="QPSLTB" />
Sourcecomponent kann auch ein Tree sein. In diesem Fall muss der Key des Trees die jeweiligen Formatinformationen enthalten. Diese werden von dem zugehörigen Serverprogramm gesetzt. Dazu muss der XML-Datenstrom der Kommunikation mit dem Server etwa wie folgt aussehen:
<TREE>
<KEY>
<KEYTYPE>NOT_SELECTED</KEYTYPE>
<SNR>1</SNR>
<WSTR>1</WSTR>
<NAME>KOAUNR</NAME>
<SORTABLE>TRUE</SORTABLE>
<SORTED>ASC</SORTED>
<TYPE>A(11)</TYPE>
<format>UPPER</format>
<LENGTH>11</LENGTH>
</KEY>
<VASI>Auftragsnummer</VASI>
</TREE>
Transaktions-bezogene Tasks
RunTransactionTask
Eine der wichtigsten und am häufigsten verwendeten Tasks ist der RunTransactionTask. Mit ihm ist es möglich, aus einer Transaktion heraus eine Folgetransaktion aufzurufen. Häufig verwendet wird dieser Task, um alle anderen Programme von der Löschung eines Datensatzes zu informieren. Es wird dann mit dem RunTransactionTask eine bestimmte Transaktion in allen offenen Programmen aufgerufen. Wenn dort diese Transaktion existiert, können diese Programme auf die Löschung des Datensatzes geeignet reagieren.
Beispiel:
<transaction id="DELETE">
...
<action type="run" sourceprogram="EVENT" sourcecomponent="DATA"
targetprogram="ALL" targetcomponent="US11200-DELETE-DATA" />
...
</transaction>
Auch für den Aufruf einer speziellen Transaktion im Programm der rechten Seite (Detailmaske) aus dem Navigationsbereich der linken Seite heraus, bei Verwendung des dortigen Kontextmenü, wird der RunTransaktionTask oft verwendet (s. folgendes Beispiel).
Beispiel:
<transaction id="OPEN">
<enabled>true</enabled>
<action type="check-visible-program" targetprogram="">
<option name="xml" value="ust/us11200.xml" />
</action>
<action type="run" sourceprogram="" sourcecomponent="NAVCOMP"
targetprogram="VISIBLE" targetcomponent="US11200-opened" />
</transaction>
Im TargetProgram-Attribut können folgende Werte übergeben werden:
- Spezieller Programmname
- "VISIBLE" - für das gerade Sichtbare Programm
- „ALL" – für alle geöffneten Programme
ReplaceAllOptionsTask
Der ReplaceAllOptionsTask überprüft alle Aktionen einer Maske und ersetzt deren Optionen mit den im EVENT.DATA-Zwischenspeicher angegebenen Werten. Welche Optionen (name-Attribut der Option) ersetzt werden, das kann auf zwei alternative Arten bestimmt werden:
- Durch die Optionen des ReplaceAllOptionsTask (wobei nur diejenigen berücksichtigt werden, für die es Werte in EVENT.DATA gibt)
- Wenn der ReplaceAllOptionsTask keine Optionen enthält, dann werden alle Optionen ersetzt, die im EVENT.DATA-Zwischenspeicher vorhanden sind.
Beispiel (für den ersten Fall):
<transaction id="ON_TOP">
<action type="replace-all-options" targetprogram="">
<option name="SSID" />
</action>
...
</transaction>
Wenn EVENT.DATA z.B. SSID = 1234567 und FFMT=OP enthält wird aus
<action type="call" sourceprogram="" sourcecomponent="TABLE"
targetprogram="EVENT" targetcomponent="DATA">
<option name="program" value="EK21001J" />
<option name="method" value="*NOTIZ" />
<option name="FFMT" value="NP" />
<option name="SSID" value="7777777" />
</action>
die neue Aktion (man beachte, dass sie Option FFMT nicht geändert wird!)
<action type="call" sourceprogram="" sourcecomponent="TABLE"
targetprogram="EVENT" targetcomponent="DATA">
<option name="program" value="EK21001J" />
<option name="method" value="*NOTIZ" />
<option name="FFMT" value="NP" />
<option name="SSID" value="1234567" />
</action>
Beispiel (für den zweiten Fall):
<transaction id="LOADFIRST-AFTER-OK">
<action type="replace-all-options" targetprogram="" />
...
</transaction>
So würde in obigem Beispiel auch die FFMT-Option ersetzt. Um schwer zu findende Fehler zu verhindern sollte man absolut sicherstellen, dass EVENT.DATA nur das enthält, was auch tatsächlich gesetzt werden soll, bspw. durch:
<action type="clear-event-data">
<option name="keep" value="SSID" />
</action>
CheckCheckmarkedTask
Dieser Task arbeitet analog zum CheckSaveTask. Geprüft wird, ob
- das XML die Transaktion EXECUTECHECKMARKED enthält
- das XML eine oder mehrere checkmarkable Tabellen enthält
- ob in in einer dieser Tabellen Sätze per Checkbox markiert sind
Wenn alle drei Bedingungen zutreffend sind, wird ein Dialog entsprechend dem Sicherungsdialog mit den Optionen „Ausführen", „Nicht Ausführen" und „Abbrechen" angezeigt. Die Aktion „Ausführen" ruft die Transaktion EXECUTECHECKMARKED auf.
<action type="check-checkmarked" targetprogram="VISIBLE" />
ExitTransactionTask
Dieser Task beendet die gesamte Transaktionssequenz, also sowohl die Transaktion, in der der Task aufgerufen wird, als auch die diese Transaktion rufenden Transaktionen.
Beispiel:
<transaction id="BA20300-REOPENED">
<action type="close" targetcomponent="VISIBLE" />
<action type="show" targetcomponent="" />
<action type="exit-transaction" />
</Transaction>
Belegbezogene Tasks
CardTask
Der CardTask ist ein Task der sich immer auf eine Card-Komponente. Der Cardtask muss immer mit mindestens einem <option>-Tag versehen sein. Die möglichen Optionen werden im folgenden erläutert:
<option name="set-key" />
Mit dieser Option wird der Schlüssel für einen Beleg gesetzt, der Beleg selber verbleibt aber noch im Anzeigemodus, wird also nicht eröffnet. Welcher Schlüssel gesetzt wird, wird über die Attribute sourceprogram/sourcecomponent gesetzt. Das Attribut targetcomponent bestimmt die Card-Komponente, für welche der Schlüssel gesetzt werden soll.
Wird der CardTask mit dieser Option ausgeführt , wird zunächst (intern) der CheckSaveTask durchgeführt, um auf noch zu verbuchende Daten zu prüfen. Anschließend wird geprüft, ob bereits ein anderer Beleg offen ist. Wenn das der Fall ist, wird die in der XML-Datei für das Ereignis "close" angegebene Transaktion für diesen Beleg ausgeführt (vgl. Zusatz zu Card-Komponenten).
Beispiel:
<transaction id="LB62090-set-key">
<action type="card" sourceprogram="EVENT" sourcecomponent="DATA"
targetprogram="" targetcomponent="Cards">
<option name="set-key" />
</action>
</transaction>
<option name="set-key" />
<option name="open" value="true" />
Durch die zweite zusätzliche Option wird der Schlüssel (Beleg) nicht nur gesetzt, sondern gleichzeitig geöffnet. Die Kombination beider Optionen kommt hauptsächlich beim Erfassen eines Beleges vor.
Beispiel:
<transaction id="LB62090-set-openkey">
<action type="card" sourceprogram="EVENT" sourcecomponent="DATA"
targetprogram="" targetcomponent="Cards">
<option name="set-key" />
<option name="open" value="true" />
</action>
</transaction>
<option name="open-key" />
Mit dieser Option wird ein bereits gesetzter Schlüssel geöffnet. Oft wird zunächst der Beleg im Navigationsbereich nur zur Anzeige angeklickt, damit ist der Schlüssel gesetzt. Wenn es nun zur Bearbeitung des Beleges kommt, muss der "open-key" nachgeholt werden.
Beispiel:
<transaction id="LB62090-open-key">
<action type="card" targetprogram="" targetcomponent="Cards">
<option name="open-key" />
</action>
</transaction>
<option name="check-open-key" />
Mit dieser Option wird abgeprüft, ob ein Key geöffnet wurde. Falls dies nicht der Fall ist, wird die Transaktionssequenz beendet, ohne die nachfolgenden Aktionen auszuführen.
Beispiel:
<transaction id="LB62090-close-key">
<action type="card" targetprogram="" targetcomponent="Cards">
<option name="check-open-key" />
</action>
<action type="run" targetprogram="" targetcomponent="LIKO2-close" />
<action type="card" targetprogram="" targetcomponent="Cards">
<option name="close-key" />
</action>
</transaction>
<option name="close-key" />
Mit dieser Option kann ein Schlüssel (Beleg) programmgesteurt, d.h. durch XML, geschlossen werden. Die Anwendung sieht man im vorhergehenden Beispiel.
<option name="clear-cache"/>
Mit dieser Option können im Spezialfall (z.B. bei dynamischen Masken,. Tabellenverwaltung) alle Programme wieder entladen werden.
Beispiel:
<transaction id="CLEAR-CACHE">
<action targetcomponent="Cards" type="card" targetprogram="">
<option name="clear-cache"/>
</action>
</transaction>
OpenCardTask
Der OpenCardTask zeigt ein Program auf einer Card-Componente an. Das anzuzeigende Programm wird dabei über den Wert der Option xml bestimmt: value="Anwendungsgebiet / Frame-Datei". Bei der Anzeige gibt es zwei Möglichkeiten:
- Das anzuzeigende Programm wurde noch nicht geladen: Der OpenCardTask lädt das OxaionUI vom Server, erstellt das Programm über die Program-Builder und fügt es zur Card-Componente hinzu. Dabei wird die LOAD-Transaktion (falls vorhanden) ausgeführt, nicht jedoch die ON_TOP-Transaktion!
- Das Programm wurde bereits angezeigt: In diesem Fall macht der OpenCardTask das Programm lediglich sichtbar und führt – falls vorhanden – die ON_TOP-Transaktion aus.
Beispiel:
<transaction id="US11290-UPKAD-opened">
<action type="open-container"
targetprogram="" targetcomponent="Cards">
<option name="xml" value="ust/us11200.xml"/>
</action>
<action type="run" sourceprogram="EVENT" sourcecomponent="DATA"
targetprogram="" targetcomponent="US11200-selected"/>
</transaction>
Das zu öffnende XML kann auch über EVENT.DATA bestimmt werden. In diesem Fall muss in EVENT.DATA das Anwendungsgebiet über das Feld ANWG und das zu öffnende XML über das Feld PGMN (ohne die .xml-Endung) übergeben werden.
Beim OpenCardTask ist es auch möglich, sourceprogram und sourcecomponent anzugeben. Dies dient dazu, in dem zu öffnenden XML Optionen (ähnlich wie beim ReplaceAllOptionsTask) mit den Werten der Source zu überschreiben. Ein häufig vorkommendes Beispiele ist die im Ziel-XML zu ersetzende Session-ID.
(<option name="SSID" value="SSID" />) .
BrowsableCardTask
Dieser Task wird im Zusammenhang mit der BrowsableCard-Komponente verwendet, die hauptsächlich im Auskunftsnavigator vorkommt. Er dient dazu, wie in einem Webbrowser durch die in der BrowsableCard-Komponente geladenen Ansichten vor oder zurück zu blättern. Die Option mode mit dem Wert back führt zum rückwärts blättern, ansonsten wird vorwärts geblättert.
Beispiel:
<transaction id="CMD_BACK">
<enabled>false</enabled>
<action type="browsable-card"
targetprogram="" targetcomponent="Cards">
<option name="mode" value="back" />
</action>
</transaction>
OpenBrowsableCardTask
Dieser Task wird zum Öffnen von XML in einer BrowsableCard-Komponente verwendet. Die Verwendung dieses Task ist identisch zum OpenCardTask.
Beispiel (der call-Task ermittelte das zu startende XML):
<transaction id="OK">
<enabled>true</enabled>
<action type="run"
targetprogram="" targetcomponent="load-mandatory" />
<action type="validate" targetprogram="" />
<action type="call" sourceprogram="" sourcecomponent="*"
targetprogram="" targetcomponent="*">
<option name="program" value="US30300J" />
<option name="mode" value="no-attribute-update" />
</action>
<action type="update" sourceprogram="" sourcecomponent="*"
targetprogram="EVENT" targetcomponent="DATA" />
<action type="open-browsable" sourceprogram="" sourcecomponent="*"
targetprogram="" targetcomponent="Cards" />
</transaction>
Tasks für SendTo und DnD
CheckDnDTask
Der CheckDnDTask prüft, ob der Benutzer gerade eine Drag-And-Drop-Operation gestartet hat. Falls ja, wird die aktuelle Transaktionssequenz verlassen. Dieser Task wird z.B. verwendet, um beim Öffnen eines Explorers über SendTo zu verhindern, daß der Baum schon geladen wird, bevor die Positionierung feststeht.
Beispiel:
<transaction id="FIRSTLIST">
<action type="check-dnd" />
<action type="call-thread" sourceprogram="" sourcecomponent="NAVCOMP"
targetprogram="" targetcomponent="NAVCOMP">
<option name="program" value="LB61090J" />
<option name="method" value="*FIRSTLIST" />
<option name="SSID" value="*SSID*" />
</action>
</transaction>
OpenDnDTask
Mit dem OpenDnD-Task kann man aus dem XML heraus eine SendTo-Aktion simulieren. Dabei kann man über das Target die Inputdaten für das empfangende Programm mitgeben. Über die Option program wird das Empfängerprogramm (Frameset) und über die Option transaction die auszuführende Transaktion vorgegeben. Mit diesem Task kann ein bisschen mehr gemacht werden, als mit dem normalen SendTo. Zum einen werden hier nicht implizit die Klassen von den Feldern übertragen, sondern die Daten, die im Target stehen, also in der Regel ganz normale Felder / Werte aus dem XML. Zum anderen sind als Empfängertransaktionen nicht nur –DROPPED-Transaktionen zulässig, sondern beliebige Transaktionen. Es sollten im Target immer nur solche Daten mitgegeben werden, die auch tatsächlich für die Empfängertransaktion benötigt werden, das kann z.B. mit clear-event-data mit der Option keep erreicht werden.
Beispiel:
<action type="open-dnd" targetprogram="EVENT" targetcomponent="DATA">
<option name="program" value="VK23090R" />
<option name="transaction" value="AUNR-DROPPED" />
</action>
Der OpenDnDTask kann sich genauso wie der OpenTask (siehe Kapitel 13.7.1) das geöffnete Programm als abhängig merken.
RunDroppedTask
Dieser Task wird in der Regel nur intern verwendet. Mit ihm wird aus dem Navigationsbereich heraus (wenn möglich) eine Dropped-Transaktion im Detailbereich ausgeführt.
Dateibezogene Tasks
CreateFileTask
Dieser Task ist hier nur der Vollständigkeit halber erwähnt, er dient hauptsächlich internen Zwecken. Der Task benötigt eine Option field. Der durch diese Option definierte Wert dient als Feldname unter dem Pfad und Name für die anzulegende Datei in der Source zu finden ist.
CheckFileExistsTask
Der CheckFileExistsTask prüft, ob die in der Option „path" übergebene Datei/Pfad gültig ist. Dabei wird die Einstellung in den client.properties „Standard-1.0-ressources" als Wurzelpfad berücksichtigt. Alternativ kann Datei/Pfad auch über die sourcecomponent angegeben werden. Die zusätzlich angebbare Option file-type wird an den Dateinamen angehängt. Wurde die Datei nicht gefunden. wird eine Fehlermeldung angezeigt und die aktuelle Transaktionssequenz verlassen.
Beispiel:
<transaction id="ShowGDL">
<icon>gdl.gif</icon>
<enabled>true</enabled>
<action type="check-save" targetprogram="VISIBLE" />
<action type="check-path" sourceprogram="" sourcecomponent="MPTTIDF">
<option name="file-type" value=".gsm" />
</action>
<action type="run" sourceprogram="" sourcecomponent="*"
targetprogram="" targetcomponent="RunGDL" />
</transaction>
SystemCopyTask
Mit diesem Task können Dateien kopiert werden. Dabei werden mit den Optionen source und target die Feldnamen in der Source angegeben, in denen sich Quell- und Zieldatei/-verzeichnis befinden. Wenn für das Target in der Source %TEMP% angegeben wird, dann wird die Quelldatei in das Temp-Verzeichnis des Benutzers kopiert.
<transaction id="selected">
...
<action type="TASK_SYSTEM_COPY"
sourceprogram="EVENT" sourcecomponent="DATA"
targetprogram="" targetcomponent="*">
<option name="source" value="FROMFILE" />
<option name="target" value="TOFILE" />
</action>
...
</transaction>
UITreeDeleteTask
Alle UITree-Tasks behandeln Dateien und Dateiverzeichnisse in JET-Explorern. Ein wichtiges Beispiel dafür findet man im CRM mit den Dokumentenablagen. Um im Anschluß an eine solche, rein clientseitige Dateioperation diesbezügliche Informationen in Historiendateien festhalten zu können, stellen die Tasks in der Regel unter dem Feldnamen PATH den vollständigen Dateinamen in EVENT.DATA als Target des Tasks zur Verfügung. Die übliche Verfahrensweise in einem XML ist deshalb so, daß man zunächst alle bekannten Daten für solche Historieneinträge in EVENT.DATA sammelt, dann den UITree-Task aufruft, dieser fügt den Dateinamen zu EVENT.DATA hinzu, und daß schließlich einen Servercall mit EVENT.DATA ausgeführt wird, welcher die Historie fortschreibt.
Der UITreeDeleteTask löscht die über Sourcecomponent bestimmten Datei.
Beispiel:
<transaction id="PCFLREntry-delete">
...
<action type="uitree-delete"
sourceprogram="" sourcecomponent="NAVCOMP"
targetprogram="EVENT" targetcomponent="DATA"/>
...
</transaction>
UITreeEditTask
Der UITreeEditTask erlaubt es, den Datei oder Verzeichnisnamen zu ändern.
Beispiel:
<transaction id="PCFLREntry-edit">
...
<action type="update" sourceprogram="EVENT" sourcecomponent="DATA"
targetprogram="EVENT" targetcomponent="DATA">
<option name="copy"
value="PKPKNR AHPKNR PKPFIN AHPFIN PATH AHPFAD"/>
</action>
<action type="uitree-edit" sourceprogram="" sourcecomponent="NAVCOMP"
targetprogram="EVENT" targetcomponent="DATA"/>
...
</transaction>
UITreeCopyTask
Mit dem UITreeCopyTask wird eine Datei oder ein Verzeichnis kopiert.
Beispiel:
<transaction id="PCFLR_FILE-FILE-DROPPED">
<action type="uitree-copy"
sourceprogram="" sourcecomponent="NAVCOMP"
targetprogram="EVENT" targetcomponent="DATA" />
</transaction>
UITreeNewTask
Der UITreeNewTask legt eine neue Datei oder ein neues Verzeichnis an. Ob es sich dabei um eine Datei oder ein Verzeichnis handelt, wird mit der Option type bestimmt.
Beispiel (neue Datei):
<transaction id="PCFLREntry-new">
...
<action type="uitree-new" sourceprogram="" sourcecomponent="NAVCOMP"
targetprogram="EVENT" targetcomponent="DATA"/>
<action type="run" sourceprogram="EVENT" sourcecomponent="DATA"
targetprogram="" targetcomponent="US233101-new"/>
</transaction>
Beispiel (neues Verzeichnis):
<transaction id="PCFLREntry-new-folder">
<icon>folder.gif</icon>
<enabled>true</enabled>
<action type="uitree-new" sourceprogram="" sourcecomponent="NAVCOMP">
<option name="type" value="folder" />
</action>
</transaction>
UITreeRefreshTask
Dieser Task lädt den Verzeichnisbaum (neu).
Beispiel:
<transaction id="PCFLREntry-refresh">
<icon>refresh16.gif</icon>
<enabled>true</enabled>
<action type="uitree-refresh"
sourceprogram="" sourcecomponent="NAVCOMP" />
</transaction>
GetFileTask
Dieser Task erlaubt es eine Datei über einen Bytestream vom JET-Server herunterzuladen, wodurch einzelne Benutzer keinen Zugriff mehr auf Netzlaufwerke benötigen, sondern nur noch der Benutzer unter dem der JET-Server ausgeführt wird. Dabei erwartet der Task mehrere Optionen die im Folgenden beschrieben werden. Da die heruntergeladenen Dateien immer an ein Programm gebunden sein müssen, muss in der source der Action das Programm angegeben werden, zu welchem die Datei gehört. Der Pfad unter dem die Datei letztlich abgelegt wurde, wird unter dem Namen „TargetPath" am Ende der Transaktion in das im target der Action definierte Data-Objekt geschrieben.
Options:
source* | Muss den Pfad zur Datei die heruntergeladen werden soll enthalten |
target | Angabe eines Zielpfades unter dem die Datei abgelegt werden soll. Wenn kein Pfad angegeben ist wird ins temporäre-Verzeichnis heruntergeladen. ACHTUNG: Dateien die mit einem target heruntergeladen wurden, werden nicht der Liste von der heruntergeladenen Dateien eines Programms hinzugefügt und können nach Änderungen somit nicht mehr auf dem Server gespeichert werden. |
name | Angabe eines Namens unter dem die Datei abgelegt werden soll. Wenn nicht angegeben wird der Name der Server-Datei verwendet |
tempDir | Pfadstruktur die im Oxaion-Temp-Verzeichnis (unter Windows „%TEMP%/oxaion" erzeugt wird und unter der die Datei abgelegt wird |
primaryKey (*) | Blank-separierte Liste von den Schlüsselfeldern der Oxaion-Datei. Wird zur Identifikation der Dateien benötigt. Wird nicht benötigt, wenn target angegeben ist. |
alwaysDownload | Sorgt dafür, dass die Datei immer heruntergeladen wird, auch wenn sie schon einmal heruntergeladen wurde. Sorgt aber außerdem dafür, dass die so versehenen Dateien beim CheckFileChangedTask und beim GetChangedFileTask nicht beachtet werden. |
modified-transaction | Angabe einer Transaktion die bei einer Dateiänderung auf dem Client ausgelöst werden soll. |
watch | Falls eine modified-transaction angegeben wurde, kann hierüber gesteuert werden, ob die Datei wirklich überwacht werden soll oder nicht. |
*Pflichtangabe
Beispiel:
<transaction id="...">
<action type="TASK_GET_FILE" sourceprogram="" sourcecomponent="*"
targetprogram="EVENT"
targetcomponent="DATA">
<option name="source" value="TargetPath" />
<option name="primaryKey" value="FIFIRM FIOBID" />
<option name="name" value="FIDOCUA" />
<option name="tempDir" value="TemporaryDirectory" />
</action>
</transaction>
Die in den Optionen angegebenen Feldnamen werden immer aus der Event Data ermittelt, sofern sie dort existieren. Wenn sie dort nicht existieren wird der in der XML angegebene Wert verwendet.
PutFileTask
Mit dem PutFileTask ist es möglich Dateien auf den JET-Server hochzuladen, ohne dass Benutzer Berechtigungen an dem Server bzw. dessen Verzeichnissen haben müssen. Die nötigen und optionalen Optionen sind:
source* | Pfad der Datei die hochgeladen werden soll. Falls der Pfad relativ ist wird davon ausgegangen, dass der Dateiname der hochzuladenden Datei in der Option filename angegeben ist. Wenn der Pfad nicht relativ ist, wird angenommen, dass der Dateinamen enthalten ist. |
filename | Muss den Namen der Datei enthalten, wenn source eine relative Pfadangabe enthält. (Kommt normalerweise nicht vor.) |
updateCount | Sofern die Datei schon einmal in dieser Sitzung heruntergeladen wurde, kann hierüber der aktuelle Wert des Update-Zählers angepasst werden. |
target* | Muss den Pfad enthalten unter dem die Datei(en) auf dem Server abgelegt werden sollen. |
primaryKey | Falls es sich um eine bereits auf dem Server vorhandene Datei handelt, die gespeichert werden soll, wurde diese beim Öffnen bereits mit dem Primärschlüssel an den Client übertragen. Dieser Primärschlüssel ist zur Identifikation hier anzugeben. Dabei müssen die einzelnen Schlüsselfelder blank-separiert im value angegeben werden. |
maxLengthOfDocu | Maximale Länge des Dateinamens. Bei Überschreitung des Wertes wird beim Upload ein Fehler ausgegeben. |
srvFileName | Falls als Wert „true" angegeben wurde bedeutet das, dass das target bereits einen vom Server vorgegebenen Dateinamen enthält. Wenn nicht wird der eigentliche Dateinamen verwendet. |
CheckFileChangedTask
Prüft eine Datei die über die Daten in der Option „primaryKey" definiert ist, ob diese lokal beim Benutzer geändert wurde. Das Ergebnis der Prüfung wird dann in die Target-Data mit dem Schlüssel „FileChanged" gelegt und ist entweder „true" oder „false".
Optionen:
primaryKey (*) | Blank-separierte Liste von den Schlüsselfeldern der Oxaion-Datei. Wird zur Identifikation der Dateien benötigt. Wird nicht benötigt, wenn target angegeben ist. |
Beispiel:
<transaction id="...">
<action type="TASK_CHECK_FILECHANGE" sourceprogram="" sourcecomponent="*"
targetprogram="EVENT"
targetcomponent="DATA">
<option name="primaryKey" value="FIFIRM FIOBID" />
</action>
</transaction>
RemoveClientSideFileTask
Ermöglicht es dem Server Dateien auf dem Client aus dem temporären Oxaion-Verzeichnis zu löschen oder diese umzubenennen.
Optionen:
primaryKey (*) | Blank-separierte Liste von den Schlüsselfeldern der Oxaion-Datei. Wird zur Identifikation der Dateien benötigt. Wird nicht benötigt, wenn target angegeben ist. |
target (*) | Kann alternativ zum primaryKey angegeben werden. Muss dann einen relativ vom temporären Oxaion-Verzeichnis ausgehenden Pfad zu der zu löschenden Datei enthalten. |
rename | Muss den Schlüssel enthalten unter dem der neue Name der Datei in der Event Data zu finden ist. |
Beispiel:
<transaction id="...">
<action type="TASK_REMOVE_CLIENT_FILE" sourceprogram="" sourcecomponent="*" targetprogram="EVENT" targetcomponent="DATA">
<option name="primaryKey" value="FIFIRM FIOBID" /> ODER
<option name="target" value="PATH" />
<option name="rename" value="NEW_FILE_NAME_KEY" />
</action>
</transaction>
GetChangedFilesTask
Ermittelt alle lokal auf den Client geladenen Dateien eines Programmes die sich geändert haben und sendet diese in Form einer Table an den Server. Wenn keine solchen Dateien vorhanden sind wird die Transaktion beendet. Um die Tabelle der Dateien an den Server zu senden müssen die gleichen Options, wie bei einem call-Task angegeben werden.
Beispiel:
<transaction id="...">
<action type="TASK_GET_CHANGED_FILES" sourceprogram="" sourcecomponent="*" targetprogram="EVENT" targetcomponent="DATA">
</action>
</transaction>
Druck-Tasks
PrintEventDataTask
Dieser Task ist vor allem im Zuge der Entwicklung interessant. Man kann damit an definierten Stellen in der XML-Datei den Inhalt von EVENT.DATA auf der Konsole des Klienten ausdrucken.
Beispiel:
<transaction id="BEISPIEL">
<action type="print-event-data" />
</transaction>
PrintTableTask
Dieser Task wird zum Ausdrucken von Tabellen im Zusammenhang mit dem call-Task verwendet (Details s. hier). Die den Task mit Daten versorgenden Servercalls (call-Task) liefern die Daten i.a. seitenweise, so dass der PrintTableTask in der Regel in der Schleife aufgerufen wird.
Beispiel:
<transaction id="RUN_PRINT_TABLE">
<action type="call"
sourceprogram="EVENT" sourcecomponent="DATA"
targetprogram="TASK_PRINT_TABLE" targetcomponent="*">
<option name="program" value="US63173J" />
</action>
<action type="if"
sourceprogram="EVENT" sourcecomponent="DATA" targetprogram="">
<option name="condition" value="eof=false" />
<option name="if-transaction" value="RUN_PRINT_TABLE" />
<option name="else-transaction" value="DONOTHING" />
</action>
</transaction>
PrintTask
Mit dem PrintTask kann man alle Feldinhalte an einer definierten Stelle im XML auf die Konsole des Klienten ausgeben, auch die nicht sichtbaren Felder. Auch dieser Task wird hauptsächlich im Zusammenhang mit der Entwicklung oder Wartung verwendet. Beim Printtask wird das Programm (XML-Datei), für welches die Daten auszugeben sind, über das Attribut targetprogram spezifiziert. Zusätzlich läßt sich über targetcomponent eine spezielle Komponente für den Druck selektieren.
Beispiel:
<transaction id="BEISPIEL">
<action type="print" targetprogram="" />
</transaction>
PrintPageDialogTask
Dieser Task dient der Anzeige des Dialoges zum Seite Einrichten und zur Speicherung der eingegebenen Daten. Er wird normalerweise nur intern verwendet.
PrintChartTask
Dieser Task wird zum Ausdrucken von Charts (UIChartComponent) verwendet. Es wird die per targetcomponent angegebene Chartkomponente auf dem Drucker ausgegeben.
Beispiel:
<transaction id="PRINT_CHART">
<action type="print-chart" targetprogram="" targetcomponent="CHART" />
</transaction>
CHART ist hierbei definiert durch
<component id="CHART" type="CHART">
<option name="format" value="3DBAR" />
...
</component>
Alle Arten von CHART unterstützen das Drucken, neben der im Beispiel angegebenen Art sind das gegenwärtig:
- <option name="format" value="BAR" />
- <option name="format" value="MINMAX" />
- <option name="format" value="PIE" />
- <option name="format" value="SINGLEBAR" />
Sonstige Tasks
CopyTableToClipboardTask
Dieser Task erlaubt es, den Output eines call-Task in die Zwischenablage zu kopieren. Voraussetzung ist, dass dieser Output die Struktur einer <table> hat (vgl. Handbuch iSeries Schnittstellenbeschreibung). Auch hier liefern die den Task mit Daten versorgenden Servercalls (call-Task) die Daten i.a. seitenweise, so daß der CopyTableToClipboardTask in der Regel in der Schleife aufgerufen wird (s. Beispiel).
Beispiel:
<transaction id="RUN_COPY_TO_CLIPBOARD">
<action type="call"
sourceprogram="EVENT" sourcecomponent="DATA"
targetprogram="TASK_COPY_TO_CLIPBOARD" targetcomponent="*">
<option name="program" value="US63173J" />
</action>
<action type="if"
sourceprogram="EVENT" sourcecomponent="DATA" targetprogram="">
<option name="condition" value="eof=false" />
<option name="if-transaction" value="RUN_COPY_TO_CLIPBOARD" />
<option name="else-transaction" value="DONOTHING" />
</action>
</transaction>
FlipFlopTask
Mit diesem Task ist es möglich, zwischen zwei Zuständen hin und her zu wechseln.
Zum Beispiel: Bei Betätigung einer Funktionstaste (oder über das Menü) sollen bestimmte Datensätze in einer Auflistung nicht angezeigt, bei erneuter Betätigung der Funktionstaste wieder alle Datensätze angezeigt werden.
In dem folgenden Beispiel wird mit der ersten Ausführung der Aktion der Wert von SLSM auf value-1 gesetzt, mit der zweiten Ausführung auf value-2, mit der dritten Ausführung wieder auf auf value-1 usw. Vor der ersten Ausführung ist der Wert null was im vorliegenden Beispiel mit " " identisch ist.
Beispiel:
<transaction id="AllProperties">
<icon>empty.gif</icon>
<enabled>true</enabled>
<action type="flip-flop" targetprogram="" targetcomponent="*">
<option name="name" value="SLSM" />
<option name="value-1" value="E" />
<option name="value-2" value="" />
</action>
<action type="run" sourceprogram="" sourcecomponent="*"
targetprogram="" targetcomponent="POSITIONING" />
</transaction>
MessageTask
Der MessageTask läßt sich sowohl bei der Entwicklung verwenden (um z.B. festzustellen, ob eine bestimmte Transaktion überhaupt durchlaufen wird) als auch zur Information des Sachbearbeiters in speziellen Situationen. Letzteres sollte aber die Ausnahme bleiben, da alle Hinweise im Zusammenhang mit der Geschäftsprozeßlogik vom Server kommen sollten. Man beachte im Zusammenhang mit dem MessageTask auch die Hinweise in Sprachenabhängigkeit von JET.
Über die Optionen text und title werden die Texte für die Titelzeile und für den Hinweis angegeben.
Beispiel:
<transaction id="SERVER-DRUCKEN">
<title><translate id="X77204" /></title>
<description><translate id="X77205" /></description>
<icon>print.gif</icon>
<enabled>true</enabled>
<action type="call" targetprogram="IGNORE">
<option name="program" value="FA10101R" />
<option name="method" value="*PRINTHOST" />
<option name="SSID" value="*SSID*" />
</action>
<action type="message">
<option name="title" transid="X77217" />
<option name="text" transid="X77216" />
</action>
</transaction>
YNTask
Mit dem YNTask läßt sich ein Ja-/Nein-/Abbrechen-Dialog ausgeben. Über die Optionen werden die Transaktionen angegeben, die bei Betätigung eines Button ausgeführt werden sollen. Es sind zwei Optionen für die Beschriftung des Dialoges zulässig, text und title, mit der einen wird der Text im Dialog angegeben, mit dem zweiten der Titel in der Titelzeile des Dialoges. Auch hier ist die Sprachenabhängigkeit zu beachten (vgl. Sprachenabhängigkeit von JET). Über die Option cancel kann der Abbrechen-Button ausgeblendet werden. Die wahlweisen Optionen yes-transaction, no-transaction und cancel-transaction definieren die im jeweiligen Fall auszuführenden Transaktionen.
Der YNTask bricht bei Ausführung normalerweise alle laufenden Transaktionen ab. Wenn jedoch nach der Ausführung des YNTask die Transaktionsverarbeitung in der XML-Maskenbeschreibung weitergeführt werden soll (z.B. wenn ein YNTask in der Endeverarbeitung nur eine zusätzliche Hintergrundverarbeitung anstoßen sollte, ansonsten aber die Endeverarbeitung zu Ende geführt werden muß), dann ist zusätzliche die Option:
<option name="continue" value="true" />
anzugeben.
Beispiel:
<transaction id="Check-Save">
<enabled>true</enabled>
<action type="yn" targetprogram="">
<option name="title" transid="D99005" />
<option name="text" transid="D99006" />
<option name="cancel" value="true" />
<option name="yes-transaction" value="US210102-leave" />
<option name="no-transaction" value="US210102-close" />
<option name="cancel-transaction" value="US210102-cancel" />
</action>
</transaction>
DeleteDialogTask
Der DeleteDialogTask öffnet den „Löschen Ja/Nein"-Dialog. Beantwortet der Benutzer mit „Nein", wird die aktuelle Transaktionssequenz verlassen, ansonsten werden die folgenden Aktionen ausgeführt. Über die Option multi kann gesteuert werden, ob sich der Löschdialog auf einen oder auf mehrere Sätze beziehen soll.
Beispiel:
<transaction id="MultiDelete">
<title><translate id="X77009" /></title>
<icon>trash.gif</icon>
<enabled>true</enabled>
<action type="check-visible-program" targetprogram="">
<option name="xml" value="kis/ki10100.xml" />
</action>
<action type="delete-dialog">
<option name="multi" value="true" />
</action>
<action type="table" targetprogram="" targetcomponent="NAVCOMP">
<option name="execute-selected" value="SingleDelete" />
</action>
</transaction>
ChangeVersionTask
In manchen Programmen ist es notwendig, dass in der Statusbar eine Versionsnummer angezeigt werden muss. Solche Versionsnummern werden zur Laufzeit durch einen call-Call ermittelt und in den Zwischenspeicher EVENT.DATA gestellt. Jetzt kann über den ChangeVersionTask die Versionsnummer in der Statusbar geändert werden. Das Feld in EVENT.DATA, in welchem die neue Versionsnummer steht, wird über die Option FIELD bestimmt.
Beispiel:
<transaction id="MN00015-VERSION-CHANGED">
<enabled>true</enabled>
<action type="call" sourceprogram="" sourcecomponent="*"
targetprogram="EVENT" targetcomponent="DATA">
<option name="program" value="BA10100J" />
<option name="method" value="*CHGVSNR" />
</action>
<action type="change-version"
sourceprogram="EVENT" sourcecomponent="DATA" targetprogram="">
<option name="FIELD" value="VSNR" />
</action>
<action type="run"
targetprogram="" targetcomponent="AfterVersionChange" />
<action type="run" sourceprogram="EVENT" sourcecomponent="DATA"
targetprogram="NAVIGATION" targetcomponent="BA10100-CHG-VERSION" />
</transaction>
RuntimeTask
Dieser Task dient dazu aus JET heraus beliebige Windows-Programme unter Verwendung von Parametern aufzurufen. Als Input für den Task sind erforderlich:
- das aufzurufende Programm (pgm)
- die Parameter für das aufzurufende Programm (param)
- das Arbeitsverzeichnis für das auszuführende Programm (dir)
Wenn kein Programm angegeben wird, dann muss der Parameter auf eine Datei verweisen, die direkt geöffnet werden kann, bspw. auf ein „*.doc", das von Word geöffnet wird.
Die Parameter sind optional, wenn ein Programm angegeben wurde.
Wenn kein Arbeitsverzeichnis angegeben wird, dann wird das bin-Verzeichnis des JET-Clients verwendet.
Diese Informationen können statisch oder dynamisch angegeben werden. Um sie statisch vorzugeben, verwenden Sie einfach Optionen mit dem jeweiligen Namen.
Beispiel:
<action type="TASK_RUNTIME">
<option name="pgm" value="email" /> <- wird umgeschlüsselt, s.u.
<option name="param" value="info@oxaion.de" />
<option name="dir" value="." />
</action>
Um dynamisch zur Laufzeit zu ermitteln, welche Informationen verwendet werden sollen, werden die entsprechenden Optionen als Schlüssel für die Daten in der source com po nent interpretiert.
Beispiel:
<action type="TASK_RUNTIME" sourceprogram="" sourcecomponent="*">
<option name="param" value="FILENAME" />
</action>
Hier wird nur param verwendet, dessen Wert aus dem Feld FILENAME in der aktuellen Maske gelesen wird.
Um statisch und dynamisch zu mischen, müssen Sie EVENT.DATA verwenden:
<action type="update" sourceprogram="" sourcecomponent="EMAIL"
targetprogram="EVENT" targetcomponent="DATA">
<option name="program" value="email" />
</action>
<action type="TASK_RUNTIME" sourceprogram="EVENT" sourcecomponent="DATA">
<option name="pgm" value="program" />
<option name="param" value="EMAIL" />
</action>
Hier wird das Feld EMAIL zusammen mit dem Programmnamen program=email in das EVENT.DATA übernommen. Der RuntimeTask verwendet dann die beiden Schlüssel, um die tatsächlichen Aufrufinformationen zu ermitteln.
Umschlüsselung der Programmnamen
Falls man ohnehin eine Datei als parm angibt, sollte man im Allgemeinen das Programm nicht explizit mit pgm angeben, damit die Systemeinstellungen verwendet werden.
Wenn keine Datei übergeben wird, dann muss das Programm angegeben werden, bspw. um das E-Mail-Programm zu starten. Damit aber nicht ein spezielles Programm (bspw. Notes) vorgegeben werden muss, erfolgt über die client.properties eine Umschlüsselung eines logischen Programmnamens (bspw. xmleditor) auf ein tatsächliches (bspw. NotePad.exe).
Beispiel:
RuntimeTextField-1.0-xmleditor=NotePad.exe
Wird ein solcher Eintrag nicht gefunden, wird der Eintrag der
RuntimeTextField-1.0-default
verwendet, hinter welchem man normalerweise die SystemCall.exe findet.
Zum Öffnen darf der RuntimeTask nicht verwendet werden, da er mit Leerzeichen in Pfadnamen nicht korrekt funktioniert. Stattdessen ist der ProcessTask zu verwenden.
ProcessTask
Dieser Task dient dem Öffnen/Ausführen von Dateien analog dem RuntimeTask, lediglich die Parametrisierung ist anders, damit auf Leerzeichen im Pfad reagiert werden kann.
Beispiel:
<action type="TASK_PROCESS" sourceprogram="" sourcecomponent="NAVCOMP">
<option name="param-0" value="default" />
<option name="param-1" value="PATH" />
</action>
SchedulerTask
Dieser Task dient der periodischen oder verzögerten Ausführung von Transaktionen. Er ermöglicht mit der Option delay die Angabe der Wartezeit und mit der Option transaction die Angabe der auszuführenden Aktion
Beispiel:
<transaction id="LOADFIRST">
...
<action type="timer" targetprogram="">
<option name="delay" value="60" />
<option name="transaction" value="US58002-PARM" />
</action>
</transaction>
SplitTask
Dieser Task splittet Feldinhalte auf Unterfelder. Ein typisches Beispiel für eine solche Aktion ist das Empfangen eines zusammengesetzten Feldes aus einer SendTo-Aktion in einer DROPPED-Transaktion und das Einstellen dieses Feldes in eine Bildschirmkomponente ohne Serverkontakt. Über die Option split wird der Feldname für das zu splittende Feld angegeben, das in sourceprogram / sourcecomponent zur Verfügung gestellt wird.
Beispiel:
<transaction id="KDNR-DROPPED">
<action type="split" sourceprogram="EVENT" sourcecomponent="DATA"
targetprogram="" targetcomponent="AKDNR">
<option name="split" value="KDNR" />
</action>
</transaction>
IfTask
Der IfTask erlaubt es, in Abhängigkeit einer Bedingung die eine oder andere Transaktion auszuführen. Von diesem Task sollte nur sehr vorsichtig Gebrauch gemacht werden, da die XML-Maskenbeschreibung i.a. nicht der Ort für die Ausführung von Anwendungslogik ist. Über die Option condition wird die Bedingung angegeben. Die Bedingung hat immer die Form
Feldname bzw. Komponentenname = Feldwert
Der Feld- bzw. Komponentenname referenziert auf das <field>-Element in der Komponentenbeschreibung, die Komponente selber wird in sourcecomponent angegeben. Wenn die Bedingung erfüllt ist, dann wird die in der Option if-transaction angegebene Transaktion ausgeführt, im anderen Fall, die in Option else-transaction angegebene Transaktion. Wurden diese Optionen nicht angegeben, so passiert gar nichts. Man kann also eine einfache IF-Abfrage durch Weglassen der Option else-transaction programmieren. Die Empfängertransaktion bekommt die zum Zeitpunkt des Aufrufs in EVENT.DATA befindlichen Daten in EVENT.DATA zur Verfügung gestellt.
Beispiel:
<transaction id="RUN_FOLGEMASKE"> ... <action type="if" sourceprogram="" sourcecomponent="NEW-WINDOW" targetprogram=""> <option name="condition" value="NEWWND=J" /> <option name="if-transaction" value="FlyingNextWindow" /> <option name="else-transaction" value="ModalNextWindow" /> </action> </transaction>
Mit einer speziellen Bedingung, lässt sich prüfen, ob das aktuelle Programm in einem modalen Dialog angezeigt wird. Als modaler Dialog gelten NEW- und NEW-BLOCKING-Aufrufe. Die Bedingung ist wie folgt zu hinterlegen:
Häufig benötigt wird dies, um in der CLOSE-Transaktion zu unterscheiden, ob nur das Window, oder "alles" geschlossen werden soll.
<action type="condition" value="in-dialog=true" />
TaskArchiveMail
Mit diesem Task wird die Möglichkeit geschaffen, E-Mails aus dem integrierten E-Mail-Client in die Ablage zu ziehen.
<transaction id="PCFLR_FOLDER-MAIL-DROPPED">
<enabled>true</enabled>
<action sourcecomponent="NAVCOMP" sourceprogram=""
targetcomponent="DATA" targetprogram="EVENT"
type="TASK_ARCHIVE_MAIL">
<option name="copy" value="PKPKNR AHPKNR PKPFIN AHPFIN"/>
</action>
...
</transaction>
Der gleiche Task existiert nocheinmal für die transaction id=PCFLR-MAIL-DROPPED. Der Unterschied liegt in dem jeweiligen Ablagepunkt. Ersteres beschreibt die das droppen der E-Mail auf einen Ordner innerhalb der Ablage und zweiteres das droppen auf den Ablageordner selbst.
Es besteht des Weiteren die Möglichkeit den Dateinamen unter dem die E-Mail abgelegt wird in dem XML vorzudefinieren.
Dazu wird in dem action-Tag folgender Eintrag definiert:
<option name="filename-pattern"
value=Von|$From@|DATE:yyyyMMdd|$Subject|.mail
/>
Die einzelnen Bestandteile des Patterns werden durch ein Pipe „|" getrennt.
Folgende Werte sind als Pattern zulässig:
- Werte aus dem E-Mail-Header (Schlüsselzeichen $)
- Datum (Schlüsselzeichen DATE:), hierbei gilt zu beachten, dass für die Monatsangabe „M" statt der „m" für Minuten angegeben wird.
- Freitext (ohne Schlüsselzeichen)
- Feldnamen (Schlüsselzeichen *)
Beispiel für die Projektablage:
<transaction id="PCFLR-MAIL-DROPPED">
<enabled>true</enabled>
<action sourcecomponent="NAVCOMP" sourceprogram=""
targetcomponent="DATA" targetprogram="EVENT"
type="TASK_ARCHIVE_MAIL">
<option name="filename-pattern"
value="*AKIBNR|$From@|DATE:yyyyMMdd|$Subject|.mail"
/>
</action>
</transaction>
Der Dateiname hätte das Format 2007-00001test demouser20080214test.mail
Damit diese Erweiterungen nicht verloren gehen muss unbedingt Kapitel 7 aus der XML-Maskenbeschreibung (Variation-Tags) beachtet werden.
CreateDocTask
Soll aus einer Anwendung ein Word-Dokument erstellt werden, so kann dieses mit Hilfe des CreateDocTask verwirklicht werden. Im Word-Dokument vorhandene Textmarken können durch Daten aus oxaion ersetzt werden. Die zu ersetzenden Textmarken müssen dann im Event-Data zur Verfügung stehen.
<transaction id="CREATE_DOC">
<action type="TASK_CREATE_DOC" sourceprogram="EVENT"
sourcecomponent="DATA" targetprogram="*">
<option name="exists" value="open" />
<option name="target" value="WRDDOC" />
<option name="template" value="WRDDOT" />
<option name="relative-to-objects" value="true" />
</action>
</transaction>
Über die Optionen muss zwingend der Dateiname im target-Tag übergeben werden. Nicht existente Verzeichnispfade werden durch den Task angelegt. Die weiteren Optionen sind optional.
Über das template-Tag kann eine Vorlage angegeben werden auf dessen Grundlage das zu neue Dokument erstellt wird.
Existiert bereits eine Datei mit gleichen Namen wie im target-Tag angegeben, wird über das exists-Tag gesteuert ob das vorhandene Dokument geöffnet werden soll. Fehlt das exists-Tag und eine gleichnamige Datei existiert bereits, öffnet sich ein Dialogfenster in welchen der Benutzer angegeben kann, ob das Dokument überschrieben oder geöffnet werden soll.
Über das relative-to-objects-Tag wird der Template-Pfad relativ zum Objects-Verzeichnis angegeben (TRUE), ansonsten relativ zum Word-Verzeichnis (FALSE). Der Default-Wert ist TRUE.
Aufgrund der unterschiedlichen zur Verfügung stehenden Office-Versionen gelten folgende Restriktionen:
- Hat der Dateiname keine gültige Dateiendung (doc, docx, docm) wird automatisch die Endung docx vergeben.
- Ist die Template-Dateierweiterung vom gleichen Typ wie die Erweiterung der Zieldatei, wird das Template in die Zieldatei kopiert und dient dort als Grundlage des erstellten Dokumentes. Sind die Dateiendungen unterschiedlich, versucht die Word-Anwendung das neue Dokument aufgrund der Vorlage zu erstellen.
- Beinhaltet das Dokument ein Makro mit dem Namen JETJETdJdJET_RUN wird dieses automatich nach Austausch eventueller Textmarken ausgeführt (nur Windows-Betriebssystemen).
- Ist die Dateierweiterung vom Typ Office-Version kleiner 2007, das verwendete Office jedoch Version größer/gleich 2007, versucht der Task ein Makro mit dem Namen WORD_CONVERT aufzurufen. Dieses Makro ruft einen „Speichern unter …"-Dialog auf um das Dokument durch das verwendete Word zu konvertieren.
CopyTask
Dieser Task kopiert den Inhalt der aktuell fokusierten Komponente in die Zwischenablage.
<action type="copy" />
PasteTask
Dieser Task fügt den Inhalt der Zwischenablage in die aktuell fokusierte Komponente ein.
<action type="paste" />
CutTask
Dieser Task schneidet den Inhalt der aktuell ausgewählten Komponente aus und fügt ihn in die Zwischenablage ein.
<action type="cut" />
DeleteTask
Dieser Task macht das selbe, wie wenn auf der aktuell fokusierten Komponente die "DELETE"-Taste gedrückt wird.
<action type="delete" />
ClipboardCopyLinkTask
Dieser Task kopiert einen Link in die Zwischenablage. Der Link kommt aus der Sourcedata.
Feld „TEXT_LINK": Der Link als Plaintext (wie er z.B. in einer Adresszeile im Browser eingegeben wird)
Feld „HTML_LINK": Der Link als HTML (z.B. „<a href="oxaion://">oxaion Starten</a")
<action type="TASK_COPY_LINK" sourceprogram="EVENT" sourcecomponent="DATA" />
GetLinkTask
Dieser Task erzeugt einen HTML- und einen Plaintext-Link aus der Source-Data und schreibt diesen in die Target-Data.
<action type="tree" targetprogram="" targetcomponent="NAVCOMP">
<option name="get-container" value="" />
</action>
<action type="TASK_GET_LINK" sourceprogram="EVENT" sourcecomponent="DATA"
targetprogram="LINK" targetcomponent="DATA">
<option name="url" value="oxaion://US11290.%PKPKNR%.%PKPFIN%@%COMPANY%@%ENVIRONMENT%" />
<option name="text" value="Geschäftspartner %PKPKNR% %PKPFIN%" />
</action>
In den Parametern „url" und „text" kann eine Vorlage für den Link eingegeben werden.
Alle durch „%" markierten Variablen werden in diesen beiden Texten durch die Werte der Felder aus der sourceData ersetzt.
Das Ergebnis wäre in diesem Fall beispielsweise (in der LINK.DATA):
HTML_LINK = „<a href="oxaion://US11290.000001.000OXAION41">Geschäftspartner 000001 000</a>"
TEXT_LINK = „oxaion://US11290.000001.000OXAION41"
CheckTabSelectedTask
Dieser Task kann abhängig davon, ob ein bestimmter Tab in einem Tab-Container selektiert (also im Vordergrund ist und angezeigt wird) ist eine Transaktion ausführen.Parameter:
- tab-selected: Die ID des Containers im Tab, die überprüft wird
- if-transaction: Die ID der Transaktion, welche ausgeführt wird, wenn der Tab selektiert ist (oder keine)
- else-transaction: Die ID der Transaktion, welche ausgeführt wird, wenn der Tab nicht selektiert ist (oder keine)
<action type="check-tab-selected" sourceprogram=""> <option name="tab-selected" value="TAB01" /> <option name="if-transaction" value="DO_SOMETHING" /> <option name="else-transaction" value="DO_SOMETHING_ELSE" /> </action>
RunOxaionLinkTask (nur oxaion open)
Dieser Task führt einen oxaion Link aus.Der Link kommt entweder aus der <option name="link" value="...">oder aus einem Feld aus SourceData. Der Name des Feldes wird dann per <option name= "link-field" value="...">definiert.
ForEachTask
Führt eine andere Transaction x-mal aus. Beispiel aus Tasks:
<action type="foreach" sourceProgram="EVENT" sourceComponent="DATA" targetProgram="EVENT" targetComponent="runInternet"> <option name="foreach" value="url"/> </action>
In EVENT.DATA steht folgendes:
url-0-URL=http://www.google.de
url-0-TITLE=google.de
url-1-URL=http://www.bing.de
url-1-TITLE=bing.de
ICON=internet.png
Jetzt wird die Transaction "runInternet" zwei mal aufgerufen. In der FOREACH.DATA steht beim ersten mal:
URL=http://www.google.de, TITLE=google.de, ICON=internet.pngund
beim zweiten Mal:
URL=http://www.bing.de, TITLE=bing.de, ICON=internet.png
Die FOREACH.DATA kann nun z.B. so verarbeitet werden:
<transaction id="runInternet"> <action type="TASK_INTERNET_EXPLORER" sourceprogram="FOREACH" sourcecomponent="DATA"> <option name="url" value="URL" /> <option name="icon" value="ICON" /> <option name="title" value="TITLE" /> </action> </transaction>
Interne Tasks
Die internen Tasks können nicht aus XML-Dateien aufgerufen werden. Falls doch, ist dies explizit angegeben.
AboutTask
Der AboutTask zeigt den Info-Dialog an. Dieser enthält Informationen über das verwendete JET-Release und den angemeldeten Benutzer.
Dieser Task kann auch über XML aufgerufen werden.
StartProgramTask
Dieser Task hat mittlerweile auch Eingang in die XML-Programmierung gefunden. Er öffnet eine neue Programmlasche mit einem durch die Option xml zu bestimmenden Programm. Das zu öffnende Programm kann alternativ auch über sourceprogram / sourcecomponent über das Feld PGMN definiert werden. Wenn während des Aufrufes des Tasks die context.clientproperty „START_PROGRAM_CHECK" gefüllt ist, wird das zu startende Programm über einen iSeries-Call ermittelt.
Beispiel:
<transaction id="OPEN_NEW_TAB">
<title><translate id="X78039" /></title>
<description><translate id="X77046" /></description>
<icon>open16.gif</icon>
<enabled>true</enabled>
<action type="TASK_START_PROGRAM">
<option name="xml" value="BA20100R" />
</action>
<action type="run" targetprogram="" targetcomponent="OPEN" />
</transaction>
CloseActivationGroupTask
Der ActivationGroupTask schließt über einen iSeries-Call die Aktivierungsgruppe des über den source-Parameter übergebenen Programmobjektes.
QuitTask
Der QuitTask schließt den JET Client, wobei er ggf. geöffnete Programme schließt und den Benutzer abmeldet.
Dieser Task kann auch über XML aufgerufen werden.
RedoTask
Der RedoTask wiederholt die letzte rückgängig gemachte Benutzereingabe.
Dieser Task kann auch über XML aufgerufen werden.
UndoTask
Der UndoTask macht die letzte Benutzereingabe rückgängig.
Dieser Task kann auch über XML aufgerufen werden.
NewFirmModeTask
Der NewFirmModeTask öffnet einen neuen Modus unter einer anderen Firma. Ein neuer Modus entspricht einer komplett unabhänigen neuen Ameldung mit den selben Anmeldeinformationen (gleicher Benutzer, gleiches Passwort...)
Dieser Task kann auch über XML aufgerufen werden.
NewModeTask
Der NewModeTask öffnet einen neuen Modus. Ein neuer Modus entspricht einer komplett unabhänigen neuen Ameldung mit den selben Anmeldeinformationen (gleicher Benutzer, gleiches Passwort...)
Dieser Task kann auch über XML aufgerufen werden.
ChangeUserNameTask
Über den ChangeUserNameTask kann ein abweichender Benutzername angegeben werden, um für das weitere Arbeiten dessen XML-Dateien zu verwenden.
Dieser Task kann auch über XML aufgerufen werden.
CloseWindowTask
Der CloseWindowTask schließt ein Matchcode-, Explorer- oder Detailfenster, ohne Endeverarbeitungen auszuführen. Er ist vorallem während der Entwicklung hilfreich, wenn ein Anwendungsfehler das weitere Arbeiten unmöglich macht.
EmptyTask
Der EmptyTask ist ein Dummy-Task der keine Aktionen durchführt.
Dieser Task kann auch über XML aufgerufen werden.
PrintPageDialogTask
Der PrintPageDialogTask öffnet den Druckdialog des Betriebssystems. Hier lassen sich Einstellungen wie z. B. das Seitenformat, die Ränder, der zu verwendende Drucker usw. vorgenommen werden. Der Task wird beispielsweise für die Konfiguration des Netzwerkdrucks in Auskunftsprogrammen verwendet.
Dieser Task kann auch über XML aufgerufen werden.
KillTask
Der KillTask beendet den JET Client unkontrolliert ohne Endeverarbeitungen durchzuführen und sich abzumelden. Er ist vorallem während der Entwicklung hilfreich, wenn ein Anwendungsfehler das weitere Arbeiten unmöglich macht.
Dieser Task kann auch über XML aufgerufen werden.
ShowXMLSourceTask
Der ShowXMLSourceTask zeigt den Pfad der XML- und Sprach-Datei des gerade angezeigten Programmes des Detailbereiches an. Er ist daher vorallem während der XML-Entwicklung hilfreich.
Dieser Task kann auch über XML aufgerufen werden.