Catching XML translation faults — oracle-tech

    Forum Stats

  • 3,701,016 Users
  • 2,239,262 Discussions


Catching XML translation faults

Valery RemizovValery Remizov Posts: 87
edited November 2018 in SOA Suite Discusssions


let's say we have service, polling FTP directory for new files using FTP-Adapter. If invalid document was consumed, following error occurs:

Error while translating.Translation exception.Error occurred while translating content from file /test/spoiled_doc_cool.xmlPlease make sure that the file content conforms to the schema. Make necessary changes to the file content or the schema.

This fault cannot be caught by Catch Activity in BPEL. I guess this happens because service fails before entering process. Is there a way to catch it in BPEL anyway? Help would be very appreciated.


Valery Remizov


  • Martien van den AkkerMartien van den Akker Posts: 2,756 Bronze Crown
    edited November 2018

    Hi Valery,

    What I do in these situations, that I can't rely on the validity of the file (or message in one of the other adapters) is to choose no schema (Opaque). The file is read and delivered in Base64 format. You can then use a method like this to decode it: You can do that in an embedded java, but I choose to create a set of java beans with in a spring context, like this: (this is in fact about zipping, but same principle using base64 encoding/decoding).

    Then you can assign the decoded string using the parseEscapedXML() function into a variable based on the actual XSD. Then you can use the Validate Activity to check if the variable content is valid.

    I know, it's a bit tedious. But this is in fact the way to do it.

    I hope it is clear?


  • Valery RemizovValery Remizov Posts: 87
    edited November 2018

    Thanks Martien,

    I thought about opaque schema, but that would be indeed tedious, especially when you have to implement this in multiple composites. Is there any other way to do it?

  • Martien van den AkkerMartien van den Akker Posts: 2,756 Bronze Crown
    edited November 2018


    When the file does not conform the XSD it will be rejected. And stored in a rejected messages folder (I don't know the exact location by heart). I found this blog (Oracle Fusion Middleware Blog: Handling Rejected Messages - SOA 11G ) that explains how to use the Fault Policy frame work to handle them.

    You can also set the PhysicalErrorArchiveDirectory' in the JCA file (of the File/FTP Adapter), see:  How to handle rejected messages in file adapter

    The thing with those solutions is that it is often difficult to correlate the particular erronous file with the BPEL instance and the source. You talk about multiple composites, but if you poll for files from multiple providers then often you need the particular file to correlate it to the source. Sometimes the XML does not conform the XSD, but you want to beable to seek out what was the problem. And I also got the situation once that the message provider didn't conform to it's own XSD's... So I created an adapted xsd to check a second time when it didn't conform to the original xsd, to check with the adapted xsd if it does conform to exceptions that I accept.

    That is the reason that I use the way described in the previous post most of the times.

    But I put the base64 encoding in a separate service and it is resuable for the composites. And then it is an invoke 2 assigns and a validate. It's not so difficult.


    Valery RemizovValery Remizov
Sign In or Register to comment.