Throw

	Important
	This article describes alternatives and workarounds to mimic the Throw errorService is unavailable due to a failure, a service responds with unexpected data or the validation of input data fails. More handling directive.

Boost.spaceCentralization and synchronization platform, where you can organize and manage your data. More IntegratorPart of the Boost.space system, where you can create your connections and automate your processes. More does not offer the Throw error handling directive. This feature implementation is being analyzed and evaluated.

Alternate solution

To conditionally throw an error you may configure a moduleThe module is an application or tool within the Boost.space system. The entire system is built on this concept of modularity. (module - Contacts) More to make it optionally purposely fail during its operationAn operation is a task performed by module. More. One possibility is to employ JSON > Parse JSON module configured to optionally throw an error (BundleValidationError in this case):

You can then attach one of the error handling directives to the error handling route to:

force the scenarioA specific connection between applications in which data can be transferred. Two types of scenarios: active/inactive. More execution to stop and perform the rollback phaseRollback is a phase that occurs when there is an error during the operation or commit phase on any module. The scenario execution stops the operation or commit phase and starts the rollback phase, reversing all changes in data. More: Rollback
force the scenario execution to stop and perform the commit phaseCommit is the third phase of scenario execution. If the operation phase is successful for all modules, the commit phase begins and makes all data changes permanent. This means that Boost.space Integrator sends information to all the services involved in the operation phase about its success.: Commit
stop the processing of a route: Ignore
stop the processing of a route and storing it in the queue of incomplete executions: Break

The following example shows the use of the Rollback directive:

Workaround – Using HTTP Module

Usecase – Retry after some time if there is no recordOne row in the Boost.space database. These are individual rows under spaces in each module. For example single products, but not their variants. More found using Break Directive. Usually, this is crucial when your record doesn’t update instantly and you would like to process it later on in automation. Using this Break directive could be handy with the lesser complexity of the setup.

Current Barrier – Boost.space Integrator does not offer a module that would enable you to easily conditionally generate (throw) errorsService is unavailable due to a failure, a service responds with unexpected data or the validation of input data fails. More.

To give you a better understanding here is the current setup without modification: This scenario search in Zendesk if there is no use it won’t throw an error forcefully to search it again you would need to implement a complex procedure by saving the record.

Solution – To conditionally throw an error you may replace the module where you want to throw an error, with an HTTP module then perform the search in a second scenario linking the HTTP module using webhookA webhook is a way for an app to send real-time information to a specific URL in response to certain events or triggers. with a second scenario. If no result found you can customize the module to throw an error

Scenario One –

Replace the Module where you want to throw an error with HTTP > Make a Request module
Configure the URL within the query parameter that you will get from the Custom Webhook module and add an optional query parameter to search for the email
Enable the advanced settings and check the evaluate all the states as errors.
Add a Break handler in that HTTP module and configure the setup to run later.

Scenario 2 –

Setup WebhooksA webhook is a way for an app to send real-time information to a specific URL in response to certain events or triggers. > Custom Webhooks as a triggerEvery scenario has a trigger, an event that starts your scenario. A scenario must have a trigger. There can only be one trigger for each scenario. When you create a new scenario, the first module you choose is your trigger for that scenario. Create a trigger by clicking on the empty module of a newly created scenario or moving the... and copy the URL use it in the HTTP module as shown in the previous steps.
Here use the Zendesk > Search for a UserCan use the system on a limited basis based on the rights assigned by the admin. More module use the parameter from the HTTP module to perform a query. Enable Continue the execution of the route even if the module returns no results
Add a RouterA router allows you to add new routes to a scenario so you can branch your flow into several routes and process the data within each route differently. More and create two routes
1. Setup the first filter for Record Exist
2. The second one for Record Doesn’t exist
Consecutively setup the webhook response module
1. If result found – send 200 statusCreate statuses for each module separately to create an ideal environment for efficient and consistent work. More along with the required body in JSON format.
2. If no result found – Send 4xx/404 and in the JSON no record found

The following example returning the result – You will notice when the Zendesk module executes the API it doesn’t send any error message but in the action, we’re replicating the error using the HTTP module.