Template match error for missing code mappings
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
Since several days publication messages towards a specific system were rejected in the transformation within eMagiz due to an template evaluation error. In the ticket we could read that although the transformation was not working in eMagiz it was working in other tooling (i.e. XSLT fiddle). The error repeated itself many times and the flow was stopped to prevent data measurement issues in eMagiz
2. Problem
The result of the issue was the business process couldn't use updated information from that specific data stream. Data presented in the business process was outdated for some parts
3. Analysis
3.1 Errors in eMagiz
To analyze the problem, we first looked at the errors within the environment to get a sense of the issue at hand. See below for the errors observed. The error indicates a transformation problem.
3.2 Transformation verification
Secondly, we used the transformation resource and the failed message payload to verify the correct working of the transformation. From that we could see the errors in the transformation around the code mappings. Removing the code mapping resulted in a correct transformation. This feedback led us to believe that the problem lied somewhere with these code mapping lines.
3.3 Code mapping verification
There are 4 code mapping transformations used in this flow. Each code mapping was inspected by comparing the input values of the failed messages to the actual code mappings. Objective was to find out a missing code mapping. This resulted in locating a missing code mapping.
3.4 Reproduce missing code mapping situation
To reproduce the issue we built a separate flow in a separate model that received the input and transformed it. Once it reached the end a Warning in the log with the text “Success” would be written. At first we tested our hypothesis by not defining the code mapping found in the previous step. This led, as expected, to the same error as we saw in the client environment.
Subsequently we add the missing value to the code mapping list of this model and ran the test again. As a result we got a line in the log stating Success for each time the test ran.
4. Result
The reported incident in which the transformation in eMagiz failed was ultimately caused by an incorrect configuration of the code mappings functionality within the eMagiz Portal on (at least) the Production environment or a change in terms of how the data is supplied which led to the mismatch between the input value and the expected values based on the code mapping configuration. Either way the problem needs to be resolved at the source or in the code mapping functionality to make the flow work again.
This document will use the actual root cause analysis information to make a generic view that can be used if you run into the same or similar problem. 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
Sometimes, a ticket suggests that something on the flow level might not work as expected and warrants further investigation. In these situations, executing various checks in the Design, Create, and Deploy phases of eMagin is good for zooming in on the problem. This entry will look at a generic approach to this and various situations we have encountered in the past few years.
2. Problem
A suspected configuration problem on the flow level needs to be analyzed generically.
3. Analysis
3.1 Reproduction
First, you should check the assumptions of the person coming to you with a ticket. This is for both the Create and the Deploy phase of eMagiz. In Deploy, you check which version of a flow is running and whether this matches the client's expectations. Once you have established the correct flow version, it could happen that what is running is not what a user expected. The first step is to eliminate this mismatch.
If the flow version is as expected, we can check the properties to see whether we see any changes. In this situation, always verify whether the user deployed the flow after the property value was changed.
Thirdly, we zoom into the Manage phase to gather related information in the form of error messages or logging that help us identify at what place in the integration the message has exited the process. Once we have that, we can determine the cause of the error message better. If there is no indication in the Error messages where the message broke down, it is wise to check the log entries and queue statistics for more information.
3.2 Analysis
You can analyze most flow configuration problems in eMagiz with the above steps.
4. Result
Once the flow configuration problem is identified, you can work towards analyzing and fixing the problem.