2

I am trying to convert the content of an IDoc XML file to an IDocDocumentList.

The following code, heavily based on the documentation, raises an error:

com.sap.conn.jco.JCoException: (106) JCO_ERROR_RESOURCE: Destination BCE does not exist

public void xmlToIDoc(String inputXml)
{
  // see provided configuration file BCE.jcoDestination
  JCoDestination destination = JCoDestinationManager.getDestination(DESTINATION);

  IDocRepository iDocRepository = JCoIDoc.getIDocRepository(destination); // !!!! throws exception

  // parse message
  IDocFactory iDocFactory = JCoIDoc.getIDocFactory();
  IDocXMLProcessor processor = iDocFactory.getIDocXMLProcessor();
  IDocDocumentList iDocList = processor.parse(iDocRepository, inputXml);

  return iDocList;
}

I must admit that it's not really clear to me why this requires a destination and a repository. I mean, it's just an XML-to-document conversion, right?

More importantly, I have the impression that the reason why this fails, is that I have no active connection to the SAP server. Can somebody confirm this?

If that is indeed the case, then is there any other way to get this to work without an active server connection ?

Thank you in advance

Sandra Rossi
  • 11,934
  • 5
  • 22
  • 48
bvdb
  • 22,839
  • 10
  • 110
  • 123
  • 1
    I don't work with JCo, but the .Net Connector works in a similar way. And it needs a working connection (including correct login) to the SAP system to fetch the metadata for function module interfaces or dictionary objects. The error message claims that a destination "BCE" doesn't exist, which means you at some point ask for a destination called BCE and JCo can't find it (probably not configured). Even with a properly configured destination, the library will likely still need actual access to the SAP system. I'm guessing here, but probably to fetch Idoc metadata for the conversion. – Dirk Trilsbeek Mar 20 '17 at 15:01
  • Thank you for your reply Dirk. That explains a lot. – bvdb Mar 20 '17 at 16:31

1 Answers1

2

Your constant DESTINATION contains the value "BCE". i guess you are using the default configuration of JCo which means that you need to provide a file named BCE.jcoDestination with containing the logon properties to your ABAP system.

Your other questions should already have been answered here.

And by the way, the main purpose of JCo and the JIDocLib Add-on library is to communicate with an ABAP system via SAP's proprietary RFC protocol. So if you do not have an "active connection to a SAP server", why would you like to use these SAP libraries at all?

Community
  • 1
  • 1
Trixx
  • 1,796
  • 1
  • 15
  • 18
  • Why? - The ability to run code without being connected is useful for testing purposes, and for simulation. – bvdb Mar 20 '17 at 16:32
  • Without connecting to the ABAP system this would not be a test. A test always needs to cover the whole scenario. A simulation might be somehow imaginable with running an SAP gateway and a registered `JCoServer` for acting similar to an ABAP system, but this would be a huge effort and you will never be able to simulate an ABAP system completely. IMHO the effort for creating such a simulation will not pay off and would only be of very limited value. – Trixx Mar 20 '17 at 18:50
  • ever heard of unit tests? You're right if you're talking about integration tests, but unit tests don't cover scenarios, they cover individual cases, ideally without any external references like databases or ERP systems. You can probably mock a lot of the Jco components for unit tests. – Dirk Trilsbeek Mar 21 '17 at 06:41
  • Ever worked with JCo? JCo's purpose is the RFC communication. You cannot test your program with using JCo but without doing RFCs. You also cannot mock most of the JCo stuff because you always need metadata which is usually obtained from an ABAP system. In some use cases you can use a static repository (not recommended), but this requires different code, so you would test different things then. Even RFCs to non-ABAP systems look and work slightly different. I know what you mean, but actually there is hardly anything that can be tested when using JCo without having a real connection. – Trixx Mar 21 '17 at 07:58
  • We made a dedicated module to process `IDocDocumentList` objects. Earlier, during analysis, we noticed that we could export these documents to XML and import them. So, it seemed like we could unit test the whole thing. But as it turns out now, it's impossible to convert an the xml to an IDocDocumentList if there is no connection to the real system. So, it looks like we are stuck. --> so, what we are considering now, is to rewrite our module to process XML directly, without using the IDocDocument objects. (But it feels so wrong.) On the other hand, if code can't be tested, you can't trust it. – bvdb Mar 21 '17 at 11:11
  • Please have a look at the interfaces `IDocDocument` and `IDocSegment`. These are mighty objects with all their checkSyntax() functionality and metadata info like min./max. occurrences, intelligent segment inserting, field data type checking, max. field lengths and so on. This info is not contained in the IDoc-XML and must be queried from an ABAP system. If you do not want to send/receive IDocs via RFC then using the JIDocLib also does not make so much sense. – Trixx Mar 21 '17 at 14:07
  • "so, what we are considering now, is to rewrite our module to process XML directly, without using the IDocDocument objects. (But it feels so wrong.)" -- Indeed. And also I would assume that then the performance will suffer; at least if you have to parse and render and parse and render the XML multiple times... – Lanzelot Mar 04 '18 at 14:28