This is an old article, written back in 2006 but never published. I think it's still worth reading and beside the fact, that oracle now took over bea, and some product versions moved on, its still up-to-date. Today, hardly a single company can do without systems from the SAP AG [1]. SAP – For years, these three letters have stood for business applications and effective company processes. However, despite the wide distribution, there are still not enough classic developers, who feel comfortable enough in the SAP world, that they are able to restore earlier integration solutions. The need for communication between the worlds is becoming increasingly important, which means that it is time to take a look at the different possibilities available and to find ways to support the interaction between the two worlds.
Introdcution
When speaking to developers from a wide range of backgrounds about the issue of SAP, a wide variety of reactions is seen. Whether excited head-nodding or open rejection of the ABAP, BAPIs, IDocs, etc. not a single expression is lacking. The majority of the developer community is not dissatisfied to consider SAP a blackbox and to merely investigate how to get around it.
It is not a surprise that non-SAP developer communities have a difficult time with the topic. There is hardly a range of products that has the same exposure and has still been able to remain so intransparent. Especially the technical aspects of the SAP products are still mostly handled by a select group of specialitists. However, this fact alone does not discourage companies from installing products from the wide range of wonderful and clever abbreviations, such as SD (Sales & Distribution), FI (Finance), CO (Controlling), HR (Human Resources), etc. The main reason though is the increasing cost pressure. The desire to omptimize relevant business processes using standard products and to uniformly support them through the IT usually gets IT departments moving. Yet, this approach is completely comprehensible. If optimization and standardization can save costs, further costs can be saved by employing certified employees instead of training existing employees, and the guaranteed support from the manaufacturer is also an added bonus.
What is quickly forgotten is the fact that such problem-free packages do have their price. In addition to implementation and company-specific customizing, there are also considerable license fees. But these are only a few reasons why companies are tending to portray only the business-critical basics in their standard products (financial accounting, human resource management, etc.). IT usually takes care of the remaining processes using older individual developments, which have expanded over the years and which take some getting used to. These are usually based on Java, Microsoft or other platforms. What initially looks like a feasible interaction actually creates a lot of questions upon closer examination. Many individual developments could potentially use interfaces to SAP, since they can access the same dataset or even functions portrayed in SAP. Thus, it would be rather profitable to connect SAP to the rest of the world.
Developers and ConsultantsThis is where the history of SAP software in companies becomes interesting for non-SAP developers as well. Both partners would have to sit down and find solutions for questions such as integration, access and data exchange. However, both sides do tend to exaggerate in the reports from such discussions. What is sure, is that it does not usually take long until this babylonian language deficit has prevented any effective cooperation at all.
When taking a close look at a customer’s different views of software, their development processes or related implementation modules, it can clearly be seen that the SAP products do differ greatly from products made by other manufacturers. To put it another way, SAP’s product portfolio contains large blocks of products for optimizing and standardizing almost all company processes. Starting with cross-industry topics, such as human resource management and financial accounting to specific solutions for say health care or the automobile industry…almost every industry is represented. Unlike other products, where programmers work with a program until it fits, no programming is performed in the SAP product. Instead, adjustments are made until the product fits the company processes and situation. This adjustment process is not referred to as “development”, but as “customizing”, i.e. customer-specific adjustments. Which is why it is also important that qualified and certified consultants make the adjustments and not developers.
Consultants speak the language of their product and process. This seems to contradict the work of classic developers, who focus on interfaces, programming languages and process environments. This is a classic process verses technology vocabulary. What makes it even more difficult is that SAP’s varied technology uses its own methods. Although consultants speak about technology as well, they are usually referring to proprietary technologies. With so many differences, it is not surprising that initiating a successful interaction does indeed require some work.
Commonalities
Since the fundamental aspects seem to differ so greatly, it is no wonder that the two worlds do not seem to migrate toward each other and that one world does not know much about the other. To create successful integration solutions between SAP and the rest of the work, a step will first have to be taken in the other direction. Many developers are aware of the abbreviation R/3. R/3 is a company information system (also referred to as ERP - Enterprise Resource Planning). R/3 has been used since about 1993 and is a client/server system. The R stands for realtime and the 3 refers to the 3 layers which create such a system (a database layer, application layer and presentation layer). R/2, the previous version, was designed for operation in mainframe systems. The direct successor of R/3 is mySAP ERP. NetWeaver was presented as the successor at the beginning of 2003. With the R/3 systems, data is stored in standard relational databases, yet the overall business processing is done in an application server. The application server executes the programs written in the proprietary language, called ABAP. Quite an expansion was seen in release 4.7 of the SAP R/3 Enterprise. As SAP’s official answer to the boom in internet technologies, it was named the SAP Web Application Server (WebAS) in the summer of 2000. Event the initial versions, 6.10 and 6.20, already had their own HTTP and Web service interfaces for the ABAP runtime. A parallel Enterprise Java Runtime appeared in the application server in version 6.30 after SAP took over the In-Q-My company. This part of the application is J2EE 1.3 conform and enables Enterprise Java programming. Whereas the technical platform used to be somewhat neglected, it was now receiving increased attention in the SAP product portfolio. The current WebAS 6.40 is the basic process environment for almost all SAP products and is delivered with NetWeaver 2004. Whoever signs up on SAP’s [2] free developer site is also given the opportunity to download and try a few preview versions of the technical basis. In addition to the current NetWeaver 2004 SP16 version, it also provides the successor version NetWeaver 2004s SP7 and a preview of NewWeaer 2007, with limited functionalities.
DifferencesIn other words, two completely separate hearts beat in WebAS: The ABAP engine for executing ABAP code and the so-alled J2EE engine. WebAS can be installed with either one or both engines. Except for the fact that the application server has two different runtimes, the concept as such is not that foreign.
Unfortunately, ones does have to admit that the similarities end there - at least when ignoring the J2EE side and focussing on the ABAP process environment. Still, non-SAP developers are faced with a myriad of foreign abbreviations when working in an SAP application environment. The ABAP engine is composed of different parts (incl. lock server, updating processes, spool processes, etc.). These processes can be distributed to different engines if necessary. In the simplest case, all parts run on a single application server. This kind of installation is referred to as a central instance. Whereas this arrangement is extremely efficient for smaller scenarios, it does have to be distributed to numerous physical systems for larger installations. A few components (especially the lock and updating processes) can only exist once per system. These are also managed under the name of “central services”. The parts responsible for actually running programs, can be freely scaled and distributed. The term “dialog instances” has been established for them.
The abbreviation ABAP originally stood for the german expression “Allgemeiner Berichts-Aufbereitungs-Prozessor“ (translation: General Report Formatting Processor). The language was mostly used to program evaluations and did not directly make changes in a database. During later developments in the language, and based on the internationalization of the products, the abbreviation was redefined as “Advanced Business Application Programming” in 1993. No scope has been defined for the language and has been continously expanded in the past. As a 4th generation language, it was specifically developed for processing mass data in commercial applications. The business logic is realized using ABAP functions, ABAP classes and semantic ABAP business objects. It can be programmed functionally or even object-specific. Data is retained using the SAP standard ABAP OpenSQL or using NativeSQL or other batch processing functions (batch input, direct input, call transaction). A presentation server is used for the formatting and for display to the user. The client includes the SAP GUI, a native Windows application. The Internet Transaction Server (ITS) can be used to access the SAP GUI function using a standard browser. The server side of all these display variants is based on the Dynpro portayal technology. The processing of Business Server Pages (BSP) became available with WebAS 6.20. These are comparable to JSP pages, except they are programmed in ABAP. A wide variety of communication interfaces are used to communicate within and outside the SAP world. The most common are RFC, ALE, BAPI, HTTP and Web service. Whereas HTTP and Web service are well known, the others are not.
RFC is the abbreviation for “Remote Function Call”. This technology is used to call ABAP functions or function modules across subsystem limits and to exchange data. RFC is based on CPI-C, an IBM development, and has been available since release R/2. Basically, RFC is a communication protocol for exchanging messages. RFC is categorized into different specific types for better understanding. These include sRFC (sychronous RFC), aRFC (asynchronous RFC), tRFC (transaction RFC) and qRFC (queued RFC). Technically, this could be considered an RPC (Remote Procedure Call).
The standard technology for realizing distributed systems at SAP is ALE technology. ALE stands for “Application Link Enabling”. It was specifically developed for exchanging data between business systems using the IDoc document format based on RFC. In doing so, ALE ensures consistent and reliable message delivery across system limits. In other words, ALE provides a routing and workflow level for transferring messages.
BAPI stands for “Business Application Programming Interfaces”. As a standardized API, it enables external access to functionalities in the SAP business objects. In the ABAP world, business objects portray real objects, such as an employee or a customer order. They are complete encapsulations containing data related to the object as well as business processes, and can thus be efficiently embedded in the actual structural and implementation details of the physical data. One clear example is the combination of business objects and BAPI. Upon close examination of the SAP business object “Material”, one can see that it includes a check for the availability of the material, etc. These checks are defined virtually as methods and take on the form of a BAPI with the name “Material.CheckAvailability”. Technically, the BAPI is a specific implementation of function modules, which have to meet corresponding design guidelines. Thus, they cannot contain dialogs, have to be RFC-capable and have to deliver a suitable return value. In other words, a BAPI can be considered an implementation guideline. More details can be found in [3].
In order to transfer the somewhat complex data structures to the SAP world and externally, the possibilities are not limited to transferring simple values. With the Intermediate Document (IDoc) SAP has defined a separate data exchange format. It is message-based and asynchronous. In it, defined and effective message types (delivery notes, orders) are assigned to the so-called IDoc types. This means, that an IDoc contains data structures as well as processing logic. It can also be used in R/3 systems, e.g. for transferring data to external systems using BAPIs.
This short examination of the SAP technology clearly shows that there is no way around function modules, RFC, BAPI or IDoc when communicating with SAP. Even if this method is described as cross-platform and standardized, it is still not possible to use the functions offered in other worlds without a little extra work. SAP provides so-called “Connectors” to achieve this purpose. There are also many open standards and other ways to connect SAP systems from the Java world.
SAP Java Connector
Java Connector (JCo) by SAP is probably one of the most widely known. The current version, 2.1.7, can be run on Windows, Linux, Solaris AIX and many other platforms. SAP customers can download them free of charge from the service website [4]. JCo is actually a complete Middleware for communicating with the SAP systems with R/3 releases. In addition to the simple connection to SAP systems and their pooling, it also includes numerous libraries for accessing IDocs, RFC and BAPIs. It supports synchronous and asynchronous access, whether from Java to ABAP or vice-versa. Only the connection to the Java world is a little more difficult. Java Native Interface (JNI) is used for accessing the shared libraries of the connector when in Java. In other words, the native methods are not called directly. A Java proxy class exists for each class of the connector, which will be addressed when in Java.
Although the connector has proven to be relatively stabile, it should still be used with caution. Experiences with JNI have shown, that the JNI interface cannot catch all of the runtime errors on all platforms. This means, that the Java Virtual Machine (VM) may simply be terminated if such an error occurs. To effectively avoid this problem, one would have to operate the JCo component on a separate JEE cluster and make it one-hundred percent downtime secure.
Another alternative would be to use the Java Resource Adapater (JRA) implementation. However, it only supports synchronous RFC calls and uses a technical user when logging on to the system. This is not suitable for all cases.
JCo can also be used to enable the communication between a combined installation of J2EE and ABAP engine. If both engines are located on hardware, the JCo will no longer use only RFC for communicating with the ABAP stack, but will also rely on an accelerated construct, the so-called FastRFC. FastRFC is an expansion of the RFC libraries. It no longer uses TCP/IP, instead it relies on a split memory area. This means, that it can only be used when the RFC client and RFC server are installed on the same engine. The programming is explained rather well in the documentation, using numerous examples. Additional support for JCo can be found on SAP’s help pages [5]. People who frequently work with JCO should also take a look at some of the tools of the OpenSource community. The community provides proxy generators and exclipe integrations [6], which simplify the use of JCo.
SAP Enterprise Connector
One very comfortable possibility for using JCo is available when developing Java in SAP. Once a developer is familiar with the possibilities of the J2EE Engine and those of the SAP development environment, NetWeaver Developer Studio (NWDS), he/she can then use the SAP Enterprise Connector. It is a plug-in for NWDS and is usually integrated into the delivery, so does not have to be installed separately. It encapsules the complexity of the JCo and creates a separate proxy class for all called ABAP functions. To do so, a small runtime component is required for the Java client. The creating of structures and copying of relevant items is still taken care of by a wizard. It can also be used in NWDS to set up connections to an SAP system and to directly search for BAPIs online. Once the right function has been found, a simple click will have the wizard generate the typical Java proxys for the target function.
Webservices
SAP has offered an implementation of Web service standards since Web application server 6.20. So-called SOAP processors can be used to address RFC-capable function modules from ABAP and convert them to Web services. The Web service implementation on the J2EE side of the WebAS 6.20 still had to be used with caution at that time. However, as of WebAS 6.0, the implementation of J2EE standards has become much more stabile and NWDS provides a complete J2EE-conform development environment. Web services can be provided quite easily in the environment. Even if NWDS is still based on an older Eclipse in version 2.0, the wizards and plug-ins provided by SAP can certainly be used. Users can easily figure out how to use them and can produce quick results. However, the JCo is needed to integrate ABAP functions into the rest of the world using the J2EE engine. There is another option if this seems too complicated, which is to pack a Web service around a BAPI directly from the ABAP. To do so, the ABAP Workbench is used to create a Web service, which only takes a few simple clicks and a few configuration settings for the authentication. The automatism also creates a suitable WSDL. Unfortunately, working with the Workbench is not easy for non-SAP developers. It definitely requires support. In this case, it is best simply to find someone who can quickly take care of the matter.
Enterprise Application Integration (EAI)
The Enterprise Application Integration (EAI) can also be used instead of connectors and SAP specifications. The tendency over the past few years to use this all-purpose tool is still unbroken, even in service-oriented architectures (SOA). The basic principle of EAI is quite simple: A central or even distributable Middleware layer provides the basic functions for connecting different services. These include connectivity, routing and transformation of information or messages. The endpoints are attached using adapters. A wide variety of data can also be transported from the source systems to the target systems. Manufacturers of EAI products also offer adapters. These may have to be configured in the target landscape and the transformations or data flow may have to be defined. Such adapters do tend to be rather costly. However, so are most EAI products, which means that their use is only profitable if the landscape and the adapters are already available. Technically, there are hardly any systems which cannot be connected by an adapter. Each manufacturer takes a slightly different approach. It is understandable that they prefer expanding their own product line and their functions, and not those from other providers. Yet everyone has SAP adapters and a reliable connection can be made using an adapter from any manufacturer.
SAP NetWeaver Exchange Infrastructure (XI/PI)
SAP’s method for EAI is the XI. The current version 3.0 is delivered as part of the NetWeaver platform and the license is free when used for internal SAP communication. However, it is quite a different story when distributing SAP data to non-SAP systems using the XI. In this case, additional licenses are required. However, one does have to admit that the integration using XI is excellent, especially from SAP’s side. Basically, the XI communication is based on HTTP and the transferred data are described in XML. Unlimited open standards are used in this case. Similarly, classic EAI infrastructures also recognize the XI adapter. However, SAP refers to them as “proxy”. In addition to ABAP and Java proxys, there are also HTTP, JDBC, IDoc, RFC, File, JMS and many others. These should cover almost all functional requirements. Yet, experts disagree when it comes to performance. One thing is certain, and that is that an additional layer usually means additional overhead.
SAP Web Dynpro
Web Dynpro is a modern variant of the class SAP dynpros. This technology can be used in the NetWeaver Developer Studio to easily create SAP-conform interfaces. It is a model-driven concept, which minimizes the coding effort and provides visual assistance when designing interfaces. The Adaptive RFC (Adaptive Remote Function Call) is used to address SAP backend systems, enabling BAPIs to be integrated into the Web Dynpro’s model-driven concept. The necessary BAPIS can be located and selected in the SAP system using a wizard. The corresponding Java proxies are then generated based on the metadata stored in the BAPIs and the data objects connected to the Web Dynpro interface elements. This process is also slightly sensitive to any changes made to the transferred data formats.
For JEE developers, the jump to NWDS and the Web Dynpro technology is a feasible undertaking. Even if they do have to get used to a few characteristics, it is still a bit similar to known and established concepts, such as MVC, components, etc. Unfortuantely, the Web Dynpro runtime libraries are only available for the SAP WebAS J2EE Engine. Thus, it cannot really be referred to as an actual integration, since most of the work is done in the SAP world and on SAP systems - even from a Java side. This scenario is a good alternative, especially when a corresponding infrastructure already exists.
SAP Enterprise Portal
The SAP Enterprise Portal (EP) is also based on the WebAS J2EE Engine Stack and is able to connect SAP backend systems. It uses a connector framework to do so. As a JCA-conform adapter, it is integrated into the J2EE Engine and assumes the communication between SAP and non-SAP applications when in the portal. Once the corresponding connectors have been integrated, the backend systems can either be addressed using a generic iView component or through the direct programming against the connector Framework API. The latter is also supported by a plug-in in NWDS. All in all, the framework not only enables the simple addressing of existing connectors, but also provides a standardized integration point for own connectors in the Enterprise Portal. A separate connector can be developed in NWDS for this purpose and deployed in the J2EE Engine. Currently, connectors are available for SAP ERP and SAP BW. JDBC is also available and can be acquired directly from SAP.
BEA/Oralce SolutionsWebLogic Portal integration
BEA WebLogic Portlets for SAP is a suite of pre-built portlets that visually integrate enterprise application data from SAP into general-purpose BEA WebLogic Portal applications. WebLogic Portal's flexible, robust infrastructure makes it easy to build new portal applications that simplify, personalize, and lower the cost of data access for customers, partners, and employees.
BEA WebLogic Portlets for SAP are built to take advantage of WebLogic Portal's capabilities. For example, administrators can use the portal to map users in the Portal to SAP users, enabling proper data security.
BEA WebLogic Portlets for SAP are supported by a powerful application connectivity architecture and framework that includes a presentation layer, processing layer, data engine layer, and database layer.
The set of included portlets map to different business objects in SAP, and can be incorporated into new or existing portal applications. The portlets are driven by a set of Java page flows that invoke an extensible processing layer and a data engine, which in turn call Java Controls to request data from SAP R/3. Data is retrieved from SAP via BAPI (Business API). The responses are processed by the data engine, and rendered by the Java page flows. Runtime data view configuration is supported using pre-packaged XSL templates.
BEA WebLogic Adapters
BEA WebLogic Adapters are easy-to-use, standards-based adapters to enterprise information systems, providing the critical "last mile" of connectivity to your applications. Designed for use with BEA WebLogic Integration, this growing portfolio of application, technology, and utility adapters conforms to the J2EE Connector Architecture specification and features enhancements that enable faster, simpler, and more robust integration of business-critical applications. The BEA WebLogic Adapter for SAP supports asynchronous, bi-directional interactions between the adapter and your SAP R/3 applications, and enables business process workflows running within BEA WebLogic Integration to transfer data to and from a SAP R/3 application. The adapter allows you to execute SAP IFR XML, IDocs, BAPI calls, or custom RFCs.
BEA WebLogic Integration
BEA WebLogic Integration converges application development and integration technologies into a single, unified platform. It delivers rapid business integration within an enterprise and empowers IT to meet dynamic business goals and new opportunities quickly, with faster time to value.
BEA AquaLogic Data Services Platform
Enable a single unified view of data from any source across the enterprise. BEA AquaLogic Data Services Platform allows data services to function as single access points for unified and consistent information - for easier data access, aggregation and updates, better data consistency, and simpler application development.
BEA AquaLogic Service Bus
BEA AquaLogic Service Bus, through its service integration and management capabilities, accelerates configuration and deployment, and simplifies management of shared services across the SOA. BEA AquaLogic Service Bus delivers intelligent message brokering, dynamic routing and transformation, all in support of heterogeneous service end-points, integrated with service lifecycle management capabilities including service registration, monitoring, and threshold-defined service level agreement enforcement.
The quantity of technical coversions for integrating SAP into the Java world is still relatively small. From a technial point of view, there are only two truly feasible solutions: Web services and Java Connectors. Anyone willing to program Java in the SAP world can also use J2EE Engine Stacks, portals or even Web Dynpros. Another broad topic is still how to integrate Web services. Whether retrieving relevant data to a JEE system using JCo and then packing it into Web services, or whether doing so directly in the J2EE Engine or even in the ABAP Stack, it all depends on the target scenario and the skills available in the developer group.
Integration by EAI/SOA is much easier. In this case, the respective manufacturers usually supports integration using adapters and the user is only responsible for data transfer and transformation. The most complete solution stack is in fact available by bea itself.
From a pragmatic point of view, more and more ready-made integration solutions in portals or even the Office suite are becoming available for a variety of application cases. Time management and accessibility inquiries do not have to be reinvented by every company, regardless of the platforms on which they will be used. The chance of finding a suitable, finsihed product is not as difficult as it used to be.
Yet, the search for a single, right way is initially disappointing. Many different factors have to be considered to find it. In addition to license fees for infrastructure, necessary hardware and expenses for finished solutions, performance and transaction security can also influence the decision. This is where experience can help you find the right solution. Especially when considering complex and major installations, there is no limit to the amount of time which can be spent searching for an optimal solution.
Additional Reading
