On This Page

Overview

The service Spring Container beans are configured here (applicationContext.xml not in action-servlet.xml).

Unless your application is calling one or more RFCs that use non-standard error tables, the only things you will need to change in this file are the bean class (e.g., "edu.mit.safo.service.SafoServiceImpl") & the property name="packageName" value (e.g, edu.mit.safo.proxy) associated with the bean id, service. This bean id is set up by the IDD Team mapped to the oas-skeleton service implementation (OasSkeletonServiceImpl) and proxy package (e.g., edu.mit.oasskeleton.proxy). You should change it to your application's service implementation (e.g., SafoServiceImpl) and you should change the packageName to your app's proxy package (e.g., edu.mit.safo.proxy).

Application-specific Service (w/Mock Service)

The application-specific service is the only thing that you must configure in this file, changing the class from the oas-skeleton service implementation to your app's service implementation and the packageName to your app's proxy package.

The service should be configured as a singleton which is the default setting. Since the beans are defined as singletons it is important to make sure the service is thread-safe (i.e., multiple users won't corrupt each other's data) which means the service implementation class should not have any non-static instance variables. Instance variables are non-local (i.e., defined within class but outside of a method, conditional statement, loop etc) variables. Note that oas-skeleton service has a static variable defined as a Logger.  This is fine since static means everyone (all threads) shares the same variable & value (think global variable across multiple users) and we want everyone to share a single log file. Go here for an explanation of the singleton pattern.

This service configuration should include values for the error handling tables that the SAP RFCs return (more on that in the Message Handling section below).

Notice that the service interface allows you to swap out implementations in the spring config so you can use a mock service instead for testing, etc.

For more information on the singleton instance variables configured above (messageKeys, messageMgr, connectionMgr & packageName) see More Info on SAPServiceSupport section in the service documentation.

SAP Specific Configuration

For SAP apps, there is a default config in 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 config excerpt below). You shouldn't need to change anything in this section.

Message Handling

The Spring config for your application-specific service should also specify where to get RFC messages from. Messages from the back end usually come as a collection of messages from a table (e.g. ET_RETURN or ET_MESSAGES). 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 leave both of these in 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. Otherwise, the method convertRFCMessage should return null.
Example configuration:

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

Note that 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).

Messages can be overridden by entries in the ApplicationResources.properties.

Search Help Service

The Search Help service with its own error message is also configured here. The actual Service is found in mortar. You don't need to change anything in this section.


  • No labels