Diagramme validieren und testen

Verwendung

Die INUBIT-Software bietet Ihnen eine integrierte Testumgebung, mit welcher Sie die Funktionsfähigkeit von Technical Workflows testen können, bevor Sie diese produktiv setzen.

Die integrierte Testumgebung bietet folgende Funktionen:

  • Test-Modus

    Um Workflows manuell zu starten und auszuführen. Den Test-Modus können Sie lokal und auf der INUBIT Process Engine nutzen:

    • Lokal

      Bei der Ausführung werden die lokalen Workflow- und Moduleinstellungen verwendet

    • Auf der INUBIT Process Engine

      Es werden die Workflow- und Moduleinstellungen genutzt, die in der INUBIT Process Engine vorhanden sind. Die Workflows können vollständig oder teilweise getestet werden.

      Siehe Test Modus: Testen von Diagrammen.

  • Watch-Modus

    Im Watch-Modus können Sie die Ausführung von ereignis- oder zeitgesteuerten Workflows in der INUBIT Process Engine überwachen, d.h., von Workflows, die durch einen Scheduler oder einen Systemkonnektor gestartet werden, der als Listener konfiguriert ist.

    Siehe Watch-Modus verwenden.

  • Prüf-Workflows

    Zusätzlich können Sie Technical Workflows mit speziell dafür erzeugten Prüf-Workflows auf die Einhaltung bestimmter Bedingungen wie z.B. Namenskonventionen testen.

    Siehe

  • Unit Tests

    Mit der Unit Test-Komponente können Sie für Technical Workflows Testfälle erstellen, welche diese abschnittsweise testen. Die Testparameter wie z.B. Eingangsnachricht, Variablen und Prüfbedingungen werden am Testfall gespeichert, sodass die Tests jederzeit reproduzierbar sind. Die Ausführung der Testfälle kann automatisiert werden, die Testergebnisse werden protokolliert.

    Siehe Unit Tests verwenden.

Weitere Unterstützung bieten die folgenden Funktionen:

Test Modus: Testen von Diagrammen

Voraussetzungen

Die Benutzerrolle oder der Benutzer besitzt das Recht Test-Modus für das zu testende Diagramm.

Überblick

Ausführbare Diagramme wie Technical Workflows können im Server- und im lokalen Modus getestet werden.

Während des Tests bewegt sich eine Statusmarke von Modul zu Modul und signalisiert damit den aktuellen Stand der Nachrichtenverarbeitung:

workbench user guide 708 0

Die unterschiedlichen Farben der Statusmarken bedeuten folgendes:

  • Grün: Das Modul wurde erfolgreich ausgeführt.

  • Rot: Das Modul wurde nicht erfolgreich ausgeführt.
    Der Test wurde gestoppt und eine Fehlermeldung ausgegeben.

  • Blau: Die Ausführung des Moduls wird wiederholt, möglich z.B. bei Systemkonnektoren, wenn Verbindungsversuche wiederholt werden.

  • Gelb: Das Modul wartet auf das Eintreten eines festgelegten Ereignisses, z.B. auf einen Zeitpunkt oder die Abarbeitung eines anderen Moduls.

Diagramme komplett oder teilweise testen

Sie können Diagramme komplett oder teilweise testen, indem Sie gezielt Start- und Breakpoints setzen:

  • workbench user guide 708 1 Startpoint
    Modul oder Verbindung, an denen der Test starten soll.

  • workbench user guide 708 2 Breakpoint
    Modul, an dem der Test gestoppt werden soll. Sie können den Test wahlweise immer an einem Breakpoint abbrechen lassen oder Bedingungen für den Abbruch definieren.
    Siehe Schritt Bedingungen für Breakpoint definieren unten.
    Über das Kontextmenü des Breakpoints kann der angehaltene Testlauf fortgesetzt werden.

    workbench user guide 708 3

Testergebnisse anzeigen

Während des Tests werden an allen Verbindungen zusätzlich Watchpoints workbench user guide 708 4 gesetzt. Wenn der Test gestoppt oder beendet ist, können Sie an jedem Watch-, Start- und Breakpoint die Testergebnisse und damit den aktuellen Stand der Nachrichten- und Variablenverarbeitung anzeigen.

Siehe Dialog Watchpoint.

Testdaten

Sie können Tests initial z.B. mit einer Beispiel-Testnachricht starten, die Sie von Ihrem Geschäftspartner erhalten. Nach dem ersten Test können Sie die Testergebnisse speichern und wiederverwenden, die an dem Watch-, Start- und Breakpoint angezeigt werden. Dabei haben Sie u.a. folgende Optionen:

  • Nachrichten speichern
    Sie können die Nachrichten im Dateisystem oder Repository speichern und für spätere Tests verwenden.
    Siehe Schritt Ergebnisdatei speichern in Dialog Watchpoint.

  • Nachrichten und Variablen speichern
    Sie können die Nachrichten und die Variablen gemeinsam als Watchpoint-Datei (*.wpf-Datei) speichern und ins Dateisystem oder Repository speichern.

Besonderheiten

Im Testmodus gelten folgende Besonderheiten:

  • Ereignis- oder zeitgesteuerte Workflows
    Workflows mit Systemkonnektoren im Listener Modus und/oder aktivierten Schedulern werden nur ausgeführt, wenn Sie diese manuell starten. Alternativ können Sie den Watch-Modus verwenden.

  • Retry- und Wait-Mechanismen
    Retry- und Wait-Mechanismen werden nicht ausgeführt.

