cancel
Showing results for 
Search instead for 
Did you mean: 

Problem migration from SAP JCO 2.1 to SAP JCO 3.0

fabrizio_bellini
Discoverer
0 Kudos

Goodmorning,
I need information to migrate my code written in java from SAP JCO 2.1 to SAP JCO 3.0 and IDOC to ver. 3.0
I read SAP JCo 2.x-3.0( Standalone)Migration Guide, but some information I don't found.

I have these methods
JCO.removeClientPool(poolName)
JCoIDoc.createRepository(String, String)
Idoc.Document.getName()
In which way I can substitute these methods in SAP JCO 3.0/IDOC ver. 3.0 ?

In my code there this class
JCO.Pool
what is the equivalent in SAP JCO 3.0/IDOC ver. 3.0 ?

In my code I have a class child of a the class
JCoIDoc.Server
that ovveride this method
protected void handleRequest(JCoFunction function), protected void handleRequest(IDocDocumentList documentList), protected boolean onCheckTID(String tid), protected void onCommit(String tid),
protected void onRollback(String tid), protected void onConfirmTID(String tid)
In SAP JCO 3.0/IDOC ver. 3.0 what can I do ?
I have try to create a child of DefaultJCoIDocServer, but those methods are not possible to override.

If you are not the right contact, can you give me the email address for the right contact ?

Thank you
Best Regards
Fabrizio

Accepted Solutions (1)

Accepted Solutions (1)

HAL9000
Product and Topic Expert
Product and Topic Expert
0 Kudos

With JCo3 the connection management concept has changed and is now completely done within the JCo framework. So there are no connection related APIs in JCo3 anymore and therefore also the pool management is now completely done internally.

Just delete everything that is related to old JCO.Client, JCO.Pool and JCO.PoolManager instances and use the new JCoDestination object instead which is not an equivalent to a physical connection anymore like JCO.Client was. A JCoDestination represents an RFC execution target instead. It cannot be opened or closed like a connection. This is similar to the RFC destinations in an ABAP system (maintained with transaction SM59).

Connection pooling is defined in the destination's configuration settings and is managed by the JCo3 framework automatically. No need to take care for the developer. Pooling can be easily setup and modified by an administrator later without any code change.

For the server related stuff, do not extend any internal JCo runtime class. Please use the interfaces from the API only, For servers you have to set the appropriate handlers, e.g. with JCoServer.setCallHandlerFactory(JCoServerCallHandlerFactory). Here you have to implement the appropriate interface, e.g. JCoServerFunctionHandlerFactory, or use the default factory implementation and register your own handlers there, The handleRequest() method is defined in the interface JCoServerFunctionHandler. You have to implement this one. Please see the JCo API JavaDoc for further info.

For TID management there is also a separate handler: the JCoServerTIDHandler which can be set using method JCoServer.setTIDHandler(JCoServerTIDHandler).

The same applies to the JCoIDocServer and the IDoc handlers from the JIDocLib 3.0.

If you need an IDocRepository this can be fetched by calling JCoIDoc.getIDocRepository(JCoDestination). But usually you don't need this for a pure JCoIDocServer implementation. Which repository a server should use is simply better defined in its configuration, namely with property jco.server.repository_destination.

An IDocRepository is only needed for creating a new IDoc from scratch or from an IDoc-XML stream.

And finally:

The equivalent method to IDoc.Document.getName() is IDocDocument.getRecordMetaData().getName()


Hopefully this answers all your questions.


Best regards,

Stefan

Answers (1)

Answers (1)

HAL9000
Product and Topic Expert
Product and Topic Expert
0 Kudos

Hi Fabrizio,

I'm glad to get your 'Like' vote.

But if my previous posting answered your questions, please also reward the forum points and mark it as the 'Correct Answer'. This does not close the thread. You can still append follow-up questions here,

Thanks in advance.

Best regards,

Stefan