We’ve covered the basics of Flogo Enterprise development in the previous articles, but there is an important topic that hasn’t been discussed for now, and this is flogo error handling. We always think everything is going to work the way we plan to, and everything is going to go down the green path, but most of the time they’re not, so you need to prepare your flows to be ready to handle these situations.
If you’re used to TIBCO BusinessWorks Development you’re going to get used to it because most of the ways to do things are pretty much the same, so any kind of logic you apply to your developments can be applied here. Let’s cover the basics first.
A flogo error handler is the main way Flogo developers handle the issues that happen in development and this has been this way for all versions from the first one until Flogo Enterprise 2.6.0 because until that moment it was the only way to do it.
The error handler is a different error flow that is going to be invoked when something is wrong similar to a catch flow in TIBCO BusinessWorks development. When you click the Error Handler button you’re going to enter into a new flow with a predefined starter named error as you can see in the picture below:
Data that is going to be starting this flow is the activity name that failed and failing message, and then you can do any handle logic you need to do until the flow is returned. Activities that you could use and logic is exactly the same you can use in your main flow
Since Flogo Enterprise 2.6.0 a new way to handle error has been included, as we said until that point any error generates an invocation of the error handler, but this doesn’t cover every use case scenario when an error happens.
As Flogo Enterprise starts with a simple microservice use-case scenario error handle was enough to handle it, but now as the power and features Flogo provides have been increasing new methods to catch and act when an error happens are needed to cover these new scenarios. So, now when you create a branch condition you can choose three options: Success, Success with Condition, and Error.
To do that, you only need to click on the engine button that appears in the branch creation from the activity that is generating the error:
And you could choose one of the three situations as you can see in the image below:
As branches are accumulative we can have an activity with different branches of different types:
But you can only add one Error Type branch for each activity if you try to add another field is going to be disabled so you can not go to be able to do it:
All this content has been focused on how to handle errors when it happens, but you can also need the other way around to be able to detect something do some checks and decide that this should be handled as an error.
To do that you have the Throw Error Activity where you can pass the data of the error you want to handle in a two-key element interface one for the error message and another for error data as you can see in the picture below:
Nomad is the Hashicorp alternative to the typical pattern of using a Kubernetes-based platform as…
DevOps vs DevSecOps: Fundamentals about DevSecOps understanding what it is, why it is crucial and…
Scan Docker images or, to be more honest, scan your container images is becoming one…
Multi-Stage Dockerfile is the pattern you can use to ensure that your docker image is…
Introduction This article will cover how to inject secrets in Pods using Hashicorp Vault. In…