摘要: 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.

Chapter Two SAP Remote Function Call (RFC)

Before you can start with JCo programming, you need to understand the SAP architecture
to a certain extent, particularly how you can invoke SAP functionality from the outside
(client programming) and how ABAP applications can invoke your components (server
programming).

The basis for all communication between SAP and external components (as well as for
most communication between SAP components) is the Remote Function Call (RFC)
protocol. RFC comes in three flavors.
Most client programs want to use regular, Synchronous RFC (sRFC), but SAP also
supports Transactional RFC (tRFC) and Queued RFC (qRFC). tRFC is used mainly to
transfer ALE Intermediate Documents (IDocs). Currently, this text covers only sRFC, but
JCo also supports tRFC and qRFC.

2.1. BAPIs and Other RFMs

ABAP Function Modules can only be called from an external client if they are marked as
RFC-enabled. R/3 contains several thousands of such RFC-enabled Function Modules
(RFMs). Amongst them are the BAPIs. BAPIs are RFMs that follow additional rules and
are defined as object type methods in SAP's Business Object Repository (BOR). Use
transaction codes BAPI and SE37 to investigate the metadata of the BAPIs and other
RFMs in SAP. If you do not have access to an SAP system, or you want to look up
interfaces in a different release, use the SAP Interface Repository
(http://ifr.sap.com).

An RFM can be released for customer use or not.(Actually, there are three states: not released, released within SAP, released for customer use. For people
outside of SAP, the two former categories can be subsumed under unreleased.) Most BAPIs
are released RFMs, only very new ones may be unreleased at first so that SAP and the customers can test them for a while before they are released in a subsequent release.
On the other hand, there are quite a few extremely useful RFMs that are not officially released for customer use.

Many of these RFMs are not documented (or only in German), which makes it harder to
figure out exactly how they work. Additionally, SAP has reserved the right to make
incompatible changes to unreleased RFMs. Using these directly in your applications
could thus result in a huge maintenance effort. Hence all access to unreleased RFMs
must be done through components in order to limit maintenance to this one component
as opposed to potentially many individual applications.

2.2. RFC-enabled Function Modules (RFMs)

RFMs can have three types of parameters, import (the client sends these to the RFM),
export (RFM sends these back to the client), and tables (bi-directional). Import and
export parameters can be simple fields (a.k.a. scalars) or structures.(Since some time
SAP now also allows complex structures and tables as parameters. The BAPIs do not use
this capability, as far as I know (nothing is ever really certain in BAPI land). JCo supports complex parameters, but this text ignores them for now.) A structure is an
ordered set of fields.

A table parameter has one or more columns (fields) and contains zero or more rows.
Import and table parameters can be mandatory or optional, export parameters are always
optional. You can check these attributes in SAP or even at runtime.

Some people assume that table parameters are somehow magically linked to the database
tables in SAP. That is not the case. If you change a table that an RFM call returned,
nothing happens in SAP. A table is really just a form of glorified array (glorified
because we have metadata for the columns). Changes in SAP will only happen if you call
an RFMthat uses a table parameter you pass to it in order to update the database.

RFMs can also define ABAP exceptions. An ABAP exception is a string (e.g.NOT_FOUND) with
an associated language-dependent message text. We will discuss exception handling below.

2.3. The SAP Data Dictionary

In RFC programming, eventually we always deal with fields. These fields can be scalar
parameters themselves or contained in a structure or table row. Most, but not all, fields
used in RFMs are based on Data Dictionary (DD) definitions. Each field in the DD is
based on a Data Element (which in turn is based on a Domain) or a built-in DD data type.
The Domain defines the basic technical attributes (data type, length, conversion routine,
check table, etc.), whereas the Data Element contains the more semantical information
(texts and documentation).

There is a lot of metadata available for each field in SAP. I will now introduce the most
important attributes and how they affect your applications (more details can be found in
the next section):
· Data type, length, number of decimals: These are essential for dealing with fields
   correctly and building nice user interfaces that are aware of the field attributes.
   JCo makes these attributes available to the client program.
· Check table: Many fields contain codes. End-users do not want to deal with them, at
   least not without the associated descriptions. When you call a BAPI and display the
   returned country code, the users will not be happy. They need the name of the country
   instead of – or together with – the code.
   If users have to enter codes, they do not want to guess; they want a list of available
   codes (Helpvalues) with their descriptions.
· Fixed values: This is similar to check tables, but the information about the codes is
   stored in the Domain, not in a separate table.
· Conversion exit: Many fields use conversion exits in SAPGUI to translate between
   the internal and external representations of data. Most BAPIs return and expect the
   internal format, which makes little to no sense to your users.
· Texts and documentation: SAP stores multiple texts per field and also extended
   documentation in many cases. This documentation is available in all installed
   languages and therefore an easy way to provide multi-lingual capabilities in your
   applications.
· Mixed case support: Many text fields in SAP are uppercase only. If users exercise
   care in entering data in mixed case, they will not be too happy to discover later that
   everything was capitalized in SAP. Your user interface should exploit the mixed case
   attribute to indicate to the users which fields are uppercase only.
   The ARAsoft JCo Extension Library allows easy access to all the required metadata that
      JCo does not expose. The library also offers services that solve all the practical 
   problems associated with the metadata,including Helpvalues, conversions, text retrieval.
   See below for details.

2.4. BAPI Specifics

As stated above, a BAPI is an RFM that follows additional rules (defined in the SAP
BAPI Programming Guide5) and is defined as a method of an object type in the BOR. An
example for a BAPI, as defined in the BOR, is SalesOrder.CreateFromDat1. The actual
RFM implementing this BAPI is BAPI_SALESORDER_CREATEFROMDAT2. When comparing the metadata shown by the BAPI Explorer (transaction code BAPI) and those in the Function Builder (transaction code SE37), you will notice that there can be discrepancies like different parameter names. When writing your actual application code,you need to use the names presented by the Function Builder. It is best to use the BAPI Explorer just as a convenient starting point to find suitable BAPIs and then review the actual metadata of the RFM in the Function Builder (unless you use proxies, see below).

The BOR presents certain attributes not available in the Function Builder:
· Is the BAPI obsolete? When SAP wants to change a BAPI in a way that would be incompatible
   with the existing version, they create a new BAPI instead, e.g. Create1 would be the new 
   version of Create. The old BAPI becomes obsolete. An obsolete BAPI is guaranteed to exist
   and work in the release in which it is marked as obsolete and the subsequent functional 
   release. For example, a BAPI made obsolete in 4.0A would still be valid in 4.5B (the 
   maintenance release for the functional release 4.5A),but might disappear in 4.6A.
· Is the BAPI released? Checking this is of utmost importance. SAP sometimes creates
   new BAPIs without releasing them yet. Only released BAPIs are guaranteed to be
   upward-compatible, though, so you should only use unreleased BAPIs if you have no
   other choice.
· Does the BAPI pop up SAPGUI dialogs? These BAPIs were built mainly for the communication
   between SAP components, they rarely make any sense in a Java application. SAPGUIs are 
   difficult to pop up from a web application running in a browser…

If you want to use BAPIs in a more object-oriented way, you need to utilize proxy classes. These proxies have the following advantages:
· A business object type in the BOR is represented by one Java class, the BAPIs are
   methods of the class.
· Instead of the somewhat ugly function and parameter names in the SAP Function Builder 
   you use the nice names in the BOR.
· You can exploit additional BOR metadata. One example is that the BOR knows which table 
   parameters are import, which are export, and which are import and export. The Function 
   Builder has no notion of this.
· You can use an easy request/response programming model. Instead of dealing with
   three parameter categories, viz. import, export, and tables, you simply have request
   and response parameters.
· You can use the Code Completion/Code Insight/Intellis*nse features of your Java IDE and 
   do not have to type hard-coded function and field names like with native JCo.
· You can generate proxies that optionally exclude those BAPIs that are obsolete, not
   released yet, or that pop up SAPGUI dialogs.

All of these advantages do not imply that you have to use proxies. Many people
(including myself) are perfectly happy with native JCo. If on the other hand, you like the
idea of using proxies, please turn to Appendix A-7.
When using BAPIs in your applications, you must also be aware of some idiosyncrasies
(some of them were introduced briefly in the section dealing with the SAP Data Dictionary). They are discussed in the following sections.

2.4.1. Conversions

BAPIs mostly use the internal representation of codes. One of the more famous examples
is units of measurement: A SAPGUI user logged on in English will type PC (piece) as a
unit while the BAPIs use the internal (German) representation ST. Another example is
customer numbers. A customer number can contain letters, but if it consists of digits
only, it is internally stored with leading zeroes. The user wants to neither see nor
have to enter these leading zeroes.

SAPGUI automatically performs the necessary conversions so that its users always see
the external representation. This is possible since for each Domain a conversion routine
(sometimes called a conversion exit) can be defined if appropriate. This exit is called
both inbound (the user enters data to be passed to the application) and outbound (the
application returns data to be displayed in SAPGUI). Data originating in the application
is converted from the internal to the external format; data entered by the user is first
validated and then converted from the external to the internal format.

The fact that, in SAPGUI, the conversion exits are always called automatically has been a
source of confusion for many developers who wanted to try out a BAPI in SAP's Function Builder (transaction code SE37) in order to learn more about the BAPI's parameters. If you run the SalesOrder.CreateFromDat2 (RFM BAPI_SALESORDER_CREATEFROMDAT2) BAPI inside SAP, for example, and enter the document (sales order) type as OR (for a standard order), all works well. If, on the other hand, you use the same code from outside of SAP, you will receive an error message telling you that you have used an invalid code.

This is due to the fact that even the very technical test environment of the Function
Builder uses the conversion exits. But the BAPI itself does not invoke them. Many developers in this situation end up hard-coding the German equivalent of OR (TA) in their programs. That may be acceptable for a quick-and-dirty demo program, but software for production use should avoid hard-coding constants that are subject to SAP customization.

Also, conversions are required for many other parameters, and it would definitely be
better to have a generic solution. The ARAsoft JCo Extension Library (see below)
automates the necessary conversions for you, but you can use the conversion BAPIs found on object type BapiService if you want to build your own component dealing with conversions.

2.4.2. Helpvalues

The BAPIs return lots of codes. When you invoke Customer.GetDetail, for example, you get back, amongst other information, the code of the country in which this customer resides. Users do not really remember what all the codes stand for, though. They want text (the code's description) in addition to, or even instead of, the code. Along the same lines,
when a user has to enter a code (e.g., a country code when adding a new customer), it would be nice if we offered a drop-down combo box with all available choices (showing the text by itself or the code and the text) instead of a plain text box where the user has to guess the correct code.

In some cases, SAP offers suitable BAPIs to retrieve the required information.
CompanyCode.GetList and GetDetail offer a list of all company codes with associated
descriptions and detailed information for one company code, respectively.
In most cases, though, we are not that lucky. There is no Country object type, for
instance. The Helpvalues object type provides BAPIs that can help us to deal with those
entities for which there is no object type in SAP. To figure out whether there is
Helpvalues support for a given entity, you must verify whether a check table or a fixed
values list is defined for the field (DDIF_FIELDINFO_GET allows you to do this at
runtime, but you can also look it up in the DD when you build your application).

Unfortunately, the Helpvalues BAPIs are hard to use and, to make matters worse, they
return different results in different SAP releases. The BAPIs are also relatively slow, so it is imperative that we make as few calls to them as possible and cache the results.
To complicate matters further, some of the entities form hierarchies. Countries, for example,contain regions (states, provinces, Kantone, Bundesländer). There are even
multi-level hierarchies (e.g., Sales Organizations containing Distribution Channels containing Divisions containing Sales Offices). You clearly need a component to deal with all these issues. If you want to avoid having to build the required component, take a look at the ARAsoft JCo Extension Library (see below) which takes care of all the necessary
processing.

2.4.3. BAPI return messages

All BAPIs are supposed to use a RETURN parameter instead of throwing ABAP exceptions.6 After each BAPI call, you should7 check the message that came back from SAP to see whether the BAPI call was successful. You have to be very careful here,though, since different BAPIs use different structures with different field names for the RETURN parameter.

The ARAsoft JCo Extension Library contains a class (BapiMessageInfo) that hides these
inconsistencies from the developer and also allows easy access to the documentation for a
BAPI message.

2.4.4. Currency amounts

Internally, SAP uses data type CURR to represent currency amounts. CURR is a packed
number (or Binary Coded Decimal, if you prefer) with two decimals. How are currencies
that use a different number of decimals stored? In order to be able to store large amounts
in currency fields, SAP shifts the amount so that the last digit of the value is stored in the second decimal position. Two Japanese Yen, for example, are stored as 0.02, which is
wrong by a factor of 100. SAP internally knows how to handle this and converts the
amounts as required before displaying them. In order to avoid that extra effort for BAPI
client programmers, SAP decided not to use data type CURR in BAPIs. Instead, the BAPI
Programming Guide states: "All parameters and fields for currency amounts must use the
domain BAPICURR with the data element BAPICURR_D or BAPICUREXT with the data element BAPICUREXT." Not all BAPIs follow the rules, though. Always doublecheck that the BAPI currency amount fields you use in your applications follow the rules.

Otherwise, you need to correct the value yourself, or let the ARAsoft JCo Extension
Library do it for you (method getCorrectAmount() of class JCoRepository).

2.4.5. Delegation

The Business Object Repository supports a concept called Delegation. This is used when
you subclass an object type and overwrite one or more of the BAPIs to enforce your own
business rules. If an SAP object type is delegated to one of its subclasses, you should
always call the RFM defined in the subclass instead of the standard SAP one.

If your company uses Delegation, or you want to sell your product to a customer who
does, you should always determine the name of the correct RFM by using some kind of
properties file or looking up the correct name dynamically using metadata access
services. In order to avoid having to build your own metadata component, you could use
the ARAsoft Java BAPI ObjectFactory that comes with the ARAsoft JCo Extension
Library.

   这是最近在一个web项目开发中遇到的问题。项目快验收时，我负责对项目进行压力测试(JMeter)。在测试中发现凡是涉及到SAP函数调用的页面最高只能达到30秒内50个并发，而且还不稳定。于是察看SAP函数的调用代码： 每个调用SAP函数的Java方法都会首先实例化一个SimpleResource类来建立连接池。同步就是这个问题的关键点，在不改变原有结构的基础上(项目中涉及这个SAP函数调用的地方超多)通过修改代码，添加同步特性后能达到10秒100~120个并发，基本能够满足业务需求，至于如何在提高并发数我觉得跟服务器配置有很大关系，除此我还没想到解决方案。修改后代码如下(偷点懒 -_-! )：
对于像web项目这种要求大量并发的情况，连接池的建立和连接释放都要好好考虑并发处理。 Chapter One Introduction

1.1. New in this Version (0.8.1)

I have added Appendix A-8 which contains a full-blown, annotated example of how to
create a sales order.

1.2. Disclaimer

This text is a preliminary, incomplete version of a book that I will publish on
programming with JCo. The complete book will have much more information. No guarantee
is given for the technical accuracy of any information in this text. We are not
responsible for any damage resulting from the use of the presented information or
running the associated sample programs.

1.3. What is JCo?

SAP's Java middleware, the SAP Java Connector (JCo) allows SAP customers and partners
to easily build SAP-enabled components and applications in Java. JCo supports both
inbound (Java calls ABAP) and outbound (ABAP calls Java) calls in desktop and (web)server applications.

1.4. Goal and Scope of This Text

This text wants to teach you how to build client applications using JCo. You are supposed
to already know Java. Some understanding of SAP would also be helpful, but you should
be able to get by even if you do not know much about SAP yet. We will cover all relevant
aspects of client programming (where Java calls SAP). The final version of this text will
also introduce outbound (server) programming.
This text does not make the study of the JCo documentation superfluous. It is probably a
good idea to look at the Javadocs for the various classes in a separate window while you
work through this text.
To try out the accompanying sample programs, you need only1 a JDK and JCo installed,
but a decent development environment (like JBuilder2) would make your life a lot easier.

1.5. Organization of This Text

In order not to confuse beginners, advanced material is presented in Appendix A. The text will tell you which chapter in this appendix will give you more in-depth information
about a topic. Appendix B is a listing of the sample programs associated with this text.