...

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 Automated RFC message handling is configured in WEB-INF/applicationContext.xml. 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 some of your RFCs return messages in the ET_MESSAGES table and some return them in ET_RETURN, you would add both of these to the spring config for the messageKeys property. If some of your RFCs return a single message in the output object, say in the field E_RETURN, then you would specify e_RETURN in the messageKeys.

  The messageKeys property contains a list of field names that are to be treated as RFC message containers by class edu.mit.mortar.controller.action.SAPBaseAction.  For example, if some RFCs return messages in a table named ET_FOO and other RFCs return messages in a structure named E_BAR, you would add these names to the messageKeys property.  Note that some commonly used values are provided for convenience but may be removed if they are unused. 

<property name="messageKeys">
     <list>
          <value>ET_FOO</value>
          <value>e_BAR</value> 
          <value>e_RETURN</value>

          <value>ET_RETURN</value> 
          <value>ET_MESSAGES</value>
          <value></value> 
     </list> 
</property> 

To take advantage of automated RFC message handling, you must specify all possible message container names that your RFCs use in the messageKeys property.  You should specify all the possible names that your RFCs return in the messageKeys property. Table names are usually all uppercase (these are just keys in a hash); however, output object field names must start with a lowercase letter (this is because the code calls the getter).

If the message objects returned from the back end have both the TYPE and MESSAGE fields, and no message overriding is planned, 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 WEB-INF/classes/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 displaynot found, the unaltered MESSAGE field is used by default.  An example of message overrides in ApplicationResources.properties:

...