Flows not installed on runtime
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
For a new release that was deployed, one of the systems didn't install any flow other than the infra flow.
2. Problem
The system was not operational and not functional causing a downtime of the business process to send invoices.
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 specific library loading problem. The duplicate dependency chain means that there two libraries loaded on the same path, making it ambiguous for the runtime to choose which library to load
3.2 Runtime dashboard view
We have also looked at the runtime dashboard, where you could see that only the infra flow was installed and started. But no other flows where installed. Furthermore, the latest or newest build number was loaded for that flow. On Acceptance the same system existed and all flows where started properly. There is no screenshot attached here due to confidentiality.
3.3 Reset action
The first regular action would be to reset the runtime to ensure the data folder that contains cached data is cleared. This action didn't resolve the issue, allthough it was expected to fix the issue.
3.4 Alternative reset action
Due to the fact that the flows are working properly in the Acceptance environment, combined with the duplicate dependency chain it was concluded that the libraries that are downloaded from the eMagiz repository are in conflict. The build number is a reference to a set of libraries that need to loaded into the runtime to make these flows operational. Apparently the runtime was still containing older libraries from the previous build number, causing the conflict.
The step to perform an alternative reset where the following: 1. In Design architecture, move the runtime from the Cloud Connector machine to a Local Connector machine 2. In Desploy Architecture, press the Apply to environment button and wait for a few minutes to allow the Cloud slot to effectuate & specifically clean the entire runtime 3. In Design architecture, move the runtime from the Local Connector machine to the Cloud Connector machine 4. In Desploy Architecture, press the Apply to environment button and wait for a few minutes to allow the Cloud slot to effectuate 5. Verify the runtime dashboard to see of the flows where installed and started.
4. Result
The runtime was cleaned up 100% from the Cloud slot, allow the local repository to be cleaned-up. This is a sibling folder to the data folder, and contains the libraries. The reset runtime action in the Deploy Architecture cleans up the data folder (excluding the H2 folder) but doesn't cleanup the libraries. In normal cases, new build numbers do not have such behavior but in specific cases this can be a alternative to the reset runtime action.