Expand +



Building Java Applications for SAP R/3 Using IBM's Visual Age

by Michael Friess | SAPinsider

June 1, 2000

by Michael Friess, IBM SAPinsider - 2000 (Volume 1), June (Issue 1)
Originally, Java was mostly known as a language to write applets, those small applications that can be incorporated into a Web page and run in a Web browser. Over time, the Java language and platform have been used to develop a broad range of applications, and they have become more and more mainstream.

     In the SAP context, developers find Java well suited to the following scenarios:

  • Web applications are built using enterprise Java technologies like servlets, JavaServer Pages (JSP), and Enterprise JavaBeans (EJB) components. The application runs on a Web application server like IBM's WebSphere and accesses the SAP system through a connector. Clients typically access the application from Web browsers through dynamic HTML, but the Web application might also support applets that communicate through Remote Method Invocation (RMI) and IIOP protocols.

  • Client/server applications are Java applications that run on a designated client and directly access the R/3 system. An installable, trusted applet may be considered as a special case, as the applet runs in a Web browser of a designated client and directly accesses the R/3 system. The advantage is the simpler deployment: it is only necessary to update the installable applet on the Web server; the client deployment is done automatically when the user accesses the Web page. Both client/ server scenarios - applets and Java applications - require a fat client and are only feasible for an intranet.

  • Thin-client applications are applets and Java applications that run in a 100% Pure Java environment. This solution requires a gateway server that communicates to the SAP system. In all these scenarios, the integration of Java with the SAP system is based on the Remote Function Call (RFC) protocol. The inbound access can either invoke RFC-enabled modules, or invoke a BAPI directly through its implementing RFC module or through the documented BAPI invocation mechanism. Outbound access is enabled through an RFC server implementation that registers Java methods to the SAP gateway and dispatches incoming requests to Java.

VisualAge for Java

IBM's integrated Java development environment, VisualAge for Java, provides tools and a runtime environment for integration of Java with SAP. VisualAge for Java delivers support for building, testing, and deploying Java applications, components, servlets, and applets, as well as JavaBeans and EJB components. For accessing enterprise resources, VisualAge for Java provides "access builders" and connectors for a range of core systems like databases, MQSeries, CICS, IMS, and others.      These tools include the Connector for SAP R/3 runtime library and the Access Builder for SAP R/3 tool. The runtime library includes a base that enables the invocation of RFC modules from Java. Additional connector enhancements are targeted for Web application scenarios. The user interface utility classes ease the GUI development of client/server applications. The included meta classes provide access to the meta information about Business Objects, BAPIs, RFC modules, tables, and structures, making this a good base for developing tools that handle these SAP objects.

     The Access Builder for SAP R/3 enables you to browse through the Business Objects and RFCs of a given R/3 system. It generates HTML documentation and JavaBeans proxies for these and even creates EJB proxies for Business Objects. The RFC proxies can be further composed to so-called EAB commands with the Enterprise Access Builder, another tool in VisualAge for Java.

Connector for SAP R/3 Base Library

On the lowest level, any SAP integration technology is based on the RFC library, a C-based native library included in the RFC Solution Developer Kit (SDK) and available on a broad range of operating systems. The way in which a Java runtime environment bridges the gap to this C library is what determines its suitability to the different application scenarios.

     In 1998, SAP and IBM defined the Common RFC Interface for Java, which can be used to access RFC modules from Java and can be implemented by different libraries. SAP also offers JRFC, a free downloadable implementation of this interface based on an Object Request Broker (ORB). The JRFC server works as a gateway between the client and the R/3 system. This architecture, which is currently only available on Windows NT, enables the use of 100% Pure Java clients and is well suited for the thin-client scenario. Figure 1 models the three scenarios: client/server, Pure Java client, and Web application.