So gehen Sie vor

  1. Zeigen Sie das ausführbare Diagramm an, das Sie testen möchten.

  2. Startpoint setzen

    1. Markieren Sie die Verbindung, an welcher der Test starten soll.
      Wenn der Test am ersten Modul des Workflows starten soll, markieren Sie das erste Modul.

    2. Öffnen Sie das Kontextmenü und wählen Sie Startpoint setzen.

  3. Breakpoints definieren

    1. Markieren Sie die Verbindung, an welcher der Test angehalten werden soll.

    2. Öffnen Sie das Kontextmenü und wählen Sie Breakpoint setzen.

  4. Bedingungen für Breakpoints definieren

    Sobald Sie einen Breakpoint gesetzt haben, können Sie festlegen, unter welchen Bedingungen der Breakpoint für einen Abbruch des Tests sorgen soll:

    1. Öffnen Sie das Kontextmenü des Breakpoints und wählen Sie Breakpoint-Bedingungen festlegen.
      Ein Dialog öffnet sich.
      In diesem Dialog können Sie eine oder mehr Bedingungen definieren. Eine Bedingung besteht entweder aus einem XPath-Ausdruck oder dem Abgleich zweier Werte. Die Werte können aus Elementen in XML-basierten Nachrichten oder Variablen stammen oder statisch definiert werden. Für den Werteabgleich gibt es folgende Operatoren:

      Operator Bedeutung

      =

      Gleich

      <

      Kleiner als

      >

      Größer als

      >=

      Größer gleich

      <=

      Kleiner gleich

      !=

      Ungleich

      Exists

      Existiert

      NotExists

      Existiert nicht

      XPath

      XPath-Ausdruck

      Beispiele:

      • /AUFTRAG/AUFTRAGSSUMME > 1000

      • /ORDER/DELIVERY/ = Express

      • /IBISProfile/Profile/Name Exists

      • count(/Order/test1) > 1

        Die Bedingung ist erfüllt, wenn die Auswertung der XPath-Funktion count() ergibt, dass der Knoten /Order/test1 mehr als einmal existiert.

        Die Buttons haben folgende Bedeutung:

        • D: Der Wert stammt aus einem Element in der XML-basierten Nachricht, das mit einem anderen Element, einer Variablen oder einem statischen Wert verglichen werden soll. Den Pfad zum Element geben Sie als XPath- Ausdruck an. Der workbench user guide 710 0-Button öffnet einen Assistenten zum Anlegen des XPath-Ausdrucks.

        • V: Der Wert stammt aus einer Variablen, die mit einem anderen Datenelement, einer Variablen oder einem statischen Wert verglichen werden soll. Die vorhandenen Variablen werden in der nebenstehenden Liste angezeigt.

        • X: Die Bedingung bezieht sich auf einen XPath-Ausdruck. Der XPath wird auf einem leeren Dokument ausgeführt, nicht auf Nachrichten. Der workbench user guide 710 0-Button öffnet einen Assistenten zum Anlegen des XPath-Ausdrucks.

        • S: Der Vergleichswert ist ein statischer Wert, den Sie manuell eingeben.

    2. Um weitere Bedingungen zu definieren, klicken Sie auf Bedingung hinzufügen.
      Sobald mindestens zwei Bedingungen vorhanden sind, können Sie definieren, mit welchem Operator die Bedingungen verknüpft werden sollen:

      • AND: Alle Bedingungen müssen zutreffen.

      • OR: Eine der Bedingungen muss zutreffen.

    3. Klicken Sie auf OK, um den Dialog zu schließen.

  5. Klicken Sie in den Workspace und selektieren danach eines der folgenden Kommandos im Kontextmenü:

    • Testdatei laden
      Öffnet einen Datei-Explorer und startet den Test mit der ausgewählten Datei aus dem Dateisystem.

    • Test ohne Datei starten
      Für Module, die keine Startdatei benötigen, wie z.B. den Workflow Starter oder den Report Data Collector.

    • Test mit Zwischenablageninhalt starten
      Um den Test mit der (Zwischen-)Ergebnisdatei eines anderen, bereits getesteten Technical Workflows zu starten. Sie müssen vorher die Ergebnisdatei des anderen Workflows in die Zwischenablage kopiert haben!

    • Test mit Repositorydatei starten
      Öffnet den Repository-Explorer zur Auswahl einer Datei aus dem Repository und startet damit den Test.

Der Test des Diagramms wird mit der ausgewählten Option gestartet. Nach dem Test wird eine Erfolgs- bzw. Fehlermeldung angezeigt.

Testmodus zurücksetzen

Um nach dem Testen alle Statusmarken, Start-, Watch- und Breakpoints zu entfernen, öffnen Sie das Kontextmenü des Designers und wählen Test-Modus zurücksetzen.

Testergebnisse und Fehlermeldungen anzeigen

Sie können an allen Watchpoints den aktuellen Stand der Nachrichtenverarbeitung und die aktuellen Werte der Variablen anzeigen. Falls ein Test an einem Modul scheitert, können Sie sich die Fehlermeldung an diesem Modul anzeigen lassen.

So gehen Sie vor

  1. Testen Sie den Workflow.

  2. Nach dem Test öffnen Sie das Kontextmenü eines Start-, Watch- oder Breakpoints und wählen Ergebnisdatei anzeigen. Alternativ doppelklicken Sie den Testpunkt.

    Über den Kontextmenüpunkt Ergebnisdatei in Zwischenablage kopieren können Sie die Ergebnisdatei direkt in die Zwischenablage kopieren, ohne sie zu öffnen.

    Der Dialog Watchpoint öffnet sich und zeigt das aktuelle Testergebnis, die Variablen und deren aktuelle Werte an. Im Fehlerfall wird eine Fehlermeldung angezeigt.
    Falls Sie die Fehlermeldung später erneut anzeigen möchten, markieren Sie das Modul, an dem der Test gescheitert ist, öffnen das Kontextmenü und wählen Fehlermeldung anzeigen.

Sie können die Testergebnisse speichern, um diese in späteren Tests wiederzuverwenden.

Aktualisierungsintervall von Testpunkten ändern

Bei sehr langen, verschachtelten oder auch sehr kurzen Technical Workflows kann es sinnvoll sein, das Zeitintervall, in dem die Anzeige der Testpunkten aktualisiert wird, zu ändern, damit Sie den Ablauf des Workflows besser nachvollziehen können.

So gehen Sie vor

  1. Klicken Sie in die Arbeitsfläche Ihres Technical Workflows.

  2. Öffnen Sie das Kontextmenü und wählen Sie Testpunkte aktualisieren > Sehr schnell/Schnell/Normal/Langsam.

Watch-Modus verwenden

Im Watch-Modus überwachen Sie die Ausführung von ereignis- oder zeitgesteuerten Workflows in der INUBIT Process Engine, d.h., von Workflows, die durch einen Scheduler oder Listener gestartet werden.

Der Stand der Ausführung eines Technical Workflows wird durch farbige Marken signalisiert. Während der Ausführung werden automatisch Watchpoints zwischen den Modulen gesetzt, an denen Sie die Zwischenergebnisse anzeigen können.

Siehe Test Modus: Testen von Diagrammen.

Wait-Module werden im Watch-Modus nicht ausgeführt.

Voraussetzungen

Das Diagramm ist bereits publiziert.

Watch-Modus aktivieren

So gehen Sie vor

  1. Zeigen Sie das Diagramm an, welches Sie im Watch-Modus überwachen wollen.

  2. Klicken Sie in die Arbeitsfläche, öffnen Sie das Kontextmenü und wählen Sie einen der beiden Befehle:

    • Watch-Modus aktivieren
      Die Ausführung des Prozesses wird solange angezeigt, wie der Prozess läuft oder bis der Watch-Modus deaktiviert wird.

    • Watch-Modus für nächsten Prozess aktivieren
      Die erste Ausführung des Prozesses wird angezeigt, danach läuft der Prozess weiter, ohne angezeigt zu werden.

Der aktuelle Modus wird in der Statuszeile der INUBIT Workbench angezeigt: Mode: Watch. Nach der ersten Ausführung wird auch die ID (PID) des Workflowprozesses in der Statuszeile angezeigt.
Siehe Dialog Watchpoint.

Bedingten Watch-Modus aktivieren

