Error handling synchronous flows

{{container}}{{container layoutStyle="columns"}}(((

To correctly manage an eMagiz project, you need robust and stable error handling. This error handling process was the same for both asynchronous and synchronous flows. In this process, all errors thrown by a flow would be routed via the asynchronous error process each eMagiz project has. For synchronous flows, this meant that apart from the actual error, each step in the process that did not receive a message within the set timeframe would subsequently throw a timeout error.

3

This process had three disadvantages

4

5

* The client needed to wait for the allowed timeout period (default 20000 ms) before knowing whether or not the action succeeded

6

* The client only received a generic timeout error instead of information on the error that occurred downstream

7

* Any synchronous error could lead to up to five separate error messages making it more confusing and difficult to analyze what was going wrong properly

8

Based on this consideration, errors are handled in a synchronous flow have changed. See below for the old way, the new way, and how to migrate to the new method.

9

10

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

11

12

== 1. Prerequisites ==

13

14

* Advanced knowledge of the eMagiz platform

15

* Synchronous messaging flows in your model

16

17

== 2. Key concepts ==

18

19

* The new approach makes sure that the error message is returned to the client

20

* You have the choice to either write a warning to the log or return an error to the asynchronous error handling as additional functionality

21

22

== 3. Error handling synchronous flows ==

23

24

=== 3.2 Legacy approach ===

25

26

In the legacy situation, the flow would handle its error message asynchronously. See the picture below for how this is configured in the flow. That way, the other flows in the chain are still waiting for an answer that will never come.

27

28

[[image:Main.Images.Migrationpath.WebHome@migration-path-error-handling-synchronous-messaging-flows--old-error-handling-sync-flows.png]]

29

30

=== 3.3 New approach ===

31

32

All (error) messages are returned to the flow preceding the current flow in the new situation. This way, the error message is given back to the client to know what went wrong. This looks as follows in a flow.

33

34

[[image:Main.Images.Migrationpath.WebHome@migration-path-error-handling-synchronous-messaging-flows--new-error-handling-sync-flows.png]]

35

36

=== 3.4 How to get to the new approach ===

37

38

Migrating from the old way of handling errors in a synchronous flow to the new way of handling errors in a synchronous flow takes several steps to make it work correctly. Below you will find all these steps. Follow them carefully to achieve the desired result

39

40

1. Identify the synchronous flow in your eMagiz project that you want to change

41

2. Navigate to Create and open the exit

42

3. Loopback the error to the response channel. See below for the correct configuration

43

44

[[image:Main.Images.Migrationpath.WebHome@migration-path-error-handling-synchronous-messaging-flows--error-component-configuration.png]]

45

46

4. Save the flow and go to the offramp

47

5. Loopback the error to the response channel (see above for the correct configuration)

48

6. Add a standard filter component and fill it in according to the below specifications

49

50

[[image:Main.Images.Migrationpath.WebHome@migration-path-error-handling-synchronous-messaging-flows--standard-filter-configuration.png]]

51

52

7. Add a new channel and link the components to achieve a result, as shown above under the new section

53

8. Save the flow

54

9. Repeat steps 5,6, 7, and 8 for the onramp

55

10. Open the entry

56

11. In here, you have the choice to handle the error in two ways

57

58

* Send the error back to the client. This can be achieved by following steps 5,6,7 and 8

59

* Send the error to the client after setting the statusCode and the error message. For this, continue with step 12

60

* Don’t send the error to the client but the emagiz error flow instead. For this, continue with step 13

61

62

12. To specify what the client will see as a response in case of an error, you can change the following two things

63

64

* The statusCode (i.e. 401,403,500,501). This can be done by setting the header, with the help of a standard header enricher, titled http_statusCode, to the desired status code

65

* The payload. The payload can be changed to what you want with the help of a standard transformer or an XSLT transformer. An example of this is shown below

66

67

[[image:Main.Images.Migrationpath.WebHome@migration-path-error-handling-synchronous-messaging-flows--response-structure-client.png]]

68

69

13. Add a JMS outbound channel adapter and send the messages to the eMagiz error flow of your project. This way, the message will appear in the Error messages overview of eMagiz, but all timeout errors won’t show up anymore.

70

14. Test your changes

71

72

* If possible, test your flowing by using the "Flow Test" functionality. For more information see [[User Guide Flow testing>>doc:Main.eMagiz Academy.Microlearnings.Crash Course.Crash Course Platform.crashcourse-platform-create-configuring-flow-test||target="blank"]]

73

* Otherwise, test it by deploying the flow and sending a message.

74

75

15. Verify your results

76

77

* If the result is the same, you are finished

78

* If changes exist, analyze them and make changes to the transformation until you have reached the correct result

79

80

Of course, it is possible to use a combination of the suggestion made in steps 11, 12, and 13 to configure the error handling to your specific use case. If you plan to implement a new synchronous flow, please consider the API Gateway functionality. For more information please see

81

[[User Guide API Gateway>>doc:Main.eMagiz Academy.Microlearnings.Crash Course.Crash Course API Gateway.WebHome||target="blank"]]

82

83

Congratulations, you have successfully migrated the error handling of your synchronous flows to the new best practice.

84

85

== 4. Key takeaways ==

86

87

* The new approach makes sure that the error message is returned to the client

88

* You have the choice to either write a warning to the log or return an error to the asynchronous error handling as additional functionality

89

90

== 5. Suggested Additional Readings ==

91

92

* [[Crash Course (Menu)>>doc:Main.eMagiz Academy.Microlearnings.Crash Course.WebHome||target="blank"]]

93

** [[Crash Course API Gateway (Navigation)>>doc:Main.eMagiz Academy.Microlearnings.Crash Course.Crash Course API Gateway.WebHome||target="blank"]]

94

* [[Intermediate Level (Menu)>>doc:Main.eMagiz Academy.Microlearnings.Intermediate Level.WebHome||target="blank"]]

95

** [[Understanding Error Handling (Navigation)>>doc:Main.eMagiz Academy.Microlearnings.Intermediate Level.Understanding Error Handling.WebHome||target="blank"]]

96

*** [[Error Handling in Messaging Synchronous (Explanation)>>doc:Main.eMagiz Academy.Microlearnings.Intermediate Level.Understanding Error Handling.intermediate-understanding-error-handling-in-emagiz-messaging-synchronous||target="blank"]]

97

* [[Error Handling Synchronous (Search Result)>>url:https://docs.emagiz.com/bin/view/Main/Search?sort=score&sortOrder=desc&highlight=true&facet=true&r=1&f_space_facet=0%2FMain.&f_type=DOCUMENT&f_locale=en&f_locale=&f_locale=en&text=%22error+handling+synchronous%22||target="blank"]]

98

99

)))((({{toc/}}))){{/container}}{{/container}}

Wiki source code of Error handling synchronous flows

Navigation