Rich Internet Applications (RIAs) are becoming increasingly popular as an alternative to the standard SAP CRM WebUI. This is because there are several advantages to using these applications, such as an improved look and feel for a better user experience and the ability to add additional features that aren’t readily available through standard SAP systems.

However, there are also some challenges that come with supporting these applications and adding additional enhancements or bug fixes to them after their initial rollout. I’ve been working with RIAs as a front end to an SAP CRM system for the past year and have developed some tips to help ensure that if you go down the path of creating an alternative user interface for an SAP CRM system, you’ll have a better chance of both immediate and long-term success.

Rich Internet Application Overview

For anyone not familiar with the term, an RIA is a Web-based application that functions in a way that is similar to a regular desktop application. RIAs are typically delivered to users through a browser that has a plug-in installed that supports the platform (although in some cases they can also be deployed directly to a user’s machine and be run locally). Some common platforms for RIA development are Adobe Flex, Microsoft Silverlight, and JavaFX.

For SAP CRM (or any SAP system), an RIA provides a different front end that can be designed to give users an experience that’s different from any of the standard SAP user interfaces (such as CRM WebUI, SAP GUI, or SAP NetWeaver Portal). An RIA can update and retrieve data from an SAP system in real time by calling custom Remote Function Calls (RFCs). The RFCs then call standard SAP function modules to write to and read from the database. RIAs can either be used in conjunction with other SAP user interfaces or used separately so that end users never actually see an SAP screen. They can also be embedded into corporate Web sites, intranet sites, or portals. Figure 1 is an example screen from an RIA. It shows a sales rep’s dashboard that wouldn’t be readily available in the standard Sales Force Automation views in the CRM WebUI.

Figure 1

An example RIA screen

Comparison of RIAs vs. the CRM WebUI

Using RIA front ends and using the SAP CRM WebUI both have their respective advantages and drawbacks, which you should consider carefully when deciding which to use. The pros and cons of each are detailed below.

Pros of RIAs

When the SAP CRM WebUI was first released, it offered major improvements over using SAP GUI for transactional data entry. One of the biggest benefits of the WebUI is that it’s fairly easy to customize. However, even with the WebUI, there are still some types of enhancements that are extremely difficult to make. With so many competing CRM tools in the marketplace, some users who have previous experience with other systems are going to expect functionality in their CRM tool that isn’t readily available in SAP CRM.

For example, prior to SAP CRM 7.0, enhancement package 1, there was an issue in the Customer Interaction Center that meant users could only handle one interaction at a time. Allowing call center agents to accept a phone call at the same time that they were working on an email and multiple chats wasn’t possible. There are ways to do this with a standard SAP system now. However, if you’re using an earlier version but have a business requirement to allow agents to handle multiple forms of incoming communication simultaneously, RIAs might give you additional ways to overcome such a limitation. Our application bypasses the Computer Telephony Integration (CTI) component of SAP CRM and communicates directly with the Avaya server by calling methods in a .dll file. There is no CTI configuration in the SAP CRM system at all. Our CTI toolbar functions the same way as if an agent were using the Avaya Interaction Center program directly and the concept of session handling is taken out of the picture.

One of the projects I worked on had a requirement that one of the screens needed to have multiple controls (such as text boxes, dropdowns, or text areas). The control types, layout, and properties such as whether or not they’re enabled, and whether or not they’re required, all needed to change dynamically based on the values selected in two dropdowns. All of this had to be accomplished without having the entire screen refresh each time a selection was changed. The entire screen needed to be configurable.

Technically if you can find a really talented WebUI developer, there are ways to do this with standard SAP functionality. However, with an RIA, you can do this more elegantly. RIAs can also include charts, graphs, and other options that aren’t readily available in the standard SAP CRM WebUI (again, a talented enough developer can add these things but there are some hurdles compared to using a platform that already has them built in). A single RIA can call RFCs in multiple back-end systems, including non-SAP systems, creating a seamless overall experience for users who would like to have a single location to enter all their data.

Pros of the Web UI

While there are a lot of benefits to using RIAs, the standard SAP CRM WebUI has its own benefits. The main one is that it’s standard SAP functionality and easily configurable. The WebUI is also supported by SAP whereas any RIA development isn’t, because an RIA is an external application that exchanges data with the database by calling custom RFCs that are developed in ABAP. If there’s an issue with one of these RFCs, there is almost never an SAP Note that can be applied to fix the issue. It is up to an ABAP developer to determine the root cause and make the appropriate code changes.

Additionally, enhancements and bug fixes are complicated by the fact that in certain cases you can no longer just use the transport path to make changes to the application. As I mentioned earlier, an RIA sends data to the SAP system that it’s connected to through RFCs. Each RFC contains a set of input and output parameters that are used to pass the necessary values back and forth.