So gehen Sie vor

  1. Zeigen Sie das Diagramm an, für das Sie eine Bedingung definieren wollen, deren Zutreffen den Watch-Modus aktiviert.

  2. Öffnen Sie das Kontextmenü des Moduls, für das Sie die Bedingung definieren wollen.

  3. Wählen Sie den Menüpunkt Watch-Modus mit Bedingung aktivieren.
    Ein Dialog öffnet sich.

    Diese Option steht nur dann zur Auswahl, wenn der Watch-Modus weder für andere Module noch für das Diagramm insgesamt aktiviert ist. Um den Watch-Modus zu deaktivieren, klicken Sie in die Arbeitsfläche, öffnen Sie das Kontextmenü und wählen Sie den Befehl Watch-Modus deaktivieren.

  4. Definieren Sie eine oder mehrere Bedingungen. Eine Bedingung besteht entweder aus einem XPath-Ausdruck oder dem Abgleich zweier Werte. Die Werte können aus Elementen in XML-basierten Nachrichten oder Variablen stammen oder statisch definiert werden. Für den Werteabgleich gibt es folgende Operatoren:

    Operator Bedeutung

    =

    Gleich

    <

    Kleiner als

    >

    Größer als

    >=

    Größer gleich

    <=

    Kleiner gleich

    !=

    Ungleich

    Exists

    Existiert

    NotExists

    Existiert nicht

    XPath

    XPath-Ausdruck

    Beispiele:

    • /AUFTRAG/AUFTRAGSSUMME > 1000

    • /AUFTRAG/LIEFERUNG/ = Express

    • /IBISProfile/Profile/Name Exists

    • count(/Order/test1) > 1

      Die Bedingung ist erfüllt, wenn die Auswertung der XPath-Funktion count() ergibt, dass der Knoten /Order/ test1 mehr als einmal existiert.

      Die Buttons haben folgende Bedeutung:

      • D: Der Wert stammt aus einem Element in der XML-basierten Nachricht, das mit einem anderen Element, einer Variablen oder einem statischen Wert verglichen werden soll. Den Pfad zum Element geben Sie als XPath-Ausdruck an. Der workbench user guide 712 1-Button öffnet einen Assistenten zum Anlegen des XPath-Ausdrucks.

      • V: Der Wert stammt aus einer Variablen, die mit einem anderen Datenelement, einer Variablen oder einem statischen Wert verglichen werden soll. Die vorhandenen Variablen werden in der nebenstehenden Liste angezeigt.

      • X: Die Bedingung bezieht sich auf einen XPath-Ausdruck. Der XPath wird auf einem leeren Dokument ausgeführt, nicht auf Nachrichten. Der workbench user guide 712 1-Button öffnet einen Assistenten zum Anlegen des XPath-Ausdrucks.

      • S: Der Vergleichswert ist ein statischer Wert, den Sie manuell eingeben.

  5. Um weitere Bedingungen zu definieren, klicken Sie auf Bedingung hinzufügen.
    Sobald mindestens zwei Bedingungen vorhanden sind, können Sie definieren, mit welchem Operator die Bedingungen verknüpft werden sollen:

    • AND: Alle Bedingungen müssen zutreffen.

    • OR: Eine der Bedingungen muss zutreffen.

  6. Klicken Sie auf OK, um den Dialog zu schließen.
    In der INUBIT Workbench-Statusleiste wird der aktuelle Modus angezeigt: Mode: Watch. Nach der ersten Ausführung wird in der Statuszeile auch die Prozess-ID (PID) des Workflows angezeigt.

Siehe Dialog Watchpoint.

Watch-Modus deaktivieren

So gehen Sie vor

Klicken Sie in die Arbeitsfläche, öffnen Sie das Kontextmenü und wählen Sie Watch-Modus deaktivieren.

Der Watch-Modus eines Workflows wird automatisch deaktiviert, wenn Sie einen Technical Workflow anzeigen, der sich in einem anderen Modus befindet. In diesem Fall müssen Sie nach der Rückkehr zum ursprünglich überwachten Workflow den Watch-Modus erneut aktivieren.

Diagramme gegen Prüf-Workflow validieren

Verwendung

Sie können Diagramme gegen einen sogenannten Prüf-Workflow validieren lassen. Diese Validierung wird grundsätzlich beim Deployen von Diagrammen durchgeführt, sobald ein Prüf-Workflow definiert ist. Zusätzlich können Sie die Validierung bei Bedarf auch manuell auslösen.

Prinzipielles Vorgehen: Validierung gegen einen Prüf-Workflow

  1. Technical Workflow erstellen
    Sie erstellen den Technical Workflow, der zur Validierung genutzt werden soll:

    Als Eingangsnachricht erhält dieser Technical Workflow automatisch immer die Namen der Diagramme, die validiert werden sollen. Beim Deployment sind das die Namen der Diagramme, die deployt werden sollen, bei der manuellen Validierung die Namen der manuell markierten Diagramme. Darüber hinaus wird dem Prüf-Workflow der Name des Benutzers oder der Benutzergruppe übergeben.

    Auf Basis dieser Namen können Sie z.B. mit dem Utility INUBIT IS Configuration weitere Informationen über die zu validierenden Diagramme abfragen. Das Ergebnis dieser Abfrage können Sie entsprechend Ihren Anforderungen mithilfe weiterer Module auswerten.

    Das Ergebnis der Validierung wird als Meldung in der INUBIT Workbench angezeigt. Sie können das Ergebnis aber auch durch ein Modul im Technical Workflow in das Dateisystem schreiben oder per Mail versenden lassen.

  2. Technical Workflow als Prüf-Workflow definieren
    Den fertigen Technical Workflow hinterlegen Sie als sogenannten Prüf-Workflow in der INUBIT Process Engine. Der Prüf-Workflow steht allen Benutzern einer INUBIT Process Engine zur Verfügung.

  3. Validierung gegen den Prüf-Workflow

    • Automatisch beim Deployment
      Sobald ein Prüf-Workflow hinterlegt ist, wird dieser beim Deployen automatisch aufgerufen. Das Deployment wird auch dann ausgeführt, wenn die Validierung fehlschlägt.

    • Manuell bei Bedarf
      Sie können die Validierung jederzeit im Designer manuell starten.

Beispiel-Prüf-Workflow: Fixe Länge von Modulnamen in Diagrammen sicherstellen

Der folgende Prüf-Workflow prüft, ob Modulnamen in Diagrammen länger als zehn Zeichen sind. Wenn die Modulnamen kürzer sind, gibt der Prüf-Workflow eine Fehlermeldung aus.

workbench user guide 714 0

  1. Als Eingangsnachricht erhält grundsätzlich jeder Prüf-Workflow die Namen der zu validierenden Diagramme, z.B.

    <Validate>
<Diagram>Invoice Supplier A</Diagram>
<Diagram>Order-Processing</Diagram>
</Validate>

  2. Um die Länge der Modulnamen prüfen zu können, müssen die Namen der Module in den Diagrammen bekannt sein. Um solche Detailinformationen auszulesen, bietet das Utility INUBIT IS Configuration die Funktion Get_Workflow_Properties_Type.

    Der XSLT Converter erzeugt den nötigen Funktionsaufruf und gibt diesen als Eingangsnachricht an das Utility INUBIT IS Configuration weiter:

    workbench user guide 714 1

  3. Das Utility INUBIT IS Configuration führt die Funktion aus, die in der Eingangsnachricht definiert ist und gibt die Eigenschaften der übergebenen Diagramme aus. Zu den Eigenschaften gehören u.a. auch die Modulnamen:

    workbench user guide 715 0

  4. Der XSLT Converter erhält die Nachricht mit den Eigenschaften, extrahiert die Modulnamen und prüft deren Länge:

    workbench user guide 716 0

    Wenn der Modulname kürzer als zehn Zeichen ist, dann erzeugt der XSLT Converter eine Fehlermeldung. Die Fehlermeldung enthält die Namen der Module, welche die Prüfbedingung nicht erfüllt haben.

  5. Die Fehlermeldung wird als Ergebnis der Validierung ausgegeben, wenn Module die Bedingungen nicht erfüllen:

    workbench user guide 716 1

