Generate payload hash on error save

[derek63]

To be used to when determining message equivalency

[derek63]

@vritant Please add more details as necessary. @alechenninger once this is implemented, we can stop doing this elsewhere (yay!)

[alechenninger]

To sum our discussion this morning, and vritant can correct me if I'm wrong, but I believe message equivalence is based on:

• Message payload
• Error payload
• Potentially also headers (though I think this would be covered by message payload... in any case if the same message and error but with different headers is supposed to be consider equivalent, that needs to be made explicit somewhere if only in documentation)

And so all of those things should affect the hash (or hashes).

[derek63]

BTW, I realized after our chat this morning that the current version of the app is working with the payload hash passed in the message header, so the changes for this issue should remove/replace that logic. That unfortunately means we still have to care about the generation of this hash in the ESB until this issue is resolved.

[vritant]

@derek63 @alechenninger thinking about this further, headers are probably over kill and might lead to bugs. Id recommend these fields ( they are all required fields in the persist API right now on a message ):

• messageType;
• sourceQueue;
• sourceLocation;
• sourceSystem;
• originalSystem;
• serviceName;
• errorComponent;
• errorMessage;
• errorDetails;
• errorSystem;
• errorType;
• payload;

note: I purposefully left out guid cause if an entity is synced twice with the same content and fails for the same reason, we will have different guids but EMA should treat them as duplicates

[alechenninger]

@vritant @derek63 The fields in the persist error api... is it documented anywhere what these are supposed to be? I would love explicit definitions of these terms. Consumers of the API will find it necessary IMO

IMO I would like to see this manifested as this heavily javadoc'd: https://github.com/esbtools/esb-message-admin/blob/master/api/src/main/java/org/esbtools/message/admin/model/EsbMessage.java

If you'd like me to move this to a separate issue, just say the word :)

[derek63]

In general this project needs documentation on all fronts (javadoc, README, gitbook, etc.) , which I plan to start adding very soon. I went ahead and opened a couple of issues so we can track the need for this (https://github.com/esbtools/esb-message-admin/issues/130 for javadocs, and https://github.com/esbtools/esb-message-admin/issues/131 for gitbooks)