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 config

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.

The 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 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.

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, 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.