Prüf-Workflow hinterlegen

Voraussetzungen

Der Technical Workflow, der als Prüf-Workflow genutzt werden soll, ist bereits erstellt.

So gehen Sie vor

  1. Öffnen Sie in der INUBIT Workbench das Register Administration > Allgemeine Einstellungen.

  2. Zeigen Sie den Konfigurationsbereich Verwaltung > Diagramme an.

  3. Klicken Sie in der Zeile Prüf-Workflow auf workbench user guide 717 2 um Ihren Technical Workflow auszuwählen.
    Ein Assistent öffnet sich.

  4. Lassen Sie sich von dem Assistenten durch die Konfiguration des Prüf-Workflows führen.
    Wenn Sie den Assistenten beendet haben, werden der Name des ausgewählten Prüf-Workflows und des Start-Moduls in der Zeile Prüf-Workflow angezeigt.

  5. Zum Speichern klicken Sie auf workbench user guide 717 3.

Prüf-Workflow löschen

So gehen Sie vor

  1. Öffnen Sie in der INUBIT Workbench das Register Administration > Allgemeine Einstellungen.

  2. Zeigen Sie den Konfigurationsbereich Verwaltung > Diagramme an.

  3. Klicken Sie in der Zeile Prüf-Workflow auf workbench user guide 717 4 und bestätigen Sie den Rückfragedialog.
    Die Verknüpfung zum Technical Workflow wird gelöscht, in der Zeile Prüf-Workflow werden weder Workflow- noch Modulname angezeigt.

Diagramme manuell gegen Prüf-Workflow validieren

Sie können einzelne Diagramme prüfen oder eine Gruppe von Diagrammen.

Voraussetzungen

  • Die Diagramme müssen bereits publiziert worden sein.

  • Der Prüf-Workflow ist hinterlegt.

So gehen Sie vor

  1. Markieren Sie das Diagramm oder das Diagrammverzeichnis im Verzeichnisbaum.

  2. Öffnen Sie das Kontextmenü und wählen Sie Prüf-Workflow starten.
    Das Diagramm wird gegen den Prüf-Workflow geprüft, danach wird das Ergebnis angezeigt.

Unit Tests verwenden

Dieses Feature muss in Ihrer Lizenz freigeschaltet sein, damit Sie es nutzen können. Um Ihre Lizenz erweitern zu lassen, wenden Sie sich an den Support der Virtimo AG.

Verwendung

Mit der Unit Test-Komponente können Sie prüfen, ob die Bedingungen, die Sie an Breakpoints in Technical Workflows definiert haben, erfüllt wurden.

Dazu erstellen Sie für den zu prüfenden Workflow einen oder mehrere Testfälle, die jeweils einen Teil (eine Unit) des Workflows testen. Natürlich können Sie auch einzelne Module testen. Die Testparameter werden direkt am Testfall gespeichert, so dass Sie die Tests jederzeit reproduzieren können. Testparameter sind z.B. die Nachricht und Variablen zum Starten des Testfalls und die Bedingungen, gegen die das Testergebnis geprüft wird.

Die Testfälle können Sie manuell oder automatisiert einzeln oder in Gruppen starten. Die Testergebnisse werden in einem Protokoll gespeichert, das zu jedem Breakpoint die nicht erfüllten Bedingungen anzeigt.

Variablenwerte eines Technical Workflows können über das Bearbeiten des Startpoints des Unit-Tests geändert werden. Konstante Werte einer globalen Variablen können für einen Unit Test nicht geändert werden.

Über Workflow-Konnektoren verbundene Technical Workflows:
Unit Tests können keine Technical Workflows prüfen, die über Workflow-Konnektoren verbunden sind. Die verbundenen Technical Workflows werden zwar durchlaufen, aber es können dort keine Testpunkte gesetzt und geprüft werden.

Test von Benutzungsoberflächen oder Nebenläufigkeiten:
Unit Tests eignen sich nicht für den automatischen Test von Benutzungsoberflächen oder für den Test von Nebenläufigkeiten, wie sie bei der Verwendung von Threads oder verteilten Systemen auftreten.

Führen Sie Unit Tests auf Ihrer Entwicklungs- und Testumgebung aus, so dass Ihre Produktivumgebung nicht beeinflusst wird.

Testfälle anlegen

Einen Testfall legen Sie direkt in dem Technical Workflow an, der geprüft werden soll.

Die Abschnitte, die durch den Testfall geprüft werden sollen, definieren Sie durch Start- und Breakpoints, die in den Testfall übernommen werden. Am Startpoint hinterlegen Sie die Startdaten, an den Breakpoints definieren Sie die Prüfbedingungen für die Testergebnisse.

Sobald Sie den Technical Workflow publizieren, wird der Testfall inkl. der Startdaten und der Prüfbedingungen automatisch als XML-Datei in das Repository gespeichert.

Voraussetzungen

  • Der Technical Workflow ist bereits angelegt.

  • Die Daten, die zum Starten des Testfalls nötig sind, sind im Repository gespeichert oder befinden sich in der Zwischenablage.

  • Die Daten, die zum Definieren der Prüfbedingungen nötig sind, sind im Repository, im Dateisystem oder in der Zwischenablage gespeichert.

So gehen Sie vor

  1. Öffnen Sie den Technical Workflow zum Bearbeiten.

  2. Öffnen Sie in der Sidebar die Palette Unit Tests.

    Leeren Testfall anlegen

  3. Klicken Sie in der Toolbar der Palette auf workbench user guide 718 2.
    Der Dialog Testfall anlegen öffnet sich.

  4. Geben Sie dem Testfall einen Namen und fügen Sie eine kurze Beschreibung hinzu.
    Die Beschreibung des Testfalls wird im Repository in der Ansicht Unit Test Dateien angezeigt, nachdem das Diagramm publiziert worden ist.

  5. Schließen Sie den Dialog mit OK.

    Startpoint und Breakpoints definieren

  6. Setzen Sie in Ihrem Technical Workflow Start- und Breakpoints.

  7. Öffnen Sie das Kontextmenü des Testfalls und wählen Sie Testpunkte von Diagramm übernehmen.
    Der Startpoint und alle Breakpoints werden in den Testfall übernommen und angezeigt.

    Startdaten festlegen

  8. Doppelklicken Sie den Startpoint.
    Der Dialog zum Auswählen der Startdatei öffnet sich.

  9. Laden Sie die Startdatei aus dem Repository oder aus dem Clipboard.

    Wenn Sie die Startdatei aus der Zwischenablage eingefügt haben, können Sie diese manuell mit dem - Button ins Repository speichern. Ansonsten wird die Startdatei beim Publizieren des Diagramms automatisch in das Repository gespeichert.

  10. Schließen Sie den Dialog mit OK.

    Prüfbedingungen festlegen

  11. Um die Bedingungen zu definieren, gegen welche die Nachricht an einem Breakpoint geprüft werden soll, doppelklicken Sie den Breakpoint im Testfall in der Palette Unit Tests.
    Der Dialog zum Definieren der Bedingungen öffnet sich.

  12. Legen Sie fest, wie die Nachricht am Breakpoint geprüft werden soll.
    Siehe Dialog Prüfbedingungen festlegen.

  13. Schließen Sie den Dialog mit OK.

  14. Publizieren Sie den Workflow, um den Testfall inkl. der Startdaten und Prüfbedingungen in das Repository zu speichern.

    Alternativ können Sie einen Testfall direkt nach einem lokalen Test anlegen. Wenn Sie dabei die Option Testpunkte vom Diagramm übernehmen markiert lassen, dann werden die Start- und Breakpoints und die Startdaten automatisch in den Testfall übernommen.

