Interfacing between SAP and Esri is more than just a technical problem. SAP and Esri model data in different ways, and matching these two data models is the first piece of the puzzle. Decisions first need to be made on which data is shared and what navigation is required between the two systems. Knowing what is possible at a technical level is crucial in making these decisions. Esri Australia was successful at interfacing to SAP as part of the implementation of ArcFM at AlintaGas in Perth, Western Australia. This paper discusses the problems faced and the solution that was implemented at AlintaGas.
AlintaGas, in Perth, Western Australia, has one of the first sites in the world where there is a working interface between Esri GIS software and SAP. AlintaGas distributes gas to approximately 400,000 residential, business and industrial customers throughout the state. Their database contains over 10,000 kilometres of gas mains and over 700,000 land parcels.
Esri Australia was selected via a tender process to develop and supply a GIS system to meet the requirements of AlintaGas. The customisation and implementation of the GIS and SAP systems at AlintaGas occurred concurrently and both systems went live at the same time: on April 28th, 1998.
The GIS environment installed at AlintaGas is MMPowerTools ODE and Kestrel from Miner and Miner. These two products are the pre-cursors to ArcFM and ArcFM Viewer. The data is stored in SDE on Oracle. The GIS system is named GNIS: Gas Network Information System.
This paper explains the key issues that needed to be resolved and the decisions made to resolve each issue. Most of these issues revolved around differences in the way that SAP and ArcFM represent facilities data.
Appendix A then provides more details on the interfaces that are implemented between GNIS and the SAP systems at both a user level and a technical level. These explanations concentrate on the interfaces from the GIS side and do not include technical details on the SAP side of the interfaces.
The first task at AlintaGas was to model business processes. The business processes that crossed between GNIS and SAP were used to help define the interfaces required between the two systems. It was important to create a smooth transition between the two systems and also that data integrity was maintained.
The business processed that cross between the two systems were defined as follows:
During initial development, the SAP Plant Maintenance and GNIS teams were working separately to define their own data models. The teams then came together to determine what equipment was common to both systems. Each had equipment that was not represented in the other system. SAP was only concerned with "maintenance signficant" equipment. That is, equipment that requires planned maintenance. The GNIS team was concerned with any equipment that needed to be located spatially. At AlintaGas, the common equipment types are mains, high pressure valves, meters/service points, meter sets, regulators, rectifiers and gate stations.
It became clear that equipment was not always represented the same in each system. There was not always a one-to-one correspondence between equipment represented in SAP and equipment represented in the GIS.
A gas main in GNIS is a single line between two nodes. In SAP, a main was more a logical entity that was more difficult to define. It was usually thought of as a series of gas pipes on the same street with the same offset, the same material and the same pressure. SAP expected GNIS to determine this automatically but there was not sufficient data to do this. Streets are just voids in the cadastre and aree not represented as polygons. There were many other issues that made this too difficult within the time frame. The GNIS version of a gas main would mean that there were far too many pipes to be represented in SAP.
Gas services in GNIS consist of a single service point. SAP requires more information on a service point, including details about the service line and the main that the service line is attached to.
SAP has the concept of equipment objects and functional locations. An equipment object refers to an identifiable piece of equipment and may be located at a functional location. A functional location represents a location where a piece of equipment may be situated. For example, a service point would be a functional location while the actual meter located at the service point would be an equipment object. A decision is required on whether equipment in GNIS should be matched to functional locations or equipment in SAP. At AlintaGas, it made sense to match GNIS equipment with functional locations in SAP.
For the common types of equipment, which attributes are held in both systems? Are the attributes represented the same way, with the same domain of values?
A crucial decision affecting the implementation is whether the attributes for common equipment are stored in both SAP and GNIS or in only one and accessed from the other. If the attributes are stored in both systems then data integrity becomes an issue. If they are stored in only one system then performance and independence become an issue. An example of a performance issue would be if GNIS always needed to symbolise equipment based on an attribute in SAP. This is likely to be too slow to be feasible. Independence means that one system can operate reasonably even when the other system is down.
At AlintaGas it is important that each system is still able to operate when the other system is unavailable and so the decision was made to duplicate the relevant attributes in both SAP and GNIS. Processes such as an export store and reconciliation were added to ensure data integrity. The export store manages data sent when the destination system is unavailable. It will periodically check the availability of the destination system and send the data when it becomes available. The reconciliation process periodically checks both systems to ensure the data is consistent. If there are discrepancies the data is updated according to the relevant master of that data. Each common attribute belongs to either SAP or GNIS. For example, if the reconciliation process detects a mismatch for a particular attribute, the value of the attribute in the master system will be taken as the correct value. A decision is needed on which system is the master for each attribute.
For all common equipment and the attributes for that equipment, the following decisions need to be made:
At AlintaGas, all common equipment is created in GNIS. The equipment is spatially located and created in GNIS and then a background interface creates the same piece of equipment in SAP. In general, attributes that affect connectivity and symbolisation are edited in GNIS. Some attributes are only editable in SAP. SAP can remove equipment from a functional location but only the GIS can delete a functional location.
There are several conclusions to be gained from the experience at AlintaGas.
The GIS at AlintaGas is known as GNIS: the Gas Network Information System. The GIS installed at AlintaGas consists of the following products:
ArcFM is an ARC/INFO ODE-based application designed specifically for the editing, maintenance, modelling and data management of utility information. ArcFM is written in Microsoft Visual Basic 5.0 for a Windows NT operating environment. ArcFM is used by approximately 6 users at AlintaGas to maintain the gas network and associated spatial data.
ArcFM Viewer is a MapObjects based application designed specifically to view and query utility information. There are currently 150 users of Kestrel in AlintaGas.
ArcFM and ArcFM Viewer use the RBE to encode the business rules of the organisation, such as symbology, data editing, data management, data connectivity and validation.
SDE on Oracle 7.3.3 is used to store AlintaGas� GIS data.
The PM module of SAP r/3 is used by AlintaGas to handle plant maintenance and works management. This is the only SAP module that has an interface to the GIS. Other SAP modules installed at AlintaGas include Finance, Human Resources and Materials Management.
The following types of equipment are stored in both the GIS and in SAP:
Both the GIS and SAP store many attributes associated with these types of equipment. Only a subset of these attributes are shared between the GIS and SAP.
The functional location is the common key between the GIS and SAP.
SAP�s primary interface method is via the use of Remote Function Calls (RFC). There are many pre-defined RFCs supplied by SAP, but new ones can also be customised. External programs can call RFCs to send data to SAP or to retrieve data from SAP.
At AlintaGas, Esri Australia built a DLL consisting of a set of wrapper functions to make it easy for the GIS applications to use the RFCs. The Visual Basic and Delphi programs call the DLL functions which, in turn, call the relevant RFCs.
The interfaces between Esri and SAP can be divided into two types. The background interfaces covers those interfaces that are concerned with keeping the data consistent between the two systems. The GUI interfaces are invoked by users, often to navigate between the two systems.
All equipment that is shared between the GIS and SAP is first created in the GIS. The GIS then assigns a functional location to the equipment and calls an RFC to create the equipment in SAP.
When a shared attribute is modified in either system, then the other system is immediately notified of the change.
If a piece of equipment is updated in the GIS then an RFC is used to update the details in SAP. This is done as soon as the change is checked into the SDE database. If there is an error with the interface (e.g. SAP is down) then the details are retained in an export store to be sent to SAP again at a later date.
When SAP modifies the shared attributes of a piece of equipment, it sends the changes back to the GIS. These updates to the GIS database need to take account of feature locking so that features that are currently locked as part of a transaction are not updated.
Both the GIS and SAP have the concept of an export store to handle the cases where updates cannot be made successfully in the other system. Some examples of this are when the other system is unavailable or the feature is locked as part of a transaction.
A separate server program monitors the GIS export store and regularly tries to send data in the export store to the other system. The GIS export store is an Oracle table that holds details of the equipment updates sent to SAP.
A separate reconciliation program was written to check for inconsistencies between the GIS and SAP data. This program starts on the SAP side and sends the GIS a list of functional locations that have been updated since the last reconciliation. The GIS then crosschecks this list of functional locations with its own data and returns a combined list of functional locations that have changed in either system, plus the associated data from the GIS. SAP then updates itself if necessary and sends calls to the GIS where updates need to be made. The changes made to either system depend on who is the custodian of the particular attribute.
This reconciliation can be run in two modes: one is a report mode to show differences between the GIS and SAP, the other actually updates both systems to put them back in sync.
The above interfaces occur behind the scenes and are not normally visible to most users. There are, however, a number of other interfaces that are used in ArcFM or ArcFM Viewer. These are mostly functions that are invoked from a toolbar button or menu item in either the GIS or SAP.
Users can select equipment in the GIS and do an equipment drill-down into SAP. That is, they can start a function that will open SAP and show the details for the functional location. They can then navigate around in SAP. When they back out of SAP they are returned to where they were in the GIS. This functionality is implemented using SAP GUI: a SAP supplied DLL that allows other programs to open a SAP screen. A separate DLL was then created by Esri Australia to make it easier to call these SAP GUI functions from the GIS programs.
Users can select equipment in the GIS and do a notification drill-down into SAP. This function will open SAP and show details for any notifications held against the selected functional location(s). The user can then navigate around SAP. When they back out of SAP they are returned to where they were in the GIS. This also uses SAP GUI functionality.
Users can select equipment in the GIS and symbolise or annotate that equipment according to the notification details stored in SAP. No notification details are stored in the GIS: all notification details are retrieved from SAP. This is done by calling an RFC that was created for this purpose. The GIS sends the RFC a list of functional locations for the selected equipment plus some parameters about the types of notifications required. The RFC then returns a list of notifications with details about each notification. The GIS symbolises or annotates the selected equipment according to these notification details.
This functionality is useful for visually inspecting the notifications that are outstanding in an area.
Users can create SAP notifications via the GIS. The GIS is used to locate a piece of equipment and to enter details about the equipment and the type of notification (e.g. fault, new meter). The GIS then calls an RFC to create the notification in SAP. A call is made to SAP GUI to open an SAP screen where the user can enter more details about the notification. When this is completed the user is returned to the GIS.
This is the only GUI interface that is invoked from SAP. From SAP, a user can view a map for a specific functional location. SAP calls a program, written by Esri Australia, and passes the functional location. This program then starts the GIS, if necessary, and uses DDE to pass across the functional location. The GIS then displays a map with the relevant piece of equipment at the centre of the screen.
A large part of the interface work at AlintaGas was spent on the analysis and design phases. The mapping of equipment between the GIS and SAP data models was not trivial and required significant analysis and design time.
There were many parts to the interfacing work that were required to make the interfacing work as part of a total solution. The interfacing needed to be transparent to end-users. Many AlintaGas business processes spanned both systems so it was imperative that the movement between systems was seamless.
Once the analysis and design was done, the technical problems were less difficult to solve. There was a reasonable knowledge base on the RFC technology, but far less on the SAP GUI interfaces. The interfaces were developed by Esri Australia, working alongside SAP consultants.
The solution has worked well for AlintaGas and has been of great benefit in getting the GIS accepted as being a vital component of the corporate business system.
Peter Houwen
Project Manager
Geographic Business Systems Pty. Ltd.
PO Box 761
345 Harborne Street
Herdsman, Western Australia 6017
Ph: +61 8 9443 8822
Fax: +61 8 9242 4412
email: phouwen@gbs.com.au
Wayne Hewitt
Esri Australia Pty. Ltd.
email: whewitt@compuserve.com
Ben Ralph
Miner and Miner
email: ben@miner.com
Colin 't Hart
Geographic Business Systems Pty. Ltd.
email: cthart@gbs.com.au