Versions Compared

Key

  • This line was added.
  • This line was removed.
  • Formatting was changed.
Comment: Migration of unmigrated content due to installation of a new plugin

...

Info

Since 2014.01 it is possible to write a NetCDF-CF based adapter, see Developing a FEWS Model Adapter (NetCDF-CF)

Table of Contents

Development of FEWS Adapter

...

  • A diagnostic file written in the Published Interface format. If such a diagnostic file is available the General Adapter will read it and write corresponding logs to the FEWS system.
  • The return code indicating the result of an execution.

    return code

    meaning

    non Zero

    graceful failure - read message

    0

    successful execution


Modules and their adapters cannot use exception or event handling as a means to communicate with the General Adapter.

...

Diagnostics file
The published interface documentation describes the (simple) xml file format. Per batch (pre processing - module run - post processing) one diagnostics file is always expected. Each line/message in this file contains the actual text and the warning level attached to this text. The warning levels in the diagnostics file will be interpreted by the general adapter. according to the following table:

Level

Name

Description

Example

4

debug

debug logging

version: 1.0

3

info

information, all is well

Module PreProcessor : program ended

2

warning

warning information

Module Processor : unresolved symbol

1

error

critical problems

Module Processor: module fails (returns 1)

0

fatal

fatal error, complete module crash

Module Processor: division by zero

All levels higher than 3 are regarded as non-essential (debug) information. The warnings are recorded in the system, but no actions will be taken.

In memory file transfer
The Java adapters should check if a file is transferred in memory to the adapter by FEWS.

public static BufferedInputStream newInputStream(File file) throws IOException {
//noinspection UseOfPropertiesAsHashtable
var stream = System.getProperties().get(file);
if (stream instanceof BufferedInputStream) return (BufferedInputStream) stream;
return new BufferedInputStream(new FileInputStream(file));
}

public static BufferedOutputStream newOutputStream(File file) throws IOException {
//noinspection UseOfPropertiesAsHashtable
var stream = System.getProperties().get(file);
if (stream instanceof BufferedOutputStream) return (BufferedOutputStream) stream;
return new BufferedOutputStream(new FileOutputStream(file));
}

Validating xml

When an adapter reads xml written by FEWS according to its own xsd there is no need for validation, it is an unnecessary step because in the creation process FEWS uses those xsd's and therefore the xml will be valid.

Since FEWS 2022.02 access to external xsd's from other xsd's is closed off for the Java xml package which is included in the jdk. This is done by setting the javax.xml.accessExternalSchema sytem property to an empty string for security reasons.

When existing adapters do use this and it is not an option to update the adapter, since FEWS stable2022.02 patch #118458 in clientConfig.xml the javax.xml.accessExternalSchema system property can be overruled via

<jvmOption>-Djavax.xml.accessExternalSchema=all</jvmOption>


Children Display
alltrue

Example model adapter (includes source code)

...

FEWS_Example_Model_Adapter.43253.zip