Testfälle ausführen

Sie können einen einzelnen Testfall oder mehrere Testfälle eines Workflows ausführen lassen. Wenn Sie mehrere Testfälle starten, werden diese nacheinander in der Reihenfolge, in der sie in der Palette angezeigt werden, ausgeführt.

Siehe Testfälle verschieben.

Die Testergebnisse werden direkt in der Palette am Testfall symbolisiert. Zusätzlich können Sie an jedem Breakpoint einen ausführlichen Bericht über das Testergebnis anzeigen.

Voraussetzungen

Der Workflow wurde publiziert.

So gehen Sie vor

  1. Zeigen Sie den Technical Workflow an, dessen Testfälle Sie ausführen möchten.

  2. Öffnen Sie in der Sidebar die Palette Unit Tests.

  3. Markieren Sie einen oder mehrere Testfälle, öffnen Sie das Kontextmenü und wählen Sie Testfälle starten.
    Die Testfälle werden ausgeführt. Wie im Test-Modus zeigen Watch- und Testpunkte den Fortschritt der Durchführung an.

    Wenn die Tests beendet sind, werden die Ergebnisse in der Palette direkt im Testfall angezeigt, z.B.:

    workbench user guide 719 2

    • Grüne Markierung: Der Test war erfolgreich.

    • Rote Markierung: Der Test ist fehlgeschlagen.

Testergebnis anzeigen

So gehen Sie vor

  1. Markieren Sie den Breakpoint, zu dem Sie das Ergebnis anzeigen möchten.

  2. Öffnen Sie das Kontextmenü und wählen Sie Validierungsergebnis anzeigen.

Testfälle bearbeiten

Sie können jederzeit neue Breakpoints zu Ihrem Testfall hinzufügen, Breakpoints löschen oder den Startpoint verschieben, in dem Sie diesen an einer anderen Position erneut hinzufügen.

Wenn Sie die Testpoints eines Testfalls im Diagramm anzeigen und ändern, indem Sie z.B. einen Breakpoint löschen, dann wird der zugehörige Breakpoint im Testfall rot markiert. Dies signalisiert, dass die im Testfall definierten Testpoints nicht mehr identisch sind mit den Testpoints, die im Diagramm angezeigt werden.

In diesem Fall können Sie über das Kontextmenü des Testfalls folgende Funktionen nutzen:

  • Testpunkte von Diagramm übernehmen passt den Testfall an Ihre aktuellen Testpoints an

  • Testpunkte im Diagramm setzen ändert die Testpoints im Diagramm passend zum Testfall.

Testpoints hinzufügen

So gehen Sie vor

  1. Öffnen Sie das Diagramm, das zum Testfall gehört, zum Bearbeiten.

  2. Öffnen Sie in der Sidebar die Palette Unit Tests.

  3. Markieren Sie den Testfall.
    Die Testpoints werden im Diagramm eingeblendet.

  4. Fügen Sie einen neuen Startpoint oder neue Breakpoints zum Diagramm hinzu.

  5. Markieren Sie den Testfall in der Palette, öffnen Sie das Kontextmenü und wählen Sie Testpunkte von Diagramm übernehmen.
    Die neuen Testpoints werden unterhalb des Testfalls angezeigt.

  6. Publizieren Sie das Diagramm.

Testpoints löschen

So gehen Sie vor

  1. Öffnen Sie das Diagramm, das zum Testfall gehört, zum Bearbeiten.

  2. Öffnen Sie in der Sidebar die Palette Unit Tests.

  3. Klappen Sie den Testfall auf.

  4. Markieren Sie den Testpoint, öffnen Sie das Kontextmenü und wählen Sie Löschen.

  5. Bestätigen Sie den Rückfragedialog.
    Der Testpoint wird gelöscht.

Testfälle verschieben

Sie können die Reihenfolge der Testfälle in der Palette per Drag‘n‘Drop beliebig ändern.

Die Reihenfolge der Testfälle ist wichtig bei deren Ausführung: Wenn Sie mehrere Testfälle eines Diagramms gleichzeitig starten, dann werden diese in der Reihenfolge ausgeführt, in der sie in der Unit Tests-Palette angezeigt werden.

Testfälle exportieren

Zum Exportieren von Testfällen haben Sie folgende Möglichkeiten:

  • Einzelnes Diagramm, Diagrammgruppe oder alle Diagramme eines Benutzers inkl. der Testfälle exportieren, dabei die Option Unit Test exportieren markieren

  • Testfälle ohne zugehörige Diagramme aus dem Repository exportieren

  • Benutzergruppe, zu welcher die Diagramme mit den Testfällen gehören, inkl. der Repositorydateien exportieren

Siehe

Testsuiten anlegen

Überblick

Um Testfälle wiederverwendbar zu machen oder ihre Ausführung zu automatisieren, legen Sie eine so genannte Testsuite an und fügen Ihre Testfälle zu der Testsuite hinzu.

Eine Testsuite kann neben Testfällen auch weitere Testsuiten enthalten.

Testsuite im Repository mit Testfällen mehrerer Diagramme erstellen

Voraussetzungen

  • Die Testfälle sind bereits vorhanden.

  • Die Technical Workflows, zu denen die Testfälle gehören, sind publiziert worden.