Figure 1 Client/Server, Pure Java Client, and Web Application Server Scenario

      The connector base library uses a different approach and provides the access to the C library from Java through the Java Native Interface (JNI) standard. While the Java part remains fully platform independent, the RFC library and a small wrapper library are specific to the platform. This direct access makes it especially suited for Web application and client/server scenarios. The platform-specific native libraries are included for a broad range of platforms: AIX, OS/2, OS/400, Sun Solaris, and Windows 95/98/NT/2000.

     Designed for server-side Java, the runtime environment is tuned for reliability, scalability, and performance:

  • It handles national characters like German umlauts and the double-byte character set (DBCS) for Asian countries, and it supports all ABAP data types available for RFC interfaces.

  • It is fully thread-safe on all platforms independent of the multithread support of the native RFC library. While the Windows RFC library is thread-safe across different RFC connections, the Unix versions are not thread-safe. With R/3 Release 4.6B, thread-safe versions of the Unix libraries are in beta and accessible through the SAP site. The connector base library adds the appropriate synchronization depending on the platform-specific RFC library and makes the Java implementation transparently thread-safe even across connections. Without any technical insight, a developer can build a Web application that accesses a pool of limited RFC connections with a huge number of threads.

  • The performance has increased significantly compared to the previous version. The native libraries are shipped in two versions: one with debugging and tracing capabilities and one optimized and slimmed down for the execution (less than 100 KB under Windows). To minimize the necessary data conversion between the C and Java layer, a table caching mechanism ensures that only required table rows are converted.

     While the connector base library is primarily used in Web applications, it can also be used in trusted applets. Obviously, an applet cannot simply use the native calls in a Web browser, as this violates the Java sandbox security rules. The Netscape browser provides a mechanism that allows the user to grant trusted applets this access. A separate JAR file of the base library with the required calls to the Netscape Security API is provided, eliminating these calls in the typical deployment scenario.

     In addition to the Common RFC Interface for Java, the base library adds generic handling of SAP Business Objects, a logging facility, and an RFC server for Java. This enables outbound communication from the R/3 system to methods on the Java platform. This RFC server is designed for multithreaded usage and can process multiple remote function calls simultaneously. It supports standard calls as well as transactional remote function calls. Furthermore, it provides interfaces to do security checking and to customize the process of instantiating the function modules. Finally, it is possible to track the idling of the RFC server, so that the application may adjust its behavior depending on the workload of the RFC server.

User Interface Utility Classes

The most significant component of the UI utility classes is the Logon bean. As with the Swing tree and table classes, the business logic is kept in a model class separate from the view class. The bean provides a tab pane with three views, which you can see in Figure 2. The first view provides a list of R/3 systems and is maintained through the common saprfc.ini file. When the Logon bean is used in an applet, the saprfc.ini file can be accessed through a URL. The second and third view specify the connection to the R/3 system, and the logon information.

     Another bean facilitates the use of BAPI help values. For example, this makes it easy to provide a combination box of currencies. A number of wrapper beans easily map R/3 tables and structures and BOR information to Swing tables, trees, and listboxes.

Figure 2 Logon Bean with a List of R/3 Systems

Connector Classes

A connector gives you physical access to the enterprise function that you want to reuse. VisualAge for Java includes connectors for CICS, Encina, IMS, MQSeries, host screens, and SAP R/3. These connector implementations adhere to the Common Connector Framework (CCF). They provide a consistent means of interacting with enterprise resources like pooling connections, invoking function handling transactions, and sharing security context.

     VisualAge for Java, Enterprise Edition, includes the Enterprise Access Builder (EAB) for Transactions, which allows you to access and reuse enterprise functions and data assets by means of object-oriented Java technology. An EAB "command" is the base interaction with an enterprise system. It sends input data to the application in the enterprise system, which in turn responds with some output data. The EAB commands use the connectors to communicate with the host system. Commands define the data that gets passed to and from the host system in a single interaction. In the case of more complex interactions, a sequence of commands would be needed, and "Navigators" encapsulate the flow of interactions with an enterprise system. The EAB tools facilitate the composition of Navigators and session EJBs.

     The CCF connector implementation for SAP R/3 integrates into this framework the access to RFC modules and SAP Business Objects. The Access Builder for SAP R/3 tool is capable of generating, for a given SAP Business Object, the appropriate EJB proxies that leverage this connector infrastructure.

