Export Mapping Attachments - Mendix
In this document, we will use the information from the actual root cause analysis to make a generic view that can be used if you run into the same or a similar problem in the future. Finally, the document will describe the situation, the problem, the analysis, and the result.
Should you have any questions, please get in touch with academy@emagiz.com.
1. Situation
When migrating Mendix from Mendix 7 to Mendix 8 (or 9) you also need to update your eMagizMendixConnector. When doing so the way in which Mendix and eMagiz communicate with each other changes. In Mendix 7 a SOAP web service layer was used for the communication. However, af of Mendix 8 queues are used to communicate between Mendix and eMagiz. As a result there might be changes required to the export mapping when sending data from Mendix to eMagiz. In cases where attachments are part of your XML body you want to send to eMagiz it becomes even more important to ensure your export mapping results in a working XML that can be processed by eMagiz.
2. Problem
Due to the fact that the export mapping in Mendix did not correctly send attachments (as base64 strings) to the queue the messages were refused by the JMS server breaking the connection between the Mendix application and eMagiz.
3. Analysis
3.1 Errors in eMagiz
To analyze the problem, we looked at the information at hand both in Mendix and in eMagiz. In the Mendix application the only signal of a broken connection was the log message saying that the eMagizMendixConnector switched to 'offline' mode. This mode is triggered when a JMS exception occurs when sending data from Mendix to eMagiz on an asynchronous call to eMagiz. In eMagiz we saw cryptic warnings on JMS level in the "Log entries". This combination of facts led us to the conclusion that what was being send by the Mendix application resulted in an invalid string.
3.2 Analyze the queue in Mendix
As a result we looked at the first message that was stored in Mendix as a result of the eMagizMendixConnector going into 'offline' mode. With this information we could reengineer how the message would have been placed on the queue by Mendix in the first place. Based on this information we could see that the picture that was send along with the XML message was not formatted correctly. In this case it turned out that due to the eMagiz definition the assumption was made that the picture needed to be send to eMagiz as an actual string so changes were made to the flow and the export mapping to make that happen.
Once a comparison was done between the old export mapping and the new export mapping we quickly found out that a difference in how the attachments were processed in the export mapping was at the root of all problems as it did not account for pushing base64 string content to an attribute.
4. Result
Once the mapping was fixed so that the target attributes was always filled with data of the proper data type, the issue didn't occur anymore.