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.