In addition to functional extensions of the SAP E-Commerce application, one of our customers’ main requests is for adjustments to the user interface (UI) so that it adheres to their individual corporate identities’ rules and guidelines. Besides the simple replacement of images and colors, companies often want to achieve a higher level of individuality and flexibility by introducing new UI elements — for example, table sorters or breadcrumbs that direct you through a path in the UI.

The problem you face when designing generic UI elements is their need to work for all E-Commerce processes. E- Commerce uses different sub-concepts for some processes, which can make it difficult to define a UI element that works for all of them.

However, after you define and develop a generic core for the UI element, you can reuse it in multiple projects. We created a catalog of UI element features that you can use to customize your E-Commerce application. One of these features is an hourglass that appears during requests that take a long time to process, such as when a user performs an extensive search operation or when complex business processes congest the corresponding back-end system. The hourglass lets end users in your Web shop know that the system is acting on a search request.

We initially developed the hourglass for a client that had an E-Commerce implementation without a TREX index server, which caches the Web shop catalog. Without TREX, the E-Commerce Web shop has to load the catalog into memory when the end user first logs in. If you have many products in your catalog, this takes a while.

An additional benefit of the hourglass is the uniform appearance that the end user sees throughout the order process. In this situation, this hourglass replaces the standard system hourglass, which only appears when an end user opens a basket. This is useful if you have complex price calculations that can slow down the system. You can also customize the hourglass image to fit your Web shop’s look and feel by adjusting the template you use to create it.

Let’s first explore how the hourglass works, and then we’ll go over the requirements to implement it. We’ll provide an overview of the steps to set up this feature — you can go to the end of this article to download the detailed directions and coding for your Java/J2EE development team.

How the Hourglass Feature Works

Figure 1 shows the hourglass displayed after a user previews the order before confirming it. We recommend implementing the hourglass feature with a server-side implementation, which uses standard J2EE techniques. In general, a protocol-conform server-side implementation works best because no client-sided script is necessary. A generic client-side implementation has to work on many browsers that have differing interpreters. Particularly because of the complex UI logic, it can be difficult to write code that would work on all clients.

Figure 1

Example of a displayed hourglass inside the order

Figure 2 shows how the system exchanges information between the client and the server in a typical request without the hourglass. A client sends a request, the server processes this request, and then the server sends back an HTML response document. Any HTTP client may send this request.

Figure 2

Request processing without the hourglass

In contrast to the standard method, the hourglass logic in Figure 3 interrupts the client/server communication before the E-Commerce business logic processes the client request. As a first response, the hourglass logic sends back a document that displays the hourglass on the client’s screen. After the client receives the hourglass document, the HTTP request cycle ends. The hourglass is not the client’s desired final result, so the client repeats its initial request. During this repetition, the Web browser displays the hourglass on the end user’s screen. By receiving a flag in the repeated request, the hourglass logic doesn’t interrupt it again. Instead, standard E-Commerce business logic processes the received request. After finishing the request processing, the system sends the desired response back to the client.

Figure 3

Request processing with an hourglass

Recall our example in which the Web shop screen displays the hourglass after the end user submits his basket. In this part of the process, it can take a while for the system to calculate the customer-specific prices — an ideal scenario for the hourglass. When the user submits a form, the user’s Web browser sends a request to the server. In contrast to the standard process, this request does not reach the E-Commerce business logic. Instead, the hourglass logic intercepts the request and returns a small HTML page that displays the hourglass.

This HTML page contains a trigger that repeats the initial request. The hourglass logic recognizes that the second request is just a repetition of the initial one because you place a small flag as a parameter in the request. The hourglass logic does not intercept the request again and ignores it. As a result, the E-Commerce business logic works on the request by directing the back-end system to revise the basket and finally generates the order simulation page. The hourglass is displayed on the client’s screen the entire time. If you use an animated GIF image as an hourglass, it is animated until receiving the final page.

We’re now going to give you a high-level overview of the process you follow to implement this functionality. For specific step-by-step instructions on this implementation, you can go to the CRM Expert knowledgebase Downloads section.

Requirements

First, you need a central logic that intercepts a user's request and sends back a Web page displaying the hourglass. You want to make sure that the hourglass has a minimal impact on existing functionality. The repeated request therefore needs to equal the initial one. Furthermore, the filter must ignore the following request types:

• File uploads (e.g., for basket uploads)
  
  
• File downloads (e.g., for catalog/basket downloads)
  
  
• Repeated requests that you identify with a specific flag. Repeated requests occur if a client repeats its initial request after receiving the hourglass page.

When the system returns the hourglass document, you must ensure that the repeated request contains all the parameters of the initial request. You also want to make sure that the hourglass template is customizable to allow Web designers to change the image and colors easily to fit the company’s branding.

You need to design the hourglass logic that serves as a container for all the server-side actions. This logic is based on J2EE filters, which you may use for session handling, validation, and security issues. J2EE filters offer developers the possibility to react before the J2EE engine directs or delivers a resource. Refer to the “For Additional Reading” sidebar to find out more about when you can use J2EE filters.

For each J2EE Web application, you can define as many J2EE filters as you need. For example, you could map filters to a specific resource to which the user has access. If you have multiple filters, the system executes them in a chain, invoking them in the same order as they are mapped to a resource inside the corresponding configuration file. Each filter can control the generated output and interrupt the filter chain so that the system does not invoke or deliver any filters or resources behind the executed one.

To better understand the filter concept, think of an online flight-booking application. This application may consist of three areas: a public area that customers use to search current offerings, a registered-only area in which you can book a flight, and a restricted area for administrators who maintain the application. To decide whether a user has access to a restricted area, you need two things:

