cancel
Showing results for 
Search instead for 
Did you mean: 

Cannot load UBL 2.0 XML documents into Message Mapping (PI 7.11)

Former Member
0 Kudos

Hi,

Has anyone tried to load any of the UBL 2.0 XML documents into a Message Mapping in PI 7.11? We cannot get this to work without PI raising Java heap space errors within the Integration Builder client.

UBL 2.0 is an international open standard of Business to Business XML schemas, information on UBL is here:

http://www.oasis-open.org/committees/tc_home.php?wg_abbrev=ubl

The schemas I have loaded as exernal definitions are these:

http://docs.oasis-open.org/ubl/os-UBL-2.0.zip (including updates applied: http://docs.oasis-open.org/ubl/os-UBL-2.0-update-delta.zip)

The schemas all load perfectly and their full tree structures can be navigated ok (the high level main schemas "import" many common schema files, and that all works fine too). So no issues loading the External Definitions.

The issue I have is when we try and use one of the main schemas (such as Message "Order" within schema "UBL-Order-2.0.xsd") within a Message Mapping. The PI Integration Builder client fails with a Java Heap Space memory issue when we try to add the Message "Order" to the Message Mapping.

We adjusted the max heap size via the Exchange Profile from 512MB to 1536MB, but it made no difference (apart from using 1.6GB of RAM on our computers for PI instead of about 600MB !!), but it would still fail with an error saying not enough Java heap space on our client PCs.

The UBL schemas dont look any more complex than other schemas of similar size, such as xCBL (which UBL is based on), so I am thinking this is either a bug in PI, or there is something not quite right in the UBL schemas (although they load fine in XMLSpy, and load fine in PI 7.11 as external definitions without errors). It seems to me that PI is struggling to convert the UBL schema definitions into Java code when inserted into Message Mapping.

If anyone else has had this issue and found a way around it, please let me know. Or if anyone else wants to try and load the schemas I referenced above and see if the same happens in their system, that would be great. In the mean time, I am going to open a customer message with SAP.

Thanks,

Brendan

Accepted Solutions (0)

Answers (2)

Answers (2)

Former Member
0 Kudos

My impression from documentation and best practice guides is that when a certain level of complexity is reached XSLT is the mapping technology of choice. Whilst UBL itself is a relatively simple structure it doesn't use any simple types (from memory), XSL is a far simpler way to get the information required into and out of UBL ...IMHO.

An argument could also be made for mapping reuse when standards such as xCBL and UBL are being used.

Former Member
0 Kudos

Hi,

Even I am facing exactly the same problem when trying to load the UBL Order.xsd into the mapping.

were you able to solve this problem?Please let me know.

Regards,

Kumar.

Former Member
0 Kudos

Hi Kumar,

We raised a customer message with OSS, and the official answer from SAP was that this is a limitation and PI cannot support large XSD schemas, such as those from UBL. The core codebase of PI would need to be rewritten, and this is not possible via a patch/support pack, it could only happen at the next major release of PI.

Because you can load the UBL schemas, but just not use them in a graphical Message Mapping, the only other way to use UBL is via other mapping methods (such as pure Java Mapping). SAP suggested to do this, but of course we didn't like that answer, but nothing we can do about it.

Regards,

Brendan

Former Member
0 Kudos

This is a quite interesting and disappointing answer from SAP. We have similar issues with other XSD's. What do they mean with "it could happen" ? They will solve it or not ? Do you know ?

CSY

Former Member
0 Kudos

They did not say if they would or would not fix this in the next major release of PI. So your guess is as good as mine. In my experience SAP will never commit to what is going to be in a future release, so I am not suprised they would not commit.