Introduction

Since 1998, IBM has been the leader in introducing tooling to access SAP® Business Application Programming Interfaces (BAPI) and Remote Function Calls (RFC) using Java^TM. IBM's early realization of Java's role on the server side meant that Quality of Service (QoS) and reliability of the runtime components would become as important as the tooling itself. This resulted in the superb tooling enjoyed by VisualAge® for Java, coupled with the highly reliable run time built on the IBM Common Connection Framework (CCF).

With theWebSphere® Studio family of development tools, IBM adopted J2C/JCA Standards and coupled them with an Open Source platform 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. While the previous generation of SAP tooling was based on CCF, the new generation of tooling provides a mechanism for a back end to communicate with the server using Java modules through the use of a Resource Adapter Archive (RAR) file. This provides a standard, tool-independent way for an RAR file to interact with tooling programs for all back end access, and makes it easier for developers of both front end Web applications and back end applications to understand, support, and communicate with each other, regardless of the tools or access schemes either is using.

IBM provides an RAR file to enable interaction between WebSphere products and SAP systems, known as the WebSphere Adapter for mySAP.com. In this three-part article series, different approaches and techniques for accessing SAP systems using the WebSphere Adapter for mySAP.com and WebSphere Studio Application Developer, Integration Edition, Version 4.1.x, will be discussed, along with how these tools and techniques relate to existing SAP proxy beans. Part 1 will provide an overview of IBM's next generation of SAP tooling and how it works with WebSphere Studio Application Developer, and an introduction to enterprise services. Subsequent articles will discuss building proxy beans to connect to SAP systems and usage scenarios, migrating VisualAge for Java SAP code into WebSphere Studio, and hints and tips for deployment, debugging and productivity.

Back to top

WebSphere Studio JCA tooling

Among the features available with WebSphere Studio Application Developer, Integration Edition (hereafter called Application Developer), are three key components critical to enterprise application integration tasks:

• Enterprise services
• JCA Tool Plugin
• Business process flows.

With the new tooling, enterprise services is used as a mechanism to connect to back end data, such as to data from an SAP server. This connection to the back end can occur the following ways:

• At design time
  Using the JCA Tool Plugin, Application Developer connects to an SAP server, finds the proper BAPIs, builds WSDL files to describe them, builds proxy beans, etc.
• At run time
  Using the WebSphere Adapter for mySAP.com (hereafter called the WebSphere SAP Adapter), there are two ways to access the back end, once you have the WSDL files that describe them:
  1. Build proxy beans that do not use enterprise services.
  2. Build proxy beans that use enterprise services, enabling the use of automatic managed connections, data flow, etc.

Before discussing these methods in detail, let's take a closer look at the components of these methods, namely enterprise services, the JCA Tool Plugin, and business process flows.

Enterprise services

Think of an enterprise service as a sort of procedure that exists in your enterprise, completely described in WSDL. Unlike Web services, which typically use SOAP over HTTP to access its source, an enterprise service can be pound (binding process) into any source over any type of protocol. In the case of SAP, an enterprise service will use the WebSphere SAP Adapter to reach the desired BAPI/RFC on the SAP server. Figure 1 shows the enterprise service WSDL document architecture:

In the upper section of the WSDL document, you see the Abstract Service Interface Definition, which is called a PortType in WSDL. PortTypes consist of one or more operations with input and output, which are described by messages. Messages are entered using XML Schema, which you use to describe the business data that flows in and out of the services.

The lower section of the WSDL document lets you describe how the service interface is implemented and where you can find it. This is done in WSDL through extensibility elements. For example:

• the service location is described by a service provider-specific port extensibility element.
• the service implementation is described by service provider-specific extensibility elements in the binding section.

Being able to extend WSDL is a very powerful feature, because it means you can describe any kind of service; it is not limited to Web services. Figure 2 shows the other services available in WebSphere Studio Application Developer.

JCA Tool Plugin

JCA 1.0 enabled Enterprise Information Systems (EIS) to be pluggable into application server environments through vendor-supplied resource adapters. IBM provides the JCA 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.

The JCA Tool Plugin defines how to provide EIS-specific binding extensions to WSDL, and also defines how a tool environment is to interact with an EIS system to get meta information about the functions it offers. The JCA Tool Plugin also defines how an EIS system provides code generation contributions, and covers the JCA Common Client Interface (CCI) extensions that take the metadata support into account for doing EIS system service invocations.

See References for more information on the JCA Tool Plugin.

Business process flows

Business Process Flow (hereafter called Flow) technology is an important piece of the middleware stack. IBM has long been offering Flow technology as part of a number of products (most notably, MQSeries Workflow for people-based workflows, MQSeries Integrator for message flows, MQSeries Adapter Offering for MQ-based adapters, and Enterprise Access Builder for Java-based adapters). The newpure-Java flow engine, written as a WebSphere enterprise service, enables the tight integration of Flow technology with other services offered by J2EE.

