How to Pass Transformed File Content Instead of Receipt Responses from one routing address to another?
I'm facing a challenge while trying to append an MD5 hash value to payment order files after performing an initial format transformation (for SEPADD format) in IFS Cloud 23.2 My current setup has two routing addresses connected to a single routing rule:
MD5 Transformer(Java Transformer) Connected Routing Address: Appends the MD5 hash to the file content.
The problem is that the MD5 transformer only receives the receipt response/Message response from the core transformer, rather than the fully transformed file content.
According to the documentation, some address types only pass the receipt instead of the transformed output.
Does anyone have experience handling this kind of transformation sequence? Is there an alternative routing strategy or configuration that ensures the MD5 transformer receives the fully transformed file content?
Page 1 / 1
Hi @InfShemaG
Is there a special reason to use two routing addresses?
If you want the final output top have IFS SEPADD + append MD5, then you can add both transformers in the same routing address.
Hope it helps!
Damith
Hi @InfShemaG
Is there a special reason to use two routing addresses?
If you want the final output top have IFS SEPADD + append MD5, then you can add both transformers in the same routing address.
Hope it helps!
Damith
Hi @dsj Thank you for your suggestion. Initially I did try it with both the transformers connected to one routing address. Because this approach created an incorrect MD5 hash value is why I tried to do it with two addresses instead of one.
And MD5 value was appended to the file but the MD5 hash value is not the correct value. When done like this I am unsure what content is passed to then create the MD5 hash value. I check if its created with the input file or message response but it is not.
I tried using another Java transformer (Custom Transformer) before my transformer under the same routing address for testing purposes and this actually created the correct value. I am unsure why the Core transformer (XSL) doesn’t work in the same way.
Hi @InfShemaG
Output from transformer1 is the input for the transformer2.
Base the MD5 creation on the xml structure output from transformer1 and then you would get the correct value.
BR,
Damith
Hi @dsj Are you suggesting converting the string passed into the transformer to XML before generating the MD5 hash? When I tested the transformer locally, I used an input file (copied from the generated file) and an expected file. In the test class, I converted both files to strings, passed the input file to the transformer instance, and compared the result with the expected file. It produced the correct results while testing locally.
Thank you, Shemani
Update: I ended up using a single routing address with two transformers—one core XSL and my custom Java transformer beneath it. The issue wasn’t with the routing rule or address but with my custom transformer. The problem stemmed from a Java version mismatch: my IDE was using Java 17, while the application was running Java 11.
To debug this, I first checked the Java version in both environments by appending a line to the output file, as I wasn’t sure how to verify the application's version directly. Next, I compared the byte size of the output and noticed a significant difference for the same content. To investigate further, I Base64-encoded the content and analyzed the patterns (\n = Cg== vs. \r\n = DQo==), which made the difference clearer. Once I confirmed that the newline characters differed, I simply replaced \n with \r\n, and that resolved the issue!
