Overview

Projects are "dynamic web app" eclipse projects.

In SAP based apps, the service does most of the conversion between SAP objects (proxy) and biz objects, as opposed to Hibernate based apps where the conversion is done by Hibernate in the dao classes.

App specific css and js go in css/app_layout.css and js/app_specific.js.

ApplicationResources.properties contains all the props specific to the app itself no matter what machine it runs on. Usually, all messages and displayable strings go here.

Apps are normally setup so that eclipse will be able to build the app (with your local machine specific props) and deploy it to your local server.

Eclipse Project Structure

The following tree documents the Eclipse standard project structure.  Each section contains detail information on the specific project component. 

Checking Out an Eclipse Project

See the iJAG FAQ for instructions on checking out an Eclipse project.

Configuring a Struts 1.2/Spring Project

See the iJAG FAQ for instructions on configuring a Struts 1.2/Spring Project. 

Message Handling 

Message handling is configured in the Spring configuration for service objects.  See the applicationContext.xml section on Message Handling for information on how to configure default message handling and override message content.

Building and Running an Application in Eclipse

If you forget to create your site folder and configure it, your app will not build. This is a common problem. If mortar 00.xx or insidemit are not checked out and set up properly, your app will not build. See iJAG FAQ for instructions on deploying locally.

To run your app, just right click the project and select Run As > Run on Server. The first time you do this it will ask you to pick which server to run on. If you check the checkbox at the bottom it won't ask you this again. By default, it will go to the action EntryAction.do. If project(s) other than the one you've chosen to run are run also, it is because they were added to your server earlier. You can remove them from the server by going to the Servers window, expanding the Oracle server, selecting the project you wish to remove, right clicking and selecting Remove.

You can access your app in your web browser at http://localhost:8888/apps/yourappnamehere/ and it will automatically go to EntryAction. If you have more than one entry point you will need to specify which XxxEngryAction to go to. For SAP apps, you do not need to specify sapSystemId as this is configured in your site/ApplicationLocal.properties file (the r3default property).

If you want to access your localhost from a different IP address, you will need to know the name. You can get this info by bringing up the Command Prompt and ping localhost. The response will be something like Pinging fss-115-2.mit.edu ... fss-115-2.mit.edu should replace loaclhost in the URL above.

When you rebuild your app, you can either do Run As again or you can right click your server and select Publish.

To debug your app, make sure you have some breakpoints set and then cause a rebuild to happen (you can do this by doing a Clean). Then restart your server in Debug mode. You can then either right click the project and select Debug As > Debug on Server, or publish the app and just go to your browser. When you reach a breakpoint, eclipse should switch to debug view and your browser will sit there waiting.

Demo Application

The skeleton we use to create new apps comes with a built-in demo app. You should base your code on this. The source for the demo is in the edu.mit.oasskeleton package structure, and there are a couple jsps and struts configs, etc. It also implements a search help.

Search Help

The documentation for implementing search help using mortar 4.1x or later is in the search help tag library (searchhelp.tld). The original version of this tag library is maintained in the skeleton, oas-skeleton.

JSP (with Search Icon)

The JSP with the search icon will pass mortar a key and one or more field names. You can get the key and field names from the ABAP developer.

Example (taken with slight variations from the safo project) 

Most of the time the ABAP developer will need to add code to the RFC, Z_CA_SEARCH_HELP, to implement the specific search help that is needed. This RFC is expecting:

• a key to be passed from the JSP  
• the field names that are going to be searched.

The first two or three characters of the key represent the business area: EHS, FI, HR, MM (materials management - Logistics Team). Ask the ABAP developer for the key and the field names.

Examples of keys and their field names:

• FI_SAFO_COST_OBJECT
  • KSTRG
  • TEXT
• EHS_LIST_PERSON_BY_NAME
  • LAST
  • FIRST
• HR_COST_OBJECT
  • KSTRG
  • TEXT

 ABAP developers should use English for our keys & field names but we sometimes slip up and use the German abbreviations. KSTRG is the German abbreviation for Cost Object.

In addition to what is passed to the RFC, the JSP also needs to code the columns that are returned from the RFC. 

The sample JSP code: 

• form is the project's controller > data > actionForm (ReportRequestForm) associated with the JSP with the magnifying glass icon .
• origaction is the project's controller > action > action (/RequestReport.do) that launched the JSP with the magnifying glass icon .
• key is the key (FI_SAFO_COST_OBJECT) you get from the ABAP developer.
• interactive ("y") indicates whether there are so many potential search results that you should first request search criteria ("y") If there are 50 or under no search criteria are necessary and mortar will take the end user directly to the search results ("n"). (? - Ask your UI person but generally if there are a max of 15 search result rows interactive should be "n".
• title is what will appear (Cost Objects Title) after "Search for " on the search help criteria page.
• incrit crit are the names (KSTRG & TEXT) you get from the ABAP developer.
• incrit label are the labels (Input Cost Object & Input Description) for these names that will appear on the search help criteria page.
• incrit vfield are the actionForm field names (co & coDesc) that correspond to these names & labels.
• dispfield field are optional tags used to specify which columns will be displayed in the search results. If specified these columns must be the same names as the metadata column headings returned by the RFC. The ABAP developer can supply the names of these columns.
• outfield rfield are used to map the columns to the actionForm field names. These must be the same names as the metadata column headings returned by the RFC. The ABAP developer can supply the names of these columns.
• outfield dfield are the actionForm field names (co & coDesc) corresponding  to the results columns.
  
  Beyond having the ABAP developer modify Z_CA_SEARCH_HELP to incorporate your specific search help and making these changes to your JSP, there is nothing else that needs to be done to implement search help for any project that has been created using oas-skeleton and mortar 4.2x or higher 

Revision History

(latest on top)