Entry into the World of SOAs

Service-oriented architectures (SOAs) are regarded as the next major stage in the evolution of corporate IT. They enable business processes to be molded and adapted with greater flexibility. This is very convenient for users because, although many companies already use solutions from the SAP Business Suite to cover their basic processes, some individual processes have potential for optimization that extends beyond the standard. For example, during the maintenance procedure for a utility company, a particular control cabinet needs not only to be found in the directory service but also geographically located.
With an SOA, software components required for a particular business process are encapsulated as services and combined with each other using a service bus. This encapsulation focuses on business-management factors. Users can therefore merge the services without any special technical know-how and, for example, access them via the SOAP (Simple Object Access Protocol) standard protocol. They can also be easily configured and reused in other contexts. Many companies are already planning to use this option in their existing IT architecture.
However, scenarios often combine standard solutions and customized developments with the inherent changes of systems and lack of integration that this brings with it. But architectures like this can also take on an SOA capability. Improved integration tools and technology standards such as web services help to overcome the interface problems and support all processes on the basis of a service-oriented infrastructure.
The key technical tools in the SOAs’ armory are EAI components. In the SAP environment, this takes the form of the SAP NetWeaver Exchange Infrastructure (SAP NetWeaver XI) in particular. Any gaps that may appear when performing service-oriented coupling of SAP solutions with third-party applications, because the applications in question do not adequately support SOAP or other standard interfaces, can be closed using open source tools. It might therefore be possible in certain cases, for example, to use an open source web server like Apache TomCat in order to provide a web service interface.

From EAI to service orientation

A project by Lynx-Consulting AG for a utility company shows how a, to all intents and purposes, classic EAI task can be used directly to facilitate entry into a service-oriented system concept. The consultants implemented the “fault management” business process by integrating geographically oriented information into business-management processes.
In addition to solutions for Enterprise Resource Planning (ERP), utility companies usually also use Geographical Information Systems (GIS). These enable recording of geographical data, the associated factual information relating to devices – such as a domestic connection or a transformer station with its various standardizations and loads – and their environment, for example the distributor for a domestic connection. This information helps to fully document networks and plan them more rapidly.
Data on management of the devices and device locations used is typically also required in the Plant Maintenance (PM) component of SAP R/3. Changes to these technical objects therefore generally affect both the ERP solution and the GIS. If integration is lacking, changes must be performed manually in each case, a process which is not very efficient and is extremely prone to errors. There is therefore a great deal of interest in end-to-end process design and synchronization.

Pivotal role: SAP NetWeaver XI

SOA with SAP NetWeaver XI
SOA with SAP NetWeaver XI

The Lynx team therefore harmonized the integration of the PM component from SAP R/3 4.6c and the GIS application GE Smallworld. To do this, they selected a configuration of the SOA principle based on EAI technologies. SAP NetWeaver XI as the EAI platform supplies the required PM functions as services and also assumes the role of the service bus.
To make the GIS service-compatible, the team created an SOAP adapter for GE Smallworld. The adapter is addressed via a web application server – in this case the open source product Apache Tomcat. Repositories with meta-information such as interface descriptions and data schemes on the implemented services are maintained on both sides, in the GIS and in SAP NetWeaver XI. This enables the services to be reused in other scenarios.
The services are hierarchically structured. The lowest level comprises the basic services that directly access GIS functions such as reading or writing of data. Enterprise services are defined on this basis. Enterprise service “read_HA_Kasten” that reads the attributes of a domestic connection box is, for example, created on the basis of basic service “genRead”. An XML structure (Extensible Markup Language) specifies precisely what GIS functions are to be provided via the enterprise service. A service, including its description in the form of a WSDL file (Web Services Definition Language), can be generated automatically from the XML structure. This file is imported into SAP NetWeaver XI as an external data definition. Here it provides a message type description for setting up an interface to enable access to the service from SAP NetWeaver XI.
Integration Builder in SAP NetWeaver XI in turn provides all the necessary tools for designing and configuring the process flow. These include the Integration Process Engine. The descriptions of Intermediate Document Interfaces (IDocs), Business Application Programming Interfaces (BAPIs) or in-house functional components from PM, such as an RFC component for reading information from the GIS, can also be managed in Integration Builder. The service descriptions are also imported into Integration Builder and the corresponding routing rules and communication channels are then configured here.
If a user accesses a GIS service from PM, for example for exchanging transformers, a message containing all the relevant data and a WSDL description of the service is sent to SAP NetWeaver XI. The platform evaluates the message and initiates a process whereby the services are called up via SOAP and supplied with the information necessary for implementation. Calling up a PM service from GE Smallworld works in the same way. The GIS passes the request on to the SOAP adapter which sends the call-up to SAP NetWeaver XI. The SOAP message is evaluated here in order to use the required functions from PM as a service. The result of the service implementation, such as whether the information was created successfully, is then transferred to the GIS, again via the SOAP adapter.
There are currently five basic services for the “fault management” process: Network tracking, changing objects, creating objects, deleting objects and reading object data.

Always open for new services

The adapter based on the SOA concept facilitates the integration of additional services. In some cases, it was also possible to effect individual functions of this adapter by setting up another customized interface that does not require any middleware like SAP NetWeaver XI. However, such interfaces are a lot more dependent on the releases of the corresponding systems and require more outlay for development and support. Furthermore, without the necessary tools, they cannot be reused for other customers who have their own particular structures in place. The solution implemented in the project, on the other hand, enables integration of other SOA middleware systems in addition to SAP NetWeaver because a repository is maintained in the case of each application. It is also possible to transfer the service information to a central repository or use the SAP Web Application Server (SAP Web AS).
Open source programs – in this case particularly the web application server Apache Tomcat and web service tools such as Axis or Xfire – allow an SOA to be set up for applications that do not normally support any service orientation. Not only do they enhance the scope for integration in the case of platforms like SAP NetWeaver, they also support fast entry into new areas of operation without having to worry about licensing issues or availability. This allows companies to take their first steps into the world of SOA in other areas, as metadata management and Product Lifecycle Management (PLM) without undue effort and while still maintaining a clear picture of the dependencies.

Dirk Osterkamp
Dirk Osterkamp