IBM WebSphere Developer Technical Journal: Accessing SAP Systems -- Part 2

Document options Document options requiring JavaScript are not displayed Rate this page Help us improve this content

Level: Introductory

Sandy Minocha (minocha@ca.ibm.com), Software Engineer, IBM Rational
Ahmed Khalifa, WebSphere Training and Technical Enablement, IBM Toronto Lab

02 Jun 2003

In Part 2 of this article series, three sample scenarios will illustrate the different types of SAP applications that can be built using these WebSphere products. As each sample is built, the various artifacts that are created will be described, and the structure and benefits of each sample will be discussed.

© Copyright International Business Machines Corporation 2003. All rights reserved.

Introduction

In Part 1 of this article series on accessing SAP® systems, we discussed the various IBM software products within the WebSphere® platform that exist to support access to SAP systems using Java^TM or J2EE, and provided an overview of WebSphere Studio Application Developer, Integration Edition, the WebSphere Adapter for mySAP.com, and the Quality of Service support in WebSphere Application Server.

In Part 2, we will take you through three sample scenarios to show you the different types of SAP applications that can be built using these WebSphere products, and describe the various artifacts that get created as each sample is built. At the end, we will discuss the structure of each sample more closely, and outline the benefits that each sample provides.

Back to top

Prerequisites and preparation

If you plan to follow the instructions outlined in this article, the following software is required:

• WebSphere Studio Application Developer, Integration Edition, Version 4.11
• WebSphere Studio Application Developer, Integration Edition, 4.1.2 PTF (see References )
• WebSphere Adapter for mySAP.com V1.0
• WebSphere Adapter for mySAP.com V1.0 CSD 1
• SAP R/3 release 3.1H and higher (except Version 4.0A)
• Windows® 2000 or Windows NT® 4.0 with Service Pack 6a or higher

Download the WebSphere Studio Application Developer, Integration Edition, 4.1.2 PTF and the WebSphere Adapter for mySAP.com V1.0 CSD 1 using the appropriate links in the References section.

Before developing the samples, complete the following steps:

1. Make the WebSphere Adapter for mySAP.com V1.0 CSD 1 deployable in WebSphere Studio .
   The WebSphere Adapter for mySAP.com V1.0 CSD 1 (hereafter called WebSphere SAP Adapter) comes with a readme file that explains how to make the adapter deployable in WebSphere Studio Application Developer, Integration Edition (hereafter called Application Developer). Make sure you perform these steps.
   
   
2. Add SAP native libraries to PATH .
   The following native libraries, included in the Windows directory of your deployed RAR file, need to be placed in a directory that is included in the system PATH:
   • ivjsid35.dll
   • ivjsij35.dll
   • librfc32.dll .
   
   
3. Deploy the WebSphere Adapter for mySAP.com V1.0 CSD 1 in WebSphere Studio .
   JCA 1.0 enabled Enterprise Information Systems (EIS) to be pluggable into application server environments through vendor-supplied resource adapters. IBM provides theJCA Tool Plugin as an extension to JCA 1.0 to let EIS providers write their own plug-in components for WebSphere Studio, providing the developer community with tooling support for their components. To add the WebSphere SAP Adapter to WebSphere Studio:
   1. In the Services view of Application Developer, right-click the Resource Adapters folder, and select New => Add Resource Adapter . The RAR Import wizard opens.
   2. Select your WebSphere SAP Adapter RAR file. Enter a name for the resource adapter, and select Finish . The resource will be added to the Resource Adapters folder in the Services view.
   Later, when you open the Service Provider browser, you will see the WebSphere SAP Adapter listed as an available service provider. Be aware that if the Service Provider browser is open when you import a resource adapter, then you will need to refresh this browser by closing and reopening it. To reopen the Service Provider browser, select your service project, then select the Service provider browser icon in the toolbar.
   
   
