You can use different components of SAP NetWeaver Composition Environment (CE) 7.2 to create a mobile sales solution. My example was built for a worldwide distributor of electronic, electrical, and industrial components. The company was looking for a low-cost, tactical solution that could be rapidly implemented to give its Europe-wide sales force remote access to the data held within the back-end SAP Customer Relationship Management (SAP CRM), SAP ERP, and SAP NetWeaver Business Warehouse (SAP NetWeaver BW) systems. The solution needed to work for desktops and the Apple iPhone 4.

I’ll discuss the overall architecture along with the design decisions we made during the implementation. Then I’ll walk through an in-depth description of the integration between the iPhone and the SAP technology. I’ll also describe in detail how the GPS and Google Maps integration was built. Figure 1 shows a screenprint of the application running within the iPhone iOS operating system. I also cover the integration between the SAP CRM contact data and the telephone and SMS capability of the phone.

Figure 1

Google Maps integration

Solution Overview 

SAP NetWeaver CE 7.2 was an obvious choice for delivering the field sales functionality. It can provide the service composition required on the back-end systems as well as options for the user interface (UI) on the phone and desktop. An SAP NetWeaver CE-based solution can be rapidly implemented to meet the challenging timelines on the project.

The solution we implemented is broken down into layers. The UI layer is separate from the business services layer, which in turn is separate from the back-end services layer. The layered architecture enables the developer to replace individual layers, should a business requirement arise. For example, at a later date, a new and innovative UI may become available. You can easily plug the new UI into the solution because the UI layer is separate from the business services layer. The whole application does not need to be redeveloped. Equally, if the company upgrades the back-end SAP systems, the business services and UI layers do not need to be redeveloped. Figure 2 is a graphical representation of the different layers within the application.

Figure 2

Architecture of the iPhone solution

Architecture — Data Services 

The lowest-level services within the application are those written on the back-end SAP CRM, SAP NetWeaver BW, and SAP ERP systems. These back-end systems are accessed through a series of standard and custom services written as Remote Function Calls (RFCs).

The RFCs are consumed by Composite Application Framework (CAF) services composed using the CAF RFC import wizard. The wizard creates a Java wrapper around the RFC and creates a deployable CAF service. The resulting service is a duplicate of the SAP RFC where the operation name matches the RFC name and all input and output parameters match the names from the RFC.

While the wizard is quick and easy to use, the results are RFC focused, meaning the CAF services have SAP operation names and SAP input and output parameters. These services could be called on by any consumer; best practice states that the consumer should not need an understanding of SAP field names to use the service.

If the UI layer consumes this RFC-focused service then the UI is directly tied to the underlying RFC. If the RFC were to change or be replaced, the CAF service and the UI layer would both need to be changed.

The addition of a business-focused CAF service layer provides the required level of separation. The business-focused CAF services provide the mapping between SAP and business nomenclature. All input and output parameters are English names and are business relevant. For example, SAP’s material field is MATNR so the RFC-focused CAF service has a parameter called MATNR. The business-focused CAF service has a parameter called Article and the service provides a mapping between MATNR and the Article parameter.

This way, when the business service is deployed, it is not SAP specific. If the underlying RFC changes, the interface to the business service remains constant and the UI layer does not need to be changed.

Architecture — UI 

The UI layer is provided by Web Dynpro for Java running on SAP NetWeaver CE. We chose Web Dynpro because this is a tactical solution that needed to be quick to develop. We did not wish to spend our development time designing buttons, table controls, and input fields that work on both an iPhone and a desktop browser. Web Dynpro’s model-driven development framework allows the UI developer to concentrate on functionality rather than the minutiae of UI design. We were also keen to push the boundaries of Web Dynpro development to use some of the new UI elements introduced with SAP NetWeaver CE 7.2.

UI Functionality 

We designed the Web Dynpro screens to work within the resolution constraints of the iPhone screen (Figure 3). The screen layout depends on the quantity of data that the screen needed to display. The majority of the screens were designed with portrait mode in mind. Some screens have tabular data, which is better displayed in landscape mode (Figure 4). The transition between portrait and landscape mode is controlled by the built-in accelerator on the phone. As the user rotates the phone, the layout switches from portrait to landscape and vice versa.

