Accessing SAP data from GIS via SAP NetWeaver PI.

More and more, GIS departments in both public and commercial organizations representing a wide variety of industries are finding that the data they create (or consume) is used within (or provided by) enterprise business applications, such as SAP. Integration with other applications is nothing new to GIS practitioners, but these have typically been associated with single-purpose applications, such as outage management system (OMS), CAD, or packaged modeling tools in support of specific operational tasks. Today, GIS is being called upon to support cross-functional enterprise applications aimed at entire business processes.

Often viewed as a financial or enterprise resource planning application, SAP has evolved into a set of integrated applications that deliver the core functionality needed for everything from cross-industry customer relationship management, supply chain management, and enterprise asset management (EAM) to industry-specific functionality in utilities, oil and gas, real estate, retail, defense, and more. Today, much of the attribute data needed to feed GIS applications finds its origin and system of record in SAP master data, created and maintained through transactions supporting wide-ranging business processes.

Getting at that data is a major driver of GIS-SAP integration. But another driver is the unique ability of GIS to model complex spatial relationships difficult to do in hierarchical SAP structures, such as networks. GIS is also well suited to create accurate SAP master data for attributes such as distance or area for use in such activities as design estimates or procurement. Finally, a major driver is that the mapcentric user interface (UI) provided by GIS is more intuitive and easier to navigate than SAP forms and lists, and GIS can execute selection and searches based on spatial relationships that cut across hierarchical data models often used in SAP. Without the ability to realistically relate data, the precision of GIS, its UI, the ability to perform spatial queries and analysis, the quality and accuracy of SAP master data, and the ability to access and use it across business processes are impaired.

Integration Touch Points

Integration with SAP is not much different than the work GIS practitioners have done between GIS and other systems. Typical integration touch points include the data, application, and user interface levels, each of which is described briefly below.

At the data level, the primary concern is to keep the GIS and SAP data synchronized; that is, ensure that, for every SAP business object where a graphic representation is desired, there is a corresponding feature in the GIS database. For example, a utility may wish to have connection objects (such as buildings) and connections (electric, gas, water) represented by features in the GIS but not the individual apartments or meters that are also managed in SAP. The linking of GIS features to SAP business objects is accomplished through foreign-key mapping, which associates the unique ID for each SAP business object with a corresponding GIS feature. Deciding where the two data models should come together and establishing and maintaining these relationships are fundamental requirements for subsequent data access and transaction processing.

At the application level, the focus is on coupling GIS with SAP to create new transactions or better execute existing transactions that use the combined functionality and data from the two systems. The aim is to create some kind of output, which may include updating the underlying data in either system. For example, a network trace in GIS may identify all the related SAP connection objects, followed by a report generated within SAP. Or, an as-built may be posted to the GIS, which automatically updates "Length of line" in the SAP master data.

Impress for GIS from Trinovois GmbH--packaged integration for asset management and CRM.

The user interface level is another primary integration point and generally encompasses GIS-centric, SAP-centric, and composite approaches. In GIS-centric approaches, the map is the main UI, and data from SAP is accessed from the map; the user typically selects features and retrieves SAP data or changes it through standard or custom SAP transactions. SAP-centric approaches generally embed a map within the SAP UI, whether SAP GUI or SAP portal, usually as a separate tab or portlet, respectively. The map UI here typically has fewer GIS functions and tools than a GIS-centric UI but allows feature-based selection and retrieval of SAP data and the initiation of SAP transactions on selected features without leaving the SAP UI. Composite approaches generally refer to applications built using the Web services of both GIS and SAP, and the UI is tailored to specific processes, roles, and tasks with the map providing a central or supporting role, depending on the scenario.

Integration Interfaces

Today, it has never been easier to bring GIS and SAP together to realize the many benefits of integrated systems. In addition to business applications, SAP provides technical applications, tools, and infrastructure that support application development and integration with external systems. It is both a business platform and an IT platform that is well suited to the integration of Esri's open, standards-based GIS. Although, in practice, it is necessary to discuss integration based on specific scenarios, some basic options and methods most commonly used can provide a good starting point.

RFCs and BAPIs

RFC

Early integration between GIS and SAP systems was primarily accomplished by accessing remotely enabled SAP function modules (RFM) using SAP's proprietary Remote Function Call (RFC) protocol. Function modules are reusable units of functionality developed in SAP's proprietary ABAP language and stored in a central repository, with defined interfaces that encapsulate both the data and subroutines for building SAP applications. Remote Function Calls provide external access to the interfaces of remotely enabled function modules.

A problem with RFCs is that they can access functions that are executed elsewhere in the system, where interfaces are not primarily concerned with an external calling application. Consequently, the stability of an RFC is not guaranteed from release to release, leaving it up to the programmer to ensure that SAP updates do not materially change the interface or program code of the RFC and break the integration.

BAPI

