Page History

...

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:

....
// 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

...

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:

..\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:

#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

...

Since 2018.02, 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.

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:

#!/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:

<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:

<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 ?"

...