...
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.
...
- 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
...
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.
...
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
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
|
Before 2018.02
From 2014.02 to 2017.02, this was 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 |
Check the attachment workflow_test_run for an example.
Since 2018.02
Since 2018.02, the 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=nl.wldelft.fews.system.workflowtestrun.WorkflowTestRun -Warg.1=%region_home% -Warg.2=%workflowtestrun% |
...
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)
...
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 ?"
...