Remove All-Entry
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
The user was cleaning up the model to eliminate a particular system. However, the user could not perform this action due to a failed check within the logic for removing an all-entry. Because the system needed to be cleared to avoid unclearness in the future in the various phases of eMagiz, it was necessary to investigate the issue further.
2. Problem
In this instance, the user could not remove a system containing an all-entry from Create. This warranted more investigation.
3. Analysis
3.1 Reproduction
To reproduce the issue, we opened a model under our control and tried the same thing (i.e., remove the last onramp linked to a system with an all-entry) to see whether we could remove the all-entry. In this scenario, we encountered the same failed check as the user did. This was a confirmation that the check itself is flawed, for which there is a backlog item for it to be solved.
In the meantime, we needed a workaround to help the user remove the system.
3.2 Analysis
Given that the error the user got contained a reference to a particular component in eMagiz (i.e., "in-vm-connection"), we considered the option of adding a support object with that exact name to the all-entry and see whether that would resolve the issue. This workaround worked when adding a JMS caching connection factory to the flow with that name. Afterward, we could remove the all-entry with ease. Given that the all-entry and the system needed to go in the first place, such a change in the structure of the flow is no problem for the user.
4. Result
After adding the workaround, the integration and the system could be removed from Create.