4. Test connectivity to SAP R/3 system .
   Before beginning, it's a good idea to test connectivity to a SAP R/3 system. A small code sample is included below to help you test the connectiion to your SAP system. Solving any connectivity difficulties now will help you troubleshoot any other problems you may encounter during development. To test your connectivity:
   1. Create a Java project:
      1. In Application Developer, select File => New => Project . The New Project wizard opens.
      2. Select Java from the left column and Java Project from the right column.
      3. Click Next .
      4. In the Project name field, type Client .
      5. Click Next to specify Java Build Path settings and dependent JARs.
      6. Select the Libraries tab.
      7. Select Add JARs . The JAR Selection wizard opens.
      8. Expand Installed Resource Adapters project, then expand the SAP folder. Select infobus.jar and ivjsap35.jar .
      9. Click OK .
      10. Select Finish . A Java project called Client is created and the Java perspective opens.
   2. Create and run a Java application:
      1. In Application Developer, right-click on the Client project, and select New => Class . The Java Class wizard opens.
      2. In the Package field, type sample .
      3. In the Name field, type TestR3 .
      4. Select the checkbox public static void main(String[] args) .
      5. Click Finish .
      6. Add the following code to this class:
      
      

      package sample; import com.sap.rfc.*; import com.sap.rfc.exception.*; public class TestR3 { public static void main(String[] args) { try { IRfcConnection aConnection = setup(); aConnection.open(); System.out.println( "Connection opened to " + aConnection.getSystemInfo()); } catch (JRfcRfcConnectionException e) { System.out.println("Caught JRfcRfcConnectionException"); e.printStackTrace(); } catch (Exception e) { e.printStackTrace(); } } /** The UserInfo and ConnectInfo instances contain all information to connect and log on to the SAP system. You use the MiddlewareInfo to explicitly define which middleware you want to use. Then, the FactoryManager is used to access the middleware-dependant factories that you use to create middleware-dependant instances. In this case, you use the JNI run time. **/ public static com.sap.rfc.IRfcConnection setup() { ConnectInfo fieldConnectInfo = new ConnectInfo(); fieldConnectInfo.setRfcMode(3); fieldConnectInfo.setHostName("r3host.com"); fieldConnectInfo.setSystemNo(00); UserInfo fieldUserInfo = new UserInfo(); fieldUserInfo.setClient("800"); fieldUserInfo.setUserName("r3user"); fieldUserInfo.setPassword("r3password"); fieldUserInfo.setLanguage("E"); FactoryManager aFactoryManager = FactoryManager.getSingleInstance(); MiddlewareInfo aMiddlewareJNI = new MiddlewareInfo(); aMiddlewareJNI.setMiddlewareType(MiddlewareInfo.middlewareTypeJNI); aFactoryManager.setMiddlewareInfo(aMiddlewareJNI); IRfcConnection fieldConnection = null; IRfcConnectionFactory aConnectionFactory = aFactoryManager.getRfcConnectionFactory(); fieldConnection = aConnectionFactory.createRfcConnection( fieldConnectInfo, fieldUserInfo); return fieldConnection; } }

      
      
      
      1. The UserInfo and ConnectInfo instances contain the information needed to connect and log on to the SAP R/3 system. Replace the described placeholders in the code with the values for your R/3 system.
      2. Use MiddlewareInfo to explicitly define which middleware you want to use. The FactoryManager uses this information to access the middleware-dependent factories that you use to create middleware-dependent instances. In this case, you use the JNI run time that comes with the WebSphere Adapter for mySAP.com. The getSystemInfo method is a convenient way to retrieve information about the SAP R/3 system.
      3. Save the class using Ctrl-S .
      4. Select the TestR3 class and expand the Run icon on the toolbar.
      5. From the pop-up menu, select Run => Java Application .
      6. Verify that no exceptions were encountered and you were able to successfully retrieve system information about your SAP R/3.

Back to top

Sample 1: Access SAP R/3 via Java application

In the first sample, we will build a Java application to retrieve the BAPI_COMPANY_GETLIST .

This sample provides an example of how to access SAP R/3 in a non-managed environment, in which an application server is not typically used. Instead, the Java application uses the resource adapter directly to access an EIS. Management of connections, transactions, and security must all be handled manually by the Java application. Figure 1 shows the SAP Proxy directly accessing the SAP R/3 system without WebSphere Application Server.

Perform the following steps to build this sample:

