This article gives a short overview of how to properly provide a technique for providing end-to-end error handling, so that a subscribing application can notify the person who caused an error to occur why the data he or she entered was rejected.
Information about the person who caused an event to be generated can be added to any object, by adding this information into the metadata for that object. Additionally, a history can be maintained showing everyone who made changes to the object.
When publishing an object, the ID of the person who caused the event should be published in the metadata for that object
[cc name="code‑1"/]If the subscribing agent wants to send a message back to the person who originally entered the data that caused the problem in the subscribing application, the information about that user may be retrieved from the metadata for that object (if it exists).
Unfortunately, the SIF specification states that the "Lifecycle/Created/Creators/Creator" value is defined as the "Unique identifier of the creator. An email address or URI could be used here." and the value of the "LifeCycle/ModificationHistory/By" value is: "Identifier of the system or person that modified the data." (both somewhat vague). So, since there is no accompanying "type" field to let anyone know the type of this field, an end-to-end solution will be possible only when all parties agree to the type of this field or be able to inspect it and determine its type (very difficult to do).
The subscribing agent should either communicate the discontent with the received information either directly using the ID passed in the metadata or by passing back a
SIF_LogEntry message.
In SIF Infrastructure 2.5, "Directed Events" will be added as a feature. If the agent uses this infrastructure, this feature should be used to only send this message back to the original sending application.
In the SIF_LogEntry, the reason for failure should be noted and the SIF_Metadata from the original message should be copied to the SIF_LogEntry message. This will allow the providing application to notify the appropriate data entry user of the error (as opposed to the entire department).
[cc name="code‑2"/]