After downloading Struts from http://Jakarta.apache.org/struts/index.html, the first order of business is to install
the Struts libraries within your Tomcat application server. Tomcat can be found at http://jakarta.apache.org/tomcat/index.html. If you haven't already installed Tomcat, simply run the application installer and install in a directory that you will remember (i.e. d:tomcat). From this point on, I will use d:tomcat as the default installation directory, however yours will likely vary. First off, extract the Struts files to a temp directory, then copy all the files contained in the lib directory to the d:tomcatcommonlib directory. By doing so, you are allowing any Webapps you create in Tomcat to have access to the Struts libraries. You should also copy the file jco.jar from the JCo install zip, available from http://service.sap.com, into the lib directory. Likewise, if you have not done so already, copy the DLL files from the JCo zip into your
system32 directory. Before we get started with the SAP development, let's make sure that we have Struts installed properly. To do so, copy all the files from the /webapps directory in the Struts zipfile into the d:tomcatwebapps directory. Now start your Tomcat server by launching startup.bat from the d:tomcatbin directory. Wait for the server to finish loading, launch a Web browser, then go to: http://localhost:8080/struts-example/. If all goes well, you should have access to the MailReader application that comes with the Struts install. If you get an error at this point, try loading http://localhost:8080. This should bring you to the Tomcat homepage. If you can get to the Tomcat homepage but not the Struts example, make sure that you copied all of the files from the /webapps directory (not the directory itself, just the files) into the d:tomcatwebapps directory. Stop Tomcat then relaunch using d:tomcatbinstartup.bat. Now that we have validated our Struts install, let's take a look at some of the actual configuration files. Using a ZIP archive utility such as Winzip or Power Archiver, open the struts-example.war found in your d:tomcatwebapps directory. From there, open a file called 'struts-config.xml'. This is the core configuration file in Struts. Here we can define both our form beans and our action mappings. Form beans allow us to repopulate screen fields with previously entered data for use in error handling, etc. However, we are going to take a closer look at the action mappings, for that is where all the action happens (bad pun intended). In Struts, the action mappings allow us to define easily not only our screen flow but how our presentation layer interacts with our business objects. Looking at the sample Struts config file we see that an action mapping consists of the action itself as well as one or more forwards. The action has a path, a type, and a name. The path specifies where the request must come from to process the business object specified by the type value. This means that when a user requests http://localhost:8080/struts-example/logon.do that request is automatically sent to the 'org.apache.struts.webapp.example.LogonAction' Java class as specificed within the struts-config.xml. The 'forward name' tags within the config file are used by the Action class containing our business logic to specify a resultant Web page after that business logic has been processed. We will talk about the Action class in the next tip, but an Action class is simply Java code where we define our business logic and the connection back to the R/3 system. The 'forward name' tag is a text string that is sent to the controller and the controller then reads that mapping from our struts-config.xml file to determine where to send the user. In the case of the editSubscription action mapping we find two different forwards, one defined 'failure' and the other defined 'sucess'. Again, these are simply arbitrary text strings used to make the config file more human legible. Depending on the forward name sent by the Action class, the user will be sent to either mainMenu.jsp or subscription.jsp. We can now see the initial formation of our screen flow taking place. As we add and change Web pages, we can easily configure that flow through the struts-config.xml file. Should we need to change business logic within our Action classes, those changes will not affect our screen flow and vice versa. The next tip will focus on the Action class and we will begin to add our own SAP specific connection logic to build out a Web application. Until then, I highly recommend reviewing the Struts documentation and reviewing the Struts examples provided in the install. You can extract the struts-example.war file into a separate directory under d:tomcatwebapps (say 'mystruts') then play around with the struts-config.xml to affect the screen flow of that application. Use http://localhost:8080/mystruts/ to test out any changes made to the example application. Check out Austin's site for more insight into building application for the Enterprise. Author Austin Sincock is product manager for ROBUSTA(tm), Gamma Enterprise Technologies Web sales solution for SAP.
Dig deeper on SAP Web applications