You are viewing an old version of this page. View the current version.

Compare with Current View Page History

« Previous Version 11 Next »

On This Page

The Service Classes

There is normally only one service class per app. The service class' job is to get data from the back end and perform some biz logic on it and return it to the front end (actions). There should be one service interface and one class that implements it, e.g. OasSkeletonService, and OasSkeletonServiceImpl.

For SAP apps, the service calls RFCs and converts their proxy data into biz model objects. The service class should be a subclass of SAPServiceSupport which provides methods to call the back end and process errors.

For Hibernate apps, the service calls the daos to get biz objects and performs whatever biz logic is necessary on them.

Spring Configuration

The service spring beans are configured in applicationContext.xml (not in action-servlet.xml).

For SAP apps, there is a default applicationContext that sets up the proper service properties needed to connect to SAP. (There are also some extra property settings for doing mock services; see the file).

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

Automated RFC message handling is configured in WEB-INF/applicationContext.xml.  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.  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 not found, the unaltered MESSAGE field is used by default.  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.

  • No labels