|
|
|||
|
The Keys to Successful SAP/Esri Interfacing By Peter Houwen, Wayne Hewitt, Ben Ralph, and Colin 't Hart Creating an interface between SAP R/3 software and Esri's GIS software is more than a technical problem. SAP and Esri software model data in different ways. Matching these data models is the first piece of the puzzle. Most issues revolve around differences in the way that R/3 and ArcFM represent facilities data. Deciding which data is shared and what navigation is required between the two systems must be done first. Knowing what is possible at a technical level is crucial in making these decisions. Esri-Australia created a successful interface with SAP as part of the implementation of ArcFM at AlintaGas in Perth, Western Australia. Background AlintaGas is one of the first sites in the world with a working interface between Esri and SAP software. AlintaGas distributes gas to approximately 400,000 residential, business, and industrial customers throughout Western Australia. Its database contains more than 10,000 kilometers of gas mains and more than 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 customization and implementation of the GIS and SAP systems occurred concurrently, and both systems went live on April 28, 1998. The GIS system, named Gas Network Information System (GNIS), consists of ArcFM, ArcFM Viewer, and Spatial Database Engine (SDE) using an Oracle 7.3.3 database. Six ArcFM users maintain the gas network and associated spatial data. There are currently 150 users of ArcFM Viewer. The Plant Maintenance module of SAP is used to handle plant maintenance and work management and is the only SAP module interfaced to GNIS. Other SAP modules installed at AlintaGas include finance, human resources, and materials management. Getting Started The first task was to model business processes at AlintaGas. Business processes that crossed between GNIS and SAP helped define the interfaces required. It was important to create a smooth transition between the two systems while maintaining data integrity. The following crossover business processes were identified:
Identifying what types of equipment are common to both applications, how data is represented in each, and what attributes are common to both, and deciding whether the common attributes should be stored in both systems or only one were the key issues. Types of Equipment During initial development, the SAP Plant Maintenance and GNIS teams separately defined their own data models. The teams then came together to determine the equipment that was common to both systems. Each team had equipment that was not represented in the other system. While SAP was concerned only with "maintenance significant" equipment (i.e., equipment requiring planned maintenance), GNIS was interested in any equipment that needed to be located spatially. The common equipment types at AtlintaGas are mains, high pressure valves, meters/service points, meter sets, regulators, rectifiers, and gate stations. Many attributes associated with these types of equipment are stored in both the GNIS and SAP, but only a subset of these attributes are shared. Representing Data Equipment was not always represented in the same manner in each system, and there was not always a one-to-one correspondence between equipment represented in SAP and GNIS. A gas main in GNIS is a single line between two nodes. In SAP, a main is a logical entity that is difficult to define. It is usually thought of as a series of gas pipes on the same street with the same offset, material, and pressure. SAP expected GNIS to determine this automatically, but data was insufficient to do this.  Streets are just voids in the cadastre and are not represented as polygons. There were additional issues. The GNIS version of a gas main would create far too many pipes for SAP to represent. Gas services in GNIS consist of a single service point. SAP requires more information for a service point including details about the service line and its main.
SAP uses the concepts of equipment objects and functional locations. An equipment object is an identifiable piece of equipment that may be located at a functional location. A functional location refers to the location of a piece of equipment. For example, a service point would be a functional location while the actual meter located at the service point would be an equipment object. Interface developers had to decide whether equipment in GNIS should be matched to functional locations or equipment in SAP. In this instance, it made sense to match GNIS equipment with functional locations in SAP. Identifying Common Attributes Once the common types of equipment were identified, the next step was to determine which attributes are held in both systems and if these attributes are represented the same way with the same domain of values. A crucial decision that affected the implementation was whether the attributes for common equipment should be stored in both SAP and GNIS or in only one system and be accessed from the other. If attributes are stored in both systems, data integrity becomes an issue. If they are stored in only one system, performance and independence become issues. For example, if GNIS always needs to symbolize equipment based on an attribute in SAP, this operation will likely be slow, and performance will be adversely affected. Independence is necessary so that one system can operate reasonably well when the other system is down. At AlintaGas, it is important that each system operates when the other system is unavailable. Consequently the relevant attributes were duplicated in both SAP and GNIS. Processes, such as export store and reconciliation, were added to ensure data integrity. The export store manages data sent when the destination system is unavailable. The reconciliation process periodically checks both systems to ensure that data is consistent. One of the systems must be responsible for each of the attributes. System designers needed to decide which system could create equipment, which attributes could be edited in each system, and which system could delete equipment. All common equipment is created and spatially located in GNIS. A background interface creates the same piece of equipment in SAP. In general, attributes that affect connectivity and symbolization are edited in GNIS. Some attributes are only editable in SAP. SAP can remove equipment from a functional location, but only GNIS can delete a functional location. SAP's primary interface method uses Remote Function Calls (RFC). There are many predefined RFCs supplied by SAP, but new ones can also be created. External programs can call RFCs to send data to or retrieve data from SAP. Esri–Australia built a dynamic linked library (DLL) for AlintaGas that consists of a set of wrapper functions that make it easy for GIS applications to use RFCs. The Visual Basic and Delphi programs call the DLL functions which, in turn, call the relevant RFCs. Interface Specifics  The interfaces between GNIS and SAP can be divided into two types. Background interfaces are concerned with keeping the data consistent between the two systems while GUI interfaces are typically invoked by users to navigate between systems. Background interfaces for equipment creation, equipment maintenance, export stores, and reconciliation are not typically seen by users.Equipment Creation All equipment shared between the GNIS and SAP is first created in GNIS. GNIS assigns a functional location to the equipment and calls an RFC to create the equipment in SAP. Equipment Maintenance When a shared attribute is modified in either system, the other system is notified immediately. An RFC is used to update the details in SAP when equipment is changed in GNIS. As soon as the change is checked into the SDE database, the RFC is initiated. 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 later. When SAP modifies shared attributes of a piece of equipment, it sends the changes to GNIS. Updates to GNIS database take into account feature locking related to transactions. Export Stores Both GNIS and SAP use an export store to handle the situations in which updates cannot be made because the other system is unavailable or a feature is locked as part of a transaction. A separate server program monitors the GNIS 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. Reconciliation A separate reconciliation program checks for inconsistencies between GNIS and SAP data. This program starts on the SAP side and sends GNIS a list of functional locations that have been updated since the last reconciliation. GNIS cross-checks this list with its own data and returns a combined list of functional locations that have changed in either system and the associated data from GNIS. SAP updates itself, if necessary, and sends calls to GNIS for the updates that need to be made. Changes made to either system depend on which is the custodian of the particular attribute. Reconciliation can be run in a report mode that shows differences between GNIS and SAP or in an update mode that actually puts both systems back in sync. User-Invoked GUIs As previously described, many operations occur behind the scenes and are not normally visible to most users. However, there are interfaces that involve functions invoked from a toolbar button or menu item in either GNIS or SAP. Equipment Drill-Down Users start a function that opens SAP and shows the details for a functional location. Users can navigate in SAP and return to where they were originally in GNIS. This functionality is implemented through the SAP GUI, a SAP-supplied DLL that allows other programs to open a SAP screen. A separate DLL, created by Esri–Australia, makes it easier to call SAP GUI functions from GIS programs. Notification Drill-Down Notification drill-down also uses SAP GUI functionality. Users can select equipment in GNIS and open a SAP window that shows details for any notifications held against the selected functional locations. Users can navigate in SAP and return to where they were in GNIS. Symbolize or Annotate Notification Users can select equipment in GNIS and symbolize or annotate that equipment according to the notification details stored in SAP. No notification details are stored in GNIS. All notification details are retrieved from SAP by calling an RFC. GNIS sends the RFC a list of functional locations for the selected equipment along with additional parameters describing the types of notifications required. The RFC returns a list of notifications with details about each notification. GNIS symbolizes or annotates the selected equipment according to these notification details. This is useful for visually inspecting outstanding notifications in an area. Create Notifications Users can create SAP notifications from GNIS.  A piece of equipment is located in GNIS. Details about the equipment and the type of notification (e.g., fault, new meter) are entered. GNIS calls an RFC that creates the notification in SAP. A call, made to SAP GUI, opens an SAP screen so the user can enter more details about the notification. After finishing this operation, the user is returned to GNIS.
Display a Map Map display is the only GUI interface 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. If necessary, this program starts GNIS, uses dynamic data exchange (DDE) to pass across the functional location, and displays a map with the relevant piece of equipment at the center of the screen. Some Conclusions A large part of the interface work at AlintaGas was spent on the analysis and design phases. Mapping of equipment between the GNIS and SAP data models was not trivial and required significant analysis and design time to make it a successful part of a total solution. The interfacing needed to be transparent to end users. Since many AlintaGas business processes spanned both systems, it was imperative that the movement between systems was seamless. These points summarize key areas that contribute to a successful interface implementation.
For more information, please contact Peter Houwen,Project Manager Geographic Business Systems Pty. Ltd. 345 Harborne Street P.O. Box 761 Herdsman, Western Australia 6017 Tel.: +61 8 9443 8822 Fax: +61 8 9242 4412 E-mail: phouwen@gbs.com.au Wayne Hewitt Esri–Australia Pty. Ltd. E-mail: whewitt@compuserve.com Ben Ralph Miner and Miner E-mail: ben@miner.com Colin 't Hart Geographic Business Systems Pty. Ltd. E-mail: cthart@gbs.com.au About the Authors Peter Houwen managed the analysis, design, development, and implementation of GNIS including the interfaces to SAP. He has a bachelor of science in computer science from Curtin University of Technology in Perth, Western Australia. He has over 20 years experience in software development. Upon the completion of the AlintaGas project, he became a project manager for Geographic Business Systems, a sister company of Esri–Australia. Wayne Hewitt is a senior GIS analyst at Esri–Australia and was leader of the PowerTools customization team on the AlintaGas project. He has worked in the GIS industry for nine years and holds a bachelor of applied science, surveying, and mapping from Curtin University of Technology. Ben Ralph, leader of the Kestrel customization at AlintaGas, did much of the technical development of the GUI interfaces with SAP. He holds a bachelor of science in computer science from Curtin University of Technology. Since the completion of the AlintaGas project, he has joined Miner & Miner where he works on ArcFM software. Colin 't Hart is a systems analyst for Geographic Business Systems. On the AlintaGas project, he developed most of the background interfaces between Esri and SAP. He has bachelor of computing and mathematical sciences (Hons) from the University of Western Australia.
|