In Figure 3, we have generated proxy beans for the CompanyCode Business Object. The generated JavaBeans proxies for RFC modules can be used to build EAB commands with the Enterprise Access Builder in VisualAge for Java.

     Java classes created with EAB tools can be used in client and server-side Java application components. WebSphere Application Server already implements the CCF infrastructure and is the ideal deployment environment for Web applications using the CCF connectors. For those applications that simply need connection pooling and do not leverage further benefits of CCF, the Connector for SAP R/3 also includes a stand-alone connection manager. You can use the connection manager with WebSphere, with other Web application servers, or in a stand-alone application.

Figure 3 Generated Proxy Beans for the CompnayCode Business Object

Meta Classes

The meta classes retrieve and hold meta information from an R/3 system. This includes the meta information about ABAP/4 tables and structures, and RFC modules, as well as the information in the Business Object Repository (BOR): information about business domains, and Business Objects and their attributes, methods, and events.

     For most typical application scenarios, the simple use of the generated proxy beans is the natural and best choice. But there are special scenarios where RFC modules or BAPIs must be dynamically invoked or the meta information itself is needed. A development tool would be such an application, and indeed, the Access Builder for SAP R/3 tool does use the meta classes.

Access Builder for SAP R/3

You start this tool from a selected Java package in the VisualAge for Java Workbench. See Figure 4 for an example of Access Builder for SAP R/3. Use this tool to retrieve and store the meta information in the BOR and the information about the RFC modules separately. Having stored this meta information locally, you can then work with the tool without being connected to the R/3 system. You can also browse and search the BOR and the RFC modules. You can also generate HTML documentation and JavaBeans proxies for Business Objects and RFC modules in addition to EJB session beans for Business Objects. When the proxy beans are generated, the tool stores them in the package from which it was invoked.

Figure 4 Access Builder for SAP R/3

Business Scenarios

If you build an SAP-integrated application in Java, the major design decisions are to identify the type of application scenario, to specify which parts are developed in ABAP and which are developed in Java, and to decide between the different Java technologies: using applets, servlets/JSP files, or servlets/JSP files with EJB. You identify or develop the required BAPIs and RFCs within the ABAP Workbench, generate the corresponding proxy beans with the Access Builder for SAP R/3, and develop the Java components that build your application within VisualAge for Java. We have already seen successful use of these strategies in a variety of companies.

     One multibillion dollar manufacturer with plants in the US, Canada, and Mexico has Web-enabled in-house processes such as a rapid order-entry system to place customer orders immediately during the customer call. While the data validation is performed immediately, the order is submitted in the background. A metrics application for the high-level management provides full-color charts of the full order-to-cash process by a variety of metrics and qualifiers - e.g., EDI vs. telephone orders - easily accessed through the Web browser. Further applications for customers and co- manufacturers are in the prototype stage.

     Another example is Degussa-H|ls AG, which was one of the first customers to go live in early 1999 with an in-house Web application to ease the purchase process for several hundred employees. In a third example, a Canada-based communication network services provider now offers an order tracking system to its registered customers on the Internet.

     Other software companies have built their solutions with VisualAge for Java. For example, a German-based company has developed an application that integrates two of its e-commerce solutions with the R/3 system for functions like product availability, order placement, and order status.


Java brings a new dimension of openness to the SAP R/3 environment. The "Write once, run anywhere" paradigm of Java allows you to develop, reuse, and deploy your application logic for traditional client-side applications (client/server applications and applets) as well as server-side applications running on a Web application server. The wide range of access builders and connectors makes VisualAge for Java and WebSphere Application Server an excellent development and integration platform. The Access Builder and Connector for SAP R/3 make VisualAge for Java the primary Java development environment for SAP developers.

     For more on VisualAge for Java, visit

Michael Friess is a Consultant on SAP Projects for IBM. He consults on VisualAge for Java and WebSphere Application Server, focusing on integration with SAP systems. He has been part of the development team for Access Builder and Connector for SAP R/3, which has been done in close relationship with SAP from the start. Michael has extensive experience as an instructor on the topics of VisualAge for Java and Access Builder for SAP R/3. Figure 1 Client/Server, Pure Java Client, and Web Application Server Scenario Figure 2 Logon Bean with a List of R/3 Systems Figure 3 Generated Proxy Beans for the CompanyCode Business Object Figure 4 Access Builder for SAP R/3.

An email has been sent to:

More from SAPinsider


Please log in to post a comment.

No comments have been submitted on this article. Be the first to comment!