Field Level Base 64 Decoding

[Former Member]

Hello,

We are trying to use the Custom Adapter Module as per the blog by wherein we are trying to decode a field level Base64 encoded file.

Scenario - Encoded XML File - to - Decoded XML File

PO Version - 7.5

Issue - Consider there are 4 fields in an XML file wherein the 3rd field is coming BASE64 encoded. Now in the output I need an XML format wherein I am trying to capture all the 4 fields and the 3rd field should be decoded.

I am using the below configuration in the Module Parameter of Sender Channel:

Now when I am doing an end to end test. The file is getting picked up and but I am getting an error during processing:

And strange part is when I check the payload, only the XPATH mentioned field is getting generated with the decoded value and the REST OF THE FILEDS ARE NOT GETTING POPULATED AT ALL. Also I am not getting the output in the XML format in the message monitoring view. Is it something I am missing in here where in anyone could help us out?

Referred Links :

SAX Error – Content is not allowed in prolog

Regards

Nitin

[engswee · Accepted solution]

Hi Nitin

The custom module was designed to decode one field and replace the whole payload with that field's decoded content. It does not preserve the other contents in the XML structure. The reason it is failing with "Content not allowed in prolog" is because it is no longer an XML structure, but the mapping step was still trying to parse it as an XML payload.

If you want to just decode one particular field while preserving the other fields, you do not need to use the module. This can be achieve using a UDF in a message mapping.

Regards

Eng Swee

[Former Member · Accepted solution]

Hi Eng Swee,

Thanks for clearing that out. Now since that its clear, it will help us to look for other ways to achieve the solution

Regarding the UDF you have mentioned above, I have already gone with that approach. And that is working perfectly fine for me. But I am having a constraint in that approach.

When I pass a file, the field length which has the decoded value exceeds String Character length and only half of the value is captured at run time. Due to which there is a data loss and the processing time also exceeds. The only possible solution which comes to my mind at this point is to use Java Mapping which we are also working on. But if there is any other approach which you (or anyone) is aware of which could ease the things. By letting us know that approach it would really help us.

Waiting for your inputs

Regards

Nitin

[engswee · Accepted solution]

Hi Nitin

As far as I know, there shouldn't be any limitation for String character length in Java. Is the length limitation defined in the XSD instead?

Can you share example of how the data loss looks like?

Regards

Eng Swee

[Former Member · Accepted solution]

Hi Eng Swee

I am using the below UDF :

When I do an end-to-end with the I get the below tag ONLY no data is there in it:

<?xml version="1.0" encoding="UTF-8"?>

-<ns0:Encode_to_Decode xmlns:ns0="urn:Test_L">

Let me try with the code you have provided and lets hope it works for me and I shall update you soon 

Regards,

Nitin

[engswee · Accepted solution]

I think you are trying to use Sun's Base64 decoder, which should be avoided - refer to my comments in

Try using my code which uses class javax.xml.bind.DatatypeConverter. You will need to add this class in the import instructions of the Message Mapping.

You should also try testing the UDF directly in the mapping area using Display Queue (as shown in my screenshot above), that will be faster to test rather than performing end to end testing.

[Former Member · Accepted solution]

Hi Eng Swee!!

You just nailed it!! I must say you are savior! I was using the Sun's Base 64 decoder. I somehow missed your comment in the blog which I had referred earlier. And now after importing the class mentioned above and using your code, EUREKA! It was converting as per my requirement. Thanks a ton for your help and time!

People like you in the community are the true assets !

Keep us Enlightening!

Regards,

Nitin

[engswee · Accepted solution]

Good to hear that it's working now. Glad to have been of assistance

[former_member296836 · Accepted solution]

Hi Eng Swee,

I have to thank you too. Like Nitin I was working with Suns library which did not worked.

Your solution with javax.xml.bind.DatatypeConverter is a simple and good solution.

Thanks

Regards

Chris