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

Transcript

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.