So gehen Sie vor

  1. Zeigen Sie in der INUBIT Workbench das Register Repository an.

  2. Wählen Sie die Ansicht Unit Test Dateien.
    Siehe Benutzeroberfläche des Repositorys.

  3. Öffnen Sie das Verzeichnis, in dem die Testsuite gespeichert werden soll.

  4. Führen Sie eine der folgenden Aktionen aus:

    • Klicken Sie im Verzeichnis-Bereich auf workbench user guide 721 0.

    • Öffnen Sie das Kontextmenü des Bereichs und wählen Sie Testsuite hinzufügen.

    • Drücken Sie die Einf-Taste.
      Der Dialog zum Anlegen einer Testsuite öffnet sich.

  5. Benennen Sie die Testsuite und geben Sie eine Beschreibung und die Verantwortlichen an.

  6. Um einen Testfall oder eine weitere Testsuite hinzuzufügen, führen Sie eine der folgenden Aktionen aus:

    • Klicken Sie auf workbench user guide 721 0.

    • Öffnen Sie das Kontextmenü der Tabelle und wählen Sie Testsuite hinzufügen.
      Der Repository Explorer öffnet sich.

  7. Navigieren Sie zu dem Testfall oder der Testsuite, die Sie hinzufügen möchten, markieren Sie diese und schließen Sie den Dialog mit OK.
    Die ausgewählte Datei wird in der Tabelle angezeigt.

  8. Legen Sie mit den Pfeil-Buttons die Reihenfolge fest, in der die Testfälle ausgeführt werden sollen.
    Die Testfälle einer Testsuite werden in der Reihenfolge ausgeführt, in der sie in der Tabelle angezeigt werden.

  9. Schließen Sie den Dialog mit OK.
    Ein weiterer Dialog öffnet sich.

  10. Optional können Sie einen Versionierungskommentar eingeben.

  11. Schließen Sie den Dialog mit OK.
    Die neue Testsuite wird im Verzeichnis-Bereich angezeigt.

Testsuite im Repository mit Testfällen eines einzelnen Diagramms erstellen

Voraussetzungen

  • Die Testfälle sind bereits angelegt.

  • Der Technical Workflows zu dem die Testfälle gehören, ist bereits publiziert.

So gehen Sie vor

  1. Zeigen Sie in der INUBIT Workbench das Register Repository an.

  2. Wählen Sie die Ansicht Unit Test Dateien.
    Siehe Benutzeroberfläche des Repositorys.

  3. Öffnen Sie das Verzeichnis, in dem die Testfälle gespeichert sind.

  4. Markieren Sie alle Testfälle, die zu der Testsuite gehören sollen, und wählen Sie im Kontextmenü Zu Testsuite zusammenfassen.

    Der Befehl Zu Testsuite zusammenfassen ist deaktiviert, wenn Sie versehentlich Reports markiert haben. Entfernen Sie die Markierung von den Reports, um die Testsuite erstellen zu können.

    Der Dialog zum Anlegen einer Testsuite öffnet sich. In der Tabelle werden die ausgewählten Testfälle bereits angezeigt.

  5. Benennen Sie die Testsuite und geben Sie eine Beschreibung und die Verantwortlichen an.

  6. Um einen Testfall oder eine weitere Testsuite hinzuzufügen, führen Sie eine der folgenden Aktionen aus:

    • Klicken Sie auf workbench user guide 721 0.

    • Öffnen Sie das Kontextmenü der Tabelle und wählen Sie Testsuite hinzufügen.
      Der Repository Explorer öffnet sich.

  7. Navigieren Sie zu dem Testfall oder der Testsuite, die Sie hinzufügen möchten, markieren Sie diese und schließen Sie den Dialog mit OK.
    Die ausgewählte Datei wird in der Tabelle angezeigt.

  8. Legen Sie mit den Pfeil-Buttons die Reihenfolge fest, in der die Testfälle ausgeführt werden sollen. Die Testfälle einer Testsuite werden in der Reihenfolge ausgeführt, in der sie in der Tabelle angezeigt werden.

  9. Schließen Sie den Dialog mit OK.
    Ein weiterer Dialog öffnet sich.

  10. Optional können Sie einen Versionierungskommentar eingeben.

  11. Schließen Sie den Dialog mit OK.
    Die neue Testsuite wird in demselben Verzeichnis wie die Testfälle gespeichert.

Testsuite im Designer mit allen Testfällen eines Diagramms erstellen

Sie können alle Testfälle, die zu einem Technical Workflow gehören, auf einmal im Designer zu einer Testsuite zusammenstellen.

Voraussetzungen

  • Die Testfälle sind bereits angelegt.

  • Der Technical Workflow, zu dem die Testfälle gehören, ist bereits publiziert.

So gehen Sie vor

  1. Zeigen Sie das Diagramm, dessen Testfälle Sie zu einer Testsuite zusammenfassen wollen, im Server-Modus an.

  2. Markieren Sie das Diagramm und wählen Sie im Kontextmenü Testsuite erstellen.
    Der Dialog zum Anlegen einer Testsuite öffnet sich und enthält automatisch alle zum Diagramm gehörenden Testfälle.

  3. Übernehmen Sie den vorgeschlagenen Namen für die Testsuite oder geben Sie einen neuen an.

  4. Geben Sie eine Beschreibung und die Verantwortlichen ein.

  5. Legen Sie mit den Pfeil-Buttons die Reihenfolge fest, in der die Testfälle ausgeführt werden sollen.
    Die Testfälle einer Testsuite werden in der Reihenfolge ausgeführt, in der sie in der Tabelle angezeigt werden.

  6. Schließen Sie den Dialog mit OK. Ein weiterer Dialog öffnet sich.

  7. Geben Sie optional einen Kommentar für die neu anzulegende Version der Datei im Repository ein.

  8. Klicken Sie auf OK.
    Die neue Testsuite wird im Repository gespeichert.

Testsuite im Designer mit allen Testfällen einer Diagrammgruppe erstellen

Voraussetzungen

  • Die Testfälle sind bereits angelegt.

  • Die Technical Workflows, zu dem die Testfälle gehören, sind bereits publiziert.

Sie können alle Testfälle, die zu den Diagrammen einer Diagrammgruppe gehören, auf einmal im Designer zu einer Testsuite zusammenstellen.

So gehen Sie vor

  1. Zeigen Sie die Diagrammgruppe, deren Testfälle Sie zu einer Testsuite zusammenfassen wollen, im Server-Modus an.

  2. Markieren Sie die Diagrammgruppe und wählen Sie im Kontextmenü Testsuite erstellen.
    Der Dialog zum Anlegen einer Testsuite öffnet sich und enthält automatisch alle in der Diagrammgruppe vorhandenen Testfälle.

  3. Übernehmen Sie den vorgeschlagenen Namen für die Testsuite oder geben Sie einen neuen an.

  4. Geben Sie eine Beschreibung und die Verantwortlichen ein.

  5. Legen Sie mit den Pfeil-Buttons die Reihenfolge fest, in der die Testfälle ausgeführt werden sollen. Die Testfälle einer Testsuite werden in der Reihenfolge ausgeführt, in der sie in der Tabelle angezeigt werden.

  6. Schließen Sie den Dialog mit OK. Ein weiterer Dialog öffnet sich.

  7. Geben Sie einen Kommentar für die neu anzulegende Version der Datei im Repository ein.

  8. Klicken Sie auf OK.
    Die neue Testsuite wird im Repository gespeichert.

Testsuite manuell starten

So gehen Sie vor

  1. Zeigen Sie in der INUBIT Workbench das Register Repository an.

  2. Zeigen Sie die Ansicht Unit Test-Dateien an. Siehe Benutzeroberfläche des Repositorys.

  3. Öffnen Sie das Verzeichnis, in dem die Testsuite gespeichert ist.

  4. Markieren Sie die Testsuite und wählen Sie im Kontextmenü die Option Testsuite ausführen.
    Die Testsuite wird gestartet. Nachdem alle Testfälle durchgeführt wurden, wird ein Report mit den Testergebnissen erstellt und angezeigt. Nach dem Schließen des Reportdialogs wird der Report automatisch in demselben Verzeichnis wie die Testsuite gespeichert.

