Overview

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. This allows us an easy method to swap the SAP implementation with a Mock implementation for testing purposes. See the applicationContext.xml for information on how to do this swapping.

For SAP apps, the service calls RFCs via sap2java generated proxies 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. If an error message is returned from the SAP RFC at this point, processing will stop and the user will either stay on the same page displaying the error message if an action input has been defined correctly in the struts-config or they will be sent to the GlobalKeys.FAIL jsp page with a MessageRuntimeException. In the rare case that you don't want to stop processing and display the error message you should wrap your service call in a try...catch statement intercepting any MessageRuntimeException messages. See ApplicationResources for documentation on the error handling.

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

The service spring beans are configured in applicationContext.xml (not in action-servlet.xml) as singletons. Because of this, there should be no instance variables defined for your service other than static variables that you intend to be accessed across threads (users). For instance, in the example below, a static variable, log, is defined. This means all users will write to the same log file which is the behavior you want.

convertRFCMessage