Defined behavior after errors
Define and document the behavior behaviour of your implementation in case of interoperability errors. Errors are also a communication item in addition to drawing a clear line between expected and unexpected behaviour.
The next type of errors error types should be taken into consideration:
- the errors Errors from "Errors" section of the specification. This mainly concerns the protocol specification.
- errors Errors after reception of faulty artefacts from another implementation.
- errors Errors when processing correct artefacts by your implementation.
- errors Errors during generation of faulty artefacts by your implementation.
Erroneous data mapping
There is always a possibility that incoming central data cannot be imported in the data model of your application.
The cause can be e.g.:
- wrong input from the end-user of the sending application
- a bug in the sending application
- a design error in the sending application
- an unexpected dialect of the specification used by the sending application
- ...
In this case, Verify that the user is consulted when incoming data from the central source can not be processed.
Input validation
cannot be processed, your application should always consult the user. Show as much as possible the information of the incoming data to your user. This should allow your user to correct the error manually up to a maximal level, or to gather enough information for later analysis.
Input validation
Typically, an application validates the data a user manually enters to see whether it is in the expected format and is within the range of allowed values for that input. Verify that this Verify that the validation of user input is also applied for incoming data from the central source. If the validation fails, the data should be handled as erroneous data.
Transformation design
Verify that your transformation of central data is well-designed and documented. The design includes the restrictions the central data should apply to to It is possible that your transformation requires more restrictions for the central data than the specification does. This extra restriction is e.g. needed for the data to be able to serve as input for the transformation.
. Your design documentation should include these restrictions. All data that is not suitable for the transformation should be handled as erroneous data.
Server processing
Verify Whilst client applications can interact with the user to solve the processing of erroneous data, server applications cannot. Verify that the processing of erroneous data on a server (where there is no immediate user interaction) is logged, monitored and eventually presented to the user.
Logging
Verify that enough information about manipulation of central and local data is logged to enable later analysis of possible problems. Without this logging, it can be very hard to analyse problems that are detected only after using another application that consumes that data.