Ergebnis der Ausführung einer Testsuite anzeigen

Voraussetzungen

Die Testsuite wurde bereits ausgeführt.

So gehen Sie vor

  1. Zeigen Sie in der INUBIT Workbench das Register Repository an.

  2. Zeigen Sie die Ansicht Unit Test-Dateien an.
    Siehe Benutzeroberfläche des Repositorys.

  3. Öffnen Sie das Verzeichnis, in dem die Testsuite gespeichert ist.

  4. Markieren Sie den gewünschten Report.

  5. Zeigen Sie im Detailbereich das Register Detaildaten an.
    In einer detaillierten Baumansicht wird dargestellt, wie die letzte Ausführung der Testsuite verlaufen ist. Dieses Protokoll enthält keine Hinweise auf Fehler der Workflowausführung.

Testsuiten exportieren

Um Testsuiten zu exportieren, haben Sie folgende Möglichkeiten:

  • Testsuite ohne zugehörige Diagramme aus dem Repository exportieren

  • Benutzergruppe, zu welcher die Diagramme mit den Testsuiten gehören, inkl. der Repositorydateien exportieren

Siehe

Testfälle und Testsuiten automatisieren

Um einen Testfall oder eine Testsuite zeitgesteuert starten zu lassen, erstellen Sie einen Technical Workflow, der einen Workflow Starter enthält, und rufen den Testfall oder die Testsuite über das Utility INUBIT IS Configuration auf.

Sie können auch mehrere Testfälle oder Testsuiten ausführen lassen, indem Sie mehrere Operationen im XSLT Converter anlegen.

So gehen Sie vor

  1. Legen Sie einen Technical Workflow an.

  2. Fügen Sie einen Workflow Starter ein, um den Technical Workflow zeitgesteuert starten zu können.

  3. Fügen Sie einen XSLT Converter ein.

  4. Erstellen Sie mit dem XSLT Converter eine Eingangsnachricht für das INUBIT IS Configuration Utility, in der die Operation Execute_Unit_Test_Type aufgerufen wird.
    Siehe Eingangsnachricht zum Aufrufen der Operationen erstellen.

  5. Geben Sie bei dem Operationsaufruf die UID oder den Zugriffspfad des Unit Tests ein.
    Dazu gehen Sie so vor:

    1. Zeigen Sie das Register Repository mit der Ansicht Unit Test Dateien an.

    2. Navigieren Sie zu dem Unit Test, den Sie ausführen lassen möchten.

    3. Markieren Sie den Unit Test und zeigen Sie das Register Detaildaten an.

    4. Kopieren Sie die UID oder den Zugriffspfad des Unit Tests in die Zwischenablage, indem Sie auf workbench user guide 724 1.

  6. Fügen Sie ein INUBIT IS Configuration-Utility in den Technical Workflow ein.

  7. Verbinden Sie die Module.
    Das Ergebnis sieht so aus:

    workbench user guide 724 2

    Wenn der Workflow zu dem im Workflow Starter konfigurierten Zeiten zeitgesteuert wird, gibt das INUBIT IS Configuration-Utility Testergebnis als XML-Report aus.

    Sie können diesen Report z.B. in eine HTML-Datei konvertieren und per E-Mail versendet lassen.

Dialogbeschreibungen für Unit-Tests

Unit Tests Toolbar

workbench user guide 725 0

  • workbench user guide 725 1: Testfall anlegen
    Erstellt einen neuen Testfall.

  • workbench user guide 725 2: Bearbeiten
    Öffnet einen Dialog zum Bearbeiten eines markierten Testfalls.

    • Name: Name des Testfalls

    • Beschreibung: Beschreibender Kommentar

  • workbench user guide 725 3: Kopieren Speichert eine Kopie eines markierten Testfalls in der Zwischenablage.

  • workbench user guide 725 4: Einfügen
    Fügt den Testfall in die Baumstruktur ein. Der Testfall muss vorher durch Ausschneiden oder Kopieren in die Zwischenablage geladen worden sein.

  • workbench user guide 725 5: Nach oben verschieben
    Verschiebt den ausgewählten Testfall nach oben.

  • workbench user guide 725 6: Nach unten verschieben Verschiebt den ausgewählten Testfall nach unten.

  • workbench user guide 725 7: Löschen
    Zum Löschen des ausgewählten Testfalls.

  • workbench user guide 725 8: Suchen
    Öffnet ein Feld zum Eingeben eines Suchbegriffs.

Dialog Prüfbedingungen festlegen

workbench user guide 726 0

In diesem Dialog haben Sie folgende Optionen:

  • Keine Bedingungen definieren und diesen Breakpoint immer als Erfolg werten
    Wenn aktiviert, werden alle weiteren Optionen im Dialog deaktiviert und der Breakpoint wird immer als Erfolg gewertet, unabhängig davon, ob der Breakpoint erreicht wurde oder nicht.

Vergleichen

Um den Inhalt einer Nachricht bzw. einer Variablen mit einer Repositorydatei zu vergleichen. Diese Validierung wird standardmäßig gewählt, wenn ein neuer Testfall angelegt wird und Daten am Breakpoint vorhanden sind.

  • Validierung hinzufügen (Button)
    Blendet weitere Bedienfelder zum Festlegen von Validierungsregeln ein.

    • Operator für Verknüpfungen: Zum Verknüpfen von mehreren Bedingungen.

      • AND: Alle Bedingungen müssen zutreffen.

      • OR: Eine der Bedingungen muss zutreffen.

    • Button D:
      Die Bedingung bezieht sich auf die Struktur der XML-basierten Nachricht, die beim Testen den Breakpoint erreicht, oder auf Werte in dieser Nachricht. In das Eingabefeld kann ein XPath-Ausdruck eingegeben werden. In diesem Fall wird die Validierung auf der angegebenen Teilmenge ausgeführt.
      Keine Eingabe und die Eingabe von / sind identisch und wählen die gesamte Datenmenge aus.

    • Button V: Die Bedingung bezieht sich auf eine Variable. Alle vorhandenen Variablen werden in der nebenstehenden Liste angezeigt.

    • Operator
      Zur Auswahl eines Operators für den Vergleich. Es gibt folgende Operatoren:

      Operator Bedeutung

      =

      Gleich

      !=

      Ungleich

    • Eingabefeld und workbench user guide 727 0 Button (Datei aus dem Repository wählen)
      Zum Auswählen einer Datei aus dem Repository, mit der die angegebene XML-Struktur oder der Wert der ausgewählten Variable verglichen werden soll. Wenn es um den Vergleich eines Variablenwertes geht, müssen Sie eine Watchpoint-Datei auswählen.
      Nach der Ausführung eines Tests wird im Eingabefeld eine Referenz auf Testdaten aus dem Breakpoint angezeigt.

    • workbench user guide 727 1 Button (Inhalt anzeigen)
      Öffnet einen Dialog und zeigt die Datei an, die im nebenstehenden Eingabefeld referenziert ist.

    • workbench user guide 727 2 Button (Ins Repository speichern…)
      Speichert die im Eingabefeld referenzierte Datei in das Repository. Wenn Sie die Daten nicht manuell speichern, werden diese beim Publizieren automatisch ins Repository gespeichert.

    • workbench user guide 727 3 Button (Entfernen)
      Löscht die nebenstehende Bedingung.

