What | nameofinstance.xml |
---|---|
Description | Workflow test runs can be configured to automate tests |
schema location | http://fews.wldelft.nl/schemas/version1.0/workflowTestRun.xsd |
Table of Contents |
---|
Warning |
---|
This component is only intended for test purposes, not for production use.Originally developed for testing purposes, the WorkflowTestRunner to run workflows automatically in a Stand Alone environment is now also used in “live” systems. This use has been proven to be performing well in practice and is now fully supported by Deltares. See also 03 Testing workflows with the WorkflowTestRunner in SA mode |
Introduction
This module allows you to automate test and to run workflows with or without starting-up the user interface. As such, it can also be used to automate tasks in stand-alone systems, for example in combination with the windows task scheduler (or cron in linux systems).
The workflow test runner can also be integrated into a CI/CD pipeline. For more information, please see: Workflow Test Runner in Azure Devops
Configuration
fig1: layout of the workflowtestrun configuration
...
- date date as yyyy-MM-dd
- time the time of day as HH:mm:ss
testReport
Since 2021.01. It is possible to generate a JUnit XML compliant XML report with the test results. Currently only junitXml is supported. This can typically be used in a build pipeline like Azure Devops or Teamcity.
For example:
Code Block |
---|
<testReport dir="%REPORT_DIR%">
<reportType>junitXml</reportType>
</testReport> |
In case one of the activities fail, a failed test will be reported.
Activities
The activities of the workflow test run configuration that will be carried out. You can use activities in any order you like, they will be executed as ordered in your configuration file.
...
Runs the workflow file with the given id. The id must be known in the application environment.
choice:
taskProperties: Use a taskProperties configuration block to define how to run the workflow
WftrWorkflowGroup:
- workflowId: identifier of workflow to run
- systemTime: (optional) overruling system time for running workflow
ExportTimeSeriesActivity
Exports the given time series to PI formatted file.
Since 2021.01 the version of the PI format can be specified using the piVersion element.
attributes:
- exportFile path that specifies the location and name of the export file
- timeSeriesSet time series set as specified here
...
- exportFile file to which the logs will be exported.
- logLevel Level from which to export the log messages (DEBUG, INFO, WARN or ERROR)http://public.wldelft.nl/display/FEWSDOC/02+Data+Handling+in+DELFT-FEWS#02DataHandlinginDELFT-FEWS-TimeSeriesSets
- moduleInstanceId: (optional) Only export logs created by configured moduleinstance run.
SetSystemTimeActivity
Changes the system time.
...
- exportFile location of the file that is to be checked with the reference file
- compareFile location of the file to compare export file with
RefreshActivity
Refreshes datastore. Empty element.
ContainsActivity
Search for the presence of text in a file
attributes:
- searchFile file to search through
- searchString array of strings to search for. All specified strings have to occur for the activity to complete successful.
- emptyFile check if file is empty
NotContainsActivity
Search if text doesn't occur in a file
attributes:
- searchFile file to search through
- searchString array of strings to search for. If any of these search strings appear in the file, the activity fails.
- emptyFile check if file is NOT empty
SleepActivity
Let process sleep for configured amount of milli seconds
Workflow test runs can either be started from within a FEWS stand-alone application, or within a JUnit test.
...
To start a workflow test in DELFT-FEWS open the debug menu (F12) and select 'run workflow test' (UC). This will open an open file dialog in which you can select a workflow configuration file to run in the current environment.
...
Workflow test runs can be started in JUnit tests in order to build (nightly) regression tests. To do so, initialize the test environment and create a datastore to pass to the workflow constructor. Next code snipped demonstrates the use of WorkflowTestRun in JUnit:
Code Block | |
---|---|
| |
| |
....
// init test application
App.init(WorkflowTestRunTest.class);
FewsInstance.init(TestSupport.getInputFile());
TestSupport.setUp();
configDir = TestSupport.getInputFile("config");
relativeViewPeriod = new RelativePeriod(-100 * TimeUnit.DAY_MILLIS, TimeUnit.DAY_MILLIS);
connection = TestSupport.createTestDatabase("test");
// create datastore
dataStore = new TestDataStore(connection, configDir, coldStatesDir, cacheDir, time0);
// select the workflowtest configuration file
File configFile = TestSupport.getInputFile("testfiles/WFT_Test1.xml");
SystemActivityDescriptor descriptor = dataStore.getRuns().getSystemActivityDescriptors().add(SystemActivityType.OC);
// the WorkflowTestRun is created here
WorkflowTestRun testRun = new WorkflowTestRun(dataStore, descriptor);
// run it
testRun.run(configFile);
....
|
Run workflow test runs from bin dir
...
Workflow test runs can be started from the command line. To do so one must configure a Region as they would for a Stand Alone system.
Before 2014.02, configure in the bin directory the 'Region.exe' and 'Region.jpif' files. For the JPIF file some adaptation must be made. Here is an example:
No Format |
---|
..\jre
-mx256m
-cp
$JARS_PATH$
nl.wldelft.fews.system.workflowtestrun.WorkflowTestRun
Region_Name
..\path_to_your_config_test_file.xml
|
Since 2014.02 this is done via an ini file:
Code Block |
---|
#Delft-FEWS ini file
main.class=nl.wldelft.fews.system.workflowtestrun.WorkflowTestRun
classpath.1=*.jar
#Java Runtime jvm.dll location
## for 32 bits use ../jre/bin/client/jvm.dll
vm.location=../jre/bin/client/jvm.dll
## 64 bits use ../jre/bin/server/jvm.dll
##vm.location=../jre/bin/server/jvm.dll
vmarg.1=-Xms512m
vmarg.2=-Xmx1024m
#location of the bin dir has changed in 2017.01 (was .)
working.directory=../bin
#region_home directory - <region_home> to be replaced with actual region home directory
arg.1=../<region_home>
arg.2=..\path_to_your_config_test_file.xml |
The procedure above works (in case of a 1.5 jre) only when double clicking on the exe or when executing it from the windows scheduler. It does not running when calling the exe from a batch file or when calling it directly from the command line. If you need this use a 1.6 jre version and create a batch file similar to the example below:
The required flags should be set when calling FEWS from the command line. This can be done conveniently with the simple DOS batch file below. Note that one should at minimum specify the root folder where the FEWS bin is stored, the regionHome directory, the patch, and the WorkflowTestRun file that is to be executed.
Code Block | ||||||||||
---|---|---|---|---|---|---|---|---|---|---|
| ||||||||||
echo off
set root=%1
set region_home=%2
set workflowtestrun=%3
start /wait %root%\bin\windows\Delft-FEWSc.exe -Dregion.home=%region_home% -DautoRollingBarrel=false -Xmx1024m -DoldPID=13096_1555070573358 -Djava.locale.providers=SPI,JRE -Dstart.time=1555070573676 -Djava.library.path=%root%\bin\windows -Wvm.location=%root%\bin\windows\jre\bin\server\jvm.dll -Wclasspath.1=%region_home%\sa_patch.jar -Wclasspath.2=%root%\bin\*.jar -Wmain.class= | ||||||||||
No Format | ||||||||||
..\jre\bin\java.exe -mx512m -cp "*" nl.wldelft.fews.system.workflowtestrun.WorkflowTestRun MYREGION ..\path_to_test_file.xml |
...
-Warg.1=%region_home% -Warg.2=%workflowtestrun% |
Linux
The normal startup script in linux systems is shown below:
Code Block | |
---|---|
| |
| |
#!/bin/sh # # Script to start Delft-FEWS # # One argument required: the name of the region directory # export JAVA_HOME=$(pwd)/jre/bin if [ "$1" = "" ]; then echo "Usage: $0 <region name>" exit fi if [ ! -d "bin" -o ! -d "$1" ]; then echo "Start the script in the directory holding the region directory" exit fi # # Assemble the list of jar files in the bin directory # cd bin base=`pwd` # Assemble the classes # classes="" for f in $base/*.jar ;do if [ "$classes" = "" ]; then classes="$f" else classes="${classes}:$f" fi done echo "Java runtime: ${JAVA_HOME:-/opt/java/bin}/java - should at least be 1.5" echo "Starting application ..." ${JAVA_HOME:-/opt/java/bin}/java -Xmx256M -Djava.library.path=$base \ -classpath "$classes" \ nl.wldelft.fews.gui.explorer.Application $1 # # Remote debugging: add the following lines to the above: # -Xdebug \ # -Xrunjdwp:transport=dt_socket,address=8000,suspend=y,server=y \ exit |
Automated stand-alone direct data access system (SA-DDA)
The stand-alone direct data access system (SA-DDA) is a stand-alone application where workflows/tasks are scheduled using Windows Task Scheduler. An automated stand-alone DDA application:
- Allows multiple users to login via ‘stand-alone direct data access clients’
- Requires one central database installation which are synced to the local datastores of the SA applications through a network share
- Workflows/models are run and scheduled on one machine (the SA server) by only one user
- supported for 2017.02 and >2018.02
An impression of the IT-infrastructure, including the connections to (external) user clients is shown in the figure below.
This feature makes possible to update SA localDataStore (in Client SA) with a new one that has been exported by an another SA (Master SA)
This feature supports only firebird database.
Master SA exports local.fdb using exportArchiveModule, for example:
Code Block | ||
---|---|---|
| ||
<exportSnapShot> <general> <archiveFolder>c:/localDataStoreSnapshot</archiveFolder> <zipExportedSnapShot>false</zipExportedSnapShot> <singularExport/> </general> <activities> <exportSnapShot> <areaId>NL</areaId> </exportSnapShot> </activities> </exportSnapShot> |
The option <singularExport/> should be used to overwrite local.fdb every time the exportArchiveModule is run. Also the option zipExportedSnapShot should be set to false, otherwise Client SA will not update.
Client SA should have option localDataStoreSnapshotDownload in the Explorer.xml , for example:
Code Block | ||
---|---|---|
| ||
<localDataStoreSnapshotDownload>
<file>c:/localDataStoreSnapshot/local.fdb</file>
<downloadEnabled>true</downloadEnabled>
</localDataStoreSnapshotDownload> |
Path configured in <file> should be the same as path configured in <archiveFolder> of exportArchiveModule. When localDataStoreSnapshotDownload configured, then an item ‘Load latest localDataStore snapshot’ appears in menu File. Using this menu item a new localDataStore can be ingested.
To make the users aware of the new localDataStore snapshot, there is a field “LDS” in the explorer status bar. This field is green if the localDataStore is up to date, or red if a new localDataStore snapshot is available . Also a notification appears when the Client SA is started and a new localDataStore snapshot is available:
“New localDataStore is available in ….. Do you want to update the current localDataStore ?"
To keep the Client and Master configs the same, localDataStoreSnapshotDownload can be configured also in Master SA, with downloadEnabled = false.