1. Create SAP Service
   1. Using the Service Project wizard in Application Developer, create a new Service project.
   2. The Service Provider browser opens with the list of available service providers. Select SAP Services . The Connection Properties page opens.
   3. In the ";SAP Import"; dialog, specify the necessary SAP R/3 connection properties for your system.
   4. In the following page, specify a query string to list the desired BAPIs/RFCs. You have the option of typing in the full BAPI/RFC name, or using an asterisk ( * ) as a wildcard. Type:
      
      BAPI_Company_GET*
      
      (With WebSphere Studio Application Developer, Integration Edition, you cannot build proxy beans for Business Objects. However, it is still possible to access all the functions of Business Objects by building individual proxy beans for their respective BAPI/RFCs.)
   5. When the list of matching BAPIs/RFCs is displayed, select http://samples.sap.ibm.com:BAPI_COMPANY_GETLIST to generate its service definition.
   
   SAP systems have very rich metadata support describing the services they offer, and provide programmatic access to this meta information. Since the metadata is in proprietary format, Application Developer relies on the WebSphere SAP Adapter's Import Service to provide a standard interface for accessing the meta information, delivering it in the form of WSDL. If you want to see all these files you might want to switch to the Packages view. Together, the following table and Figure 2 show the different kinds of files that the import service will build to describe the BAPI_COMPANY_GETLIST:
   
   

   BapiCompanyGetlist.wsdl	Service interface file. Defines the interface to the BAPI including the collection of operations it supports to the BAPI.
   BapiCompanyGetlistSAP.wsdl	Service binding file. Defines an SAP binding to manage communication requests/responses between the client and the BAPI, as well as the address of the service.
   BapiCompanyGetlist.xsd	XML Schema definition file. Defines messages in XML Schema to describe the business data that flows in and out of the service.
   BAPI_COMPANY_GETLIST.ser	Stores SAP R/3 meta information for the BAPI. This file is necessary for a successful proxy generation.

   Figure 2. Generated files
   