Bedingung

Zum Validieren des Ergebnisses über eine oder mehrere Bedingungen. Wenn die Validierung fehlerfrei verlief, wird ein OK in den Ergebnis-Report geschrieben, bei einem Fehler enthält der Report die fehlgeschlagene Bedingung.

Siehe Reguläre Ausdrücke.

  • Bedingung hinzufügen (Button)
    Blendet die folgenden Bedienfelder zum Festlegen von Bedingungen ein:

    workbench user guide 727 4

  • Operator für Verknüpfungen: Zum Verknüpfen von mehreren Bedingungen.*

  • AND: Alle Bedingungen müssen zutreffen.

  • OR: Eine der Bedingungen muss zutreffen.

    • Button D: Die Bedingung bezieht sich auf ein Element in der XML-basierten Nachricht. Im Eingabefeld muss ein XPath-Ausdruck eingegeben werden. Falls eine Beispiel-XML-Datei vorliegt, klicken Sie auf den workbench user guide 727 0-Button und wählen das Element aus.

    • Button V: Die Bedingung bezieht sich auf eine Variable. Alle vorhandenen Variablen werden in der nebenstehenden Liste angezeigt.

    • Button X: Die Bedingung bezieht sich auf einen XPath-Ausdruck. Der XPath wird auf einem leeren Dokument ausgeführt (nicht auf dem Datenstrom). Der workbench user guide 727 0-Button öffnet einen Assistenten zum Anlegen des XPath-Ausdrucks.

    • Operator
      Zur Auswahl eines Operators für den Werteabgleich. Es gibt folgende Operatoren:

      Operator Bedeutung

      =

      Gleich

      <

      Kleiner als

      >

      Größer als

      >=

      Größer gleich

      <=

      Kleiner gleich

      !=

      Ungleich

      Exists

      Existiert

      NotExists

      Existiert nicht

      XPath

      XPath-Ausdruck

    • Buttons D und V: Siehe oben.

    • Button S: Die Bedingung bezieht sich auf die eingegebene Zeichenkette.

      Beispiele:

    • /AUFTRAG/AUFTRAGSSUMME > 1000

    • /AUFTRAG/LIEFERUNG/ = Express

    • /IBISProfile/Profile/Name Exists

      Wenn der Knoten Name in der Eingangsnachricht vorhanden ist, dann wird in diesen Ausgang verzweigt.

    • count(/Order/test1) > 1

      Wenn die Auswertung der XPath-Funktion count() ergibt, dass der Knoten /Order/test1 mehr als einmal existiert, dann wird in diesen Ausgang verzweigt.

Schema-Validierung

Um den Inhalt einer XML-Nachricht bzw. einer XML-Variablen gegen eine XML-Schemadatei zu validieren. Zur Validierung wird eine im Repository hinterlegte Schemadatei ausgewählt.

  • Validierung hinzufügen (Button)
    Blendet weitere Bedienfelder zum Festlegen von Validierungsregeln ein.

  • Operator für Verknüpfungen: Zum Verknüpfen von mehreren Bedingungen.

    • AND: Alle Bedingungen müssen zutreffen.

    • OR: Eine der Bedingungen muss zutreffen.

  • Button D: Siehe oben.

  • Button V: Siehe oben.

  • Bedingung
    Zur Auswahl einer Bedingung für die Schemaprüfung. Es gibt folgende Bedingungen:

    Bedingung Bedeutung

    validTo

    Entspricht der Schema-Datei

    notValidTo

    Entspricht nicht der Schema-Datei

  • Datei aus dem Repository wählen
    Zum Auswählen einer Datei aus dem Repository, mit der die Breakpoint-Daten aus dem Testfall verglichen werden soll. Bei einem initialen Testfall können hier auch lokale Daten aus dem Breakpoint liegen. Diese können explizit mit dem workbench user guide 728 0-Button ins Repository gespeichert werden. Ansonsten werden die Daten beim Publizieren automatisch ins Repository gespeichert.

XSLT

Validiert das Testergebnis über ein XSLT-Stylesheet. Sie können ein beliebiges Mapping definieren, das Ergebnis wird vollständig in den Ergebnis-Report übernommen.
Wenn das Testergebnis am Testfall visualisiert werden soll, müssen Sie sicherstellen, dass Ihr Mapping ein success- oder error-Element (abhängig vom Ergebnis) auf der root-Ebene oder auf der ersten Ebene unterhalb von root generiert.

  • Validierung hinzufügen (Button)
    Blendet weitere folgenden Bedienfelder zum Festlegen von Validierungsregeln ein.

    • Operator für Verknüpfungen: Zum Verknüpfen von mehreren Bedingungen.

      • AND: Alle Bedingungen müssen zutreffen.

      • OR: Eine der Bedingungen muss zutreffen.

    • Button D: Siehe oben.

    • Button V: Siehe oben.

    • XSLT-Skript
      Zur Auswahl und zum Bearbeiten eines XSLT Stylesheet zur Validierung des Testergebnisses.

      Zur Vereinfachung der Validierung können Sie die an JUnit angelehnten assert-Funktionen nutzen. Für Informationen über deren Einsatz öffnen Sie mit dem Button Bearbeiten das Template.

  • Falls Breakpoint nicht erreicht wird, als Erfolg werten
    Standardmäßig ist die Option nicht markiert, um sicherzustellen, dass die Validierung als fehlerhaft gewertet wird, wenn die Breakpoint-Daten fehlen.

    • Option nicht markiert:
      Falls ein Breakpoint beim Durchlaufen eines Workflows nicht erreicht wird, dann scheitert der Testfall an dem entsprechenden Breakpoint. Ein Fehler wird geworfen.

    • Option markiert:
      Der Test wird als erfolgreich gewertet, obwohl die Breakpoint-Daten fehlen.

Dialog Watchpoint

workbench user guide 730 0

Der Watchpoint-Dialog besteht aus folgenden Bereichen:

  1. Toolbar

    • workbench user guide 730 1 Watchpointdatei speichern…​

      Zum Speichern der Nachricht in das Dateisystem.

    • workbench user guide 730 2 Watchpointdatei ins Repository speichern

      Erzeugt eine *.wpf-Datei und speichert diese in das Repository.

      Siehe Test Modus: Testen von Diagrammen.

    • workbench user guide 730 3 In Zwischenablage kopieren

      Speichert die Nachricht mit allen Workflow-Variablen in die Zwischenablage.

      Sie können diese Funktion z.B. nutzen, um im XSLT Converter Variablen anzulegen oder einen Workflow zu starten.

  2. Nachrichten

    Die Nachrichten werden entsprechend ihrem Format dargestellt. Standardmäßig werden hier XML-Dateien als Baumstruktur angezeigt.

  3. Variablen

    Liste aller Workflow-Variablen mit den aktuellen Werten.

Press Esc to exit full screen
Modal image placeholder
Press Esc to exit full screen