JCo ABAP XString to Java byte[] misses last byte

[Former Member]

Hello,

we have on ABAP side some classes using the i_xml library to create XML. The output is an XString in ABAP containing the XML.

Via JCo we call a RFC Module that has as Export Parameter this XML. When this RFC is called from ABAP the XML is complete. When called from Java by JCo it misses the last byte (which is the last ">" of the last XML Tag.

We use the following line to retrieve the Parameter from the JCo function.

byte[] xmlBytes = function.getExportParameterList().getByteArray("EV_XML");

When we call xmlBytes.length we get the length in ABAP - 1. So if ABAP says it has 3000 Bytes in Java we get 2999.

We changed the encoding in XML to UTF-8 or ISO-8859-1 but that had no impact at all.

Our system is a NW 7.10 SP 7 with JCo as included. SAP System is an ECC 6.0.

Thx for any help,

Frank

[Former Member · Accepted solution]

How is the EV_XML parameter defined in the ABAP RFM interface?

Did you shortly change this interface definition?

If yes, did you make a reboot of your AS Java server instance since then?

[Former Member · Accepted solution]

The EV_XML is defined as following:

VALUE(EV_XML) TYPE AFC_XML_XSTRING

where AFC_XML_STRING has Type AFC_XML_STRING which is defiend as RAWSTRING.

I have restarted the Server just now and tried again This time it seems to work. I wasn't aware that you have to do that even if you work with plain JCo. We don't use the adaptive FW here as it's available only from 7.11 on. Sometimes its soo easy

Thx for the help, Frank

[Former Member · Accepted solution]

Well, the RFC meta data is usually cached within an JCo repository instance. With release 7.20 you will be able to clear the repository from the NWA screen. With release 7.10/7.11 you have to do this the hard way (reboot) or write and deploy some own EJBs/servlets for this task.

By the way, I recommend using character or string types for transferring XML data. Otherwise with raw types you have to take care about codepage conversions on your own. XML must not contain any non-printable characters anyway, so a character or string type would be fine for this.