JCO.Server within Tomcat problem

Hello.
I have implemented a JCO Server as a servlet and it is working just fine. However, it refuses to allow other servlets to connect to SAP. It grabs a hold of sapjcorfc.dll and will not let go. So that when I run a servlet that needs to call a BAPI I get the following error message:
java.lang.ExceptionInInitializerError: JCO.classInitialize(): Could not load middleware layer 'com.sap.mw.jco.rfc.MiddlewareRFC'
JCO.nativeInit(): Could not initialize dynamic link library sapjcorfc [Native Library C:\WINDOWS\system32\sapjcorfc.dll already loaded in another classloader]. java.library.path [C:\Program Files\Java\jdk1.5.0_10\bin;.;C:\WINDOWS\system32;C:\WINDOWS;C:\WINDOWS\system32;C:\WINDOWS;C:\WINDOWS\System32\Wbem;C:\Program Files\ATI Technologies\ATI Control Panel;C:\Program Files\Java\jdk1.5.0_10\bin]
com.sap.mw.jco.JCO.<clinit>(JCO.java:776)
Anyone have any idea how I can tell the JCO server not to be so selfish. I tried the JCO Library 2.0.9 and 2.1.8 with same results. This is obviously running on Windows, XP variety. Tomcat 5.5 and Java 1.5.
Thank you in advance.
Rudy

> Hi Rudy,
>
> You are a little bit off topic here,
Sorry <blush> I thought I might be, but I was getting desperate. I posted it in the Java Programming but didn't get much there.
> anyway please check
> <a href="/thread/2 [original link is broken]
> 61626">this</a> thread and especially the two SAP
> notes mentioned there.
Thank you. This hint is what I was looking for. I was hoping to be able to get to it today, but I guess it'll have to wait till Monday. In the meantime I found another solution in the OSS notes yesterday. It seem as though the classloader for the sapjcorfc.dll will look for it in the same directory as sapjco.jar first. So I deleted it from the system32 folder and copied it into WEB-INF\lib folder of each project and voila it worked. Although I still want to figure out what this solution is as well.
>
> HTH!
>
> -Vladimir
Spasibo Volodya.

