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 behaviorbehaviour.
The next error types should be taken into consideration:
...
There is always a possibility that incoming central data can not cannot be imported in the data model of your application.
...
In this case, when incoming data from the central source can not cannot be processed, your application should always consult the user. Show as much as posibble 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.
...
Whilst client applications can interact with the user to solve the processing of erroneous data, server applications can notcannot. Verify that the processing of erroneous data on a server is logged, monitored and eventually presented to the user.
...
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.
...