Chapter Four. Connecting to SAP
JCo supports two programming models for connecting to SAP: direct connections,
which you create and hold on to as long as you want, and connection pools, from which
you take a connection when you need it and to which you return it as soon as possible so
that others can use it. These two models can be combined in one application.
If you are building web server applications, you definitely want to use connection pools8,
but they can also be used in desktop applications.
4.1. Direct Connections
In our first sample program, TutorialConnect1, we want to connect to SAP, display some
connection attributes, and finally disconnect. The complete code for this, as well as for all other sample programs, is listed in Appendix B.
4.1.1. New classes introduced JCO9
The main class of the SAP Java Connector. Offers many
useful static methods.JCO.Client Represents a connection to SAP.JCO.Attributes Attributes
of a connection, e.g., the release of the SAP system.
4.1.2. Import statements
Any program using JCo should contain the following import statement:
import com.sap.mw.jco.*;
inconvenient.
4.1.3. Defining a connection variable
JCO.Client mConnection; A connection with SAP is handled by an object of class JCO.Client. Since the term client
means a logical partition of an SAP system (and has to be entered when you log on to
SAP, for example), this text calls an object of class JCO.Client a connection.
4.1.4. Creating a JCO.Client object
// Change the logon information to your own system/user
mConnection =JCO.createClient("001", // SAP client
"<userid>", // userid
"****", // password
"EN", // language (null for the default language)
"<hostname>", // application server host name
"00"); // system number
You do not use a constructor to instantiate JCO.Client objects. Instead, you use the
createClient() method of class JCO. There are several overloaded versions of this method
to support:
· Connections to a specific application server (as in the above example),
· Connections to a load balancing server group,
· Connections based on the information in a java.util.Properties object. This is
especially useful in order to avoid hard-coded system/user information in the Java
code.
Several other versions are described in the Javadocs10.
4.1.5. Opening the connection
Creating the JCO.Client object does not connect to SAP, but a subsequent call to
connect() will accomplish this:
try 
{
mConnection.connect();
}catch (Exception ex) {
ex.printStackTrace();
System.exit(1);
}
4.1.6. Calling a function
Now we are ready to call functions in SAP. Since we need to learn a few more things
before we can call actual application functions, in this sample program we just print out
the RFC attributes for our connection.
System.out.println(mConnection.getAttributes()); See the Javadoc for JCO.Attributes for a discussion of the individual properties.
4.1.7. Closing the connection
After we have accomplished whatever it was we wanted to do (call one BAPI or a few
hundred), eventually we want to disconnect again:
mConnection.disconnect(); As opposed to using connection pools (see below), where you want to return the
connection to the pool as soon as possible, for direct connections it is not a good idea to
connect to SAP, call one function, and disconnect again for every function call. There is
some overhead involved in logging on to SAP and therefore we should stay connected
until we are finished or until we know that there will be no further activity for quite some
time.
4.1.8. Sample output
The output from running TutorialConnect1 should look similar to this:
DEST: <unknown>
OWN_HOST: arasoft1
PARTNER_HOST: hostname
SYSTNR: 00
SYSID: XYZ
CLIENT: 400
USER: TGS
LANGUAGE:
ISO_LANGUAGE:
OWN_CODEPAGE: 1100
OWN_CHARSET: ISO8859_1
OWN_ENCODING: ISO-8859-1
OWN_BYTES_PER_CHAR: 1
PARTNER_CODEPAGE: 1100
OWN_REL: 46D
PARTNER_REL: 46B
PARTNER_TYPE: 3
KERNEL_REL: 46D
TRACE:
RFC_ROLE: C
OWN_TYPE: E
CPIC_CONVID: 31905351 In case you cannot run this sample program successfully, make sure that the system and
user information has been changed to the correct values. Also check that the class path
includes the JCo directory and the sample program itself. If that still does not help, there
is some networking/configuration problem and you need to talk to your SAP Basis
administrator.
4.2. Connection Pools
In (web) server applications, we usually use–at least to some extent–generic userids to
log on to SAP. In that case it makes sense to use connection pooling. In this chapter, we
will discuss how to use connection pools with JCo. For a general discussion on when and
how to use connection pools, how to separate an application into generic and specific
parts, etc., see the in-depth discussion on Connection Pooling in Appendix A-1.
A JCo connection pool is identified by its name and is global within the Java Virtual
Machine (JVM). All connections in a pool use the same system/userid/client information.
There can be as many pools as you need, though.
In sample program TutorialConnect2 (remember: Appendix B contains the complete
program listing), we will list the connection attributes the same way we did in
TutorialConnect1. The only difference is that we now use connection pooling.
4.2.1. New classes introduced
JCO.Pool Represents one connection pool.
JCO.PoolManager Manages all connection pools within one JVM.
4.2.2. Selecting a pool name
static final String POOL_NAME = "Pool";
As far as JCo is concerned, you can use any pool name. Just remember that a pool is
global within the JVM, so different applications running in the same JVM need to follow
some naming standard to avoid unpleasant surprises.
4.2.3. Does the pool exist already?
JCO.Pool pool = JCO.getClientPoolManager().getPool(POOL_NAME);
if (pool == null){ All pools are managed by the global JCo PoolManager object (a singleton), which we
can access via the getClientPoolManager() method of class JCO. The getPool() method
tries to access a pool with the specific pool name. null is returned if no such pool exists.
If we are sure that no pool with the given name already exists when we execute our code,
then obviously we can skip the check and proceed to the pool creation immediately.
4.2.4. Creating a connection pool
OrderedProperties logonProperties =OrderedProperties.load("/logon.properties");
JCO.addClientPool(POOL_NAME, // pool name
5, // maximum number of connections
logonProperties); // properties
To create a new connection pool, we use method addClientPool(). The maximum number
of connections specified can never be increased, so we have to choose a number large
enough for our application. Several overloaded versions of addClientPool() allow us to
specify logon information in different ways. In this case, we have chosen to use a
Properties object, created from a file using a utility class called OrderedProperties (a
subclass of Properties, see Appendix B for the complete source code). Any other way of
creating a Properties object could have been used instead.
The following is a sample logon.properties file:
jco.client.client=001
jco.client.user=userid
jco.client.passwd=****
jco.client.ashost=hostname
jco.client.sysnr=00
Whenever we need an actual connection from the pool, we will borrow (acquire) it, make
one or more calls to SAP, and finally return (release) the connection to the pool. For a
detailed discussion of application design issues related to connection pools, refer to the
Connection Pooling discussion in Appendix A-1.
mConnection = JCO.getClient(POOL_NAME); The getClient() method is used to acquire a connection. JCo will either give us an
existing open connection or open a new one for us – until we reach the limit of
connections specified for the pool.
There is an overloaded version of getClient() with an additional parameter that is only
required for R/3 3.1 systems. See the discussion of Using Connection Pools with R/3 3.1
in Appendix A-2.
If all connections in the pool are in use and the pool has reached its maximum size, JCo
will wait for a certain time. If no connection has become available in the meantime, JCo
will throw an exception with the group set to JCO.Exception.JCO_ERROR_RESOURCE. (See discussion of exception handling below). The default wait period is 30 seconds. You can change the value by calling the setMaxWaitTime() method available for the PoolManager as well as for individual JCO.Pool objects. The new value is passed in milliseconds.
System.out.println(mConnection.getAttributes());
}catch (Exception ex) {
ex.printStackTrace();
}finally {
JCO.releaseClient(mConnection);
}
After our getAttributes() call is complete, we release the connection with releaseClient().
We normally put this into a finally block so that it will be executed regardless of
whether or not an exception was thrown. Not releasing connections would eventually
lead to big problems since all connections could become unavailable and no new requests
requiring a connection could be processed any more.
In terms of our session with SAP, the session begins when we call getClient() and it ends
when we call releaseClient().
As long as our application is stateless – as far as SAP is concerned – we will always
release the connection back to the pool as soon as we have finished with the SAP calls
connected to one activity. Not necessarily after each SAP call, though. In other words, if
you need to call multiple RFMs in a sequence, uninterrupted by user or other external
interaction, you should keep the connection11, and return it after all your calls are done.
For a discussion of SAP state and commit handling, see Appendix A-5 on BAPIs, State,
and Commit.
Note that when you use a connection pool, you never call the connect() or disconnect()
methods of JCO.Client. The PoolManager takes care of all this as appropriate. If you are
interested in knowing how long the PoolManager keeps connections to SAP open and
how you can control that behavior, read Appendix A-3 about Dynamic Pool
Management. Appendix A-4 discusses Pool Monitoring.
posted on 2005-12-06 20:17
Dr.Magic 閱讀(1955)
評論(0) 編輯 收藏