Figure 3

Portrait mode of the screen running on the iPhone

Figure 4

Landscape mode of the screen running on the iPhone

Telephone, SMS, and Email Integration

The user can drill down through a screen with a list of customers to get a list of customer contacts. Each row in the list contains the data for a single contact from SAP CRM. The data includes name, job, phone number, and email address. You can select each contact and the user has the ability to phone, SMS, or email the contact by clicking a hyperlink. Figure 5 shows this functionality.

Figure 5

Part of the contacts screen demonstrating WebWidget content

In previous releases of Web Dynpro, the developer was restricted to only using Web Dynpro UI elements. Web Dynpro running in SAP NetWeaver CE 7.2 has new UI elements such as Adobe Flash islands, Microsoft Silverlight islands, and WebWidgets to help the UI developer integrate other Web technologies.

The WebWidget UI element is one of the new UI elements within SAP NetWeaver CE 7.2. A WebWidget is a generic SAP UI element that enables the developer to build in snippets of HTML layout and code within a Web Dynpro view. The HTML within the WebWidget can be dynamic so that at runtime the WebWidget’s content can be controlled by the Web Dynpro framework. We used a WebWidget to provide telephone, email, and SMS text integration between Web Dynpro and the iPhone.

The WebWidget is a simple UI element with only a few attributes. The HTML attribute is used to link to a context attribute of type String containing the HTML source. In this example, the table of contacts has a row selection event. This event is used to build up the HTML string based on the data values of the selected contact. The line of code in the Web Dynpro action is shown in Figure 6.

Figure 6

Web Dynpro action code

The HTML elements used for SMS and phone calls are a little-known extension of the HTML <A> anchor tag. Most HTML developers are familiar with the mailto: Universal Resource Identifier (URI) scheme, which triggers the client email program to create an email (Figure 7).

Figure 7

Scheme to create an email

The telephone URI scheme tel: and SMS scheme sms: are more recent additions. Mobile browsers such as those used on the iPhone and Android phones support these protocols. If a number is provided in conjunction with the tel: or sms: protocol, then the iPhone browser asks the user if they want to call or SMS that number. The body of the SMS or email can even be specified by using an extension to the URI scheme:

Figure 8

URI scheme extension

GPS and Google Maps Integration

One of the most innovative and challenging features we had to build was the interactive map of customer locations. The application needed to interact with the GPS on the iPhone to get the current location. It then needed to use this information to work out the 10 nearest customers to the current location. These customers then had to be rendered on an interactive Google map.

The end-to-end solution is split up into a number of different challenges. Each of these challenges is described in a separate section below.

Geo-Location and Distance Calculation

The first task was to calculate the latitude and longitude (called geo-coding) of each customer within the back-end system. Google provides a well-documented application programming interface (API) for calling the Google geo-coding-related Web services. These Web services return a latitude and longitude for any given address.

We created an SAP NetWeaver CE-based CAF service to handle the call to the geo-coding Web services. The input parameters were a customer address. The service calls a Web service (hosted by Google) that converts the address into a latitude and longitude. The CAF service then returns this location information to the calling program. The CAF service was executed by the SAP CRM system for each of the customers in the SAP CRM customer master. These values were stored in custom fields within the SAP CRM back-end system.

Once all customers had a latitude and longitude, then it was relatively straightforward to write an RFC and accompanying CAF service to pass back the 10 nearest customers for any given latitude and longitude. The calculation to determine which was nearest requires a measure of distance to be calculated from one geo-location to another. We used the haversine formula to calculate the great circle distance between each position. This provides an as-the-crow-flies distance over the earth’s surface and ignores the effects of altitude.

Integrating with the GPS

The next challenge is to integrate with the GPS on the iPhone. Most modern browsers support the JavaScript API for determining the current location via a GPS. The iPhone 4 uses the Safari browser and fully supports this functionality. The JavaScript code shown in Figure 9 determines the browser’s current physical location via the built-in GPS.

Figure 9

JavaScript code for the browser’s location

When the script is executed on the iPhone, the user is prompted to allow the JavaScript routine to execute because it could be a security risk allowing unauthorized scripts to access the phone’s built-in features. If the user allows the location to be calculated, the latitude and longitude are immediately returned within the above method.