• Authentication: Decides if a user is authenticated by checking if he has logged into the application using a registered account
  
  
• Authorization: Decides if the authenticated user has sufficient privileges to access the designated area

You can set up authentication and authorization by using two J2EE filters that are mapped to the restricted areas. The authentication filter grants access to the resource and the authorization filter checks the user’s privileges.

Process Overview

The following is an overview of the five-step process you follow to set up these filters.

Step 1. Create the central filter class to handle incoming requests

Step 2. Implement an acceptor logic

Step 3. Design and implement a template processor to generate the hourglass document

Step 4. Return the hourglass document to the client

Step 5. Map the hourglass filter to specific resources that the E-Commerce application provides

Step 1. Create the central filter class to handle incoming requests. According to the requirements we defined above, this class must contain an acceptor logic that can decide whether or not to show the hourglass. For instance, in the case of file uploads and downloads, the acceptor logic has to ignore the request so that the hourglass won’t appear. When uploading files, the request has special multi-part formatting. If a request is in this formatting, the hourglass ignores it.

Determining file downloads is not easy because when a request arrives, it is not clear what kind of output the system needs to generate. Consequently, you cannot exclude file downloads automatically without any metadata. The corresponding developer has to ensure that he does not accidentally include downloadable content — such as an action that generates PDFs — when mapping the filters to resources.

Step 2. Implement an acceptor logic. As we mentioned earlier, repeated requests are marked by a flag as a parameter in the request. The acceptor logic just has to check if the flag is set and if this is the case, it ignores the request by passing it through.

Figure 4 shows how the acceptor works. Incoming requests are either processed by the central class (indicated by the purple arrows) or directed to the business logic (indicated by the gray arrows) if the system ignores them. After you develop the acceptor, you can decide whether you want to react on a request or not.

Figure 4

How the hourglass filter processes a request

Step 3. Design and implement a template processor to generate the hourglass document. After you implement the acceptor logic, you must create something that prepares and delivers the document that actually displays the hourglass on the user’s screen. As mentioned in the “Requirements” section, this document must be easily customizable.

For this we use a simple template mechanism, which is an HTML file located in the deployment root of the E- Commerce application. It is the central class’s task to initialize the template on start up and to deliver it after the acceptor chooses to return the hourglass document. The template processor, located in the central class, replaces all placeholders inside the template with corresponding values. You can easily change the variables inside the template by performing a simple string search and replace operation.

You also have to determine how to design the HTML template and which variables you need to achieve the requirements we described in the “Requirements” section.

The repeated requests concentrate on contained HTTP parameters, which are information that the system transfers from the client’s Web browser to the corresponding server. For example, if you perform a search on Google, the system transfers the search string you entered as an HTTP parameter so that Google knows what you want to find.

The HTML template that is processed is just a common HTML page that contains forms, texts, and images. To transfer all the information from the initial request to the repeated one, you have to insert all the parameters of the initial request into the HTML form for the repeated request. Furthermore, the form’s target has to be exactly the same resource that the system requested during the initial request.

You also have to insert another parameter, serving as a flag, into the form so that the acceptor logic identifies and ignores the repeated request. Otherwise, the hourglass procedure results in an endless loop because the central class would always return the hourglass document on each incoming request.

Using this HTML form to transfer information from the initial request to the repeated request fulfills three of the requirements. The only action left is to submit the form automatically. You can do this using JavaScript code, which the system executes after the user’s browser loads the hourglass document. JavaScript, HTML forms, and other HTML elements (which actually display the hourglass image) lead to the template structure shown in Figure 5.

Figure 5

Structure of the HTML template to generate the document that displays the hourglass

Step 4. Return the hourglass document to the client. After creating the central class, implementing the acceptor, and finalizing the template processor, you are finished with developing. The next step is sending the template back to the client by writing the template’s content to the active output stream. Figure 6 summarizes the complete process from sending an initial request to receiving the desired response.

Figure 6

Diagram of the complete hourglass process

Step 5. Map the hourglass filter to specific resources that the E-Commerce application provides. Determine all the operations in your E-Commerce application that take a long time. Then map the hourglass filter to these operations by editing the E-Commerce Web application’s configuration file. This allows the J2EE engine to invoke the hourglass filter if the system requests a mapped action and the process that is shown in Figure 6 takes place.

Extensibility

You can extend or improve upon the implementation as needed. For example, you could add language-dependent text inside the template by introducing a new variable that represents a status text. You should fill the variable with information from the standard E-Commerce resource bundles, which contain all the language-dependent texts. Finally, you could add request-specific messages so that users receive a custom text related to the action being performed. For example, the system may display “Order being processed” when you send an order or “Searching …” when you are searching through the catalog.

Patrick Hey

Patrick Hey is a manager/senior consultant at the SYCOR GmbH with more than five years of SAP E-Commerce experience. After studying commercial information technology, he started his career with the design and implementation of solutions in various subject areas of business applications. Today he is responsible for a team of 12 consultants, developers, and solution architects who create solutions based on SAP E-Commerce 3.1/4.0/5.0, SAP WebDynpro, SAP NetWeaver Portal, and SAP NetWeaver Process Integration.

You may contact the author at patrick.hey@sycoramericas.com.

If you have comments about this article or publication, or would like to submit an article idea, please contact the editor.

Ludwig Hunecke

Ludwig Hunecke is a development consultant working at SYCOR GmbH. His daily work focuses on solutions within the range of SAP E-Commerce, SAP WebDynpro, JSE/J2EE, and SAP NetWeaver Development Infrastructure. In the past four years, Ludwig has designed and implemented diverse requirements for multiple customer projects.

You may contact the author at ludwig.hunecke@sycoramericas.com.

If you have comments about this article or publication, or would like to submit an article idea, please contact the editor.