Similar Messages

  • JCO server problems

    Hello,
    We've developed JCO server which serve as a bridge between SAP R/3 and MS SQL database system. In R/3 system is created TCP/IP destination and JCO server connects to this destination as a registered program.
    In our test environment everything works fine. In customer production environment I face this behaviour:
    After installation of solution it works. But after "some time", when I try to test destination in SM59 and I've got this error:
    SM59 - test connection
    connection to partner broken / CPI-C error CM_PRODUCT_SPECIFIC_ERROR
    COMPONENT      NI (network interface)                                                                         
    COUNTER        2422932                                                                               
    ERROR TEXT     Connection reset by peer                                                                       
    ERROR NUMBER   232                                                                               
    MODULE         niuxi.c                                                                               
    LINE           1204                                                                               
    RETURN CODE    -6 
    What is interesting, problem persist, if i turn off JCO server (I expect error message, that no program is registered!),.... so I change the registered program ID (in SM59), change this in configuration of JCO server - it works.. but again after some time I've got that error.
    R/3 version is 4.6c
    Can you give suggestions, how to solve this problem (where should be the problem)?
    Thanks for any answer.
    Best Regards,
    Juraj

    Hi,
    It gives me the correct IP when I ping yes. It's only when the SLD tries to resolve IP via JCO destinations. Yesterday I put in all hosts in my landscape into the hosts file of the SLD, disabled the NIC that it shouldn't be using and restarted.
    Still it tries to resolve hosts in my landscape to 10.150.83.XXX. How is this possible??
    Thanks - any other ideas?
    .: HP

  • JCo server programming, properties and connection settings

    Greetings, SAP professionals.
    The reason I come to this forum is that I'm hoping to gain some insights into the use of the SAP Java Connector (JCo). I am a developer who was tasked with making a new component for a systems integration application. As is typical of integration software, our app can link together various different systems using a variety of protocols, as well as providing the means to apply business logic on messages passed from one location to another. We already have a connector acting as an SAP client which was implemented using JCo. Now, we were asked to develop a new component: a server capable of accepting RFCs from a remote SAP system acting as client. The server is to be created using the JCo classes, so basically an extension of JCo.Server, with some logic for creating function templates from configuration files.
    However, while I'm understanding the structure of the Java API, it's not entirely clear to me just what the classes do. I've found the JavaDoc for JCo to be mostly descriptive of the interface of classes and methods, but not really explaining what these achieve, or how. So I'm hoping to be set straight, as I fear I'm kind of misunderstanding the functionality of JCo... Being mainly an integrations developer, I unfortunately often have to settle for gaining a superficial knowledge of a variety of systems to quickly interface with them, so I don't have any prior knowledge of SAP but still need to be able to implement something with JCo without too much delay.
    The most important question I have is this: when a JCO.Server implementation is started, does it act as a fully standalone component capable of receiving calls, or does it merely act as a sort of listener for some main SAP system? I'm not talking about a reliability on the two .dll files (or .so for Linux) that are required for the use of JCo, I just wish to know if the JCo package is entirely self-sufficient for server functionality or if it is intended to be linked to some SAP system.
    A second problem I have is that the parameters passed to various constructors aren't clear to me... I'm not familiar with SAP terminology, nor have I worked with any client apps that make use of an SAP system.
    The meaning of client strings, gwhost, gwservice, ashost, system IDs and program IDs mostly elude me, especially when it comes to knowing what client parameters must match what server parameters.
    In order to familiarize myself with the classes, I've tried playing around with them a bit trying to create a small test app that first starts a JCO.Server instance, then tries to make a remote function call to it with a JCO.Client (within the same class, for simplicity and debugging purposes). I was wondering if this actually makes sense... Would a JCo client be capable of connecting to a JCo server, all running purely in Java, or is that nonsense?
    To eliminate some common troubleshooting options, I'll quicly describe the steps I've taken:
    Both librfc32.dll and sapjcorfc.dll were placed in the Windows system32 folder. Maybe only librfd32 needs to be placed there, but I copied both anyway to make sure.
    The directory containing the jar file and both dll files is included in my environment path variable.
    I've added a line to the C:\Windows\system32\drivers\etc\services file as follows:
    sapgw00          3300/tcp                           #SAP System Gateway Port
    I've opened port 3300 in my Windows firewall. In fact, I also tested with the firewall completely turned off.
    However, I do not manage to get my test class to work. I've tried ports 3300, 3200 and 3600. I've tried various permutations of the client and server properties. I've tried removing the line from the services file, which would prompt the client to state upon connecting that the service "sapgw00" is unknown. When I add it back in, the error changes to "partner not reached", so it is definitely picking something up.
    The server itself starts just fine, but connecting through a client doesn't work. My class source code is posted below. Maybe what I'm trying to do doesn't make any sense, but at the moment it's my best guess.
    I realize this is a pretty long post and the class, while not exactly big, also implies a bit of reading of its own. But if anyone could give me any answers that are new to me, I'd be hugely grateful. Right now I'm kind of stuck, and just setting up the service and letting our customer test on it is a somewhat slow approach that can't match developing and testing on one and the same host.
    Preliminary thanks to everyone who took the effort to read this.
    //Start of code
    import java.util.Properties;
    import com.sap.mw.jco.IFunctionTemplate;
    import com.sap.mw.jco.IMetaData;
    import com.sap.mw.jco.IRepository;
    import com.sap.mw.jco.JCO;
    public class Test {
         public static void main(String[] args) {
              Test test = new Test();
              ServerThread serverThread = test.new ServerThread();
              serverThread.start();
              while(!serverThread.isReady) {
                   try {
                        Thread.sleep(5000);
                   } catch(final InterruptedException i) {
                        System.out.println("Rudely awakened");
              try {
    //               JCO.Function func = getSampleFunction(test, "STAY");
    //               serverThread.server.handleRequest(func);
    //               System.out.println(func.getExportParameterList().toXML());
    //               func = getSampleFunction(test, "STOP");
    //               serverThread.server.handleRequest(func);
    //               System.out.println(func.getExportParameterList().toXML());
                   final Properties clientProps = getClientProps();
                   JCO.Client client = JCO.createClient(clientProps);
                   client.connect();
                   IRepository rep = JCO.createRepository("1", client);
                   IFunctionTemplate templ = rep.getFunctionTemplate("TEST_FUNC");
                   JCO.Function function = templ.getFunction();
                   function.getImportParameterList().setValue("STAY", "FIELD1");
                   client.execute(function);
                   JCO.Function function2 = templ.getFunction();
                   function2.getImportParameterList().setValue("STOP", "FIELD1");
                   client.execute(function2);
              } catch(final Exception e) {
                   e.printStackTrace(System.out);
                   serverThread.requestStop();
                   while(serverThread.isAlive) {
                        try {
                             Thread.sleep(5000);
                        } catch(final InterruptedException i) {
                             System.out.println("Rudely awakened");
              } finally {
         private static Properties getClientProps() {
              final Properties props = new Properties();
              props.setProperty("jco.client.client", "100");
              props.setProperty("jco.client.user", "");
              props.setProperty("jco.client.passwd", "");
              props.setProperty("jco.client.lang", "");
              props.setProperty("jco.client.sysnr", "00");
              props.setProperty("jco.client.ashost", "/H/localhost/S/sapgw00");
              props.setProperty("jco.client.gwhost", "localhost");
              props.setProperty("jco.client.gwserv", "sapgw00");
              return props;
         public class ServerThread extends Thread {
              public void run() {
                   isAlive = true;
                   IRepository repos = new TestRepository("testrep");
                   repos.addFunctionInterfaceToCache(getFunctionInterface());
                   server = new TestServer(repos);
                   server.start();
                   System.out.println("Server successfully started");
                   isReady = true;
                   while(!stop) {
                        try {
                             Thread.sleep(1000);
                        } catch(final InterruptedException i) {
                             System.out.println("Wouldn't let me sleep...");
                        stop = server.stopRequested;
                   server.stop();
                   isAlive = false;
                   System.out.println("Server successfully stopped");
              public void requestStop() {
                   server.requestStop();
              public TestServer server;
              public boolean isReady = false;
              public boolean isAlive = false;
         public class TestServer extends JCO.Server {
              public TestServer(IRepository rep) {
                   super("localhost", "sapgw00", "PROGID", rep);
              public void handleRequest(JCO.Function fct) {
                   try {
                        JCO.ParameterList importParams = fct.getImportParameterList();
                        final String importXML = importParams.toXML();
                        System.out.println("XML representation of import parameters: ");
                        System.out.println(importXML);
                        final String input = importParams.getString("FIELD1");
                        System.out.println("FIELD1 value: " + input);
                        JCO.ParameterList exportParams = fct.getExportParameterList();
                        if(input.equals("STOP")) {
                             exportParams.getField("FIELD2").setValue("OK");
                             stopRequested = true;
                   catch(JCO.AbapException ex) {
                        throw ex;
                   catch(Throwable t) {
                        throw new JCO.AbapException("SYSTEM_FAILURE", t.getMessage());
              public boolean checkAuthorization(String functionName, int authorMode, String partner, byte[] key) {
                   System.out.println(functionName + " " + partner);
                   return true;
              public void requestStop() {
                   stopRequested = true;
              public boolean stopRequested = false;
         public class TestRepository extends JCO.BasicRepository implements IRepository {
              public TestRepository(String name) {
                   super(name);
         public static IMetaData getFunctionInterface() {
              JCO.MetaData metaData = new JCO.MetaData("TEST_FUNC");
              metaData.addInfo("FIELD1", IMetaData.TYPE_STRING, 4);
              metaData.setFlags(0, IMetaData.IMPORT_PARAMETER);
              metaData.addInfo("FIELDX", IMetaData.TYPE_STRING, 8);
              metaData.setFlags(1, IMetaData.IMPORT_PARAMETER & IMetaData.OPTIONAL_PARAMETER);
              metaData.addInfo("FIELD2", IMetaData.TYPE_STRING, 2);
              metaData.setFlags(2, IMetaData.EXPORT_PARAMETER);
              return metaData;
         public static JCO.Function getSampleFunction(Test test, String s) {
              TestRepository testRep = test.new TestRepository("testrepository");
              testRep.addFunctionInterfaceToCache(getFunctionInterface());
              JCO.Function func = testRep.getFunctionTemplate("TEST_FUNC").getFunction();
              func.getImportParameterList().setValue(s, "FIELD1");
              return func;
         private static boolean stop = false;

    If I understood you correctly, you want to provide a "service" that can be called from SAP. To provide this service you've chosen to implement an (external) RFC server program via JCo. One common method for RFC server programs is to register in SAP on the gateway - you do this by supplying the three parameters
    <ol>
    <li><b>jco.server.gwhost</b> -  SAP gateway host on which the server should be registered (so this would be the server name or IP address of the SAP gateway; localhost is only correct, if your RFC server program runs on the same server as the SAP gateway)</li>
    <li><b>jco.server.gwserv</b>  - Gateway service, i.e. the port on which a registration can be done</li>
    <li><b>jco.server.progid</b> - Program ID under which your RFC server program can be reached (free, made-up case sensitive name, that should represent the service your RFC server is providing)</li>
    </ol>
    So essentially you're creating a listener, that is registered in SAP and waits for any invocations. Within SAP they will define a <i>RFC destination</i>, which basically represents a TCP/IP connection pointing to the SAP gateway where you registered with the given program ID. If you want more details, check the SAP help pages for <a target="_blank" href="http://help.sap.com/saphelp_nw04/helpdata/en/22/04262b488911d189490000e829fbbd/content.htm">RFC destinations</a> (you're looking for destination type <b>T</b>, see explanations <a target="_blank" href="http://help.sap.com/saphelp_nw04/helpdata/en/22/042652488911d189490000e829fbbd/content.htm">here</a>).
    Usually gateway host and service (port) are given to you by the SAP basis folks and you tell them which program ID you're using. They will then enter those parameters in an RFC destination of type <b>T</b> in SAP. So no need for any of the client parameters you've mentioned. Although, I'd like to repeat, it's usually handy to also have SAP logon parameters maintained on your RFC server program, so that you can utilize the repository data from SAP (might be irrelevant in your case).
    Hope this clarifies it a bit...

  • Scenario SAP R/3 --(RFC)-- XI--(RFC)-- JCo.Server

    Hello,
    I am wondering if anyone can send me some feeback for such scenario. SAP R/3 version is 4.6c, SAP XI is 3.0 and JCo are 2.0.12.
    I am having some trouble which I think are link to the fact that the SAP XI is Unicode and not the JCo.Server ... However I was thinking SAP XI will adapt, since it works well for scenario SAP R/3 (RFC)> XI (RFC)> SAP R/3.
    Thanks for your feeback.

    Hi Grégory,
    I guess I faced a similar problem,  the problem was that in the receiver RFC adapter you have to specify both an RFC target system and a system to lookup the metadata.
    The target RFC system hat to have the same unicodeness of the metadata lookup system that means in your case that if jco server is non unicode also you R3 has to be non unicode otherwhise it will not (never) work, because this is a mandatory requirement of the RFC adapter.
    In my case this was not possible so I was redirecting the RFC call to the ABAP stack of XI (where I had exposed the same function module which was simply recalling the same function module to the target system) and it worked/works.
    Regards,
    Sergio

  • RFC call failed: JCO.Server could not find server function 'SET_SLD_DATA'

    Hi, All
    the system is PI 7.0 EHP1 oraclei Win2003 server, I configured SLD but I run RZ70, having error "RFC call failed: JCO.Server could not find server function 'SET_SLD_DATA' ". I know there are lot of tread about this error, but none of themsolve my problem. all JCO, RFC connections and SDL DATA supplier(VA) seem OK. error message in SM21 is "Could not send SLD data"
    detail from SM21
    The system could not send the data that has been collected automatical
    for the System Landscape Directory (SLD). Check whether the gateway
    configured in transaction RZ70 has been started and whether the SLD
    bridge has been registered with this gateway.
    You can use transaction SM59 to check this in the sending system for t
    implemented RFC destinations. The RFC destinations have the standard
    names "SLD_UC" for Unicode sending systems and "SLD_NUC" for non-Unico
    sending systems. If a different RFC destination has been entered in
    RZ70, check this destination instead.
    You can use the Gateway Monitor to check the target gateways. In ABAP
    systems, this monitor is started with transaction SMGW, or you can use
    the external SAP program "gwmon". Check whether the specified gateway
    has an active registration.
    OF COURSE I checked  RFC of  SLD_UC and SMGW
    any different ideas
    Regards
    ABH

    Hi
    Please check the following notes are implemented
    Note 906454                           
    Note 907729
    You may be aware but if you are not --->RZ70 creates the required SLD* RFCs during runtime - therefore if you have defined these RFCs manually first using the same namespace you can get RFC conflicts which result in a failed submission    
    Please also check the user in the RFC is known to both systems and has required authorization to write to SLD
    Generally with SLD you have to install or select a suitable gateway to handle incoming data supply traffic
    Also the gateway you are using has be known to SLD and reflected in RZ70 - i.e these defintions have to be the same
    It is also recommended to delete all references to SLD_* RFCs in data supplier and target SLD
    after a failed submission attempt to allow RZ70 to recreate these consistently once the above has been checked
    Best wishes
    Stuart

  • "jco.server.unicode" is gone in JCO 3.0.5??!!

    Recently  we have migrated from   JCO 2.1.8  to  3.0.5.   Currently we are witnessing some problems with communications from non-Unicode Sap systems.
    In the previous version  (JCO 2.1.8)  JCoIDoc.Server had a property "jco.server.unicode"  in the latter one the property  is gone.
    AS far as I  understand, JCo3 Server based on the data sent form a client recognizes encoding and applies proper conversion. However when we try to establish a non-Unicode connection ( from a Unicode enabled system),  through setting In the SM59 transaction (tab MDMP & Unicode) u201ECommunication Type with Target Systemu201D  to Non-Unicode, we are getting  the following error :
    com.sap.conn.idoc.IDocMetaDataUnavailableException: (3) IDOC_ERROR_METADATA_UNAVAILABLE: The meta data for the IDoc type "??????????????????
    ????????å å" with extension "     SAPCFL CF5CL          ???" is unavailable.
            at com.sap.conn.idoc.rt.DefaultIDocDocument.(JCoIDocDocument.java:92)
            at com.sap.conn.idoc.jco.rt.JCoIDocDocument.createIDocDocument(JCoIDocDocument.java:170)
            at com.sap.conn.idoc.jco.rt.JCoIDocRuntime.createIDocDocumentList(JCoIDocRuntime.java:80)
            at com.sap.conn.idoc.jco.JCoIDoc$DefaultJCoIDocRuntime.createIDocDocumentList(JCoIDoc.java:144)
            at com.sap.conn.idoc.jco.rt.DefaultJCoIDocServerWorker$IDocDispatcher.handleRequest(DefaultJCoIDocServerWorker.java:107)
            at com.sap.conn.jco.rt.DefaultServerWorker.dispatchRequest(DefaultServerWorker.java:153)
            at com.sap.conn.jco.rt.MiddlewareJavaRfc$JavaRfcServer.dispatchRequest(MiddlewareJavaRfc.java:3300)
            at com.sap.conn.jco.rt.MiddlewareJavaRfc$JavaRfcServer.executePlayback(MiddlewareJavaRfc.java:2780)
            at com.sap.conn.jco.rt.MiddlewareJavaRfc$JavaRfcServer.playbackTRfc(MiddlewareJavaRfc.java:2598)
            at com.sap.conn.jco.rt.MiddlewareJavaRfc$JavaRfcServer.handletRfcRequest(MiddlewareJavaRfc.java:2489)
            at com.sap.conn.jco.rt.MiddlewareJavaRfc$JavaRfcServer.listen(MiddlewareJavaRfc.java:2310)
            at com.sap.conn.jco.rt.DefaultServerWorker.dispatch(DefaultServerWorker.java:277)
            at com.sap.conn.jco.rt.DefaultServerWorker.loop(DefaultServerWorker.java:337)
            at com.sap.conn.jco.rt.DefaultServerWorker.run(DefaultServerWorker.java:238)
            at java.lang.Thread.run(Thread.java:619)
    11:15:20,062 ERROR   Sap server details
    Class: com.syncron.bpe.engine.extinterface.sap.idoc.SapIDocServer
    Program id: GIM
    Thread name: JCoServerThread-1
    Registered (at gateway) connection count: 5
    Max thread count: 1
    Exception occured
    com.sap.conn.jco.JCoException: (104) RFC_ERROR_SYSTEM_FAILURE: IDocException occurred (raised by system karbie-nc6400|a_rfc)
            at com.sap.conn.jco.rt.MiddlewareJavaRfc.generateJCoException(MiddlewareJavaRfc.java:639)
            at com.sap.conn.jco.rt.MiddlewareJavaRfc$JavaRfcServer.listen(MiddlewareJavaRfc.java:2395)
            at com.sap.conn.jco.rt.DefaultServerWorker.dispatch(DefaultServerWorker.java:277)
            at com.sap.conn.jco.rt.DefaultServerWorker.loop(DefaultServerWorker.java:337)
            at com.sap.conn.jco.rt.DefaultServerWorker.run(DefaultServerWorker.java:238)
            at java.lang.Thread.run(Thread.java:619)
    Caused by: RfcException: karbie-nc6400
        message: IDocException occurred
        Return code: RFC_FAILURE(1)
        error group: 104
        key: RFC_ERROR_SYSTEM_FAILURE
    Exception raised by karbie-nc6400|a_rfc
            at com.sap.conn.jco.rt.MiddlewareJavaRfc$JavaRfcServer.executePlayback(MiddlewareJavaRfc.java:2785)
            at com.sap.conn.jco.rt.MiddlewareJavaRfc$JavaRfcServer.playbackTRfc(MiddlewareJavaRfc.java:2598)
            at com.sap.conn.jco.rt.MiddlewareJavaRfc$JavaRfcServer.handletRfcRequest(MiddlewareJavaRfc.java:2489)
            at com.sap.conn.jco.rt.MiddlewareJavaRfc$JavaRfcServer.listen(MiddlewareJavaRfc.java:2310)
            ... 4 more
    Caused by: RfcException: karbie-nc6400
        message: IDocException occurred
        Return code: RFC_FAILURE(1)
        error group: 104
        key: RFC_ERROR_SYSTEM_FAILURE
    Exception raised by karbie-nc6400|a_rfc
            at com.sap.conn.jco.rt.MiddlewareJavaRfc$JavaRfcServer.dispatchRequest(MiddlewareJavaRfc.java:3329)
            at com.sap.conn.jco.rt.MiddlewareJavaRfc$JavaRfcServer.executePlayback(MiddlewareJavaRfc.java:2780)
            ... 7 more
    Caused by: com.sap.conn.idoc.IDocRuntimeException: IDocException occurred
            at com.sap.conn.idoc.jco.rt.DefaultJCoIDocServerWorker$IDocDispatcher.handleRequest(DefaultJCoIDocServerWorker.java:151)
            at com.sap.conn.jco.rt.DefaultServerWorker.dispatchRequest(DefaultServerWorker.java:153)
            at com.sap.conn.jco.rt.MiddlewareJavaRfc$JavaRfcServer.dispatchRequest(MiddlewareJavaRfc.java:3300)
            ... 8 more
    Caused by: com.sap.conn.idoc.IDocMetaDataUnavailableException: (3) IDOC_ERROR_METADATA_UNAVAILABLE: The meta data for the IDoc type "???????
    ???????????????????å å" with extension "     SAPCFL CF5CL          ???" is unavailable.
            at com.sap.conn.idoc.rt.DefaultIDocDocument.(JCoIDocDocument.java:92)
            at com.sap.conn.idoc.jco.rt.JCoIDocDocument.createIDocDocument(JCoIDocDocument.java:170)
            at com.sap.conn.idoc.jco.rt.JCoIDocRuntime.createIDocDocumentList(JCoIDocRuntime.java:80)
            at com.sap.conn.idoc.jco.JCoIDoc$DefaultJCoIDocRuntime.createIDocDocumentList(JCoIDoc.java:144)
            at com.sap.conn.idoc.jco.rt.DefaultJCoIDocServerWorker$IDocDispatcher.handleRequest(DefaultJCoIDocServerWorker.java:107)
            ... 10 more
    With JCO 2.1.8  we used to solve it through setting the mentioned "jco.server.unicode"   to 1, in the  current one it seems that there is not much to configure regarding encoding.
    Please advice.

    In unicode ABAP backend systems you always have to set the destination in SM59 to "Unicode" if the communication partner is JCo. There is no choice for setting the Non-Unicode option. It won't work.
    JCo3 does not require a manual setting of the "jco.server.unicode" property any longer. Therefore the property has been deleted. In JCo3 you don't have to take care for this anymore.

  • JCO.Server appends null character to string

    I am a complete SAP and JCO newbie so I'll try making as much since as I can, given the fact that I'm not familiar with SAP terminology and technology. I've been lent as a developer to another group which needs a legacy application rewritten. The application processes a RFC and decrypts the RFC encrypted payload and returns it along with a status code.
    I have made progress - I'm able to register my server with the SAP runtime and using the SAP GUI application and the help of a SAP developer, I'm able to make an RFC call to my application. I'm able to read the parameters sent from SAP and write parameters back.
    The problem is that one of the parameters I'm writing back (java.lang.String) appears to have and extra character on SAP side. On the GUI it appears as a '#' (pound) sign. The SAP developer told me the string is terminated with a null character which I know is a C/C++ thing but not a Java thing. I don't think it is a Unicode issue. The Java server is not running in Unicode mode and any attempt to set the jco.server.unicode property (I may have forgotten the exact name) to a value of 1 causes the RFC to fail.
    I think the issue is likely to be the manner in which I defined the function parameters or the manner in which I write them. The following are code snippets:
    Defining the function:
    JCO.MetaData metadata = new JCO.MetaData(Constants.FUNCTION_DECRYPT);
    metadata.addInfo(Constants.PARAMETER_SCHEME,      JCO.TYPE_INT,    255,   0,  0, JCO.IMPORT_PARAMETER, null);
    metadata.addInfo(Constants.PARAMETER_ENCRYPTED,   JCO.TYPE_STRING, 255,   0,  0, JCO.IMPORT_PARAMETER, null);
    metadata.addInfo(Constants.PARAMETER_DECRYPTED,   JCO.TYPE_STRING, 255,   0,  0, JCO.EXPORT_PARAMETER, null);
    metadata.addInfo(Constants.PARAMETER_RETURN_CODE, JCO.TYPE_INT,    255,   0,  0, JCO.EXPORT_PARAMETER, null);
    Server request handling code:
    protected void handleRequest(JCO.Function function)
                    // Obtaining import/export parameter lists.
                    JCO.ParameterList input  = function.getImportParameterList();
                    JCO.ParameterList output = function.getExportParameterList();
                    // Getting scheme and encrypted text parameters.
                    int scheme       = input.getInt(Constants.PARAMETER_SCHEME);
                    String encrypted = input.getString(Constants.PARAMETER_ENCRYPTED);
                    // Decoding base 64 string.
                    byte[] bytes = Base64.decode(encrypted);
                    // Obtaining cipher by scheme and decrypting the text.
                    AppCipher cipher = ApplicationConfiguration.getDecryptor(scheme);
                    if(cipher == null)
                                    logger.error("Unable to get cipher due to an unknown encryption scheme: " + scheme);
                    else
                                    byte[] decrypted = cipher.decrypt(bytes);
                                    String plainText = new String(decrypted);
                                    // Setting decrypted value information and return code.
                                    output.setValue(plainText, Constants.PARAMETER_DECRYPTED);
                                    output.setValue(Constants.RETURN_CODE_SUCCESS, Constants.PARAMETER_RETURN_CODE);

    I seem to have made progress. If I define the parameter type as JCO.TYPE_CHAR instead of JCO.TYPE_STRING, it works:
    metadata.addInfo(Constants.PARAMETER_DECRYPTED,   JCO.TYPE_CHAR,   255,   0,  0, JCO.EXPORT_PARAMETER, null);
    That is the only change I made. I'm still setting the parameter value as java.lang.String. I hope this won't cause issues elsewhere. I was also able to change the field definition and set it as a byte array. However, that had the problem of having to define the exact length of the byte array in the field metadata otherwise the remaining bytes would appear as null bytes on SAP side.

  • JCo Server does not start

    Hi,
    I'm trying to create and start a JCoIDoc.Server on a Web Application Server 700 system. Because I could not find the required classes in the trfc.jar archive on the server I downloaded and packaged the required java connector classes sapidoc.jar and sapidocjco.jar in my EAR file.
    The deployment works fine and the server should be started automatically by a servlet. There are no error entries in the logfile. In addition I can see my own entries in the logfile that the servlet was executed an the server started.
    Nevertheless I can not send anything from an ECC 5.0 system to my java connector server. Using the "netstat -a" command in a DOS console on the Java server I can not even see that the port for incomming idocs is listening.
    Having a look at the ECC 5.0 system using transaction "smgw" I do not see the my JCo Server
    Has anybody an idea what goes wrong or if I forgot anything to realize? The code is quite similar to the jco sample code.
    Or is it in general not possible to start a JCoIDoc.Server on a Web Application Server 700 system?
    Best regards,
    Markus

    you should have no problem doing this....
    However -- as you downloaded the Idoc libraries instead of extracting them for the tar...?
    a) make sure they are accessible (on the classpath) They may need to be in the same directory as the JCO...
    b) make sure they are compatible... read up on the download page and in sapnotes which version exactly you need...
    Or ask your friendly basis admin where he stashed them and use the ones coming with the installation...
    Enjoy

  • JCo Server Load Balancing

    We have created a JCo Server interface using RFC modules in SAP to communicate with an external web based system.  The SAP system calls the external application via tRFC and qRFC as needed from the business transaction.  We have achieved high throughput by clustering our external web application server, putting a load balancer in front of that web application, and finally creating multiple JCo Server instances within own JVMs (currently 6 instances with 5 servers each).  The JCo Server is registered to the central gateway of the SAP system using gwhost, gwserv, and progid.  With this setup we have successfully performed up to 50,000 transactions an hour.
    My understanding is that the SAP gateway will act as a load balancer on the SAP side.  Is this right or should we consider to install a hardware load balancer "in front" of the SAP gateway and try to map this to the message server instead?  Or concern is that our JCo Server process will "flood" the central gateway and take all resources away form the SAP system.  Unfortunately the JCo Server class doesn't allow to connect to any other resource on the SAP system then the central gateway.
    Any suggestions or real live examples are appreciated.
    Stefan

    Hi Stefan
    We are doing a similar project wherein we are calling a middleware server based on the JCO.Server from SAP.
    You did say that you have achieved a throughput of 50000 transactions and we are interested in knowing how ?.
    Could you briefly tell use how you achieved it. In our case we have one instance of the JCO.Server working on the JVM.
    Here is what we did .
    We tried to start two instances of the middle ware server on the same JVM on the same BOX and register it with the gateway . This dint work .
    We were successfull in starting two instances of the middleware server from two different JVM on two different boxes and registering it at the gateway under the same id.
    This we know will work as the gateway will use its load balancing to distribute load between the two instances.
    But we are interested in knowing how we can start more then one server instance on a given JVM.
    Our questions are
    It we have threading in our middleware server, we believe it will not help as if the SAP gateway server has opened an connection with one instance of the middleware server. It is not possible for it to open another one...till the first one is complete. Hence threading within the middleware server is redundant.
    Your thoughts and comments are appreciated.

  • JCO Server and SAP trfc queue

    Hi,
    we are sending IDocs from our sap system to a JCO server. Let's assume  we are sending 1000 IDocs to it. After sending there are no IDocs in the trfc-queue and the status of all IDocs is "green". Can we assume the JCO server received all 1000 IDocs? Is an  empty trfc-queue always an indicator for a successfull sending process even there are some problems with a weak network(network interruptions). I know IDocs are tansaction based. For my understanding a transaction is okay or not. So an empty trfc queue should indicate everything went fine and all IDocs were received?
    I appreciate any comments on that issue ...
    -Steffen

    If the status of all idocs is green which indicates the communication layer is ok. As you said, the idocs are transaction based. You need to make use of transaction id to confirm everything is fine from the viewpoint of your business logic.
    Dennis

  • JCO.SERVER could not find the server function

    Hi,
    I am calling "BAPI_COMPANY_GETDETAIL".thuough the zprogram"ZBAPI_COMPANY_GETDETAIL"
    REPORT ZBAPI_COMPANY_GETDETAIL.
    DATA:BEGIN OF ITAB,
    RCOMP LIKE T880-RCOMP,
    END OF ITAB.
    ITAB-RCOMP = 99999.
    CALL FUNCTION 'BAPI_COMPANY_GETDETAIL'
    EXPORTING
    COMPANYID = ITAB.
    IMPORTING
    COMPANY_DETAIL =
    RETURN =
    The Details I Gave......
    In SM59 of R/3:
    PROGRAMID:LCRSAPRFC_PIT
    GATEWAYHOST:PITEST
    GATEWAYSERVICE:sapgw01
    Tested the connection and it is running
    ID:
    In Communication Channel.
    Application server (Gateway):PITEST
    Application server Service (Gateway):
    PROGRAMID:LCRSAPRFC_PIT
    RFC Metadata Repository parameter.
    ip of XI Server
    System No Xi System NO
    username
    pwd
    In SM58 I find the Following error.
    "JCO.SERVER could not find the server function BAPI_COMPANY_GETDETAIL.
    I Tested RFC ADAPTOR in  RWG and it is ok.
    I do not Understand where the problem is.
    Please clarify.
    Thanks,
    Srinivasa

    Thanks for the reply,
    Yes RFC is in the Sender  side.
    I am calling "BAPI_COMPANY_GETDETAIL".thuough the zprogram"ZBAPI_COMPANY_GETDETAIL"
    REPORT ZBAPI_COMPANY_GETDETAIL.
    DATA:BEGIN OF ITAB,
    RCOMP LIKE T880-RCOMP,
    END OF ITAB.
    ITAB-RCOMP = 99999.
    CALL FUNCTION 'BAPI_COMPANY_GETDETAIL'
    EXPORTING
    COMPANYID = ITAB.
    IMPORTING
    COMPANY_DETAIL =
    RETURN =
    The Details I Gave......
    In SM59 of R/3:
    PROGRAMID:LCRSAPRFC_PIT
    GATEWAYHOST:PITEST(XI system name)
    GATEWAYSERVICE:sapgw01
    Tested the connection and it is running
    ID:
    In Communication Channel.
    Application server (Gateway):PITEST(XI system name)
    Application server Service (Gateway):
    PROGRAMID:LCRSAPRFC_PIT
    RFC Metadata Repository parameter.
    ip of XI Server
    System No Xi System NO
    username
    pwd
    In SM58 I find the Following error.
    "JCO.SERVER could not find the server function BAPI_COMPANY_GETDETAIL.
    I Tested RFC ADAPTOR in RWG and it is ok.
    I do not Understand where the problem is.
    These is what I gave,

  • JCo Server - ABAP to NWJ2EE - Metadata Access

    Hi Friends,
    we are here in a project, which also deals to fetch data from an external non ABAP system. The calling system is a 4.6C. We therefore use the JCo server service (registered RFC connection), which can be called by the 4.6C system. Basicly it works, but we discovered, that currently we get a single point of failure, because we have to provide repository information (connection information) within the visual admin.
    The help page
    <a href="http://help.sap.com/saphelp_nw04/helpdata/en/b0/46e13d82fcfb34e10000000a114084/frameset.htm">SAP JCo Server Programming</a> and its examples, would lead us to provide connection properties, e.g. within the coding. Therefore, within visual admin, section "JCo RFC Provider", JNDI name, program ID and connection properties are maintained. The J2EE application therefore use those predefined entries. When starting the first request to JCo server, metadata are being read from repository, which here must be the calling system (our 4.6C system). Within the repository section, you can only provide dedicated application server login information, not e.g. a load balanced one. Thus this is for reasons of high availability, a single point of failure. An ABAP instance itself is not HA required, because you can use multiple of them. The message service itself but is HA required.
    Now after this long explanation my question:
    Are we on the right way, using e.g. visual admin to define the registered server programs, etc - or is there a more integrated, flexible integration possible?
    Perhaps, we need only the correct entry point of documentation or workshops, to direct our project developers to the right way.
    All information I found about higher integration was only for Web Dynpro - and therefore for JCo client integration. But this is not our scenario.
    thanks a lot in advance for your replies,
    reiner leibig

    You might benefit by reading the JCO pdf delivered with the jco download from sapservice.com....(free)....
    Usually it is easier to define the structure and the function interface as an SAP function even if there is no body (abap to java). This means that the JCO will read correctly all the metainformation about the function. You then call the function as an RFC specifying the host...
    Have fun...
    In your case I would read carefully the example (getting the company code info etc...)
    It shows how to manipulate the table returned by ABAP...

  • ABAP process hangs when calling a jCO Server J2EE-available RFC

    Hi there
    Here's the scenario:
    We have deployed a jCO server under the SAP WAS. This jCO server implements two functions. They are both called from ABAP process through RFC. We are using the same RFC destination for both
    First function is defined with import/export parameters and the second one only operates with a TABLE parameter.
    Incidentally, these functions are captured by the jCO server, which calls an IBM MQ server
    First function works fine. Second function hangs and there is not even a timeout so the ABAP process (run on foreground) can stay forever.
    The interesting part is that the same application works really fine when called from a Tomcat using a standalon instance of the jCO.
    Additional info:
    We have noticed that some time after the second function gets called, there are five dumps on the system (the same amount of servers we make available). These are CALL_FUNCTION_SIGNON_REJECTED.
    The fun part of the dumps is that the user making the RFC call is a different user that the one we use for the jCO connection, and the client number is '000', instead of the '728' we are using for the connection. Somehow they seem related but we do not know how yet:
    Short text
        You are not authorized to logon to the target system (error code 1).
    What happened?
        Error in the ABAP Application Program
        The current ABAP program "SAPMSSY1" had to be terminated because it has
        come across a statement that unfortunately cannot be executed.
    Error analysis
        RFC (Remote Function Call) sent with invalid
        user ID "%_LOG01% " or client 000.
        User "ARINSO " under client 001 from system "SMD " has tried to carry out an
         RFC
        call under the user ID "%_LOG01% " and client 000 (Note: For releases < 4.0,
         the
         information on caller and caller system do not exist.).
    Call Program........."SAPLSMSY_ACTUALIZE_DATA"
    Function Module..... "SCSM_SYSTEM_LIST"
    Call Destination.... "SM_ET7CLNT000_READ"
    Source Server....... "sapwasmd_SMD_10"
    Source IP Address... "172.17.82.80"
    Termination occurred in the ABAP program "SAPMSSY1" - in
         "REMOTE_FUNCTION_CALL".
        The main program was "SAPMSSY1 ".
        In the source code you have the termination point in line 67
        of the (Include) program "SAPMSSY1".
    Any tip or suggestion on where to look at is more than welcome
    Thanks in advance,
    Miguel

    And this is the content of the defaultTrace.0.trc log from the WAS
    1.#005056AB04C500440000000200002B0000046B495CA1AF67#1243862737727#com.sap.caf.um.relgrou
    ps.imp.principals.RelGroupFactory##com.sap.caf.um.relgroups.imp.principals.RelGroupFactor
    y.RelGroupFactory()#######SAPEngine_System_Thread[impl:5]_13##0#0#Info#1#/System/Server#P
    lain###sap.com caf/um/relgroups/imp MAIN_NW701P03_C 2846629#
    #1.#005056AB04C500240000000100002B0000046B495CCDAAFB#1243862740608#com.sap.engine.library
    .monitor.mapping.ccms.Trace##com.sap.engine.library.monitor.mapping.ccms.Trace####n/a##b3
    89a8004eaf11dec9b7005056ab04c5#SAPEngine_System_Thread[impl:5]_39##0#0#Error##Plain###Reg
    isterNode</Kernel/System Threads Pool/WaitingTasksCount>: com.sap.engine.library.monitor.
    mapping.ccms.CcmsConnectorException: 2100850: Invalid configuration group for node'/Kerne
    l/System Threads Pool/WaitingTasksCount' (MANAGERS.SThreadPool.WaitingInRequestQueueCount
    , max. 40 characters)#
    #1.#005056AB04C500240000000200002B0000046B495CCDB4CC#1243862740612#com.sap.engine.library
    .monitor.mapping.ccms.Trace##com.sap.engine.library.monitor.mapping.ccms.Trace####n/a##b3
    89a8004eaf11dec9b7005056ab04c5#SAPEngine_System_Thread[impl:5]_39##0#0#Error##Plain###Reg
    isterNode</Kernel/System Threads Pool/WaitingTasksQueueOverflow>: com.sap.engine.library.
    monitor.mapping.ccms.CcmsConnectorException: 2100850: Invalid configuration group for nod
    e'/Kernel/System Threads Pool/WaitingTasksQueueOverflow' (MANAGERS.SThreadPool.Waiting4Fr
    eeReqQueueSlotCount, max. 40 characters)#
    #1.#005056AB04C500240000000300002B0000046B495CCDCDA1#1243862740618#com.sap.engine.library
    .monitor.mapping.ccms.Trace##com.sap.engine.library.monitor.mapping.ccms.Trace####n/a##b3
    89a8004eaf11dec9b7005056ab04c5#SAPEngine_System_Thread[impl:5]_39##0#0#Error##Plain###Reg
    isterNode</Kernel/Application Threads Pool/WaitingTasksCount>: com.sap.engine.library.mon
    itor.mapping.ccms.CcmsConnectorException: 2100850: Invalid configuration group for node'/
    Kernel/Application Threads Pool/WaitingTasksCount' (MANAGERS.AThreadPool.WaitingInRequest
    QueueCount, max. 40 characters)#
    #1.#005056AB04C500240000000400002B0000046B495CCDD69B#1243862740620#com.sap.engine.library
    .monitor.mapping.ccms.Trace##com.sap.engine.library.monitor.mapping.ccms.Trace####n/a##b3
    89a8004eaf11dec9b7005056ab04c5#SAPEngine_System_Thread[impl:5]_39##0#0#Error##Plain###Reg
    isterNode</Kernel/Application Threads Pool/WaitingTasksQueueOverflow>: com.sap.engine.lib
    rary.monitor.mapping.ccms.CcmsConnectorException: 2100850: Invalid configuration group fo
    r node'/Kernel/Application Threads Pool/WaitingTasksQueueOverflow' (MANAGERS.AThreadPool.
    Waiting4FreeReqQueueSlotCount, max. 40 characters)#
    #1.#005056AB04C500600000001600002B0000046B4960688301#1243862801089#com.sap.slm.exec.messa
    ge.SLMApplication#sap.com/tcslmslmapp#com.sap.slm.exec.message.SLMApplication#Guest#0##
    n/a##c59827604eaf11de9fb3005056ab04c5#SAPEngine_Application_Thread[impl:3]_0##0#0#Error##
    Java###null##
    #1.#005056AB04C500730000000000002B0000046B4CF0593ABD#1243878100908#System.err#arinso.com/
    valtran_validator#System.err#Guest#0##ET7#MIGUELGU                        #4A240FF606CD5E
    5AE10000000A38418C#Thread[JCO.ServerThread-11,5,SAPEngine_Application_Thread[impl:3]_Grou
    p]##0#0#Error##Plain###com.sap.mw.jco.JCO$AbapException: (126) 1: Array index out of rang
    e: 48#
    #1.#005056AB04C500730000000100002B0000046B4CF0594028#1243878100909#System.err#arinso.com/
    valtran_validator#System.err#Guest#0##ET7#MIGUELGU                        #4A240FF606CD5E
    5AE10000000A38418C#Thread[JCO.ServerThread-11,5,SAPEngine_Application_Thread[impl:3]_Grou
    p]##0#0#Error##Plain### at com.efh.jco.valtran.sap.ValtranRequestHandler.serverExceptionO
    ccurred(ValtranRequestHandler.java:164)#
    #1.#005056AB04C500730000000200002B0000046B4CF059406B#1243878100910#System.err#arinso.com/
    valtran_validator#System.err#Guest#0##ET7#MIGUELGU                        #4A240FF606CD5E
    5AE10000000A38418C#Thread[JCO.ServerThread-11,5,SAPEngine_Application_Thread[impl:3]_Grou
    p]##0#0#Error##Plain### at com.sap.mw.jco.JCO.fireServerExceptionOccurred(JCO.java:880)#
    #1.#005056AB04C500730000000300002B0000046B4CF05940A3#1243878100910#System.err#arinso.com/
    valtran_validator#System.err#Guest#0##ET7#MIGUELGU                        #4A240FF606CD5E
    5AE10000000A38418C#Thread[JCO.ServerThread-11,5,SAPEngine_Application_Thread[impl:3]_Grou
    p]##0#0#Error##Plain### at com.sap.mw.jco.JCO$Server.listen(JCO.java:8187)#
    #1.#005056AB04C500730000000400002B0000046B4CF05940DB#1243878100910#System.err#arinso.com/
    valtran_validator#System.err#Guest#0##ET7#MIGUELGU                        #4A240FF606CD5E
    5AE10000000A38418C#Thread[JCO.ServerThread-11,5,SAPEngine_Application_Thread[impl:3]_Grou
    p]##0#0#Error##Plain### at com.sap.mw.jco.JCO$Server.work(JCO.java:8303)#
    #1.#005056AB04C500730000000500002B0000046B4CF0594111#1243878100910#System.err#arinso.com/
    valtran_validator#System.err#Guest#0##ET7#MIGUELGU                        #4A240FF606CD5E
    5AE10000000A38418C#Thread[JCO.ServerThread-11,5,SAPEngine_Application_Thread[impl:3]_Grou
    p]##0#0#Error##Plain### at com.sap.mw.jco.JCO$Server.loop(JCO.java:8250)#
    #1.#005056AB04C500730000000600002B0000046B4CF0594143#1243878100910#System.err#arinso.com/
    valtran_validator#System.err#Guest#0##ET7#MIGUELGU                        #4A240FF606CD5E
    5AE10000000A38418C#Thread[JCO.ServerThread-11,5,SAPEngine_Application_Thread[impl:3]_Grou
    p]##0#0#Error##Plain### at com.sap.mw.jco.JCO$Server.run(JCO.java:8166)#
    #1.#005056AB04C500730000000700002B0000046B4CF05941F0#1243878100910#System.err#arinso.com/
    valtran_validator#System.err#Guest#0##ET7#MIGUELGU                        #4A240FF606CD5E
    5AE10000000A38418C#Thread[JCO.ServerThread-11,5,SAPEngine_Application_Thread[impl:3]_Grou
    p]##0#0#Error##Plain### at java.lang.Thread.run(Thread.java:770)#

  • JCo Server High Availability

    How can I make the JCo server implement "High Availability" functionality. The SAP Server which the makes calls to the JCo Server is HA-aware. So if there is a failover, the SAP Server switches over to the other instance but the JCo server keeps sending the message "Server unavailable". Is there a solution for this problem.
    Thanks.

    Single Appliance not necessarily means Single Point of Failure, an appliance with HW Redundancy could handle failure and provide High Availability, if only configured well.
    Does Symantec BrightMail Appliance provide such redundancy configuration?
    You will have to ask their support or in a Symantec Forum.
    Twitter!: Please Note: My Posts are provided “AS IS” without warranty of any kind, either expressed or implied.

  • JCo Server Shutdown

    I have implemented a JCo Server using Example 5 in Jco Documentation.
    The Server shuts down automatically every other day with no dumps leading no trails on how to debug.when we restart, it runs just fine.
    my hunch is that the threads are not properly handled or not releasing the memory, i m not sure.
    Does any one had similar problem or any clues ?
    Thanks,
    Sujatha

    hi:
    I also encountered  a  JCO Server problem which likes your problem above when SAP R/3 call java function.
    The SAP R/3 is 4.6c, the JCo package version is 2.0.7.
    In my java program, I start a Jco server and register that Jco server in R/3 sm59. In sm59 I register that connection as a TCP/IP connection.
    In the RZ11, I get the gateway information. 
    My java program is a servlet program, which is running on the WAS640. The program is referred to JCO example 5. I attach the original code in the attachment.
    When I start the Jco server, I get successful connection information in sm59. At that time, the ABAP program can call java program successfully.
    But unluckily I find that link is not stable. Maybe after an hour or several hours, when I run the ABAP program again, RFC error message will popup. At that time I test the connection in sm59, an error message will show “the connection is not registered”. Also in SMGW I can’t find the java rfc connection. Then, I have to restart the jco server, establish a new rfc connection.
    I don’t know what happen. I think maybe it is my program problem(I search the JCO help and try to find a function setting the timeout. But I don’t find any). Maybe there is something to do with basis (I don’t know whether there is a timeout configuration in r/3 or there is a background job will clean up the java connection).
    Would you please give me some advices. I really don’t know how to fix that problem. Thank you for your help.

Maybe you are looking for