Long-Term Support of Rich Internet Applications: What You Need to Know to Be Successful

Tom Leddy, Principal Engineer, SAP CRM, OfficeMax

Abstract

Understand the pros and cons of using a Rich Internet Application (RIA). See what’s involved with enhancing

these applications and fixing issues when they arise after the initial rollout.

[end abstract]

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 [subhead 1]

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 [subhead 1]

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 [subhead 2]

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 [subhead 2]

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 [subhead 1]

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 [subhead 1]

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 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.

To contact the author, click here: Tom Leddy. You can also follow him on Twitter: @tomruns_262. If you

have comments about this article or CRM Expert, or would like to submit an article idea, please contact Antoine

Cadot-Wood, the CRM Expert editor.