Salesforce

Database Transactions and Error Handling (Magic xpi 4.14)

« Go Back

Information

 
Created BySalesforce Service User
Approval Process StatusPublished
Objective
Description

Database Transactions and Error Handling (Magic xpi 4.14)

If you define a flow with the DB Transaction flow property set to Yes, and a database that the transaction will be applied on, all Data Mapper steps that connect to this database will take part in the transaction. You must choose all the databases that are using this flow. There is no option to have a transaction only on some of the databases in the same context. If you want to run one of the Data Mapper steps out of the transaction, you must run it in a parallel step.

  • If the error behavior of the Data Mapper steps is set to Continue, all the records will be rolled back; the step and the rest of the flow will continue. However, if a crash occurs during the flow execution, all database operations included in the transaction will be rolled back.

  • If the error behavior of a Data Mapper step is set to Exit, and there is an error in the step, then all database operations included in the transaction will be rolled back and also the flow will terminate. Moreover, if this Data Mapper step is located in a flow called by a parent flow, the calling flow will also terminate.

  • If you select Dynamic, the step execution ends immediately if the error flow ends in an error. If the error flow clears the error, the flow will continue.

Flow Transaction

The Flow Transaction is a Logical unit and the following entities in the flow life cycle will be included as part of the transaction

· All the databases defined as part of the flow transaction.

· The Mapper steps which use database definitions and are defined outside the transaction.

· All the sub-flows called as part of the flow on which the transaction is applied.

These three entities constitute to the Logical unit for transaction and hence any commit or the rollback operation will be applicable for all the databases involved in the above 3 entities and not limited to the databases involved in the flow transaction.

  • The Record Dynamic option is not supported for the JDBC schema.

  • The execution of the step will stop if the deadlock condition is detected when the flow level transaction is enabled.

  • In certain scenarios, the "Rollback DB Transaction for Flow" error message might appear in the activity log, even though the records get committed in the database. The message can be ignored.

  • When the JDBC Data connector and Call Flow schema are configured in the same Mapper step with the DB transaction level set to Mapper, then in case of error in the child flow, the data in parent as well as child flow gets committed instead of getting rolled back.

  • The transaction applied on the Flow level will commit or rollback to the place where the transaction was initiated. As a result of rollback, the main flow and all the nested flows in the current runtime thread will be aborted.

  • In a multi-flow design, error flow should be defined in the flow where error actually takes place. For example, if the error is occurring in a child flow, the error flow should be defined on the child flow instead of main flow.

  • It is recommended to define error policies on the main flow.

Reference
Attachment 
Attachment