1. How to use SAP Debug !

JCO - Use JCO.Client class' method setAbapDebug(true) to switch debugging on for your project.

IBM Connector classes - Its not as straight forward as JCO. With JCO you can programmatically specify which function modules
you want to debug where as with IBM connector classes you have to generate a JniSettings.ser file for debug mode.

First locate the path to Jnisettings.ser on your machine. You need to over write this with the one you created for debug mode
To create this Jnisettings.ser file run the class com.ibm.sap.bapi.jni.JniSettings.class with the following command line arguments
-sapgui 1 -abapdebug 1

More information on this is Here

2. How to handle multiple connection from R/3 while using JCO.Server !

Usually when you extend JCO.Server

class MyServer extends JCO.Server {

// Process incoming requests
public void handleRequest(JCO.Function fct) {
// Application specific processing goes here

and do new MyServer().start(); it will start only one listener thread to your R3 instance which means you can have only *one*
concurrent user at any point of time. To avoid this you should create new instances for as many concurrent users as you want.

3. Can't create more than 100 connections to R/3 !

To avoid this set CPIC_MAX_CONV=<YOUR_MAX_VALUE> in the environment variable in your app server or OS.

You might also need to change this value at R/3 server( needs reboot ).

4. How to disable trace files ( CPIC*, dev_rfc.trc, *.trc) creation !

The JNI layer actually creates these files. In case of any error dev_rfc.trc gets created and you can't disable this from
your application code . However for every connection to R/3 the trace files that are created can be avoided -
use JCO.setTraceLevel(0) to switch off tracing
for JCO.Server you can use setTrace(false) method.

Alternatively if you had no luck with the above then you can disable the trace file creation from R/3 from transaction smgw.

5. How to avoid creating meta-data in the Java application !

Mostly for JCO.Server based application you need to have the function module definition(metadata) ready in the repository
before the handleRequest() is called. However this is a maintenance nightmare in the long run since you need to *hard-code*
every field/structure/table/import/export parameters in the code.
An alternative is to write function modules in R/3 having this information in the *interfaces*. When your app starts up you
should make a call to R3 to get the function module information and store it in the JCO.Repository so that the definition is
available when handleRequest() is called.
Any time there is a change in the interface the R/3 interface is updated and there is no code that maintains the meta
information at the Java application end.

6. dev_rfc.trc *beware* !

While your JCO.Server is running and the R/3 system goes down the JNI layer will generate an error log in dev_rfc.trc file
with the message that the target host is not available . This message will be added to file till the system becomes available
or you close your application.
*This file then might use up all the space on your hard drive*.

7. Generate Stateless Session Beans from VisualAge !

If your application does'nt use the overloaded ejbCreate(UserInfo) method of the generated Session bean then you can get rid
of this method so that you can define your session bean as *stateless* (since stateless session beans have the default
ejbCreate() method only) .
But watch out if you are re architecting your application since this means that now your generated beans (stateless) don't
maintain any state between method calls.