The SAP Java Connector (JCo1) allows you to connect to SAP2
using either a direct connection or a connection pool. When should you
use which approach? Since most customers employ JCo to build browser-based
multi-user applications, I will limit this discussion to those scenarios.
Pooled Connections for Generic Functions
JCo needs a Repository object for the metadata of the RFC-enabled
Function Modules (RFMs) that your application calls. You should have exactly
one Repository object per SAP system you communicate with.3
It is highly recommended that you use a connection pool of sufficient
size for this Repository object so that JCo never has to wait for access
to SAP’s metadata. Unused4 connections in a pool will
be closed after an application-definable wait period so that the application
does not hold on to precious SAP resources any longer than necessary.
pool should also be used for generic functions required by all applications,
like accessing metadata, retrieving help values, converting codes, etc.
Of course, it is best to componentize all these generic functions so as
to take advantage of caching read-only information in order to minimize
the number of round-trips to the SAP system.
could use the same connection pool for the Repository object and
the other generic components. Most customers utilize a special generic
userid with limited SAP authorizations for this pool.
Are You Authorized?
For access to security-critical SAP functionality (especially updates)
you should always use “real” userids. And since a connection
pool by definition uses the same userid for all its connections, the best
option would seem to be to use direct connections for these userids. Recently,
though, a customer for whom I taught an advanced JCo workshop surprised
me with a different approach. In this company, they use a connection pool
for every user. And once they explained the reason behind this, I became
an instant fan. A direct connection to SAP is held from the moment the
application issues the connect() call until it calls disconnect().
What if you have many users who start working with your application and
then go to lunch or have to do some other work? Obviously, you do not
want to keep their connections to SAP open for too long. One way of dealing
with this issue is to set the HTTP session time-out to a comparatively
low value and disconnect from SAP when the time-out occurs. The disadvantage
here is that the user may be unhappy if the time-out happens too quickly
and all user data bound to the HttpSession object (like a shopping
a connection pool for each userid allows you to be more flexible. You
can use a larger HTTP session time-out and a smaller value for the ConnectionTimeout5
property of the connection pool. In order to save memory in the JVM, you
can remove the connection pool for the user when the HTTP session time-out
occurs (and you are sure that this user does not have any other sessions
using the same connection pool!).
naming convention for the connection pool names should make sure that
the SAP system name, client number, and userid are all contained in the
connection pool name in order to avoid unpleasant surprises if you run
different applications in the same JVM.
External Commit Handling
Connection pools operate most efficiently when you release a connection
back to the pool after each series of RFM calls that are executed without
any user intervention. But you have to take into account that the SAP
session is reset when the connection goes back to the pool. This is equivalent
to typing /n in the Command Field (OkCode) of SAPGUI. In other
words, all asynchronous update task records written since the last commit
or rollback will be lost.
is not a problem as long as you perform only read-only activities or call
BAPIs that execute their own
COMMIT WORK. Since most update BAPIs
written for R/3 Release 4.0 and later require a separate commit, though,
you have to make sure that the
WORK has been issued before
you release the connection.
dive right in and have fun!