A flow consists of a series of service nodes, with each node representing the invocation of a service operation. Service nodes are tied together by control links which indicate the sequence of execution, under which condition execution takes place. The data flow between service nodes is constructed using data links. These data links can include data mapping nodes, for cases when messages between service nodes do not match. The flow composition is described using the Flow Definition Markup Language (FDML).

Application Developer provides visual flow-based tools to define the sequence and flow of information between application artifacts such as back end adapters, Java beans, EJBs, Web services or other flows. (In WebSphere Studio Application Developer Version 4.1.x, only non-interruptible, short-running, and synchronous flows are supported. This type of flow is referred to as a microflow or a Service flow. Interruptible, long-running and asynchronous flows are planned for future releases.)

Back to top

WebSphere Adapter for mySAP.com

The WebSphere SAP adapter provides a conduit for SAP to communicate between an SAP R/3 system and Java-based applications. The WebSphere SAP Adapter consists of three components (Figure 3):

• Base Connector
• JCA Resource Adapter
• JCA Tool Plugin

Base Connector

The Base Connector contains the runtime classes needed to access SAP R/3 systems. It implements the client interface of the SAP RFC protocol according to the Common RFC Interface for Java, a middleware-independent layer for RFC access. Thus, applications built with the Base Connector can use different SAP R/3 access methods at run time without recoding. A Java Native Implementation (JNI) of the Common RFC Interface for Java is included with the Base Connector.

JCA Resource Adapter

JCA provides a common infrastructure programming model for resource adapters. The common infrastructure programming model defines the contract between a JCA-compliant application server and a JCA resource adapter. It enables the application server to control the state of the resource adapter, while the resource adapter can leverage Quality of Service provided by the application server (such as security, transactions, connection pooling, etc.) in an easy way. The JCA Resource Adapter component inthe WebSphere SAP Adapter implements the JCA 1.0 specification.

For more information, see WebSphere Adapter for mySAP.com V1.0 in the References section.

JCA Tool Plugin

The JCA Tool Plugin component in the WebSphere SAP Adapter makes the adapter pluggable into WebSphere Studio Application Developer.

The JCA Tool Plugin includes the following components:

• A set of WSDL extensibility element implementations that define a connector binding specific to the WebSphere SAP Adapter.
• A set of runtime components which enable the WebSphere SAP Adapter to be invoked as a service.
• A tool descriptor file to be used by tool environments to use the WebSphere SAP Adapter.

For more information, see WebSphere Adapater for mySAP.com V1.0 CSD 1 in the References section.

Back to top

Quality of Service in WebSphere Application Server

SAP connectors enjoyed a bullet-proof reputation under VisualAge for Java, and running under WebSphere Application Server since Version 2.0, the reliability of the runtime and server components has carried on with the new J2C-compliant adapter and the emergence of the new tooling standard discussed above. The overall Quality of Service in WebSphere Application Server is provided by three services:

• Connection pooling
• Transaction management
• Security management

Connection pooling

When retrieving data from an SAP server,much the total transaction time (from making the connection to receiving the data to closing the connection) is spent making the connection itself. Connection pooling alleviates this bottleneck. When you call for a connection, you are just passed a handle to the next available connection that's already in a ready state. By eliminating the connection time, performance is improved greatly, and scalability is handled by predefining as many connections in the pool as you need.

The EJB container in WebSphere Application Server V4 supports managed connections, meaning that enterprise beans can use the managed environment in this release. This support is not extended to the Web container, however, so servlets cannot directly use the managed environment. They must instead make a call to an enterprise bean to utilize the managed environment.

You can limit the number of connections that exist at any one time by specifying a value in the Maximum Connections field of the SAP connection factory. After this number is reached, no new connections are created and the exception javax.resource.spi.ResourceAllocationException is thrown. Alternatively, you can specify that new connection requests wait a period of time for a connection to become available. This period of time is specified in the Connection Timeout field of the connection factory. You can also set the number of minimum connections that must exist at any one time by specifying a value in the Minimum Connections field of the connection factory.

There is no recomended specific values to set on the maximum connections and minimum connections fields. The ideal value for maximum connections depends on the network throughput from WebSphere Application Server to SAP. Setting the value to beyond what the network can handle will result in degradation. The value for minimum connections depends on how many connections you can afford (in terms of cost) to keep open. It would be ideal if this value was set to equal the maximum connections value.

To get a managed connection in WebSphere Application Server (Figure 5):

1. The J2EE application makes a call to look up an SAP connection factory.
2. WebSphere Application Server returns an SAP connection factory from the JNDI server back to the J2EE application.
3. J2EE application requests the SAP connection factory for a connection to the SAP server. The SAP connection factory sends a request to WebSphere Application Server for a managed connection.
4. From its connection pool, WebSphere Application Server returns a managed connection back to the J2EE application.
5. J2EE application uses the managed connection to send and receive data from a resource adapter.
6. The resource adapter uses the managed connection to send and receive data from SAP.

