...
It is also possible to call external java classes (*.jar) from the general adapter. Within this option it is NOT necessary to have the java *.jar file stored in the Delft-FEWS \bin\ directory. In this way, the dependency is clear and should it be seen as separate from the 'core' code of Delft-FEWS. The <command> element is important here in which you specify the full name of the Java runnable class and the option to specify its location in the <binDir>. The use of global properties is allowed. An example can be found below and more information can also be found here.
No Format |
---|
... <executeActivities> <executeActivity> <command> <className>nl.wldelft.fews.ftpPull.FtpPull</className> <binDir>%REGION_HOME%/Modules/FtpPull</binDir> </command> <arguments> <argument>-configFile</argument> <argument>$FTPPULL_CONFIG_FILE$</argument> <argument>-root</argument> <argument>%ROOT_DIR%</argument> </arguments> <timeOut>900000</timeOut> </executeActivity> </executeActivities> ... |
User interaction
Modules called from the DELFT-FEWS system should in principle be defined such that these require no user interaction through menus and screens. This principle holds for all modules that are run from the system as a requirement in making an automatic forecast. These modules are then typically run on forecasting shell servers, i.e. dedicated servers for module execution. An exception to this rule can be made for modules run on the operator client that require manual interaction. The interface to these is from the point of view of the general adapter exactly the same as any other module. However, the module itself may require user interaction to complete the task required. An example is the interactive correlation utility.
...
Communication of module diagnostics is through the applicable published interface formats. The general adapter starts a task, and on completion reads the output of that task. There is no provision for intermediate communication.
Module run information
There are two approaches in the exchange of run-time information to the module. This includes for example when start date/time of the module run and the end date/time of the module run. The first approach is through the exchange of time series whereby the module adapter derives the run information from the time series identified as inputs. The run should then start at the first time step in that timeseries, which typically coincides with the date/time of the state, and the last time step in the timeseries.
In some cases the multiple time series may be used as input to the module, and if these are of differing lengths a driving timeseries is required to be defined in the adapter.
Another approach is to export additional information from FEWS. The general adapter can be configured to export a run information file, which includes the start and end date of the run, the forecast start time (time0), as well as an optional indication of the time until observed data is available (where this is different to the time0). The file also includes specification of all input and output files as defined, with the full path names, as well as a configurable amount of key value pairs (synonomous to command line arguments).