Very often consultants or customers wish to change the look and feel of a BSP application. Within the SAP Enterprise Portal (EP6), there are tools available that allows one turn every possible knob: definitely a designer’s dream. However, for mere mortals, these tools are very complicated to use, and it takes many hours to change from any predefined SAP theme to a new corporate theme. We developed a quick-and-dirty “look and feel service” for the ABAP stack that allows us to have a new colour scheme up and running in _three_ minutes. The new scheme will probably not be a perfect match for anyone responsible for corporate branding. However, for a presentation it is a definite “winner”. The “quick-and-dirty” here reflects in no means on the quality of the programming (I should know, I wrote it), nor on the quality of the algorithm (I should know, the best HTML crack in our group did it). It reflects more on the scope of the solution, and the constraints that are imposed by the route we choose. This work was not done as part of any development plan, but is more the fruits of “having some fun” over a lunch hour or ten. As the tool is deemed to have value for a large group of people, the official decision has been made to ship it. The tool was developed on WebAS, as we had many requirements from consultants that wanted to enhance their presentations at customers, and did not have the space on their laptops for also running an EP6. As they usually have already a mini WebAS running, we decided to reuse this infrastructure. The small print: This tool has a number of constrains. The use of the tool implies also the acceptance of these limitations. Throughout the rest of this weblog, please read these “small print” sections very carefully. Support for the tool will be provided via OSS on queue BC-BSP on a “best effort” basis only. Which means we will do everything possible to keep it running smoothly, but there are no guarantees that we can support this indefinitely. h2. The First Three Minutes One picture should be enough to tell the true story. Allow us two to get it perfectly right. The first picture shows the same BSP application with different predefined themes. These themes we defined to quickly show the effects of applying a new theme to a BSP application. 
The second picture shows the complete (yes, that is it!) theme editor. Effectively, you define five new colours from which the complete theme is then generated. If the corporate branding colours are already defined, then just plug them into the editor and press the preview button. 
What the editor does, is on the fly generate new CSS files, as well as hundreds on new GIF images in exactly the right colors. Two interesting ideas flowed into this theme editor. The first is that a few basic colors are sufficient to specify the complete theme. The second is that it is possible even with ABAP to generate all the MIME objects on the fly as they are requested without a noticeable speed hit. We even parse and patch each GIF file that is used within the theme during the usual load process. h2. How Does Customisation Normally Work? The normal process for customizing a theme is to use the tools provided by EP6. These tools provide the complete freedom to change all different aspects of the theme. This might be important for corporate branding purposes. However, to get an initial theme running is already a lot of work. For example, typical steps include that all GIF images (over 300 per theme!) be touched (loaded into a bitmap editor individually!) to set their colours correctly. Even a first version can take hours to get up and running. What the theme editor in EP6 does, is to store all customer settings as metadata, and not directly in the CSS files. Thereafter, in a generation step, the actual required CSS files are created. This is important for handling upgrade situations. When the SAP ships new rendering classes, the information required for the CSS files are also shipped only in metadata form. This is mixed with the old theme settings, and then new CSS files are generated at runtime. Our first constraint was to have a solution that will “survive” a new service pack. The small print: The solution described here generated new themes on the fly. They are never stored in any database, but only cached (both server and browser). After an upgrade, the BSP runtime will load the CSS files with a new version number. This bypasses the cache, causing the CSS files to be loaded (and patched) again. What this implies, is that we do NOT store any generated theme in the MIME repository. The goal of this project was never to replace the theme editor already available in EP6. As such, this approach attempts only a quick approximation of the results, which should be sufficient for showing an application to a customer in the “correct” colour scheme. If fine-tuning of a theme is required, this must still be done with the usual EP6 theme editor. The small print: This work (and the weblog) does NOT show the actual integration into the EP6 theme editor. If there is interest, it can be described in a second weblog. h2. A New Theme from Five Colours The heart of the approach is simplicity. Instead of asking the user to configure and edit all colours, we wanted to have one colour: blue for SAP, etc. Just give us the base colour, and we do the rest. In the end, it turns out that five colours are required and sufficient: one background colour, two branding colours and two selection colours. What we did, was to manually analyse all style classes for all SAP base themes. From this, we grouped relevant classes together, and determined heuristics of how the colours are used in the base themes. Specifically, we calculate the “distance” of a specific colour from the base colour of the theme. Then, given the five new colours, we apply the same “distance” to the base colours to have the data for the new theme. The other important aspect, is the template theme from which the new theme should be generated. SAP ships today standard five themes. Each theme is different in metrics (padding, font sizes, margins) and also different in the spectrum of colors used. The “distances” between the different colours and the base colour is an important aspect of the theme used as template. For example, typically the high-contrast themes group colours more together at two extremes, achieving the required contrast on screen. Today, SAP sets as default theme “Tradeshow”, and it is recommended to use this as template for most cases. The small print: This theme editor _only_ works with design2003! h2. Integration into WebAS The biggest constrain for us was that the new theme must be upgrade save as much as possible. The first approach we took was to update all CSS and GIF files, and store them in the MIME repository. However, this takes a very long time to generate, and had the side effect that we had to patch resources that might not even be needed. The bigger problem was that we had no hooks to update the mime repository after a new service pack was applied. The route that we then took was to write a new HTTP handler (BSP In-Depth: Writing an HTTP Handler). This handler will intercept all requests to mime objects. Once it detects that a customized object is required, the handler will load the mime object, patch it, and then send it out to the browser. Typically, the time it takes to load a mime object far exceeds the time required to quickly patch the colours in flight. As a last step, the mimes are cached for 7 days in both the server and browser cache. This works, as the BSP runtime was changed in the latest service packs to load all mimes with a version number. Once a service pack is installed, the version number changes, and the mimes will be loaded new. With the caching, the performance of this “patch on the fly” solution is blazing fast. The small print: when using this handler on lower service pack levels, it is recommended to reduce the cache time back to one hour. This might negatively impact overall performance. Only with 620SP54 and 640SP13 will the caching automatically be updated to 7 days. The first question/problem we had, was where to store the new colour information required. Initial approaches always placed thisbasic colour data in the database. However, we set the browser caching 7 days. Once a colour was changed, the browser would not know, nor request the update files until at the end of the seven days. After calculating many days, we realized that 5 colours is only 30 bytes! We added this directly into the URL! For example, for the “Bisque” theme shown above, the theme root was set to: /sap/public/bc/ur/design2002/themes/~alfs~1000202FFE4C43B2D1B7D674EDAA520565656 Here we have encoded inside the URL the template to use (one byte), the font family to use (one byte with lookup table) and then the 30 bytes for the 5 colours. The big win was that any minor change in the theme resulted in a change of the generated URL, which effectively implied new objects that were not already in the cache. Thus, the complete theme is loaded on the fly again. The other benefit was that it was now possible to have hundreds of themes active in parallel, without writing them into the MIME repository. This was especially important when testing to find the right colour combination. All the different tests with minor colour changes has different URLs, thus keeping the cache content consistent for each test run, allowing one to quickly compare the different themes. The small print: The solution adds about 50 bytes per roundtrip to the complete rendered overhead. We did experiment with using a base64 encoding on the colour values to reduce the overhead with about 20 bytes, but is was not really worth the effort. In slightly more detail: design 2003 mime resources are loaded via the path /sap/public/bc/ur/design2002/themes/sap_tradeshow/.… On this path there is already one HTTP handler installed. What we did, was to write a new HTTP handler that is chained into this path. The new handler is called first. It looks at the incoming URL to search for its signature “~alfs~”. If the signature is found, the correct MIME is loaded, patched (with the colour information from the URL), and the response is written (with caching). All other systems requesting the same resource will be served from the ICM cache, thus making the patch work a once-off process. Should the URL not contain the correct signature, the handler will just signal that it did not handle the incoming HTTP request, and the usual MIME repository handler is then scheduled.
h2. The Source Code: Making It Work See note 850851, ALFS: ABAP (Quick and Dirty) Look and Feel Service, for the complete source. A ZIP file with the source code is attached to the note. This can be manually installed on any system. Officially, the code will ship with 620SP54, 640SP13 and 700SP03. No “Note Assisted” corrections are provided for this solution. Keep in mind that it is very much work developed under the SDN flag, and now just made available. Furthermore, a few manual steps would have been required in anycase. To install the code, create a new class, and add the interface IF_HTTP_EXTENSION. Paste the following code into the HANDLE_REQUEST method: METHOD if_http_extension~handle_request. TRY. server->transactional = if_http_server=>co_enabled. if_http_extension~flow_rc = if_http_extension=>co_flow_ok_others_mand. IF server->request->get_header_field( if_http_header_fields_sap=>path_info ) CS '~alfs~'. lcl_alfs=>handle_request( server ). if_http_extension~flow_rc = if_http_extension=>co_flow_ok. ENDIF. CATCH cx_root. ENDTRY. ENDMETHOD. All that this code does is quickly check for the ALFS signature. Once found, all further processing is done in local classes. Observe the setting of the flow_rc variable to signal whether the HTTP request has been handled or not. In a next step, edit both the CCDEF (button
) and CCIMPL (button 
) sections of this class. Paste the complete source from the note into the corresponding sections. Save and activate the class. Keep in mind that the code is slightly different between 620 and 640. As a last step, start transaction SICF. Find the node /sap/public/bc/ur and edit it. Add the new handler class to the list of handler classes. 
The second picture shows the complete (yes, that is it!) theme editor. Effectively, you define five new colours from which the complete theme is then generated. If the corporate branding colours are already defined, then just plug them into the editor and press the preview button. What the editor does, is on the fly generate new CSS files, as well as hundreds on new GIF images in exactly the right colors. Two interesting ideas flowed into this theme editor. The first is that a few basic colors are sufficient to specify the complete theme. The second is that it is possible even with ABAP to generate all the MIME objects on the fly as they are requested without a noticeable speed hit. We even parse and patch each GIF file that is used within the theme during the usual load process. h2. How Does Customisation Normally Work? The normal process for customizing a theme is to use the tools provided by EP6. These tools provide the complete freedom to change all different aspects of the theme. This might be important for corporate branding purposes. However, to get an initial theme running is already a lot of work. For example, typical steps include that all GIF images (over 300 per theme!) be touched (loaded into a bitmap editor individually!) to set their colours correctly. Even a first version can take hours to get up and running. What the theme editor in EP6 does, is to store all customer settings as metadata, and not directly in the CSS files. Thereafter, in a generation step, the actual required CSS files are created. This is important for handling upgrade situations. When the SAP ships new rendering classes, the information required for the CSS files are also shipped only in metadata form. This is mixed with the old theme settings, and then new CSS files are generated at runtime. Our first constraint was to have a solution that will “survive” a new service pack. The small print: The solution described here generated new themes on the fly. They are never stored in any database, but only cached (both server and browser). After an upgrade, the BSP runtime will load the CSS files with a new version number. This bypasses the cache, causing the CSS files to be loaded (and patched) again. What this implies, is that we do NOT store any generated theme in the MIME repository. The goal of this project was never to replace the theme editor already available in EP6. As such, this approach attempts only a quick approximation of the results, which should be sufficient for showing an application to a customer in the “correct” colour scheme. If fine-tuning of a theme is required, this must still be done with the usual EP6 theme editor. The small print: This work (and the weblog) does NOT show the actual integration into the EP6 theme editor. If there is interest, it can be described in a second weblog. h2. A New Theme from Five Colours The heart of the approach is simplicity. Instead of asking the user to configure and edit all colours, we wanted to have one colour: blue for SAP, etc. Just give us the base colour, and we do the rest. In the end, it turns out that five colours are required and sufficient: one background colour, two branding colours and two selection colours. What we did, was to manually analyse all style classes for all SAP base themes. From this, we grouped relevant classes together, and determined heuristics of how the colours are used in the base themes. Specifically, we calculate the “distance” of a specific colour from the base colour of the theme. Then, given the five new colours, we apply the same “distance” to the base colours to have the data for the new theme. The other important aspect, is the template theme from which the new theme should be generated. SAP ships today standard five themes. Each theme is different in metrics (padding, font sizes, margins) and also different in the spectrum of colors used. The “distances” between the different colours and the base colour is an important aspect of the theme used as template. For example, typically the high-contrast themes group colours more together at two extremes, achieving the required contrast on screen. Today, SAP sets as default theme “Tradeshow”, and it is recommended to use this as template for most cases. The small print: This theme editor _only_ works with design2003! h2. Integration into WebAS The biggest constrain for us was that the new theme must be upgrade save as much as possible. The first approach we took was to update all CSS and GIF files, and store them in the MIME repository. However, this takes a very long time to generate, and had the side effect that we had to patch resources that might not even be needed. The bigger problem was that we had no hooks to update the mime repository after a new service pack was applied. The route that we then took was to write a new HTTP handler (BSP In-Depth: Writing an HTTP Handler). This handler will intercept all requests to mime objects. Once it detects that a customized object is required, the handler will load the mime object, patch it, and then send it out to the browser. Typically, the time it takes to load a mime object far exceeds the time required to quickly patch the colours in flight. As a last step, the mimes are cached for 7 days in both the server and browser cache. This works, as the BSP runtime was changed in the latest service packs to load all mimes with a version number. Once a service pack is installed, the version number changes, and the mimes will be loaded new. With the caching, the performance of this “patch on the fly” solution is blazing fast. The small print: when using this handler on lower service pack levels, it is recommended to reduce the cache time back to one hour. This might negatively impact overall performance. Only with 620SP54 and 640SP13 will the caching automatically be updated to 7 days. The first question/problem we had, was where to store the new colour information required. Initial approaches always placed thisbasic colour data in the database. However, we set the browser caching 7 days. Once a colour was changed, the browser would not know, nor request the update files until at the end of the seven days. After calculating many days, we realized that 5 colours is only 30 bytes! We added this directly into the URL! For example, for the “Bisque” theme shown above, the theme root was set to: /sap/public/bc/ur/design2002/themes/~alfs~1000202FFE4C43B2D1B7D674EDAA520565656 Here we have encoded inside the URL the template to use (one byte), the font family to use (one byte with lookup table) and then the 30 bytes for the 5 colours. The big win was that any minor change in the theme resulted in a change of the generated URL, which effectively implied new objects that were not already in the cache. Thus, the complete theme is loaded on the fly again. The other benefit was that it was now possible to have hundreds of themes active in parallel, without writing them into the MIME repository. This was especially important when testing to find the right colour combination. All the different tests with minor colour changes has different URLs, thus keeping the cache content consistent for each test run, allowing one to quickly compare the different themes. The small print: The solution adds about 50 bytes per roundtrip to the complete rendered overhead. We did experiment with using a base64 encoding on the colour values to reduce the overhead with about 20 bytes, but is was not really worth the effort. In slightly more detail: design 2003 mime resources are loaded via the path /sap/public/bc/ur/design2002/themes/sap_tradeshow/.… On this path there is already one HTTP handler installed. What we did, was to write a new HTTP handler that is chained into this path. The new handler is called first. It looks at the incoming URL to search for its signature “~alfs~”. If the signature is found, the correct MIME is loaded, patched (with the colour information from the URL), and the response is written (with caching). All other systems requesting the same resource will be served from the ICM cache, thus making the patch work a once-off process. Should the URL not contain the correct signature, the handler will just signal that it did not handle the incoming HTTP request, and the usual MIME repository handler is then scheduled.h2. The Source Code: Making It Work See note 850851, ALFS: ABAP (Quick and Dirty) Look and Feel Service, for the complete source. A ZIP file with the source code is attached to the note. This can be manually installed on any system. Officially, the code will ship with 620SP54, 640SP13 and 700SP03. No “Note Assisted” corrections are provided for this solution. Keep in mind that it is very much work developed under the SDN flag, and now just made available. Furthermore, a few manual steps would have been required in anycase. To install the code, create a new class, and add the interface IF_HTTP_EXTENSION. Paste the following code into the HANDLE_REQUEST method: METHOD if_http_extension~handle_request. TRY. server->transactional = if_http_server=>co_enabled. if_http_extension~flow_rc = if_http_extension=>co_flow_ok_others_mand. IF server->request->get_header_field( if_http_header_fields_sap=>path_info ) CS '~alfs~'. lcl_alfs=>handle_request( server ). if_http_extension~flow_rc = if_http_extension=>co_flow_ok. ENDIF. CATCH cx_root. ENDTRY. ENDMETHOD. All that this code does is quickly check for the ALFS signature. Once found, all further processing is done in local classes. Observe the setting of the flow_rc variable to signal whether the HTTP request has been handled or not. In a next step, edit both the CCDEF (button
) and CCIMPL (button ) sections of this class. Paste the complete source from the note into the corresponding sections. Save and activate the class. Keep in mind that the code is slightly different between 620 and 640. As a last step, start transaction SICF. Find the node /sap/public/bc/ur and edit it. Add the new handler class to the list of handler classes.
3 Comments