2. Run SAP Service
   Once created, a service can be easily invoked using a Proxy bean. We will use the Service Proxy wizard to create the Proxy bean, called SAP Proxy:
   1. Invoke the Service Proxy wizard on the service binding file BapiCompanyGetlistSAP.wsdl .
   2. In the next page, generate the SAP Proxy for BAPI_COMPANY_GETLIST using the Command bean proxy style.
   3. Double-click on BapiCompanyGetlistProxy class to open the source editor.
   4. Add the following code to the main():
      

      public static void main(String[] args) { try { BapiCompanyGetlistProxy aProxy = new BapiCompanyGetlistProxy(); // user code begin {set_inputs} // user code end aProxy.execute(); // user code begin {get_outputs} Bapi00141Table table = aProxy.getCompanyList(); if (table == null) { System.out.println("Returned table is null!"); return; } Bapi00141TableRow[] rows = table.getBapi00141Table(); for (int i = 0; i < rows.length; i++) { Bapi00141TableRow row = rows[i]; System.out.println( "Company # " + i + " : " + row.getCompany() + ", Name : " + row.getName1()); } // user code end } catch (Exception e) { // user code begin {exception_handling} e.printStackTrace(); // user code end } }

      
      
      
   5. Invoke the BapiCompanyGetlistProxy class. You should get a clean run without exceptions. In the Console view, you will see a list of company names retrieved from SAP.
   
   Since the JCA Tool Plugin framework differentiates between the Java representation and the native representation of the data structures used, two sets of helper classes are generated by the Service Proxy wizard (in addition to generating the SAP Proxy):
   • Java representation of the data structure described by XML Schema, located in the <namespace> package.
   • Format handlers which marshall the Java representation of the data structures to/from their binding-dependent native format (SAP in this case). Format handler helper classes have ";FormatHandler"; appended to their names; e.g., the associated format handler helper class for data structure XXX.java is XXXFormatHandler.java . Format handlers are located in the <namespace>.sap.rfc package; the fixed package appendix lets the framework map transparently between the Java and the SAP-specific representation. (Classes in the .sap.rfc package can also be used directly.)
     
     

   com.ibm.sap.samples	Java/WSDLRepresentation Package
   BapiXXXTablexx.java	Java representation of the different tables or rows that are passed (or returned) as parameters to/from the RFC call. This representation reads information from the generated WSDL files.
   BapireturnStructure	This structure represents the BAPI return values.
   BapiGetListRespnose.java	The response class that contains different tables and rows (as defined earlier).
   BapiCompanyGetListProxy.java	The proxy beans used to invoke the RFC Call.
   com.ibm.sap.samples.sap.rfc	The SAP-specific representation classes (does not use new WSDL based architecture).
   BapiXXTableXXX.java	The old format of Java representation; contains all the information about the generated fields in Java (not in WSDL).
   BapiXXXFormatHandler.java	Java structures marshalling classes.
   BAPI_COMPANY_GETLIST	Java Proxy bean that used to be generated in VisualAge® for Java. This class can be used directly without invoking the WSDL files, and can be used from clients developed using previous releases of SAP connectivity in VisualAge for Java.

Back to top

Sample 2: Access SAP R/3 via Web Service/EJB

In the second sample, we will build a Web service to retrieve the BAPI_COMPANY_GETLIST .

Sample 2 provides an example of how to access SAP R/3 in a managed environment, in which the Java application accesses a resource adapter through an application server, such as WebSphere Application Server. Management of connections, transactions, and security is provided by the application server, saving the developer from having to code this manually. Figure 3 shows the SOAP Proxy accessing a SAP R/3 through WebSphere Application Server.

The Web services architecture is based upon the interactions between three roles: service provider, service registry and service requestor. The interactions involve the publish, find and bind operations. Together, these roles and operations act upon the Web services artifacts: the Web service software module and its description. In a typical scenario:

• A service provider hosts a network-accessible software module (an implementation of a Web service).
• The service provider defines a service description for the Web service and publishes it to a service requestor or service registry.
• The service requestor uses a find operation to retrieve the service description (locally or from the service registry) and uses the service description to bind with the service provider, and invoke or interact with the Web service implementation.

This sample built by following the steps below provides a good example of the above scenario:

1. Create Web Service
   1. Using the Enterprise Application Project wizard in Application Developer, create EAR, Web and EJB projects.
   2. Invoke the Deployment wizard on the service binding file named BapiCompanyGetlistSAP.wsdl .
   3. Select SOAP as the inbound binding type and accept all other defaults.

   The different artifacts created by the Deployment wizard are listed in the table below:

   EJB Module
   BapiCompanyGetlistServiceBean	Session bean that implements the Web service.
   BapiCompanyGetlistServiceEJB.wsdl	Service binding file. Defines EJB binding to manage communication requests/responses between the client and the application server, as well as the address of the service.
   Web Module
   SOAP router	Listens to SOAP requests. When a request comes in, it invokes the session bean.
   BapiCompanyGetlistSOAP.wsdl	Service binding file. Defines SOAP binding to manage communication requests/responses between the client and the application server, as well as the address of the service.

   
   
2. Deploy Web Service
   Application Developer includes a WebSphere Test Environment (essentially a local copy of WebSphere Application Server, Advanced Single Server Edition, run time environment, with enhancements to support JCA), enabling you to test J2EE applications using server instances and server configurations.
   
   To create server instances (servers that can test J2EE applications) and server configurations (setup information):
   1. In Application Developer, use the Create a New Server Instance and Configuration wizard to create a WebSphere Test Environment server instance and configuration.
   2. The new server instance appears in the Server Configuration view and in the Servers view. The server configuration appears in the Server Configuration view.
   3. Using the J2C page of the server configuration, add the SAP resource adapter and the SAP connection factory, and complete the necessary SAP R/3 connection properties for your system. For example, typical properties for a system without loadbalancing would include: client, hostName, language, password, systemNo, userName.
   4. Add your J2EE application to the server configuration.
   5. Bind the SAP connection factory to your J2EE application. Using the Bindings page of the EJB Extension Editor, add the SAP connection factory to the resource reference.
   6. Start the server. This will enable the SOAP router in your J2EE application to begin listening for SOAP requests.
   
   
3. Run Web Service
   Once deployed, the Web service is easily invoked using a Proxy bean, SOAP Proxy. When executed, SOAP Proxy calls a remote method on the service as if the method was a local one. Once the proxy makes the remote call, it handles all communication details with the J2EE application (Web service implementation) using SOAP.
   
   Use the Service Proxy wizard to create SOAP Proxy (and the helper classes, described above):
   1. Invoke the Service Proxy wizard on the service binding file BapiCompanyGetlistSOAP.wsdl .
   2. In the next page, generate the SOAP Proxy for BAPI_COMPANY_GETLIST using the Command bean proxy style.
   3. Double-click on BapiCompanyGetlistProxy class to open the source editor.
   4. Add the following code to the main():

      public static void main(String[] args) {try { BapiCompanyGetlistProxy aProxy = new BapiCompanyGetlistProxy(); // user code begin {set_inputs} // user code end aProxy.execute(); // user code begin {get_outputs} Bapi00141Table table = aProxy.getCompanyList(); if (table == null) { System.out.println( "Returned table is null!"); return; } Bapi00141TableRow[] rows = table.getBapi00141Table(); for (int i = 0; i < rows.length; i++) { Bapi00141TableRow row = rows[i]; System.out.println( " Company # " + i + " : " + row.getCompany() + ", Name : " + row.getName1()); } // user code end } catch (Exception e) { // user code begin {exception_handling} e.printStackTrace(); // user code end } }

      
      
      
   5. Invoke the BapiCompanyGetlistProxy class. You should get a clean run without exceptions. In the Console view, you will see a list company names.

Other options

So far, with Samples 1 and 2, we have illustrated ways to access SAP R/3 with two types of Java applications. There are, in fact, two more types of Java applications possible (see Figure 4):

• Instead of building a Web service in Sample 2, we could have built a J2EE application with no Web service. Here, we would access SAP R/3 directly through the session bean using the EJB Proxy. The J2EE application will still be running in a managed environment; the only difference is that the SAP R/3 would not be accessable via SOAP.
• We could also take the Java application from Sample 1 and wrap it as a J2EE application. Here, we would access SAP R/3 directly through the servlet using a Web browser. Although this J2EE application would be running in WebSphere Application Server, it would not be running in a managed environment (i.e., it will not have Quality of Service), since this type of managed configuration is not supported in WebSphere Application Server V4.

Back to top

Sample 3: Access SAP R/3 via CCI-based Java application

This sample provides an alternative to Samples 1 and 2 for accessing BAPI/RFCs. The main difference is that Sample 3 uses the Common Client Interface (CCI) to invoke the BAPI/RFC call versus the Services run time used by Samples 1 and 2.

The steps to create a WSDL representation of the BAPI/RFC and helper classes for the generated SAP Service are identical to the above two samples. However, the difference lies in the set of helper classes that are used. Furthermore, once the helper classes are generated, the SAP service definition file is no longer used. (Essentially, the set of classes that represent your Java application are very similiar to the classes generated using VisualAge for Java's Access Builder for SAP R/3.)

The code sample below shows an example of how to access proxy beans using CCI APIs.

Back to top

Conclusion

Access to SAP backend systems through Java applications and Web Services is a critical factor for businesses, with application integration requirements becoming more and more important. With theWebSphere Studio family of development tools, IBM adopted the Services Oriented Architecture (SOA) as the basis for its new tooling. With this new tooling came a new architecture in which the idea of using Web Services Description Language (WSDL) as a means to generally describe services was introduced, along with the concept of an enterprise service. The new generation of tooling provides a mechanism for representing BAPI/RFCs through WSDL definitions.

The next article in this series will discuss hints and tips for developing SAP applications using WebSphere Studio Application Developer, Integration Edition, and will highlight the following topics:

• Tracing connectivity information into SAP.
• Setting the default values for your server connection.
• Reducing clutter in Java perspectives.
• Accessing BAPI/RFC parameters using service proxy classes.
• Retrieving SAPConnection using a ConnectionSpec object.
• Porting BAPI, RFC and Business Object Proxy Beans from VisualAge for Java

Resources

• WebSphere Studio Application Developer Integration Edition
  
  
• WebSphere Studio Application Developer Integration Edition 4.1.2 PTF
  
  
• WebSphere Adapter for mySAP.com V1.0 CSD 1
  
  
• Running WebSphere Studio Application Developer Integration Edition Version 4.1.1 JCA Applications on WebSphere Application Server, Advanced Edition
  
  
• The J2EE Connector Architecture (JCA) Tool Plug-in
  
  
• WebSphere Application Server InfoCenter
  
  
• J2EE Connector Architecture
  
  
• WebSphere Adapters
  

About the authors

		Sandy Minocha works for the IBM Rational ISV Enablement team, which engages with key Rational tools business partners, providing technical guidance and support as they integrate into the Rational suite of products. The team also performs technical validations of partner plug-ins for the Ready for IBM Rational software partner program.

		Ahmed Khalifa works for the VisualAge and WebSphere Enablement team at the IBM Toronto software lab. His career started back in 1986, in the hot summer of Upper Egypt, when he wrote his first spreadsheet using Basic on a Commodore 64. In 1990, Ahmed received an engineering degree in architecture with a diploma in computer science, and then worked on CAD applications using C++ on DOS, Windows, and Macintosh. Ahmed joined IBM Egypt in 1993 and worked on the development of Arabic APIs for OS/2. Ahmed joined the IBM Toronto Lab team in 1997. He can be reached at akhalifa@ca.ibm.com.

Rate this page

Please take a moment to complete this form to help us better serve you. Did the information help you to achieve your goal? Yes No Don't know   Please provide us with comments to help improve this page:   How useful is the information? 1 2 3 4 5 Not useful Extremely useful

Share this.... Digg this story del.icio.us Slashdot it!

Back to top