If one of these parameters changes, or if a parameter is added or removed, an equivalent change needs to be made in the RIA. The application needs to be recompiled and the new build has to be scheduled to be pushed out to the users at the exact same time that the transports are moved into the target system. Otherwise, users attempting to access the functionality that was changed get an error from which they most likely won’t be able to recover.

Furthermore, one of the most convenient aspects of making changes to the WebUI is that when they get moved into production, there is no additional action required by the users – whatever screen changes were made are visible and functional to each user the next time they access the view that was modified. With an RIA, on the other hand, once the changes have been made and a new build has been deployed, depending on the specific type of changes that have been made, users may need to reboot their machines altogether instead of simply logging out and back into the application as they can with the WebUI.

Lastly, the WebUI comes pre-built with all the standard SAP functionality. Prior to implementing it, a functional analyst can go through the configuration and turn off the features that aren’t needed. Then if the business later decides to add additional functionality, the configuration can be changed to add this functionality back in. All the views will already be built and just waiting to be used. Furthermore, with proper training, even a business analyst can make certain types of changes to the WebUI without the involvement of any technical resources.

With an RIA, on the other hand, the process is to determine the initial business requirements and then build a front-end application that specifically meets those requirements. If requirements come up later to add any additional functionality, it’s not a simple matter of just turning on some new features.

Either the existing application needs to be modified by a developer to add new screens with the new functionality or a new application needs to be written altogether. There is no way that a business analyst can make any of these changes on their own, and while a lot of IT departments have people with SAP skills in house, there’s a good chance that external resources will be required for making changes to an RIA. Over time this can become costly. The total cost of ownership of a WebUI implementation is much lower than that of an RIA.

Long-Term Support of an RIA

In addition to coordinating deployments, one of the other challenges with an RIA is that because the front applications aren’t written in ABAP, any code changes require a different skill set from what ABAP developers traditionally have. Additionally, functional analysts need to take on a slightly more technical role than what they may be used to. Tasks that used to only require a person or group of people with SAP skills now require a second group of people with a separate set of skills, which complicates the deployment process and raises the total cost of ownership.

Some of the functionally that a functional analyst usually controls through WebUI configuration now must be done by a developer. A functional analyst often needs to develop specifications for enhancements that include changes that need to be made by both the ABAP and UI development teams and then act as a go-between to make sure that both sides of the application are developed correctly.

Tips and Tricks

The main piece of advice that I would give to anyone considering an SAP CRM solution that includes RIA is to research what’s available and make sure that you’re using the right tool for the job. The downsides of using an RIA are that changes require additional effort from a group of individuals whose skill set is different from that of a traditional SAP developer. You therefore need to make an extra effort to coordinate changes. The upside is that you can develop a completely customized front end that makes your users more efficient and even introduce additional functionality that’s not available or would be very difficult to implement with standard SAP. Depending on what kind of results you want and what your plan and budget are for long-term support, you should make sure to choose the correct solution.

Any organization that plans on using an RIA would want to either hire a full-time team of developers who have experience in the language in which the RIA is being developed or build relationships with contractors who have the skills so that when it’s time to make future enhancements, the resources required are readily available. We currently have three Adobe Flex developers but may be adding more in the future as we roll out more functionality. The number of resources needed depends on the implementation.

For long-term support, a process that I’ve been successful with is to set up release cycles and coordinate changes with all the development teams involved. I choose release dates when groups of enhancements and bug fixes can be made at the same time and communicate them to the business. Remember that in a lot of cases, just sending transports into production is not going to be an option anymore because changes need to be coordinated with a new build of the UI application so I try to refrain from doing any one-off fixes except in emergency situations.

Instead we bundle groups of bug fixes and enhancements into groups and release them together. This helps to ensure that you don’t end up in a situation in which our front-end applications are out of synch with the code in the back end, which leads to errors.

Lastly, functional analysts who work with systems that use RIAs benefit from gaining a little technical knowledge. The ability to run an RFC directly in SAP GUI and enter the same input parameters that would have been passed to it from the UI can be a valuable troubleshooting tool. They also gain strong knowledge of how the system works in general as far as exchanging data between the UI and the back end.

Tom Leddy

Tom Leddy is the principal SAP CRM engineer at OfficeMax. He has been working extensively with SAP CRM in various roles since 2004. His primary areas of expertise are Web UI Configuration and Development, Integrating Rich Internet Applications with SAP CRM, Sales, Service, Marketing, and Interaction Center. Tom has a master’s degree in computer science from Governor’s State University.

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