Memory issues with large (Base64) content in your XML

Improve your IAF skills!

When we receive XMLs with large base64 content we typically are not going to manipulate this part of the xml. But when we are going to transform or validate our XML  the DOM object created for the parser will grow by at least a factor 10. In my case I was evaluating and transforming the xml content multiple times which resulted in a OOM.

On my request an addition to the framework was made (Thanks Peter)


On the receiver we add an attribute elementToMove with the name of the xml element we want to extract from our XML.

In our XML the FileContent is replaced by a reference to a SessionKey
f.e. <FileContent>{sessionKey:ref_FileContent}</FileContent>

The contents of the FileContent element is placed in a SessionKey named ref_FileContent, if multiple FileContent elements are found you will get multiple SessionKeys (numbered)

The only thing we need to do is Restore the FileContent
This will replace sessionKey:ref_FileContent
 with the actual FileContent as a last step in of this pipe.

As for now the restoreMovedElements is not usefull in a sender because it will add the FfileContent after sending the message. As a workaround we can add an echo pipe in the process.
<pipe name=”RestoreFilecontent”
             <forward name=”success” path=”Sender”/>

In the next release of the IAF the feature to send SessionKeys to sub adapter is extended to allow a wildcard.In the scenario above we do not know which and how many SessionKeys we will have.

in your sender add to send all sessionKeys starting with ref_FileContent
<param name=”ref_FileContent” sessionKey=”*” />