Builder Handbuch - Version 6.0.1 - download-visual

Builder Handbuch - Version 6.0.1 - download-visual
Visual Rules Suite - Builder
Builder Handbuch
Version 6.0.1
Bosch Software Innovations
Americas:
Bosch Software Innovations Corp.
161 N. Clark Street
Suite 3500
Chicago, Illinois 60601/USA
Tel. +1 312 368-2500
[email protected]
www.bosch-si.com
Asia:
Bosch Software Innovations
c/o Robert Bosch (SEA) Pte Ltd
11 Bishan Street 21
Singapore 573943
Tel. +65 6571 2220
[email protected]
www.bosch-si.com
Europe:
Bosch Software Innovations GmbH
Ziegelei 7
88090 Immenstaad/GERMANY
Tel. +49 7545 202-300
[email protected]
www.bosch-si.de
Builder Handbuch: Version 6.0.1
Visual Rules Builder Handbuch, Version 6.0.1
Copyright © 2004-2012 Bosch Software Innovations GmbH
© Bosch Software Innovations GmbH, 2012. Alle Rechte vorbehalten. Weitergabe und Vervielfältigung dieser Publikation oder
von Teilen daraus sind, zu welchem Zweck und in welcher Form auch immer, ohne die ausdrückliche schriftliche Genehmigung
durch die Bosch Software Innovations GmbH nicht gestattet. MLDS, Visual Rules und Work Frame Relations sind eingetragene
Marken der Bosch Software Innovations GmbH. BOSCH und die Bildmarke sind registrierte Marken der Robert Bosch
GmbH, Deutschland. Verwendete Produkt- und Firmenbezeichnungen sind eingetragene Marken und - unabhängig von ihrer
Kennzeichnung - Eigentum ihrer jeweiligen Inhaber.
Builder Handbuch
Inhaltsverzeichnis
1. Einführung ................................................................................................................................. 1
1.1. Konfiguration der Lizenz ............................................................................................................. 1
1.2. Inhalte der Distribution ............................................................................................................... 1
2. Einsatz von Maven ...................................................................................................................... 3
2.1. Überblick ................................................................................................................................. 3
2.2. Installation der Visual Rules Maven Plugins ................................................................................... 3
2.3. Konfiguration der Lizenzdatei ...................................................................................................... 4
2.4. Bauen des mitgelieferten Maven Beispielprojekts ............................................................................ 4
2.5. Bereitstellung von Regelartefakten für die Benutzung im Visual Rules Modeler ...................................... 5
2.6. Projekt Struktur ......................................................................................................................... 5
2.7. Validierung von Regelmodellen .................................................................................................... 6
2.8. Testen von Regelmodellen ......................................................................................................... 7
2.9. Generierung einer Dokumentation der Testergebnisse ...................................................................... 8
2.10. Generierung von Java Quellcode ............................................................................................... 9
2.11. Generierung der Web Service Schnittstelle ................................................................................. 10
2.12. Generierung der Manifest Datei ................................................................................................ 11
2.13. Einstellen von Dateien und Verzeichnissen in einen Visual Rules Team Server .................................. 13
2.14. Anlegen und Bestücken einer Verzweigung im Visual Rules Team Server ......................................... 14
2.15. Bereitstellung auf dem Visual Rules Execution Server ................................................................... 16
2.16. Erstellen von Visual Rules Archive (VRA) Dateien ........................................................................ 18
3. Einsatz von Ant ......................................................................................................................... 19
3.1. Überblick ............................................................................................................................... 19
3.2. Ausführen des mitgelieferten Beispiels eines Ant Buildskripts ........................................................... 19
3.3. Konfiguration der Ant-Tasks ...................................................................................................... 21
3.4. Generieren von Java-Regelcode ................................................................................................ 21
3.5. Kompilieren des Java-Regelcodes .............................................................................................. 22
3.6. Ausführen von Regeltests ......................................................................................................... 23
3.7. Abholen von Regelprojekten aus einem Visual Rules Team Server ................................................... 25
3.8. Einstellen von Dateien und Verzeichnissen in einen Visual Rules Team Server .................................... 25
3.9. Anlegen und Bestücken einer Verzweigung im Visual Rules Team Server .......................................... 26
3.10. Ein Regelartefakt auf einem Visual Rules Execution Server bereitstellen ........................................... 27
3.11. Bereitstellung einer Visual Rules Archive (VRA) Datei auf einem Visual Rules Execution Server ............. 29
© Bosch Software Innovations
iii/30
Kapitel 1. Einführung
Kapitel 1. Einführung
Mit Hilfe der Builder Komponenten können die Prozesse zur Änderung, zum Test und zur Freigabe von Regeln
automatisiert werden. Die Automatisierung erfolgt entweder mittels Ant oder mit Maven, zwei populären
Werkzeugen zur Automatisierung von Build-Prozessen.
Es stehen Maven-Plugins für folgende Aufgaben zur Verfügung:
• Validierung von Regelmodellen
• Testen von Regeln
• Generierung einer Dokumentation der Testergebnisse
• Generierung von Java-Code aus Regelmodellen
• Generierung einer Web Service Schnittstelle
• Generierung von Manifest Dateien
• Einstellen von Dateien und Arbeiten mit Verzweigungen im Visual Rules Team Server
• Bereitstellen von Regelartefakten auf einem Visual Rules Execution Server
• Erstellen von Visual Rules Archive (VRA) Dateien
Weitere Information zu Maven und dessen Verwendung sind im Internet unter http://maven.apache.org/ verfügbar.
Die Builder Distribution enthält Ant-Tasks für folgende Aufgaben:
• Generierung von Java-Code aus Regelmodellen (inkl. Validierung, WSDL und Manifest)
• Testen von Regeln
• Einstellen von Regelprojekten in einem Visual Rules Team Server
• Abholen von Regelprojekten von einem Visual Rules Team Server
• Erstellen einer Verzweigung im Visual Rules Team Server
• Bereitstellung von Regelartefakten auf einem Visual Rules Execution Server
• Bereitstellung eines Visual Rules Archive (VRA) auf einem Visual Rules Execution Server
Weitere Informationen zu Ant und dessen Verwendung sind im Internet unter http://ant.apache.org verfügbar.
1.1. Konfiguration der Lizenz
Die Builder Komponenten benötigen eine gültige Lizenz. Wenn sich die Lizenzdatei im Standardverzeichnis
befindet, welches .visualrules6 im Benutzerverzeichnis des angemeldeten Benutzers ist, ist eine weitere
Konfiguration nicht notwendig. Ansonsten muss für jeden Task und jedes Plugin angegeben werden, von wo
die Lizenzdatei gelesen werden soll. Details finden sie in den Referenz Kapiteln der Ant Tasks sowie der Maven
Plugins.
1.2. Inhalte der Distribution
Die Visual Rules Builder Distribution wird als ZIP-Datei bereitgestellt mit dem folgenden Inhalt:
© Bosch Software Innovations
1/30
Kapitel 1. Einführung
Tabelle 1.1. Inhalte der Distribution
Verzeichnis
Inhalte
doc
Handbuch (Deutsch und Englisch)
examples
Beispiele
Anwendung
Abschnitt 3.2, „Ausführen des
mitgelieferten Beispiels eines Ant
Buildskripts“
Abschnitt 2.4, „Bauen
des mitgelieferten Maven
Beispielprojekts“
licenses
Lizenzbedingungen,
Liste benutzter 3rd Party Software
visualrules-ant-tasks
Ant-Tasks und deren
Abhängigkeiten
Kapitel 3, Einsatz von Ant
Abschnitt 3.3, „Konfiguration der
Ant-Tasks“
visualrules-maven-plugins
visualrules-runtime
Maven-Plugins, deren
Abhängigkeiten und Skript zur
Installation
Kapitel 2, Einsatz von Maven
Visual Rules Laufzeitbibliotheken
wie aufgeführt in
Abschnitt 3.5, „Kompilieren des
Java-Regelcodes“
Tabelle 3.7, „Visual Rules
Laufzeitbibliothek Abhängigkeiten“
Abschnitt 3.6, „Ausführen von
Regeltests“
und
Abschnitt 3.10, „Ein Regelartefakt
auf einem Visual Rules Execution
Server bereitstellen“
Tabelle 3.8, „Visual Rules
DatabaseIntegrator
Laufzeitbibliothek Abhängigkeiten“
© Bosch Software Innovations
Abschnitt 2.2, „Installation der Visual
Rules Maven Plugins“
2/30
Kapitel 2. Einsatz von Maven
Kapitel 2. Einsatz von Maven
2.1. Überblick
Die Visual Rules Builder Distribution bieten verschiedene Maven Plugins für die grundlegenden Funktionalitäten in
Visual Rules:
• visualrules-validation-maven-plugin für die Validierung von Regelmodellen
• visualrules-testing-maven-plugin zum Testen von Regeln
• visualrules-testdocgenerator-maven-plugin für die Generierung einer Dokumentation der
Testergebnisse
• visualrules-javagenerator-maven-plugin für die Generierung von Java Quellcode
• visualrules-wsdlgenerator-maven-plugin für die Generierung von WSDL und XML Schema Dateien
• visualrules-manifestgenerator-maven-plugin für das Erzeugen von Meta Informationen für ein
Regelartefakt
• visualrules-team-maven-plugin für das Einstellen von Dateien und Arbeiten mit Verzweigungen im
Visual Rules Team Server
• visualrules-deploy-maven-plugin um ein Regelartefakt auf dem Visual Rules Execution Server
bereitzustellen
• visualrules-archive-maven-plugin um eine Visual Rules Archive (VRA) Datei zu erstellen
In den folgenden Abschnitten wird davon ausgegangen, dass Maven bereits installiert und
konfiguriert ist. Dokumentation und die Möglichkeiten Maven herunterzuladen sind auf der Webseite
http://maven.apache.org verfügbar.
Eclipse bietet von Haus aus keine eingebaute Unterstützung für Maven. Da der Visual Rules
Modeler auf der Eclipse Platform aufsetzt, bietet dieser somit auch keine direkte Maven
Unterstüzung. Das M2 Eclipse Project bietet eine Integration von Maven für Eclipse.
2.2. Installation der Visual Rules Maven Plugins
Die Visual Rules Maven Plugins müssen in einem Maven-Repository verfügbar sein. Für diesen Zweck enthält die
Builder Distribution ein Skript um die Plugins in einem Repository bereitzustellen. Das Skript ist deploy.cmd für
Windows basierende Systeme und deploy.sh für Unix basierende Systeme.
Die Bereitstellung und Nutzung der Visual Rules Maven Plugins darf nur unter Berücksichtigung der
lizenztechnisch geregelten Nutzungsrechte erfolgen.
Das Skript wird die Plugins und deren Abhängigkeiten in ein Maven-Repository bereitstellen. Dafür muss das
Repository erlauben, dass Artefakte im release Modus hochgeladen werden können und sowohl normale
Artefakte als auch Plugins verwalten. Beispielsweise eignet sich dafür eine Installation von Apache Archiva.
Detaillierte Beschreibungen zur Installation und Konfiguration von Apache Archiva können im
Internet auf http://archiva.apache.org/ gefunden werden.
Das Maven-Repository sollte zur Maven Konfiguration hinzugefügt werden und zwar sowohl als normales als auch
als Plugin Repository. Zusätzlich sind die Angabe des Benutzernamens und des Passworts erforderlich. In der
Maven Dokumentation sind genauere Informationen zu diesem Thema vorhanden.
Ehe das Skript ausgeführt werden kann, müssen noch einige notwendige Informationen eingetragen werden. Die
ersten fünf Zeilen des Skripts sind Variablen Definitionen. Hier werden die Informationen des benutzten Maven-
© Bosch Software Innovations
3/30
Kapitel 2. Einsatz von Maven
Repositories eingetragen. Im folgenden Beispiel ist dies exemplarisch für das Skript unter Windows gemacht. Es
wird davon ausgegangen, dass ein Apache Archiva in der Standardkonfiguration benutzt wird, der auf dem lokalen
Rechner (localhost) läuft, auf dem Port 9090 lauscht und releaseRepositoryID die ID des Repositories ist, wie
sie in der settings.xml von Maven eingestellt ist.
set
set
set
set
set
REPOSITORY_ID=releaseRepositoryID
REPOSITORY_LAYOUT=default
URL=http://localhost:9090/archiva/repository/releases/
UNIQUE_VERSION=false
GOAL=deploy:deploy-file
Tabelle 2.1. Variablen des Installationsskripts
Variable
Beschreibung
REPOSITORY_ID
Die id des Maven-Repositories, wie auch in der Maven Konfiguration eingestellt.
REPOSITORY_LAYOUT
Die verwendete Verzeichnisstruktur des Maven-Repositories. Mögliche Werte sind:
default oder legacy (dies hängt vom eingesetzten Repository ab).
URL
URL des Maven-Repositories, in welches das Artefakt hochgeladen wird.
UNIQUE_VERSION
Ob snapshots mit einer eindeutigen Version hochgeladen werden.
GOAL
Setzt man GOAL auf den Wert install:install-file, so werden die
Maven Plugins ins lokale Maven Repository installiert. Der Standardwert ist
deploy:deploy-file, was eine Installation in das oben per URL angegebene
Repository bewirkt.
2.3. Konfiguration der Lizenzdatei
Sofern sich die Lizenzdatei nicht im Standardverzeichnis befindet, wie in Abschnitt 1.1, „Konfiguration der Lizenz“
beschrieben, ist es notwendig den Pfad der Lizenzdatei bei jedem Plugin zu konfigurieren. Dadurch wird jedoch
der Build-Prozess von der eingesetzten Rechnerplattform abhängig.
Maven unterstützt das Konzept sogenannter Profile, welche eingesetzt werden können, um mit
einem von einer Plattform abhängigen Build-Prozess umzugehen. In der Maven Dokumentation ist
dies ausführlich beschrieben.
2.4. Bauen des mitgelieferten Maven Beispielprojekts
Um das mitgelieferte Beispielprojekt zu importieren, wählen Sie in der Menüleiste Datei -> Neu -> Beispiel... aus.
In der Visual Rules Kategorie wählen Sie dann Visual Rules Example Project und klicken auf Weiter >. Wählen Sie
das Beispiel Movie Ticket Pricing Maven und klicken auf Fertigstellen.
Die in diesem Beispiel benutzten Maven Plugins müssen in einem Maven-Repository wie
beispielsweise Apache Archiva verfügbar sein. Zum Ausprobieren reicht es bereits, wenn dies
auf dem lokalen Rechner läuft. Die Builder Distribution enthält ein Skript um die Visual Rules
Maven Plugins in einem Maven-Repository bereitzustellen. Dies ist ausführlicher in Abschnitt 2.2,
„Installation der Visual Rules Maven Plugins“ beschrieben.
Die folgenden Beispiele benutzen Maven auf der Kommandozeile. Dafür wird eine Eingabeaufforderung benötigt.
Dies ist spezifisch für das eingesetzte Betriebssytem und wird hier nicht erläutert.
Öffnen Sie eine Eingabeaufforderung und navigieren Sie zu Ihrem Arbeitsbereich. Wechseln Sie in das
Verzeichnis Movie Ticket Pricing Maven und geben Sie mvn package in der Kommandozeile ein.
Maven startet daraufhin den Build-Prozess, der die Visual Rules Maven Plugins benutzt für die Validierung des
Regelmodells und der Generierung von Java Quellcode, WSDL, XML Schema Dateien sowie Meta Informationen.
Das Ergebnis des Prozesses ist eine Jar Datei, die als Regelartefakt im Visual Rules Modeler und auf dem
Execution Server eingesetzt werden kann.
Zusätzlich wird auch eine Visual Rules Archive (VRA) Datei erstellt. Diese enthält neben dem Regelartefakt auch
alle benötigten Abhängigkeiten. Für weitere Informationen siehe Abschnitt 2.16, „Erstellen von Visual Rules
© Bosch Software Innovations
4/30
Kapitel 2. Einsatz von Maven
Archive (VRA) Dateien“ und Abschnitt 3.11, „Bereitstellung einer Visual Rules Archive (VRA) Datei auf einem
Visual Rules Execution Server“.
Die Datei pom.xml im Beispielprojekt ist so konfiguriert, dass sie das gebaute Regelartefakt auf einer
Standardinstallation eines Visual Rules Execution Server bereitstellen kann. Bevor fortgefahren wird, sollte
sichergestellt sein, dass der Server betriebsbereit ist. Das Visual Rules Maven Deploy Plugin wird mit der
install Phase des Builds ausgeführt. Durch Eingabe von mvn install in der Kommandozeile, started der
Build-Prozess erneut und installiert das Regelartefakt in das lokale Maven-Repository und stellt es auf dem Visual
Rules Execution Server bereit.
2.5. Bereitstellung von Regelartefakten für die Benutzung im Visual Rules Modeler
Maven verwaltet Artefakte in Repositories. Die grundlegende Idee ist, dass ein Build-Prozesses ein Artefakt
produziert, welches in einem Maven-Repository bereitgestellt wird und somit für andere Benutzer zum
Herunterladen verfügbar ist. Das Artefakt, welches durch das Beispiel erstellt wird, eignet sich genauso dafür
und ist darüber hinaus als Abhängigkeit im Visual Rules Modeler einsetzbar. Für diesen Zweck muss das
Regelartefakt in einem Maven-Repository bereitgestellt werden, wozu der mvn deploy Befehl dient. Damit dies
möglich ist, muss der Abschnitt distributionManagement in der pom.xml des Projekts hinzugefügt werden.
Darin werden die Maven-Repositories definiert, in denen ein Artefakt bereitgestellt werden kann. Diese sollten
auch im Visual Rules Modeler eingestellt sein, um die Artefakte herunterladen zu können.
Der nachfolgende Ausschnitt zeigt, wie dies für eine Standardinstallation des Apache Archivas aussehen kann. Es
sind zwei Maven-Repositories definiert: eines für snapshots und eines für releases. Das ist ein Konzept von
Maven, welches auf http://maven.apache.org eingehender erläutert wird.
<project ...>
...
<distributionManagement>
<snapshotRepository>
<id>snapshotRepositoryID</id>
<uniqueVersion>false</uniqueVersion>
<url>dav:http://localhost:8080/archiva/repository/snapshots/</url>
</snapshotRepository>
<repository>
<id>releaseRepositoryID</id>
<url>dav:http://localhost:8080/archiva/repository/releases/</url>
</repository>
</distributionManagement>
...
</project>
2.6. Projekt Struktur
Das Movie Ticket Pricing Maven Beispiel ist anders aufgebaut als normale Projekte in Eclipse. Das
Regelmodel und seine Dateien befinden sich im Quellordner src/main/rules. Dadurch das sie dort liegen,
werden sie in das Artefakt mit eingepackt. Damit Namenskonflikte mit dem kompilierten Bytecode vermieden
werden ist es ratsam, die Dateien im Artefakt an eine andere Stelle zu verschieben. Um das zu erreichen, enthält
die pom.xml folgende Konfiguration:
<project ...>
...
<build>
<resources>
<resource>
<targetPath>META-INF/visualrules/models</targetPath>
<directory>src/main/rules</directory>
</resource>
</resources>
...
</build>
...
</project>
Nach einem mvn package Befehl befinden sich die Dateien des Modells im Verzeichnis META-INF/
visualrules/models innerhalb der Jar Datei.
© Bosch Software Innovations
5/30
Kapitel 2. Einsatz von Maven
Es wird ausdrücklich empfohlen die Dateien des Modells nicht direkt in den Ordner src/
main/rules oder src/main/resources zu legen, ohne eine entsprechende Konfiguration
vorzunehmen. In diesem Fall ist es wahrscheinlich, dass der Name der Ordner und die Pakete des
generierten Java Quellcodes einen Konflikt in Bezug auf Groß- und Kleinschreibung haben, was zu
einem unbenutzbaren Regelartefakt führt.
Eine weitere Anmerkung gilt dem target Ordner, in dem Maven alle erzeugten Dateien und kompilierten
Bytecode legt. Im Beispiel ist der Codegenerator so konfiguriert, dass target/generated-sources/
visualrules als Zielverzeichnis benutzt wird. Das ist ein Quellordner und kann somit innerhalb Eclipse und von
einem Maven Build verwendet werden.
Nach einem erfolgreich ausgeführtem mvn package Befehl findet sich das erstellte Regelartefakt ebenfalls im
target Verzeichnis.
2.7. Validierung von Regelmodellen
Das Visual Rules Maven Validation Plugin wendet alle Validierungsregeln auf alle Regelmodell im Projekt an. Ein
gefundener Fehler löst einen Abbruch des Build-Prozesses aus.
Die Aufgabe des visualrules-validation-maven-plugin ist es Regelmodelle zu validieren, bevor diese
von anderen Plugins als Eingabe verarbeitet werden. Es ist beabsichtigt, dass dies in der validate Phase
ausgeführt werden sollte.
<build>
...
<plugins>
...
<plugin>
<groupId>de.visualrules.builder</groupId>
<artifactId>visualrules-validation-maven-plugin</artifactId>
<version>${vrBuilderVersion}</version>
<executions>
<execution>
<configuration>
<!-- optional -->
<licensefile>C:\mycompany\mylicense.txt</licensefile>
<!-- optional -->
<verbose>false</verbose>
</configuration>
<goals>
<goal>validate</goal>
</goals>
</execution>
</executions>
</plugin>
...
</plugins>
...
</build>
Beispiel 2.1. Beispiel für das visualrules-validation-maven-plugin
Tabelle 2.2. Parameter für das visualrules-validation-maven-plugin
Parameter
Beschreibung
Erforderlich
Typ
verbose
Falls true werden alle Warnungen und
Fehlermeldungen auf der Konsole ausgegeben.
Ansonsten nur die erste Fehlermeldung.
Nein (default:
false)
Wahrheitswert
licensefile
Der Dateipfad zu einer gültigen Lizenzdatei.
Das ist erforderlich, wenn sich keine Lizenz im
Standardverzeichnis befindet.
Nein
Datei
writeXmlReport
Falls true werden alle Validierungsmeldungen in
eine XML Datei geschrieben. Diese findet sich im
sogenannten "reporting" Verzeichnis, beispielsweise
target/site/visual-rules-reports
Nein (default:
false)
Wahrheitswert
© Bosch Software Innovations
6/30
Kapitel 2. Einsatz von Maven
2.8. Testen von Regelmodellen
Das visualrules-testing-maven-plugin Maven Plugin wird zur Ausführung von Visual Rules Tests im
Buildprozess verwendet. Per default wird jeder Test innerhalb des Projektes ausgeführt. Scheitert einer der
Tests, so wird das Ergebniss des Buildprozesses als fehlerhaft erachtet und somit wird der Build abgebrochen.
Das Plugin kann auch konfiguriert werden, um Testsuites auszuführen. In diesem Betriebsmodus, werden alle
Testsuites die durch ein Pattern bestimmt sind, ausgeführt. Das Verhalten beim Scheitern einer Testsuite ist die
gleiche wie oben erwähnt. Es ist nicht möglich, sowohl Tests als auch Testsuites gleichzeitig auszuführen.
Die Ergebnisse eines Tests werden im Normalfall auf der Konsole ausgegeben und in eine XML Datei
geschrieben. Es ist ebenfalls möglich einen noch detaillierten Report zu erzeugen, der ebenfalls die Statistiken
enthält. Dieser Report kann dann im Visual Rules Modeler betrachtet werden. Alle erzeugten Dateien finden
sich im sogenannten "reporting" Verzeichnis, beispielsweise target/site/visual-rules-reports.
Die Erstellung einer zusammenfassenden HTML-Dokumentation wird in Abschnitt 2.9, „Generierung einer
Dokumentation der Testergebnisse“ beschrieben.
Zu guter Letzt, gibt es noch die Möglichkeit, die Ausführung aller Tests zu konfigurieren. Es lässt sich eine globale
Konfiguration und die Detailstufe der Statistiken für sowohl Request und Session einstellen. Zu beachten ist, dass
damit die Einstellungen in jedem einzelnen Test oder Testsuite ausgehebelt werden.
<build>
...
<plugins>
...
<plugin>
<groupId>de.visualrules.builder</groupId>
<artifactId>visualrules-testing-maven-plugin</artifactId>
<version>${vrBuilderVersion}</version>
<executions>
<execution>
<configuration>
<!-- optional -->
<licensefile>C:\mycompany\mylicense.txt</licensefile>
<!-- optional -->
<testSuitePattern>All Tests</testSuitePattern>
<!-- optional -->
<writeTestReportArchive>true</writeTestReportArchive>
<!-- optional -->
<writeXmlReport>true</writeXmlReport>
<!-- optional -->
<activeConfigurationName>production</activeConfigurationName>
<!-- optional -->
<requestStatisticsLevel>medium</requestStatisticsLevel>
<!-- optional -->
<sessionStatisticsLevel>medium</sessionStatisticsLevel>
<!-- optional -->
<verbose>false</verbose>
</configuration>
<goals>
<goal>test</goal>
</goals>
</execution>
</executions>
</plugin>
...
</plugins>
...
</build>
Beispiel 2.2. Beispiel für das visualrules-testing-maven-plugin
© Bosch Software Innovations
7/30
Kapitel 2. Einsatz von Maven
Tabelle 2.3. Parameter für das visualrules-testing-maven-plugin
Parameter
Description
Required
Type
verbose
Falls true werden Informationen zu jedem
ausgeführten Test auf der Konsole ausgegeben.
Nein (default:
false)
Wahrheitswert
licensefile
Der Dateipfad zu einer gültigen Lizenzdatei.
Das ist erforderlich, wenn sich keine Lizenz im
Standardverzeichnis befindet.
Nein
Datei
testSuitePattern
Das Pattern für die Testsuite. Das ist typischerweise ein
Dateiname, wobei Platzhalter enthalten sein können.
Es kann ? verwendet werden um genau ein beliebiges
Zeichen auszudrücken und * für beliebige Zeichen. Das
Pattern All* würde beispielsweise All Tests als
auch All Nightly Tests finden.
Nein
Zeichenkette
writeTestReport
Archive
Falls true wird eine Archiv Datei erzeugt, die neben
den Testergebnissen auch die Statistiken enthält und im
Visual Rules Modeler betrachtet werden kann.
Nein (default:
false)
Wahrheitswert
writeXmlReport
Falls true werden die Testergebnisse in einem
einfachen XML Format geschrieben.
Nein (default:
true)
Wahrheitswert
active
Configuration
Name
Name der Konfiguration für die Regelausführung, die
von allen Tests verwendet wird.
Nein
Zeichenkette
request
StatisticsLevel
Die Detailstufe der Request-Statistik die für alle
Nein
Tests verwendet wird. Erlaubte Werte sind (Groß-/
Kleinschreibung egal): QUIET, LOW, MEDIUM oder HIGH.
Zeichenkette
session
StatisticsLevel
Die Detailstufe der Session-Statistik die für alle
Nein
Tests verwendet wird. Erlaubte Werte sind (Groß-/
Kleinschreibung egal): QUIET, LOW, MEDIUM oder HIGH.
Zeichenkette
2.9. Generierung einer Dokumentation der Testergebnisse
Das visualrules-testdocgenerator-maven-plugin Maven Plugin ermöglicht es, eine
zusammenfassende HTML-Dokumentation aller Testergebnisse zu erzeugen. Es ist notwendig, dass zuvor
die Testausführung einschließlich der Erstellung der XML-Reports stattgefunden hat. Der generierte Report
TestResults.html befindet sich im gleichen "reporting" Verzeichnis wie die XML-Reports, beispielsweise
target/site/visual-rules-reports.
Es ist beabsichtigt, dass die Ausführung in der site Phase erfolgen sollte.
© Bosch Software Innovations
8/30
Kapitel 2. Einsatz von Maven
<build>
...
<plugins>
...
<plugin>
<groupId>de.visualrules.builder</groupId>
<artifactId>visualrules-testdocgenerator-maven-plugin</artifactId>
<version>${vrBuilderVersion}</version>
<executions>
<execution>
<configuration>
<!-- optional -->
<licensefile>C:\mycompany\mylicense.txt</licensefile>
</configuration>
<phase>site</phase>
<goals>
<goal>generate-testdoc</goal>
</goals>
</execution>
</executions>
</plugin>
...
</plugins>
...
</build>
Beispiel 2.3. Beispiel für das visualrules-testdocgenerator-maven-plugin
Tabelle 2.4. Parameter für das visualrules-testdocgenerator-maven-plugin
Parameter
Beschreibung
Erforderlich
Typ
licensefile
Der Dateipfad zu einer gültigen Lizenzdatei.
Das ist erforderlich, wenn sich keine Lizenz im
Standardverzeichnis befindet.
Nein
Datei
2.10. Generierung von Java Quellcode
Das visualrules-javagenerator-maven-plugin Maven Plugin ist zuständig für die Erzeugung von
Java Quellcode. Normalerweise wird ein Ordner unterhalb des target Ordners des Projektes benutzt. Wird ein
anderes Zielverzeichnis auf dem Regelmodell definiert, wird dieses benutzt. Es sind jedoch nicht alle möglichen
Einstellungen auch in einem Maven Build-Prozess verwendbar, zum Beispiel wenn in ein anderes Projekt
geschrieben wird. Für diesen Fall kann der Parameter targetDirectory gesetzt werden, um die Einstellungen
im Regelmodell zu überschreiben.
© Bosch Software Innovations
9/30
Kapitel 2. Einsatz von Maven
<build>
...
<plugins>
...
<plugin>
<groupId>de.visualrules.builder</groupId>
<artifactId>visualrules-javagenerator-maven-plugin</artifactId>
<version>${vrBuilderVersion}</version>
<executions>
<execution>
<configuration>
<!-- optional -->
<verbose>false</verbose>
<!-- optional -->
<licensefile>C:\mycompany\mylicense.txt</licensefile>
<!-- optional -->
<targetDirectory>target/vr-srcgen</targetDirectory>
</configuration>
<goals>
<goal>generate</goal>
</goals>
</execution>
</executions>
</plugin>
...
</plugins>
...
</build>
Beispiel 2.4. Beispiel für das visualrules-javagenerator-maven-plugin
Tabelle 2.5. Parameter für das visualrules-javagenerator-maven-plugin
Parameter
Beschreibung
Erforderlich
Typ
verbose
Falls true werden alle Warnungen und
Fehlermeldungen auf der Konsole ausgegeben.
Ansonsten nur zwei Meldungen (am Anfang und am
Ende).
Nein (default:
false)
Wahrheitswert
targetDirectory
Der Ordner wo der Codegenerator den Quellcode
ablegt. Das kann ein absoluter oder relativer Pfad sein.
Diese Einstellung überschreibt die im Regelmodell
definierte.
Nein
Ordner
encoding
Setzt die Kodierung des generierten Java Quellcodes.
Ist diese Einstellung nicht gesetzt, so wird die default
Kodierung der Java virtuellen Maschine verwendet.
Sofern eine Kodierung auf dem Regelmodell eingestellt
ist, wird diese immer stattdessen verwendet.
Nein
Zeichenkette
licensefile
Der Dateipfad zu einer gültigen Lizenzdatei.
Das ist erforderlich, wenn sich keine Lizenz im
Standardverzeichnis befindet.
Nein
Datei
2.11. Generierung der Web Service Schnittstelle
Das visualrules-wsdlgenerator-maven-plugin Maven Plugin ist in der Lage WSDL und XML Schema
Dateien zu erzeugen, die für die Web Service Schnittstelle benötigt werden. Damit ist das Regelartefakt auf dem
Visual Rules Execution Server einsetzbar.
© Bosch Software Innovations
10/30
Kapitel 2. Einsatz von Maven
<build>
...
<plugins>
...
<plugin>
<groupId>de.visualrules.builder</groupId>
<artifactId>visualrules-wsdlgenerator-maven-plugin</artifactId>
<version>${vrBuilderVersion}</version>
<executions>
<execution>
<configuration>
<!-- optional -->
<licensefile>C:\mycompany\mylicense.txt</licensefile>
</configuration>
<goals>
<goal>generate</goal>
</goals>
</execution>
</executions>
</plugin>
...
</plugins>
...
</build>
Beispiel 2.5. Beispiel für das visualrules-wsdlgenerator-maven-plugin
Tabelle 2.6. Parameter für das visualrules-wsdlgenerator-maven-plugin
Parameter
Beschreibung
Erforderlich
Typ
licensefile
Der Dateipfad zu einer gültigen Lizenzdatei.
Das ist erforderlich, wenn sich keine Lizenz im
Standardverzeichnis befindet.
Nein
Datei
2.12. Generierung der Manifest Datei
Soll das Regelartefakt im Visual Rules Modeler oder Execution Server eingesetzt werden, ist es erforderlich, dass
eine Manifest Datei mit bestimmten Meta Informationen und eine Datei zur Beschreibung der Abhängigkeiten zur
Laufzeit, enthalten sind. Das ist der Einsatzzweck dieses Plugins.
Das visualrules-manifestgenerator-maven-plugin Maven Plugin wird benutzt um diese Meta
Information zu erzeugen. Dieses Plugin ist für den Einsatz zusammen mit dem Java- and WSDL Generator Plugin
gedacht. Gibt es mehrere Regelmodelle innerhalb des Projekts, dann muss eines als Einstiegspunkt ausgewählt
werden.
© Bosch Software Innovations
11/30
Kapitel 2. Einsatz von Maven
<build>
...
<plugins>
...
<plugin>
<groupId>de.visualrules.builder</groupId>
<artifactId>visualrules-manifestgenerator-maven-plugin</artifactId>
<version>${vrBuilderVersion}</version>
<executions>
<execution>
<configuration>
<includesWebService>true</includesWebService>
<!-- optional -->
<licensefile>C:\mycompany\mylicense.txt</licensefile>
<!-- optional -->
<entryModel>MyModelName</entryModel>
</configuration>
<goals>
<goal>generate</goal>
</goals>
</execution>
</executions>
</plugin>
...
</plugins>
...
</build>
Damit die Manifest Datei mit in das Regelartefakt gepackt wird, ist es erforderlich, dass maven-jar-plugin in
nachfolgender Weise zu konfigurieren:
<build>
...
<pluginManagement>
...
<plugins>
...
<plugin>
<groupId>org.apache.maven.plugins</groupId>
<artifactId>maven-jar-plugin</artifactId>
<configuration>
<useDefaultManifestFile>true</useDefaultManifestFile>
</configuration>
</plugin>
...
</plugins>
</pluginManagement>
...
</build>
Beispiel 2.6. Beispiel für das visualrules-manifestgenerator-maven-plugin
Tabelle 2.7. Parameter für das visualrules-manifestgenerator-maven-plugin
Parameter
Beschreibung
Erforderlich
Typ
includesWeb
Service
Dies sollte auf true gesetzt sein, falls das WSDL
Generator Plugin ebenfalls eingesetzt wird.
Ja
Wahrheitswert
entryModel
Falls in einem Projekt mehr als ein Regelmodell
enthalten ist, ist es erforderlich den Names des
Regelmodells zu spezifizieren, welches als
Einstiegspunkt aufgerufen wird. Das kann weggelassen
werden, wenn es nur ein Regelmodell gibt.
Nein
Zeichenkette
licensefile
Der Dateipfad zu einer gültigen Lizenzdatei.
Das ist erforderlich, wenn sich keine Lizenz im
Standardverzeichnis befindet.
Nein
Datei
© Bosch Software Innovations
12/30
Kapitel 2. Einsatz von Maven
2.13. Einstellen von Dateien und Verzeichnissen in einen Visual Rules Team Server
Das folgende Beispiel illustriert, wie eine Datei oder ein Verzeichnis in einen Visual Rules Team Server 6.x
(separat erhältlich) mithilfe des visualrules-team-maven-plugin Maven Plugin eingestellt werden kann:
<build>
...
<plugins>
...
<plugin>
<groupId>de.visualrules.builder</groupId>
<artifactId>visualrules-team-maven-plugin</artifactId>
<version>${vrBuilderVersion}</version>
<executions>
<execution>
<configuration>
<url>http://localhost:8080/teamserver</url>
<username>admin</username>
<password>admin</password>
<tenant>DEFAULT</tenant>
<destination>Movie Ticket Pricing</destination>
<repository>RuleRepository</repository>
<fileset>
<directory>${basedir}</directory>
<includes>
<include>**/*</include>
</includes>
<excludes>
<exclude>target/*</exclude>
</excludes>
</fileset>
</configuration>
<goals>
<goal>checkin</goal>
</goals>
</execution>
</executions>
</plugin>
...
</plugins>
...
</build>
Beispiel 2.7. Beispiel für das visualrules-team-maven-plugin zum Einstellen von Dateien und Verzeichnissen
© Bosch Software Innovations
13/30
Kapitel 2. Einsatz von Maven
Tabelle 2.8. Parameter für das visualrules-team-maven-plugin zum Einstellen von Dateien und Verzeichnissen
Parameter
Beschreibung
Erforderlich
Typ
url
Die URL des Visual Rules Team Server Backends.
Ja
URL
username
Der Name des Benutzers auf dem Server.
Ja
Zeichenkette
password
Das Passwort des Benutzers auf dem Server.
Ja
Zeichenkette
tenant
Der Mandantenname, der für den Login verwendet wird
Ja
Zeichenkette
repository
Der Name des Repositories.
Ja
Zeichenkette
destination
Der Name des Ordners, in den die Dateien und
Verzeichnisse eingestellt werden sollen (wird ggf.
angelegt).
Ja
Zeichenkette
fileset
Dateien und Verzeichnisse, die eingestellt werden
sollen.
Ja
Fileset
branch
Die Verzweigung, unter der die destination abgelegt
wird.
Nein.
Wenn nicht
spezifiziert, wird
die aktuellste
Verzweigung
im Repository
genommen.
Zeichenkette
encoding
Das Encoding der Dateien, die im Team Server
eingestellt werden sollen.
Nein (Standard:
das Java
Encoding)
Zeichenkette
commit
Comment
Kommentar zu der Einstellung.
Nein (Standard:
ohne
Kommentar)
Zeichenkette
licensefile
Der Dateipfad zu einer gültigen Lizenzdatei.
Das ist erforderlich, wenn sich keine Lizenz im
Standardverzeichnis befindet.
Nein.
Wenn nicht
spezifiziert, wird
im Verzeichnis
<user.home>/
.visualrules6
nach einer
Lizenz gesucht.
Datei
2.14. Anlegen und Bestücken einer Verzweigung im Visual Rules Team Server
Das folgende Beispiel illustriert, wie eine neue Verzweigung im Visual Rules Team Server (Version 6.x) mithilfe
des visualrules-team-maven-plugin Maven Plugins angelegt und mit einem Projekt bestückt werden kann:
© Bosch Software Innovations
14/30
Kapitel 2. Einsatz von Maven
<build>
...
<plugins>
...
<plugin>
<groupId>de.visualrules.builder</groupId>
<artifactId>visualrules-team-maven-plugin</artifactId>
<version>${vrBuilderVersion}</version>
<executions>
<execution>
<configuration>
<url>http://localhost:8080/teamserver</url>
<username>admin</username>
<password>admin</password>
<tenant>DEFAULT</tenant>
<repository>RuleRepository</repository>
<projects>Movie Ticket Pricing</projects>
<branch>HEAD</branch>
<newBranch>br-1.0.x</newBranch>
</configuration>
<goals>
<goal>branch</goal>
</goals>
</execution>
</executions>
</plugin>
...
</plugins>
...
</build>
Beispiel 2.8. Beispiel für das visualrules-team-maven-plugin zum Anlegen und Bestücken einer Team Server
Verzweigung
© Bosch Software Innovations
15/30
Kapitel 2. Einsatz von Maven
Tabelle 2.9. Parameter für das visualrules-team-maven-plugin zum Anlegen und Bestücken einer Team Server
Verzweigung
Parameter
Beschreibung
Erforderlich
Typ
url
Die URL des Visual Rules Team Server Backends.
Ja
URL
username
Der Name des Benutzers auf dem Server.
Ja
Zeichenkette
password
Das Passwort des Benutzers auf dem Server.
Ja
Zeichenkette
tenant
Der Mandantenname, der für den Login verwendet wird
Ja
Zeichenkette
repository
Der Name des Repositories.
Ja
Zeichenkette
branch
Die Verzweigung, unter der die destination abgelegt
wird.
Nein.
Wenn nicht
spezifiziert, wird
die aktuellste
Verzweigung
im Repository
genommen.
Zeichenkette
newBranch
Name der neu anzulegenden Verzweigung
Ja
Zeichenkette
projects
Angabe eines oder mehrerer Projekte die der neu
anzulegenden Verzweigung zugeordnet werden.
Mehrere Projekte können durch | voneinander getrennt
werden.
Ja
Zeichenkette
licensefile
Der Dateipfad zu einer gültigen Lizenzdatei.
Das ist erforderlich, wenn sich keine Lizenz im
Standardverzeichnis befindet.
Nein.
Wenn nicht
spezifiziert, wird
im Verzeichnis
<user.home>/
.visualrules6
nach einer
Lizenz gesucht.
Datei
2.15. Bereitstellung auf dem Visual Rules Execution Server
Das visualrules-deploy-maven-plugin Maven Plugin stellt ein Regelartefakt auf einem betriebsfähigen
Visual Rules Execution Server bereit. Dieses Plugin darf nur nach der package Phase ausgeführt werden.
© Bosch Software Innovations
16/30
Kapitel 2. Einsatz von Maven
<build>
...
<plugins>
...
<plugin>
<groupId>de.visualrules.builder</groupId>
<artifactId>visualrules-deploy-maven-plugin</artifactId>
<version>${vrBuilderVersion}</version>
<configuration>
<url>http://localhost:8080/executionserver/admin/upload</url>
<user>admin</user>
<password>admin</password>
<tenant>DEFAULT</tenant>
<!-- optional -->
<timeout>5000</timeout>
<!-- optional -->
<licensefile>C:\mycompany\mylicense.txt</licensefile>
</configuration>
<executions>
<execution>
<phase>install</phase>
<goals>
<goal>vrdeploy</goal>
</goals>
</execution>
</executions>
</plugin>
...
</plugins>
...
</build>
Beispiel 2.9. Beispiel für das visualrules-deploy-maven-plugin
Tabelle 2.10. Parameter für das visualrules-deploy-maven-plugin
Parameter
Beschreibung
Erforderlich
Typ
url
Die URL des Visual Rules Execution Server.
Ja
Zeichenkette
user
Der Name des Benutzers auf dem Server.
Ja
Zeichenkette
password
Das Passwort des Benutzers auf dem Server.
Ja
Zeichenkette
tenant
Der Mandantenname, der für den Login verwendet wird
Ja
Zeichenkette
timeout
Die maximal zulässige Dauer einer Verbindung in
Millisekunden. Das muss ein positiver Wert sein.
Nein
Ganzzahl
licensefile
Der Dateipfad zu einer gültigen Lizenzdatei.
Das ist erforderlich, wenn sich keine Lizenz im
Standardverzeichnis befindet.
Nein
Datei
active
Einstellung ob der Rule Service aktiv oder inaktiv ist
Nein
Wahrheitswert
validFrom
Wert für die 'Gültig von' Einstellung eines Rule Service.
Format ist: yyyy-MM-dd HH:mm:ss
Nein
Zeichenkette
validTo
Wert für die 'Gültig bis' Einstellung eines Rule Service.
Format ist: yyyy-MM-dd HH:mm:ss
Nein
Zeichenkette
Mehr Information zu den Einstellungen active, validFrom, validTo finden sich im Execution Server
Benutzerhandbuch.
© Bosch Software Innovations
17/30
Kapitel 2. Einsatz von Maven
2.16. Erstellen von Visual Rules Archive (VRA) Dateien
Mit dem visualrules-archive-maven-plugin Maven Plugin können Visual Rules Archive (VRA) Dateien
erstellt werden. Eine VRA Datei enthält, neben dem eigentlichen Regelartefakt, alle notwendigen Abhängigkeiten
und Informationen zu groupId, artifactId und version der enthalteten Dateien und ist somit gut geeignet für eine
Verteilung auf verschiedenen Umgebungen wie Test oder Produktion.
Das folgende Beispiel zeigt die Verwendung des visualrules-archive-maven-plugin Maven Plugins:
<project>
...
<build>
...
<plugins>
<plugin>
<groupId>de.visualrules.builder</groupId>
<artifactId>visualrules-archive-maven-plugin</artifactId>
<version>${vrBuilderVersion}</version>
<executions>
<execution>
<goals>
<goal>vrarchive</goal>
</goals>
</execution>
</executions>
</plugin>
</plugins>
</build>
</project>
Beispiel 2.10. Beispiel für das visualrules-archive-maven-plugin
Tabelle 2.11. Parameter für das visualrules-archive-maven-plugin
Parameter
Beschreibung
Erforderlich
licensefile
Der Dateipfad zu einer gültigen Lizenzdatei.
Nein. Das ist
Datei
erforderlich,
wenn sich
keine Lizenz im
Standardverzeichnis
befindet.
© Bosch Software Innovations
Typ
18/30
Kapitel 3. Einsatz von Ant
Kapitel 3. Einsatz von Ant
3.1. Überblick
Die Visual Rules Builder Distribution enthält folgende Ant-Tasks:
• VRGenerate für die Generierung von Java-Code
• VRTest für das Testen von Regeln
• VRCheckout für dasAbholen von Regelprojekten aus einem Visual Rules Team Server
• VRCheckin für das Einstellen von Dateien in einen Visual Rules Team Server
• VRBranch für das Anlegen und Bestücken einer Verzweigung im Visual Rules Team Server
• VRDeploy für das Bereitstellen von Artefakten auf einem Visual Rules Execution Server
• VRArchiveDeploy für das Bereitstellen von Visual Rules Archive (VRA) Dateien auf einem Visual Rules
Execution Server
3.2. Ausführen des mitgelieferten Beispiels eines Ant Buildskripts
Die Builder Distribution enthält ein Beispielprojekt zur Illustration der Ant Tasks.
Um das Beispiel ausführen zu können, müssen ein Java Development Kit (JDK) und Apache
Ant installiert und korrekt konfiguriert sein. Der bin Ordner der Ant Distribution muss im PATH
eingetragen und die ANT_HOME Umgebungsvariable muss gesetzt sein. Siehe http://ant.apache.org
für weitere Infos.
1.
Öffnen Sie die Kommandozeile und wechseln Sie in den Movie Ticket Pricing Ant Ordner. Sie finden
diesen im examples Ordner der Builder Distribution, z.B.:
C:\VR-builder\examples\Movie Ticket Pricing Ant>
2.
Das Projekt enthält eine build.xml Datei. Dies ist ein Ant Buildskript, welches als Beispiele für die
Verwendung der Ant Tasks dient. Starten Sie Ant, um das Buildskript build.xml auszuführen.
Das Ant Buildskript erzeugt den Regelcode (VRGenerate), kompiliert ihn und führt schließlich einen
Regeltest aus (VRTest). Die Ausgabe sieht so aus:
© Bosch Software Innovations
19/30
Kapitel 3. Einsatz von Ant
C:\VR-builder\examples\Movie Ticket Pricing Ant>ant
Buildfile: build.xml
generateRuleCode:
[VRGenerate] Generated 26 Java source files to C:\VR-builder\examples\Movie Ticket Pricing
Ant\src-ant
[VRGenerate] Generated wsdl to C:\VR-builder\examples\Movie Ticket Pricing Ant\src-ant
\META-INF\visualrules\webservice
[VRGenerate] Generated MANIFEST.MF to C:\VR-builder\examples\Movie Ticket Pricing Ant\srcant\META-INF
compile:
[javac] Compiling 25 source files to C:\VR-builder\examples\Movie Ticket Pricing Ant
\bin-ant
[javac] Note: Some input files use unchecked or unsafe operations.
[javac] Note: Recompile with -Xlint:unchecked for details.
executeTests:
[VRTest] Der Test 'BonusPoints Test' wurde in 9ms ausgeführt (7/7 Testfälle bearbeitet,
1.29ms pro Testfall).
[VRTest] Der Test 'Pricing Test' wurde in 7ms ausgeführt (8/8 Testfälle bearbeitet,
0.88ms pro Testfall).
executeTestSuite:
[VRTest] Der Test 'BonusPoints Test' wurde in 3ms ausgeführt (7/7 Testfälle bearbeitet,
0.43ms pro Testfall).
[VRTest] Der Test 'Pricing Test' wurde in 5ms ausgeführt (8/8 Testfälle bearbeitet,
0.63ms pro Testfall).
[VRTest] Test suite 'All Tests' ausgeführt.
all:
BUILD SUCCESSFUL
Total time: 6 seconds
C:\VR-builder\examples\Movie Ticket Pricing Ant>
3.
Wenn Sie einen Visual Rules Execution Server haben, können Sie auch das deployArtifact Target in
build.xml ausführen, um ein Regelartefakt zu erzeugen und auf dem Execution Server bereitzustellen
(VRDeploy).
Sie müssen dazu die Parameter des VRDeploy Task in build.xml korrekt konfigurieren, d.h. Sie müssen
die genaue Execution Server URL, den Benutzernamen und das Passwort angeben.
Wenn Sie das deployArtifact Target ausführen, sieht die Ausgabe etwa so aus:
© Bosch Software Innovations
20/30
Kapitel 3. Einsatz von Ant
C:\VR-builder\examples\Movie Ticket Pricing Ant>ant deployArtifact
Buildfile: build.xml
generateRuleCode:
[VRGenerate] Generated 26 Java source files to C:\VR-builder\examples\Movie Ticket Pricing
Ant\src-ant
[VRGenerate] Generated wsdl to C:\VR-builder\examples\Movie Ticket Pricing Ant\src-ant
\META-INF\visualrules\webservice
[VRGenerate] Generated MANIFEST.MF to C:\VR-builder\examples\Movie Ticket Pricing Ant\srcant\META-INF
compile:
[javac] Compiling 25 source files to C:\VR-builder\examples\Movie Ticket Pricing Ant
\bin-ant
[javac] Note: Some input files use unchecked or unsafe operations.
[javac] Note: Recompile with -Xlint:unchecked for details.
createArtifact:
[jar] Building jar: C:\VR-builder\examples\Movie Ticket Pricing Ant
\movieticketpricing-1.0.jar
deployArtifact:
[VRDeploy] Successfully deployed C:\VR-builder\examples\Movie Ticket Pricing Ant
\movieticketpricing-1.0.jar
as movie-ticket-pricing-ant:Movie-Ticket-Pricing-Ant:1.0 to http://
localhost:8080/executionserver-4.6.1/admin/upload
BUILD SUCCESSFUL
Total time: 6 seconds
C:\VR-builder\examples\Movie Ticket Pricing Ant>
3.3. Konfiguration der Ant-Tasks
Damit Ant die Ant Tasks der Builder Distribution in ihrem Buildskript erkennt, müssen diese mit taskdef Tags
definiert werden. Dies zeigt der folgende Ausschnitt. Alle JAR Dateien in den lib und runtime Ordnern der
Builder Distribution kommen auf den Klassenpfad der Tasks.
Das Property builder.home müssen Sie auf ihr Installationsverzeichnis der Builder Distribution setzen.
<property name="builder.home" value="C:\VR-builder" />
<path id="cp">
<fileset dir="${builder.home}/lib/" includes="*.jar"/>
<fileset dir="${builder.home}/runtime/" includes="*.jar"/>
</path>
<taskdef name="VRGenerate"
classname="de.visualrules.ant.java.codegeneration.internal.VRGenerate" classpathref="cp"/>
<taskdef name="VRTest"
classname="de.visualrules.ant.java.execution.internal.VRTest" classpathref="cp"/>
<taskdef name="VRCheckout"
classname="de.visualrules.ant.team.internal.VRCheckout" classpathref="cp"/>
<taskdef name="VRDeploy"
classname="de.visualrules.ant.deploy.internal.VRDeploy" classpathref="cp"/>
<taskdef name="VRCheckin"
classname="de.visualrules.ant.team.internal.VRCheckin" classpathref="cp" />
<taskdef name="VRBranch"
classname="de.visualrules.ant.team.internal.VRBranch" classpathref="cp" />
<taskdef name="VRArchiveDeploy"
classname="de.visualrules.ant.deploy.internal.VRArchiveDeploy" classpathref="cp" />
3.4. Generieren von Java-Regelcode
Der Task VRGenerate dient der Generierung von Java-Regelcode. Der Task kann wie folgt benutzt werden.
© Bosch Software Innovations
21/30
Kapitel 3. Einsatz von Ant
<VRGenerate modelFile="${modelFile}" targetDir="${src-dir}" >
<!-- Folders and Jars containing additional rule model files (e.g. referenced via Reuse
Packages) -->
<modelpath />
</VRGenerate>
Tabelle 3.1. Parameter für den Task VRGenerate
Attribut
Beschreibung
Erforderlich
Ant Typ
modelFile
Pfad zur Regelmodell-Datei.
Ja
Datei
targetDir
Pfad zum Zielverzeichnis.
Ja
Verzeichnis
modelpath
Ein verschachteltes path Element das auf
Verzeichnisse und Jar Dateien zeigt die zusätzliche
benötigte Modelle enthalten (z.B. über Pakete
wiederverwenden referenzierte Modelle).
Nein
path
validateModel
Gibt an, ob das Modell vor der Generierung des
Regelcodes validiert werden soll.
Nein (Standard:
true)
boolean
enableStatistics
AndListener
Code
Gibt an, ob Code für das Sammeln der
Ausführungsstatistiken und zur Bearbeitung
kundenspezifischer Listener erfolgen soll.
Nein (Standard:
true)
boolean
checkPathLimit
Gibt an, ob die generierten Dateien auf ein
Überschreiten des Windows Pfadlimits hin überprüft
werden sollen. Wenn diese Option auf true gesetzt ist,
schlägt der Build fehl, falls das Limit überschritten ist.
Nein (Standard:
false)
boolean
generate
manifest
Gibt an, ob eine MANIFEST.MF Datei generiert werden
soll. Die Datei wird im Verzeichnis META-INF im
targetDir angelegt.
Nein (Standard:
false)
Boolean
generatewsdl
Gibt an, ob WSDL und XML-Schema Dateien mit
Web Service Schnittstellen erzeugt werden sollen.
Die Dateien werden im Verzeichnis META-INF/
visualrules/webservice im targetDir angelegt.
Wenn sowohl die WSDL Generierung als auch die
Manifest Generierung aktiviert sind werden zusätzliche
Web-Service Informationen in die Manifest Datei
geschrieben.
Nein (Standard:
false)
Boolean
encoding
Setzt die Kodierung des generierten Java Quellcodes.
Ist diese Einstellung nicht gesetzt, so wird die default
Kodierung der Java virtuellen Maschine verwendet.
Sofern eine Kodierung auf dem Regelmodell eingestellt
ist, wird diese immer stattdessen verwendet.
Nein
String
licenseFile
Pfad der Lizenzdatei. Wenn nicht spezifiziert, wird im
Verzeichnis <user.home>/.visualrules6 nach einer
Lizenz gesucht.
Nein
Datei
3.5. Kompilieren des Java-Regelcodes
Der generierte Regelcode kann mit dem Task javac kompiliert werden. Der generierte Code hat Abhängigkeiten
zu verschiedenen Bibliotheken: der Visual Rules Laufzeitbibliothek, verschiedenen Dritthersteller-Bibliotheken
sowie die Bibliotheken die vom Benutzer eingefügt wurden (zum Beispiel über Benutzerdefinierte Funktionen,
Java Typbibliotheken, usw-.). Diese Bibliotheken müssen auf dem Klassenpfad des javac-Tasks sein, um den
Code kompilieren zu können. Im Beispiel sieht die Kompilierung des Regelcodes wie folgt aus:
© Bosch Software Innovations
22/30
Kapitel 3. Einsatz von Ant
<javac srcdir="${basedir}/src-ant" destdir="${basedir}/bin-ant">
<classpath>
<fileset dir="${vr5.home}/plugins">
<include name="de.visualrules.runtime*/visualrules-runtime.jar" />
<include name="de.visualrules.commons.collections*/lib/*.jar" />
<include name="de.visualrules.commons.lang*/lib/*.jar" />
<include name="de.visualrules.commons.logging*/lib/*.jar" />
<include name="de.visualrules.java.mail*/lib/*.jar" />
</fileset>
</classpath>
</javac>
3.6. Ausführen von Regeltests
Der Task VRTest ermöglicht die automatisierte Ausführung von Regeltests und/oder Test Suites. Im mitgelieferten
Beispiel wird der Task VRTest wie folgt verwendet.
<VRTest summaryReportDir="${basedir}/summaryReports"
generateHtmlReport="true"
executionResultDir="${basedir}/executionResults"
failOnError="false"
activeConfigurationName="default"
verbose="true"
requestStatisticsLevel="medium"
sessionStatisticsLevel="medium">
<!-- Tests to execute -->
<tests>
<fileset dir="${basedir}">
<include name="**/*.vrtest"/>
</fileset>
</tests>
<!-- Folders containing the rule model files -->
<modelPath>
<pathelement location="${basedir}" />
</modelPath>
<!-- Classpath containing the compiled rule model code and any additional classes needed for
execution the tests -->
<classpath>
<pathelement location="${basedir}/bin-ant" />
</classpath>
</VRTest>
© Bosch Software Innovations
23/30
Kapitel 3. Einsatz von Ant
Tabelle 3.2. Parameter des Tasks VRTest
Attribut/
Element
Beschreibung
Erforderlich
Ant Typ
tests
Ein geschachteltes path Element, das alle
auszuführenden Tests und/oder Test Suites enthält.
Ja
Path
modelpath
Ein geschachteltes path Element, das Ordner und/
oder Jar-Dateien aufführt in denen die benötigten
Regelmodelldateien enhalten sind (z.B. auch
referenzierte Regelmodele).
Ja
Path
classpath
Ein gechachteltes path Element, das Ordner und/oder
Jar-Dateien aufführt in denen der kompilierte RegelCode sowie zusätzliche Klassen (z.B. eigene Aktionen/
Funktionen) enthalten sind.
Ja
Path
summaryReport
Dir
Definiert das Zielverzeichnis für zusammenfassende
Testberichte (einfache XML-Dateien, die Auskunft
darüber geben, welche Tests scheiterten und welche
nicht). Wird kein Verzeichnis angegeben, so werden
keine Testberichte gespeichert (default).
Nein
String
generateHtml
Report
Wenn mit true belegt, wird ein zusammenfassender
Bericht aller Testergebnisse im HTML-Format erzeugt
und als TestResults.html in dem Verzeichnis
gespeichert, das in summaryReportDir spezifiziert
ist. Ist summaryReportDir nicht definiert, wird kein
HTML-Bericht erstellt.
Nein (default:
false)
Boolean
executionResult
Dir
Definiert das Zielverzeichnis für die
Ausführungsergebnisse (*.vrexecution). Diese Dateien
können in den Visual Rules Modeler kopiert werden
um dort die detailierten Testergebnise uns Statistiken
einsehen zu können. Wird kein Verzeichnis angegeben,
so werden keine Ausführungsergebnisse gespeichert
(default).
Nein
String
failOnError
Wenn mit true belegt wird beim Scheitern mindestens
eines Tests eine Exception vom VRTest Task geworfen.
Es werden alle Tests ausgeführt.
Nein (default:
true)
Boolean
active
Configuration
Name
Definiert den Namen der Konfiguration, die während der
Testausführung verwendet werden soll. Überschreibt
alle Konfigurationen, die eventuell durch die Tests und/
oder Test Suites vorgegeben sind.
Nein
String
verbose
Wenn mit true belegt werden Statusmeldungen zur
Testausführung auf die Standard-Ausgabe geleitet.
Nein (default:
false)
Boolean
request
StatisticsLevel
Überschreibt den Statistik-Level für einzelne Testfälle.
Nein
Enumeration
(mögliche Werte
sind: none,
medium, high)
session
StatisticsLevel
Überschreibt den Statistik-Level eines gesamten Tests.
Nein
Enumeration
(mögliche Werte
sind: none,
medium, high)
licenseFile
Pfad zur Lizenzdatei. Wenn kein Pfad angegeben, so
wird im Standardpfad für Lizenzdateien nach einer
gültigen Lizenz gesucht.
No
File
© Bosch Software Innovations
24/30
Kapitel 3. Einsatz von Ant
3.7. Abholen von Regelprojekten aus einem Visual Rules Team Server
Das folgende Beispiel illustriert, wie Regelprojekte aus einem Visual Rules Team Server 6.x.x (separat erhältlich)
mithilfe des VRCheckout Tasks abgeholt werden können:
<VRCheckout url="http://localhost:8080/teamserver-6.x.x" username="vruser" password="secret"
tenant="DEFAULT" repository="repo1"
project="MyProject" targetdirectory="${basedir}" />
Tabelle 3.3. Parameter für den Task VRCheckout
Attribut
Beschreibung
Erforderlich
Ant Typ
username
Der Benutzername, der für den Login verwendet wird.
Ja
Zeichenkette
password
Das Passwort, das für den Login verwendet wird.
Ja
Zeichenkette
tenant
Der Mandantenname, das für den Login verwendet
wird.
Ja
Zeichenkette
repository
Der Name des Repository für das Abholen.
Ja
Zeichenkette
project
Der Name des Projektes, das abgeholt werden soll.
Ja
Zeichenkette
targetDirectory
Das Verzeichnis im lokalen Dateisystem, wo das Projekt Ja
abgelegt werden soll.
Verzeichnis
create
Subdirectory
Falls true werden die Dateien in ein Unterverzeichnis
von targetDirectory gelegt, das so lautet wie das
Projekt. Falls false werden die Dateien direkt in
targetDirectory abgelegt.
Nein (Standard:
true)
boolean
branch
Die Verzweigung des Projektes, das abgeholt werden
soll
Nein.
Wenn nicht
spezifiziert, wird
die aktuellste
Verzweigung
im Repository
genommen.
Zeichenkette
licenseFile
Pfad der Lizenzdatei
Nein.
Wenn nicht
spezifiziert, wird
im Verzeichnis
<user.home>/
.visualrules6
nach einer
Lizenz gesucht.
Datei
url
Die URL des Team Server Backends (z.B. http://
some.host.com:8080/teamserver)
Ja
URL
3.8. Einstellen von Dateien und Verzeichnissen in einen Visual Rules Team Server
Das folgende Beispiel illustriert, wie eine Datei oder ein Verzeichnis in einen Visual Rules Team Server 6.x.x
(separat erhältlich) mithilfe des VRCheckin Tasks eingestellt werden kann:
<VRCheckin url="http://localhost:8080/teamserver-6.x.x" username="vruser" password="secret"
tenant="DEFAULT" repository="repo1" destination="testDest">
<fileset dir="${basedir}">
<include name="**/*" />
<exclude name="bin/*"/>
</fileset>
</VRCheckin>
© Bosch Software Innovations
25/30
Kapitel 3. Einsatz von Ant
Tabelle 3.4. Parameter für den Task VRCheckin
Attribut
Beschreibung
Erforderlich
Ant Typ
url
Die URL des Team Server Backends (z.B. http://
some.host.com:8080/teamserver).
Ja
URL
username
Der Benutzername, der für den Login verwendet wird.
Ja
Zeichenkette
password
Das Passwort, das für den Login verwendet wird.
Ja
Zeichenkette
tenant
Der Mandantenname, das für den Login verwendet
wird.
Ja
Zeichenkette
repository
Der Name des Repositories.
Ja
Zeichenkette
destination
Der Name des Ordners, in den die Dateien und
Verzeichnisse eingestellt werden sollen (wird ggf.
angelegt).
Ja
Zeichenkette
fileset
Dateien und Verzeichnisse, die eingestellt werden
sollen.
Ja
Fileset
branch
Die Verzweigung, unter der die destination abgelegt
wird.
Nein.
Wenn nicht
spezifiziert, wird
die aktuellste
Verzweigung
im Repository
genommen.
Zeichenkette
encoding
Das Encoding der Dateien, die im Team Server
eingestellt werden sollen.
Nein (Standard:
das Java
Encoding)
Zeichenkette
licenseFile
Pfad der Lizenzdatei
Nein.
Wenn nicht
spezifiziert, wird
im Verzeichnis
<user.home>/
.visualrules6
nach einer
Lizenz gesucht.
Datei
commit
Comment
Kommentar zu der Einstellung.
Nein (Standard:
ohne
Kommentar)
Zeichenkette
3.9. Anlegen und Bestücken einer Verzweigung im Visual Rules Team Server
Das folgende Beispiel illustriert, wie eine neue Verzweigung im Visual Rules Team Server (Version 6.x.x) mithilfe
des VRBranch Tasks angelegt und mit einem Projekt bestückt werden kann:
<VRBranch url="http://localhost:8080/teamserver-6.x.x" username="vruser" password="secret"
tenant="DEFAULT" repository="repo1" projects="Movie Ticket Pricing Ant" newBranch="Release"/>
© Bosch Software Innovations
26/30
Kapitel 3. Einsatz von Ant
Tabelle 3.5. Parameter für den Task VRBranch
Attribut
Beschreibung
Erforderlich
Ant Typ
url
Die URL des Team Server Backends (z.B. http://
some.host.com:8080/teamserver).
Ja
URL
username
Der Benutzername, der für den Login verwendet wird.
Ja
Zeichenkette
password
Das Passwort, das für den Login verwendet wird.
Ja
Zeichenkette
tenant
Der Mandantenname, das für den Login verwendet
wird.
Ja
Zeichenkette
repository
Der Repository-Namen.
Ja
Zeichenkette
newBranch
Name der neu anzulegenden Verzweigung.
Ja
Zeichenkette
branch
Angabe einer bestehenden Verzweigung von der die
Projekte kopiert werden sollen.
Nein (Standard:
die aktuellste
Verzweigung)
Zeichenkette
projects
Angabe eines oder mehrerer Projekte die der neu
anzulegenden Verzweigung zugeordnet werden.
Mehrere Projekte können durch | voneinander getrennt
werden.
Ja
Zeichenkette
licenseFile
Pfad der Lizenzdatei
Nein.
Wenn nicht
spezifiziert, wird
im Verzeichnis
<user.home>/
.visualrules6
nach einer
Lizenz gesucht.
Datei
3.10. Ein Regelartefakt auf einem Visual Rules Execution Server bereitstellen
Mithilfe des VRDeploy Task kann ein Regelartefakt auf einem Execution Server bereitgestellt werden. Um ein
Regelartefakt zu erstellen das vom Execution Server genutzt werden kann muss ein JAR Archiv erstellt werden
das besondere Dateien enthält die vom Execution Server verarbeitet werden können. Wenn die Ant Tasks genutzt
werden um ein solches Archiv zu erstellen müssen die Folgenden Schritte befolgt werden:
• Das generatemanifest Attribut des VRGenerate Tasks muss auf true gesetzt werden. Wenn es
gewünscht ist die Regeln des Artefaktes auf einem Visual Rules Execution Server zu nutzen ist es außerdem
notwendig generatewsdl auf true zu setzen.
• Die MANIFEST.MF die vom Task VRGenerate erstellt wurde muss der erste Eintrag im JAR Archiv sein. Um
dies zu erreichen muss die Datei explizit als manifest beim Aufruf des jar Tasks angegeben werden.
• In der resultierenden JAR Datei müssen die Modelle aus denen der Java-Code generiert wurde im Verzeichnis
META-INF/visualrules/models abgelegt werden.
• Eine ruleartifact.vr muss erstellt werden die alle transitiven Abhängigkeiten des Projekts enthält. In
dieser Datei müssen alle Abhängigkeiten mit groupId, artifactId und version angegeben werden. Die
Datei muss sowohl die Java Abhängigkeiten (zum Beispiel die Visual Rules Laufzeitbibliothek) als auch die
Abhängigen Regelartefakte enthalten. Als Beispiel liegt dem Movie Ticket Pricing Ant Beispiel, das im
Modeler verfügbar ist, eine ruleartifact.vr bei.
Das folgende Beispiel zeigt wie ein Artefakt auf dem Visual Rules Execution Server (separat erhältlich)
bereitgestellt werden kann.
<VRDeploy username="admin" password="admin" fileToDeploy="artifact-1.0.jar"
uploadURL="http://localhost:8080/executionserver/admin/upload"
groupid="yourgroupid" artifactid="YourArtifactId" version="1.0" />
© Bosch Software Innovations
27/30
Kapitel 3. Einsatz von Ant
Tabelle 3.6. Parameter für den VRDeploy Ant Task
Attribut
Beschreibung
Erforderlich
Ant Typ
username
Der Benutzername der für die Bereitstellung genutzt
werden soll.
Ja
Zeichenkette
password
Das Password das für die Bereitstellung genutzt werden
soll.
Ja
Zeichenkette
uploadURL
Die upload URL des Visual Rules Execution Server auf
dem das Artefakt bereitgestellt werden soll.
Ja
Zeichenkette
fileToDeploy
Der Pfad zu dem Artefakt das bereitgestellt werden soll.
Ja
Datei
groupId
Die Gruppen-ID des Artefakts das bereitgestellt werden
soll.
Ja
Zeichenkette
artifactId
Die Artefakt-ID des Artefakts das bereitgestellt werden
soll.
Ja
Zeichenkette
version
Die Version des Artefakts das bereitgestellt werden soll.
Ja
Zeichenkette
licenseFile
Pfad der Lizenzdatei.
Nein.
Wenn nicht
spezifiziert, wird
im Verzeichnis
<user.home>/
.visualrules6
nach einer
Lizenz gesucht.
Datei
timeOut
Wert in Millisekunden (ms) für die Zeitüberschreitung
der Verbindung zur Bereitstellung.
Nein.
Wenn nicht
spezifiziert,
wird ein
Standardwert
von 5000ms
(5 Sekunden)
verwendet
Ganzzahl
active
Einstellung ob der Rule Service aktiv oder inaktiv ist.
Nein.
Sofern nicht
spezifiziert,
wird der
Standardwert
des Execution
Servers
verwendet.
Wahrheitswert
validFrom
Wert für die 'Gültig von' Einstellung eines Rule Service.
Format ist: yyyy-MM-dd HH:mm:ss
Nein
Zeichenkette
validTo
Wert für die 'Gültig bis' Einstellung eines Rule Service.
Format ist: yyyy-MM-dd HH:mm:ss
Nein
Zeichenkette
Mehr Information zu den Einstellungen active, validFrom, validTo finden sich im Execution Server
Benutzerhandbuch.
Zusätzlich ist es notwendig alle abhängigen Artefakte, die in der ruleartifact.vr angegeben sind auf dem
Execution Server bereitzustellen. In der unten stehenden Tabelle finden Sie eine Liste von Abhängigkeiten, die
von der Visual Rules Laufzeitbibliothek benötigt werden. Diese werden immer benötigt, um eine Regelartefakt
auszuführen. Diese JAR Archive befinden sich im runtime Verzeichnis der Builder Distribution und sollten immer
in der ruleartifact.vr stehen und auf dem Execution Server bereitgestellt sein.
© Bosch Software Innovations
28/30
Kapitel 3. Einsatz von Ant
Tabelle 3.7. Visual Rules Laufzeitbibliothek Abhängigkeiten
jar Name
groupId
artifactId
version
visualrules-runtime.jar
de.visualrules
visualrules-runtime
5.x.x
mail.jar
javax.mail
mail
1.4.2
activation.jar
javax.activation
activation
1.1
stax-api-1.0.jar
stax
stax-api
1.0
stax-1.2.0.jar
stax
stax
1.2.0
commons-collections-3.2.1.jar
commons-collections
commons-collections
3.2.1
commons-lang-2.5.jar
commons-lang
commons-lang
2.5
commons-logging-1.0.3.jar
commons-logging
commons-logging
1.0.3
xbean.jar
org.apache.xmlbeans
xmlbeans
2.4.0
Wenn der DatabaseIntegrator benutzt wird, muss zusätzlich folgende Abhängigkeit definiert sein:
Tabelle 3.8. Visual Rules DatabaseIntegrator Laufzeitbibliothek Abhängigkeiten
jar Name
groupId
artifactId
version
visualrules-dbcruntime.jar
de.visualrules
visualrules-dbcruntime
5.x.x
Beim Arbeiten mit Projekten die viele Abhängigkeiten untereinander und zu verschiedenen
Java Bibliotheken haben kann dieser Prozess mühsam werden, da für jedes der Projekte eine
ruleartifact.vr erstellt und gewartet werden muss. Prüfen Sie ob es möglich ist Maven statt Ant
für ihren Build-Prozess einzusetzen, welches die Abhängigkeitsverwaltung vereinfacht.
3.11. Bereitstellung einer Visual Rules Archive (VRA) Datei auf einem Visual Rules Execution Server
Als eine Alternative zu VRDeploy, stellt VRArchiveDeploy Visual Rules Archive (VRA) Dateien auf einem
Visual Rules Execution Server bereit. VRA Dateien werden von der Visual Rules Team Platform gebaut oder
können von einem laufenden Visual Rules Execution Server heruntergeladen werden. Die VRA Datei enthält alle
Abhängigkeiten und notwendigen Informationen zu groupId, artifactId und version der enthalteten Dateien und ist
somit gut geeignet für eine Verteilung auf verschiedenen Umgebungen wie Test oder Produktion.
Der folgende Auszug zeigt wie "archive.vra" auf einem laufenden Execution Server bereitgestellt wird:
<VRArchiveDeploy username="admin" password="admin"
uploadURL="http://localhost:8080/executionserver/admin/upload"
archiveFile="archive.vra"/>
© Bosch Software Innovations
29/30
Kapitel 3. Einsatz von Ant
Tabelle 3.9. Parameter für den VRArchiveDeploy Ant Task
Attribut
Beschreibung
Erforderlich
Ant Typ
username
Der Benutzername der für die Bereitstellung genutzt
werden soll.
Ja
Zeichenkette
password
Das Password das für die Bereitstellung genutzt werden
soll.
Ja
Zeichenkette
uploadURL
Die upload URL des Visual Rules Execution Server auf
dem das Artefakt bereitgestellt werden soll.
Ja
Zeichenkette
archiveFile
Der absolute oder relative Pfad der Archiv (VRA) Datei.
Ja
Datei
licenseFile
Pfad der Lizenzdatei
Nein.
Wenn nicht
spezifiziert, wird
im Verzeichnis
<user.home>/
.visualrules6
nach einer
Lizenz gesucht.
Datei
timeOut
Wert in Millisekunden (ms) für die Zeitüberschreitung
der Verbindung zur Bereitstellung.
Nein.
Wenn nicht
spezifiziert,
wird ein
Standardwert
von 5000ms
(5 Sekunden)
verwendet.
Ganzzahl
active
Einstellung ob alle Rule Services des Archivs aktiv oder
inaktiv sind.
Nein.
Sofern nicht
spezifiziert,
wird der
Standardwert
des Execution
Servers
verwendet.
Wahrheitswert
Mehr Information zu der Einstellung active findet sich im Execution Server Benutzerhandbuch.
© Bosch Software Innovations
30/30
Was this manual useful for you? yes no
Thank you for your participation!

* Your assessment is very important for improving the work of artificial intelligence, which forms the content of this project

Download PDF

advertisement