With the increased use of the Internet and the necessity for a controlled, standardized, and stable interface for external access to internal SAP functionality, SAP introduced the Business Application Programming Interface (BAPI). BAPIs are implemented as RFMs in SAP and are defined in a Business Object Repository (BOR) as the methods of SAP business objects. To the outside world, SAP business objects reveal only their interface, which consists of a set of clearly defined methods that collectively represent the object's behavior—what it does. Some methods can change the object's internal state, that is, the object's data. Applications can only access the business object data through the object's methods. Programmers can work with SAP business objects and call their methods without having to know anything about the object's underlying implementation details.

BAPIs represent an interface layer that separates a business object's data from the applications and technologies that are used to access it. When updated by SAP, the downward compatibility of the interface and program code is guaranteed whenever possible. Using BAPI Explorer, application developers can get an overview of the status of BAPIs in the BOR.

A very large portion of SAP's functionality is exposed for external development via RFCs and BAPIs. They can be invoked in .NET, Java, C/C++, and other languages, using various free SAP libraries and proprietary connectors or adapters available for Windows, UNIX, and other platforms. The ArcGIS platform and applications are well suited to this environment through strong support for .NET and Java. GIS developers should be familiar with this synchronous function (method) call interface approach. Indeed, most GIS-SAP integration to date has been accomplished using these application programming interfaces (APIs).

Web Services, Enterprise Services, and Partner-Delivered Enterprise Services

With the introduction of SAP NetWeaver, service-oriented architecture and Web services have moved to center stage, both for developing SAP applications and for exposing SAP functionality to external applications. Web services are the preferred technical foundation of enterprise SOA, and SAP makes extensive use of Web services throughout its entire platform.

GISConnex from IMAGEM--packaged integration for utilities.

But not all Web services are created equally, and SAP distinguishes between API-style Web services and enterprise services (ES). API-style Web services simply mirror existing application interfaces (RFC, BAPI) as WSDL markup. Enterprise services, though technically the same, are designed from a business process and consuming application point of view, providing a more business-oriented service description rather than a description only a programmer or another program would understand. They also tend to be coarser grained than API-style Web services, often designed around several underlying fine-grained services to meet a larger business objective. For example, a "Create Installation Point" ES may require a number of lower-level calls to be carried out. Instead of looking for all the required RFCs, BAPIs, or their corresponding API-style Web services, users can build an ES and integrate applications at a more logical and meaningful level to business users and programmers alike. Potential for reuse across processes and with other services is explicitly considered when building an ES, and they leverage business object models and global data types maintained in an Enterprise Services Repository (ESR), further promoting reuse and stability. In short, a lot more thought goes into an ES than an API-style Web service, which can be generated automatically by development tools in most cases.

Partner-delivered enterprise services (PdES) are enterprise services definitions developed by SAP partners like Esri or systems integrators and deliver some business value not available in SAP. However, they are built using the same processes and standards and using the same ESR global data types as SAP-delivered enterprise services. They reside in the ESR as full-fledged citizens ready to be used in application or integration scenarios, and their technical implementation rests with the partner rather than within SAP. Esri was one of the early independent software vendors to build and provision PdES. Over time, SAP expects a wide variety of PdESs to be available, extending the functionality of SAP and reducing the integration costs with external applications like GIS.

Many GIS developers today are familiar with Web services, have used Esri Web services for a wide range of application and integration scenarios, and should not have difficulty using SAP Web services of any kind, because at a technical level, they are no different than any other Web service. They use standard Web protocols, so there is no need to install and learn proprietary connectors, adapters, or other middleware.

So far, we've talked about the various main interfaces available to get at SAP functionality and data. By far, the biggest challenge in GIS-SAP integration is not to learn how to use these interfaces—as they are not very different from what GIS developers have been doing all along—but to understand the breadth of functionality available in SAP and see where GIS can be used to enhance it. Where functionality gaps exist, SAP's NetWeaver platform provides a complete development environment for creating new functionality and exposing it for external consumption, very much in line with the ArcGIS platform.

Main SAP integration approaches.

REST, Flex, AJAX, and Mashups

The Web services described above are "industrial-strength" Web services; that is, they use SOAP and XML for messaging and data transfer and, most often, WSDL for their interface end point. Recently, more "light-duty" approaches have regained popularity and are based on a REST architecture—the architecture of the Web itself. Using Web services typically involves using URLs, XML, and HTTP to model application resources in a similar but less rigorous way as the object-oriented modeling used extensively with the previously described technologies. REST provides a way to define and address specific sources of information, known as resources. For example, a GIS resource may return a list of all connection object features within a geographic extent and work with another SAP resource to get a list of work orders for those features from SAP. The state (data) in the client application changes (transfers) with each resource representation—REST.

