It's the action's job to take biz objects from the service and convert them (if necessary) for display on the screen, and take data from the jsp and convert it to biz objects to send to the service. An action should do only one thing, i.e. we aren't doing actions the "multiple method" way.

In Struts 1.2 projects, actions are defined as singletons which means that they should not have instance variables unless the instance variables are static variables whose values are meant to be shared across users.

For apps that use SAP, all your actions should be subclasses of SAPBaseAction which is, in turn, a subclass of IDDAction which is a subclass of Strut's Action. (org.apache.struts.action is the core of the struts framework, providing the "Controller" aspect of a MVC model. Action is one of the classes in this core code.)

If the action is an entry point (i.e., chained to /EntryAction or /XXXEntryAction which is associated with the class edu.mit.mortar.controller.action.GlobalEntryAction in the action-servlet.xml)  the following steps automatically happen when someone launches your application via this entry point:

  1. The method edu.mit.mortar.controller.action.GlobalEntryAction.execute is called and a session is created and the following session attributes are set:
    1. GlobalKeys.SAP_SYSTEM_ID (e.g., SF2)
    2. GlobalKeys.WAS_SYSTEM_ID (web application server system id - is this null for OAS apps?)
    3. GlobalKeys.WAS_HOST (web application server host - is this null for OAS apps?)
    4. GlobalKeys.USER_HOME (gateway page?)
  2. Your action (which has been configured to chain after /EntryAction) is called which immediately calls the method IDDAction.execute which sets the following session attributes:
    1. GlobalKeys.CERT (user's certificate)
    2. GlobalKeys.USERNAME (e.g., Carolyn A Fuller)
    3. GlobalKeys.KERBID (e.g., fuller)
  3. At the end of IDDAction, SAPBaseAction.doProcess is called which opens a connection to SAP.
  4. At the end of SAPBaseAction, your action's method doAction is called within a MessageRuntimeException try catch.
  5. If your action's method doAction calls a SAP RFC, SAPServiceSupport.execute is called.
  6. 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.
    BAPIExceptions will be sent to the GlobalKeys.FAIL jsp page.
  7. The value associated with the ActionMapping findForward method (i.e., "SearchResultsPage") should exactly match the forward name associated with the action's path (i.e., /SearchPeople) in struts-config.

Your action can access the session attributes set in IDDAction or GlobalEntryAction with code similar to the following:

String kerbid = (String)request.getSession().getAttribute(GlobalKeys.KERBID)); 

This provides automatic RFC error message handling (i.e. it takes all rfc messages and stores them into the struts actionmessages automatically).

Notice that above, this action  is setting a request attribute "searchResults" with the Collection, results, which is being returned by the service.

Below the business object, CumulativeReport, is being set as an attribute, cumulativeReport, in the request.

 If your action is associated with an ActionForm, you can set the values of instance variables within this ActionForm. Below SafoForm is the ActionForm associated with this Action in the struts-config.xml configuration file.

 

  • No labels