Transaction management

There are basically three types of transactions:

• No transactions
• Local transactions
  These transactions are managed internally by the resource manager (i.e., the SAP resource adapter) and are utilized when only one resource manager is involved. Local transactions only support one phase commit (1PC) because they only reference one SAP system.
• Global transactions
  Global transactions (also known as JTA or XA transactions) are managed by a transaction manager, which controls and coordinates transactions across multiple resource managers. The transaction manager coordinates the two phase commit (2PC) process across multiple resource managers as follows:
  1. Phase 1:
     • The transaction manager asks all resource managers to prepare to commit their work.
     • If a resource manager can commit its work, it replies affirmatively and hardens its recoverable data to permanent storage.
     • A negative reply reports an inability to commit for any reason.
  2. Phase 2:
     • The transaction manager directs all resource managers either to commit or rollback work done on behalf of the global transaction, based on the replies from Phase 1.

If the resource adapter supports global transactions then it must also implement support for 1PC. This allows the transaction manager to do 1PC optimization.

There are two types of optimization (not currently supported in WebSphere Application Server V4):

• Local transaction optimization
  Forces the use of 1PC in the situation when 2PC is not needed for a global transaction. For example, this would be used when only one resource manager was referenced, making 2PC unnecessary overhead. The result is the transaction manager skips the prepare statement and goes straight to commit or roll back.
• Last resource optimization
  Also known as last agent optimization, this type of optimization allows the use of a single 1PC resource in a global transaction, along with any number of 2PC resources. At transaction commit, the 2PC resources will first be prepared. If successful, the 1PC resource will be called to commit, followed by a call to commit for 2PC resources.

The CSD version of the WebSphere SAP Adapter also provides an RAR file whose transaction attribute is set to NoTransaction. This may be necessary if you are using the WebSphere SAP Adapter in a 2PC scenario with last resource optimization and an additional 1PC resource. Since last resource optimization only works with a single 1PC resource, this scenario would not work with the WebSphere SAP Adapter that supports local transactions. However, since the default of the WebSphere SAP Adapter that does not support transactions is to autocommit every BAPI/RFC call, you need to be aware of potential processing problems associated with this behavior. For example, it's possible that during a global transaction some BAPI calls will be exectuted successfully, meaning they are autocommited. If an error occurs when accessing one of the resources participating in the transaction, the transaction can fail and be rolled back. This could lead to a state where changes made in SAP remain persistent, whereas the other resource updates are discarded.

Security management

To create a connection to an SAP server, there must be some form of an SAP signon to authenticate who the connection requester is. There are two types of authentication mechanisms:

• Application managed authentication
  This requires the application to pass userid and password credentials through the ConnectionSpec to SAP.If the credentials in the ConnectionSpec are not set, then the credentials from the userid and password fields of the SAP connection factory are used. This will be discussed further in Part 4 of this article series.
• Container managed authentication
  The application relies on the application server to provide security credentials, rather than have them manually specified by the application.

Only application managed authentication (Option C in the JCA specification) is supported in WebSphere Application Server V4. The <res-auth> element of the deployment descriptor, which determines whether application or container managed security should be used, is ignored.

Back to top

Conclusion

The WebSphere SAP adapter, along with WebSphere Studio Application Developer and WebSphere Application Server, provides a means of integrating SAP systems in Web applications using Enterprise Services and generic WSDL description files. This new connectivity builds on the great Quality of Service that the SAP Adapter enjoyed in previous releases, while expanding it into an open architecture.

The next article in this series will discuss building proxy beans to connect to SAP systems, and will highlight the following topics:

• How to setup WebSphere Studio to work with the IBM WebSphere SAP Adapter
• How to build the SAP Enterprise Service WSDL
• Building old style proxy beans using managed connections
• Building new style proxy beans using managed connections
• Using new style proxy beans to build Web services.

Resources

• WebSphere Studio Application Developer Integration Edition
  
  
• 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

Rate this article

Comments

Back to top

Table of contents

• Introduction
• WebSphere Studio JCA tooling
• WebSphere Adapter for mySAP.com
• Quality of Service in WebSphere Application Server
• Conclusion
• Resources
• About the authors
• Comments

Local resources

• IBM Innovation Center - Austin, TX
• IBM Innovation Center - Chicago, IL
• IBM Innovation Center - Dallas, TX
• IBM Innovation Center - San Mateo, CA
• IBM Innovation Center - Waltham, MA
• Technical Briefings in North America

Dig deeper into WebSphere on developerWorks

Discover knowledge paths

Skill-building guides for WebSphere, Linux, open source, cloud, Java, business analytics, and more.

Special offers