Below you will find a document describing the migration path to migrate your custom error handling on flow level to the latest generation runtime. For the key aspects of the new generation compared to the current generation, please read this fundamental.

Should you have any questions, please get in touch with academy@emagiz.com.

1. Prerequisites

• Advanced knowledge of the eMagiz platform
• A thorough understanding of your eMagiz model

2. Key concepts

• This migration path allows you to maintain custom error handling on flow level
• The error flow of your model needs to be resetted (when using no custom error handling) or adapted when using custom error handling

3. Technical Migration Path

As part of the "Transfer Settings from Design" step in the general migration path on migrating to the 3rd generation runtime you need to select for which flows in your runtime you want the custom error handling to be maintained. Apart from that you also need to rebuild your error flow in such a way that it receives the errors and processes the messages as you desire.

Before diving into the error process flow and how to rebuild it to make it work for you let us first explain how the error handling will change when migrating. In the 3rd runtime generation any inbound component in any flow can put data on the errorChannel by selecting "errorChannel" as the channel of choice to handle exceptions. This is the default in any asynchronous flow that starts with an inbound component. If you want to make use of this same functionality when adding an inbound channel adapter to your flow you simply select the "errorChannel" option as channel on your exception channel and you are done.

As a result, the error will directly be sent to the eMagiz infrastructure to be analyzed and processed. This is a stark difference compared to the current solution that places the error on the error flow of your own model (if reachable) and from there places it on a seperate eMagiz model maintained by eMagiz and from there it is processed further throughout the portal.

By switching this behavior we improve the functionality in three distinct ways:

• Errors do not flow through many models before arriving in the Manage phase which makes it better maintanable.
• Easier to implement in entries and event processor without running risks of breaking other parts of the model.
• Clear distinction between eMagiz error handling and "custom error handling".

See below for how this is visualized in the flow designer.

3.1 Error flow configuration

Before resetting your error process flow you should identify which part of your error process flow were added by you to support your custom error handling. When you have identified these components select and copy them. Subsequently reset the error process so you end up with a blank slate in which you can then copy the custom components. Last thing to do is to make sure that the channels are connected properly and from that moment on the error process flow will only be used to handle custom errors.

4. Key takeaways

• Part of the migration path consists of determining whether you want to keep "custom error handling".
• When "custom error handling" is used you need to redesign your error process flow accordingly.