BSP Programming: Writing a Pattern Engine
Employee Self Services (ESS) is one of the hottest new developments in the intranet. Most companies attempt to streamline processes, and have employees complete simple administrative processes directly themselves. Typical examples are booking holidays, address changes, or ordering office utilities. These processes are all targeted at occasional use, and must be simple to use. The typical approach is to use a fixed pattern, which all ESS applications follow, so that the casual user will be able to complete the process relatively easily. For this weblog, we would like to write an ESS application for holiday (vacation) booking. First, we will write a pattern engine that does all of the generic work and handles the overall layout. Thereafter, we will write our small ESS application. Product remark: The work presented here does not come from any SAP product. The words ESS and pattern engine are used here in a generic way, and do not reflect any product development work that I am aware of. For this weblog, my favorite search engine was used to obtain one or two screen shots of a typical ESS application from a website in the Internet. For all our ESS applications, we would like to have the same layout. At the top should be the title. A roadmap will be used to give an overview of all the steps to be followed, plus the current active step. Navigation buttons must be at the bottom of the page. All ESS processes will have at a minimum: an introduction page to explain how to complete the process, the actual work pages, a save page giving a summary of the entered data, plus a final confirmation page. After the weblog that showed how to write composite elements (BSP Programming: Writing Composite Elements), the first idea was to use a composite element to handle the complete layout, wrapped around the body of the ESS application. However, BSP elements are excellent at handling rendering, but not good for complex logic.In this case, we would have required additional data structures to hold configuration information and extra classes to handle events. It was then that the plan for using a BSP controller as a pattern engine was hatched. Using a controller has many benefits. The code for the controller is placed in a separate class. Adding the controller into a BSP application is just one data entry. The same controller can be used many times within one BSP application. As a controller is effectively a normal ABAP class, it is possible to place all the type declarations, data and event handling into this class. Furthermore, it is possible to use the same techniques that are used in composite elements, also in controllers. Thus, the controller can contain rendering code, and is quite capable of processing BSP elements. For our design, we have one controller that will be the pattern engine. The pattern engine is responsible for handling the complete layout, deciding what the current active step is, and displaying it. In addition, the pattern engine will offer a number of events (mapped onto method calls) to help the ESS application, for example: next, previous, confirmed and finished. The ESS application will consist of a controller that inherits from the pattern engine, a model class, and all the views that are required for rendering each step. Because the ESS application inherits from the pattern engine, it is very easy to complete the configuration data about the pattern and to overwrite any events of interest. Furthermore, the ESS application will contain all the business logic. The use of a model class is optional. For the ESS application it is used, as the model binding makes it easier to have the data from the incoming request placed automatically back in the model. The model class also handles the conversion between internal and external representation. A typical example is the conversion of a date from ‘YYYYMMDD’ into my preferred version ‘YYYY-MM-DD’ and to ‘MM/DD/YYYY’ for our stateside colleagues. For each step in the ESS application, one view is written. The view itself will only contain the BSP elements that represent that actual ESS application. Everything else will be done by the pattern engine. h3. The Final ESS Application Before looking at the actual code, let us first look at what we want to achieve. This will make the actual code much easier to understand. Our small ESS application will have five steps. The first is an introduction page, which explains the complete process quickly. The second step will give an overview of the holidays that have been taken this year, and list the available holidays. The next step will be to enter the data for the next holiday! After the data has been verified as correct, it will be presented in read-only mode in step four, with a confirm button. Up to this step, it’s always possible to navigate back to the previous steps, or to cancel the process. In the last step, a final confirmation shows that the holiday has been booked. Now the only navigation option is to press the finish button. For typical ESS applications, this exit URL will be configured to return to a small “portal” that contained all the different ESS applications. h3. Writing the ESS Application Before looking at the more complex pattern engine, let’s first look at the work required to develop the ESS application. We create a new BSP application that has one controller and five views.