Both Esri and SAP support this "RESTful" approach, and resources can often be accessed through JavaScript (JS) and Adobe Flex APIs, which are familiar to many programmers and easy to learn. When used, they eliminate the need for middleware and proprietary connectors because the middleware is built into most modern browsers. Although capable of supporting complex integration scenarios, they have most often been associated with mashups and offer a quick, easy, and inexpensive method of integration.

Integration Approaches

Point-to-Point Integration

To date, the vast majority of integration projects have followed a point-to-point approach. Batch export and import of data is one example, an inexpensive approach to design and implement but hard to maintain in the long run, often requiring significant human involvement. And because it's not a real-time data transfer, its usefulness is limited in many enterprise scenarios. Batch integration can be accomplished via several file formats, through standard or custom APIs, or encapsulated within Web services. Direct access to the SAP database is not allowed for the same reasons that direct access to the enterprise geodatabase is not allowed—SAP applies business rules at the application level to ensure the integrity of the database.

Much of the integraton done to date has been accomplished by accessing SAP functions and data in real time via RFCs and BAPIs via proprietary connectors provided by SAP or third parties following a tightly coupled point-to-point integration pattern, such as using the SAP .NET connector with ArcGIS Desktop. This approach often results in a tightly integrated solution with connector or other dependencies that produce brittle, hard-to-maintain, and poorly scalable solutions. Because of this, integration efforts often begin and end within a very limited organizational and functional scope to solve a pressing local need. At some point, new integration projects stop as resources are used, keeping the old ones running from release to release. Exposing RFCs and BAPIs as Web services eliminates the need for proprietary connectors but does not automatically mean they are well designed Web services or result in loosely coupled integrations.

Mediated Integration

With mediated integration the GIS is hosted on an application server, for example, ArcGIS Server running on a J2EE server. This server hosts the integration-related APIs that connect to ArcGIS Server, proxies connections from ArcGIS Desktop to the SAP server, and hosts the integration-related map viewing applications. Here the integration pattern is server-to-server, with the GIS server communicating directly with the SAP server. No client application talks directly to the other system's server. This approach avoids having "unknown" applications connecting to the back-end SAP system and, if implemented using Web services, offers an efficient, scalable, and maintainable integration.

Another level of mediation introduces middleware that sits between the GIS server and the SAP back-end server. SAP provides an integration platform built as a set of Web services that provides the features of traditional middleware platforms, such as brokers, message buses, and other standard enterprise application integration functions. SAP Web services can be invoked directly or mediated through SAP's process integration component (SAP NetWeaver PI), which provides a services repository for creating and storing service and business process definitions and metadata, as well as a services registry for publishing, classifying, and discovering services. It also includes an enterprise services bus for managing XML messages between internal and external systems, reconciling incompatible schema and data formats between provider and consumer applications and supporting various connectivity options for different end points, such as file, database, Web services, Java Message Service, RFC, and more. Of course, other middleware products can be used as well.

Unlike point-to-point or server-to-server integration that, apart from the business domain knowledge, is already familiar to GIS developers, mediated integration using middleware most often is not. Its message-based orientation introduces a different programming model, and the complexity of the platform can be overwhelming (and its performance underwhelming if used for all integration scenarios). Although generally more expensive than point-to-point or server-to-server solutions for an individual project, properly used middleware approaches promote loosely coupled integrations, are well suited to heterogeneous environments, and provide unique opportunities to bring GIS to the enterprise. Learning about it should be at the top of all GIS developers' to-do lists if SAP is part of their business and IT landscape.

Packaged Integration

By far, the majority of integrations between GIS and SAP to date have been developed by in-house teams or systems integrators using a variety of the technologies and approaches described above. Recently, independent software vendors have begun to offer packaged integrations for specific industries, SAP applications, and business processes, most notably around EAM. These solutions either are built using some combination of SAP and proprietary technology or may be based entirely on the SAP platform. Solutions are available today from trinovis (www.impress.com), IMAGEM (www.gisconnex.com), and AED-SICAD (www.aed-sicad.com). They offer an alternative to 100 percent custom development; are typically certified to run on the SAP platform; and have ongoing support, technical and functional upgrades, and training programs.

Bringing It All Together

To many GIS practitioners, SAP may well be a mysterious, big black box; however, they should see by now that its external interfaces and means of invoking and using them are not mysterious, and most GIS developers are familiar with them. GIS professionals should focus on learning the major functionality components of SAP, the business processes supported, and the data stored within its boundaries. The seeds of integration ideas and projects lie there.

We've discussed many technical integration options and approaches, and it should be recognized that rarely is a single option or approach used within the context of a single organization, or even a single integration project. Specific scenarios drive the selection. Also, many large organizations may have non-SAP adapters and middleware that can be used in a manner similar to that described here or in conjunction with SAP's.

So don't be afraid to walk down the hall to your SAP colleagues; you will find you have more in common than not, and together, you can leverage your company's investments in both GIS and SAP.

More Information

For more information, contact Steve Benner, Esri (e-mail: sbenner@esri.com).