Page History

...

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

Image Added

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:

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

To keep the Client and Master configs the same, localDataStoreSnapshotDownload can be configured also in Master SA, with downloadEnabled = false.