摘要: Code highlighting produced by Actipro CodeHighlighter (freeware)http://www.CodeHighlighter.com/-->   1 #-*- coding:utf-8 -*-  2 #           N:0  3 #      NW:1     EN:7  4 #   W:2             E:6 ...  阅读全文 I havn't been here for a long time.
There're so many things happend in this times.
I got the truth that do never trust anybody,anything.
Nothing will go on as you except before. User: P145460-Extended Trial Key : 0JR3GD-46X84Y-N4M7J9-YKKR5U Myeclipse注册码

for eclispe3.0版:
license name:IceCraft
VAR7ZL-819-56-54678656108018950

for eclispe2.1版:
license name:IceCraft
VAR7ZL-719-56-54678657538454123

for Myeclipse4.X
license name: csdn
license key: pLR8ZC-956-55-5467865159452715

for MyEclipse5.0
Subscriber: www.1cn.biz
Subscriber Code: jLR8ZC-444-55-4467865481680090
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.*;

Otherwise, you have to fully qualify each JCo class and interface which is very
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. Chapter Tree JCo Overview

JCo is a high-performance, JNI-based middleware for SAP's Remote Function Call
(RFC) protocol. JCo allows you to build both client and server applications. JCo works
with any SAP system starting with 3.1H. JCo is available for Windows 32, Linux, and
other platforms.

JCo's ability to use connection pooling makes it an ideal choice for web server
applications that are clients of an SAP system, but you can also develop desktop
applications.

3.1. Downloading JCo

You need to be an SAP customer or partner (with a valid SAPnet (OSS) userid) to
download JCo. Go to http://service.sap.com/connectors and follow the
download instructions. You will also find the complete list of supported platforms here.

3.2. Installing JCo

3.2.1. JCo 1.1

Make sure that you are always using the latest JCo 1.1 version, but at least 1.1.03.
The following instructions apply to Windows 32 platforms. The instructions for installing
JCo on other platforms are contained in the appropriate JCo download.

1. Create a directory, e.g., c:\JCo, and unzip the JCo zip file to that directory, keeping
the directory structure intact.

2. Copy the librfc32.dll file from your JCo root directory to
C:\WINNT\SYSTEM32 unless the version you already have there is newer than the
one supplied with JCo.

3. Make sure that jCO.jar (found in your JCo root directory) is in the class path of
any project that wants to use JCo.

For production deployment, the following files from the JCo zip file are required:
· jCO.jar
· librfc32.dll
· jRFC11.dll (if you are using JDK 1.1)
· jRFC12.dll (if you are using Java 2)

What else do you get in the downloaded zip file?
· The docs directory contains the Javadocs for JCo. Start with the index.html file.
· The demo directory contains some sample programs, including, but not limited to,
the samples discussed in this text.

3.2.2. JCo 2.0

JCo 2.0 is available with SAP Basis Release 6.20. JCo 2.0 does not support JDK 1.1
anymore, but requires Java 2 (JDK 1.2 and later). If you still need to use JDK 1.1, please
keep using JCo 1.1 (1.1.03 or later).
The following instructions apply to Windows 32 platforms. The instructions for installing
JCo on other platforms are contained in the appropriate JCo download.

4. Create a directory, e.g., c:\JCo, and unzip the JCo zip file to that directory, keeping
the directory structure intact.

5. Copy the librfc32.dll file from your JCo root directory to
C:\WINNT\SYSTEM32 unless the version you already have there is newer than the
one supplied with JCo.

6. Make sure that sapjco.jar (found in your JCo root directory) is in the class path
of any project that wants to use JCo.
For production deployment, the following files from the JCo zip file are required:
· sapjco.jar
· librfc32.dll
· sapjcorfc.dll
What else do you get in the downloaded zip file?
· The docs directory contains the Javadocs for JCo. Start with the index.html file.
· The demo directory contains some sample programs, including, but not limited to,
the samples discussed in this text.