You are viewing an old version of this page. View the current version.

Compare with Current View Page History

« Previous Version 5 Next »

Defined behavior after errors

Define and document the behavior of your implementation in case of errors. Hier nog wat uitleg waarom dit belangrijk is??? 

The next error types should be taken into consideration:

  • Errors from "Errors" section of the specification. This mainly concerns the protocol specification.
  • Errors after reception of faulty artefacts from another implementation.
  • Errors when processing correct artefacts by your implementation.
  • Errors during generation of faulty artefacts by your implementation.

Erroneous data mapping

When participating in data exchange E.g. in the Vitalink Medication Scheme. You can import data into your application that does not map on your database structure or data that are not what you expected (e.g. because you interpreted the spec differently or the sending application made a mistake). In that case, your application should always consult the user when incoming data from the central source can not be processed. Show as much machine-readable or plain text information as you can to the user so the least possible information is lost. 

Input validation

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. SNAP IK NIET, NOG OPNEMEN IN REQ

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 be able to serve as input for the transformation.
All data that is not suitable for the transformation should be handled as erroneous data. SNAP IK NIET, NOG OPNEMEN IN REQ

Server processing

Nog wat uitleg geven waarom dit belangrijk is en waarvoor het loggen achteraf kan dienen. 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. NOG OPNEMEN IN REQ

Logging

Nog wat uitleg geven waarom dit belangrijk is en waarvoor het loggen achteraf kan dienen. Verify that enough information about manipulation of central and local data is logged to enable later analysis of possible problems. NOG OPNEMEN IN REQ


  • No labels