Skip to main content

         This documentation site is for previous versions. Visit our new documentation site for current releases.      

This content has been archived and is no longer being updated.

Links may not function; however, this content may be relevant to outdated versions of the product.

Error handling in connector rules

Updated on September 10, 2021

 This presentation is part of the Services and Connectors Self-Study Course.


You need to think about any manual rollback processing you need to put in place if you have a fatal exception during a particular flow action.  Let's say you have two Integrator shapes in your flow that execute when submitting a flow action. 

  • The first integrator shape calls a SOAP service that inserts rows into a database. 
  • The second integrator shape calls a SOAP service that also inserts rows into the database.

There is a failure in the second integrator shape.

From a business perspective, the first operation should be cancelled (rollback) when the second operation fails.  There are a couple things that you can do depending upon your circumstances, which include:

  1. Manage the exception in the Connector Activity called by the second integrator shape, and as part of managing the exception, issue another SOAP request to reverse the operation of the first one.  You can do this by configuring a Transition section in the activity step that calls a Connector Rule.
  2. Transfer the current business process to an error handling flow.  Developers make whatever fix is necessary, and deploy new rules to production.  A system administrator restarts the real flow, re-executing at the second integrator shape.
  3. Manage the actual committal of the data from within the services being called, such that data in the first operation is not committed until the second operation appears to be successful.  An SOA might help in this effort.

If you are executing two or more SQL connectors as part of a single flow action, you may be able to use distributed transactions if your database and application server software both support it.  This would mean that if the second SQL connector fails, you could actually roll back the operation from the first connector, which would be done automatically by the application server.

Note:  You can run connectors in parallel such that two or more connectors are run asynchronously.

Have a question? Get answers now.

Visit the Support Center to ask questions, engage in discussions, share ideas, and help others.

Did you find this content helpful?

Want to help us improve this content?

We'd prefer it if you saw us at our best. is not optimized for Internet Explorer. For the optimal experience, please use:

Close Deprecation Notice
Contact us