Interaction Between JavaScript and Web Dynpro

The next challenge is Web Dynpro’s lack of support for JavaScript coding within its view framework. As Web Dynpro has a fixed suite of UI elements, native JavaScript is not supported.

The solution is to build a simple HTML Web page containing the JavaScript and store it within the Web Dynpro project as a MIME object. Figure 10 shows the HTML pages within the Web Dynpro project. The HTML pages were created using SAP NetWeaver Developer Studio, but instead of using the Web Dynpro Explorer view, I switched to the Navigator view. This allows a view on all files within a Web Dynpro project. I then used SAP NetWeaver Developer Studio’s own internal text editor to create the HTML files.

Figure 10

The Web pages within the Web Dynpro project

The HTML page is then integrated into a Web Dynpro view via an iFrame UI element. The iFrame allows external HTML content to be displayed within a view. The iFrame UI element has a parameter called URL, which contains the Web resource that will be rendered within the frame.

Once the latitude and longitude have been determined in the JavaScript, the values need to be passed back into the Web Dynpro context. The iFrame is isolated from the surrounding Web Dynpro view so data communication between the HTML page and the parent Web Dynpro is not possible. You can solve the data transfer issue by having the simple HTML page redirect itself to run another Web Dynpro.

Once the latitude and longitude are calculated, a URL is programmatically built up at runtime by the JavaScript within the HTML page. This URL executes another Web Dynpro. The URL doesn’t just run the Web Dynpro, it also contains name-value pairs that are used to pass the geo-location into the destination Web Dynpro context. The code in Figure 11 is from the HTML page and shows how the URL is constructed:

Figure 11

Code for passing geo-location into Web Dynpro

The newly executed Web Dynpro must then handle the two name-value pairs during start-up.

The name-value pairs are passed in as parameters into the start-up plug automatically. The parameters need to be added to the start-up plug manually. You can add them by editing the plug in the InterfaceView within the relevant Web Dynpro component. Once added, the values are automatically passed into the handler for the event (Figure 12).

Figure 12

Inbound plugs

When the Web Dynpro is executed, the name-value pairs are passed in from the calling URL and stored in the context. The Web Dynpro then calls the CAF service to get the 10 nearest customers to the given latitude and longitude. The results from the service are displayed in a Web Dynpro table and are also rendered in an interactive Google map.

Google Maps 

Google has a JavaScript API that dynamically builds interactive online maps. The API can create the map, define its width and height, and add points of interest. Once again, as the API is JavaScript based, an HTML Web page is needed to hold the required JavaScript to create the interactive map. An iFrame is used to hold the HTML page within the view. Figure 13 shows the layout of the view.

Figure 13

Web Dynpro view containing table of data and iFrame for Google Maps

URL name-value pairs are again used to transfer data between the two parts of the view. This time, the Web Dynpro builds the URL for the HTML page and appends the name-value pairs containing the location data. The HTML in Figure 14 takes the latitude and longitude values and renders them as an interactive Google map.

Figure 14

HTML for Google Maps

The end result is a table of customer data and a linked interactive Google map with each of the customers highlighted as a point of interest, as shown in Figure 1. The user can zoom in and out, and switch to different map types including street view.

Richard Tucker

Richard Tucker joined Atos Origin as an ABAP consultant in 1998. He quickly recognized SAP Web development as an emerging market and was instrumental in building Atos Origin’s SAP Web development capability. He has successfully implemented all SAP Web technologies for the last 10 years for numerous customers. Since 2005, he has concentrated on Web Dynpro implementations, with a long track record in building successful component-based applications. This track record was the basis for his well-received SAP TechEd 2007 presentation on behalf of SDN.

Atos Origin is an international information technology services company with 50,000 employees in 40 countries. Its business is turning client vision into results through the application of consulting, systems integration, and managed operations. Atos Origin is the Worldwide Information Technology Partner for the Olympic Games and has a client base of international blue-chip companies across all sectors. Atos Origin is the 2007 Winner of the SAP Partner Excellence Award for Customer Satisfaction and Quality Performance for a third consecutive year.

You may contact the author at richard.tucker@atosorigin.com.

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