Overview

This arti­cle gives a short overview of how to prop­er­ly pro­vide a tech­nique for pro­vid­ing end-to-end error han­dling, so that a sub­scrib­ing appli­ca­tion can noti­fy the per­son who caused an error to occur why the data he or she entered was reject­ed.

Responsibility of the publishing application

Infor­ma­tion about the per­son who caused an event to be gen­er­at­ed can be added to any object, by adding this infor­ma­tion into the meta­da­ta for that object. Addi­tion­al­ly, a his­to­ry can be main­tained show­ing every­one who made changes to the object.

When pub­lish­ing an object, the ID of the per­son who caused the event should be pub­lished in the meta­da­ta for that object

Responsibility of the subscribing agent

If the sub­scrib­ing agent wants to send a mes­sage back to the per­son who orig­i­nal­ly entered the data that caused the prob­lem in the sub­scrib­ing appli­ca­tion, the infor­ma­tion about that user may be retrieved from the meta­da­ta for that object (if it exists).

Unfor­tu­nate­ly, the SIF spec­i­fi­ca­tion states that the "Lifecycle/Created/Creators/Creator" val­ue is defined as the "Unique iden­ti­fi­er of the cre­ator. An email address or URI could be used here." and the val­ue of the "LifeCycle/ModificationHistory/By" val­ue is: "Iden­ti­fi­er of the sys­tem or per­son that mod­i­fied the data." (both some­what vague). So, since there is no accom­pa­ny­ing "type" field to let any­one know the type of this field, an end-to-end solu­tion will be pos­si­ble only when all par­ties agree to the type of this field or be able to inspect it and deter­mine its type (very dif­fi­cult to do).

The sub­scrib­ing agent should either com­mu­ni­cate the dis­con­tent with the received infor­ma­tion either direct­ly using the ID passed in the meta­da­ta or by pass­ing back a
SIF_LogEntry mes­sage.

In SIF Infra­struc­ture 2.5, "Direct­ed Events" will be added as a fea­ture. If the agent uses this infra­struc­ture, this fea­ture should be used to only send this mes­sage back to the orig­i­nal send­ing appli­ca­tion.

In the SIF_LogEntry, the rea­son for fail­ure should be not­ed and the SIF_Metadata from the orig­i­nal mes­sage should be copied to the SIF_LogEntry mes­sage. This will allow the pro­vid­ing appli­ca­tion to noti­fy the appro­pri­ate data entry user of the error (as opposed to the entire depart­ment).