...
The service interface allows you to swap out implementations in the spring config so you can use a mock service instead for testing, etc.
Message Handling
Default message handling is configured in applicationContext.xmlThe spring config for services also specifies where to get RFC messages from. Messages from the back end usually either come as a collection of messages from a table (e.g. ET_RETURN or ET_MESSAGES), or a single message stuffed into a field in the return output object. The SAPBaseAction and SAPServiceSupport classes in conjunction with the applicationContext.xml configuration file automatically handle
message processing so you don't have to. The only thing you need to do is configure what tables and/or properties the message/messages can be in based on what all its RFCs return. E.g.:
...
If the message objects returned from the back end have both the TYPE and MESSAGE fields, then setting messageKeys is all the configuration you need to do (these are automatically dealt with). However, if some other type of object is returned instead that doesn't have these fields, you will need to add code in the convertRFCMessage method in
your service implementation to convert these message objects to the RFCMessage type.
Message content can also be overridden and customized in the ApplicationResources.properties file. Objects of class edu.mit.mortar.controller.action.SAPBaseAction attempt to first find and display messages configured in ApplicationResources.properties based on ID, NUMBER, MESSAGE_V1, MESSAGE_V2, MESSAGE_V3, and MESSAGE_V4. If none are found then MESSAGE is used for display. An example of message overrides in ApplicationResources.properties:
ZVP and 00 are examples of the ID. 032, 043, and 255 are examples of the NUMBER. The variables are within the curlycue brackets (0, 1 ,2 3) and reference MESSAGE_V1 - MESSAGE_V4.