-
Notifications
You must be signed in to change notification settings - Fork 9
Description
Right now editable message is determined from a header instead of as a field in the entity (db). On the client side, this detail is hidden for reads only, and editableMessage is populated when messages are searched for. But, when persisting a message, the reverse is not true: clients must know to add this as a header.
I would add this logic to ConversionUtility so that going from an EsbMessage adds a header entity for the editableMessage field on the message model. Similarly, when reading, I would also move this logic to ConversionUtility from the entity to the EsbMessage.
Of course, maybe there is a better way. But for example, in EsbMessageAdminServiceImpl:
EsbMessage[] messageArray = new EsbMessage[1];
messageArray[0] = ConversionUtility.convertToEsbMessage(messages.get(0));
messageArray[0].setAllowsResubmit( EmaResubmit.allowsResubmit(messageArray[0]) );
messageArray[0].setEditableMessage( EmaResubmit.isEditableMessage(messageArray[0]) );
Map<String,String> matchedConfiguration = matchCriteria(messageArray[0], getNonViewableMessages());
if(matchedConfiguration!=null) {
messageArray[0].setPayload(matchedConfiguration.get("replaceMessage"));
}
result.setMessages(messageArray);The extra setter calls are maybe pointing out that convertToEsbMessage is not doing it's job completely. Maybe it would be better if the returned EsbMessage(s) could be fully populated after that call, so this instead looked like:
EsbMessage[] messageArray = new EsbMessage[1];
messageArray[0] = ConversionUtility.convertToEsbMessage(messages.get(0), getNonViewableMessages())
result.setMessages(messageArray);