Please Note, this feature is only available when the new mapper component with Sailor
2.6.13
version is installed in the system.
We introduce a new concept for error handling in the integration flows. Now you have a possibility to choose what to do with errors. In short you can handle those errors by building a workflow to catch them and store them in a most convenient way for you.
Before you would get error reports when you subscribe to receive them per email or if you would constantly checking your flows for errors on the platform UI by logging in.
Now you can do both of these if you still prefer it, but you can proactively handle those errors and decide what should happen with these errors and who should handle them.
To use and customise error handling choose the icon presented in the right bottom of the flow designer page after you configure the first step in the flow.
You can choose to configure it right away or wait when you finish the flow design and configure it to handle errors in one go since only one error handling is supported in this version.
Here is how the completed flow with error handling would look. Note, it handled the error in the third step.
In this example all errors in email components get redirected into a separate Google spreadsheet document.
In case when your custom component is not using a system-wide mapper component
right before to map the fields, then it will not show in the component chooser
as a method to process your errors. You can overcome this by upgrading your custom component Node.js Sailor to at least 2.6.13
version.
At this moment the components which do not require mapper component input to function would not show in the components list to choose.
At the moment the Custom Error Handling works for limited use cases and errors. For example it can not handle the following cases:
The incoming metadata from the Custom Error Handling is hard-coded. It has the following structure:
{
"error": {
"message": "Error message",
"name": "Error name",
"stack": "Error stack trace"
},
"errorInput": {
"properties": {
"headers": { "header":"value" }
},
"content": {
"headers": { "header":"value" },
"body": {}
}
}
}
We continue our improvements and developments of the New Secrets Management service. In this round we made great improvements on authentication parameters.
auth_uri
and token_uri
for OAuth2Authentication clients for OAuth2 now support auth_uri
and token_uri
attributes
in credentials.
Please Note: API-requests for auth-clients is different now. More iformation in auth-clients-(experimental) section of API documentation.
Secrets Management Service refreshes tokens 60 second earlier than
exires_in
parameter record to ensure the stability of the connection.
expires_in
taken from token_expires_in
Now when you create a new secret linked to auth-client
with a parameter token_expires_in
,
the parameter expires_in
gets the value from the token_expires_in
data.
From 1.1.0
version of Request-Reply component you
can add and configure the HTTP response code using the new Response Code
input field during the design phase. Response code is passed in the reply message
header. The default value is 200
by default.
2.6.13
.2.6.13
.2.6.13
.2.6.10
.2.6.9
.