Rolling back an outer transaction

The rollBackOuterTransaction operation is useful in operational environments that use outer transactions. In case a running outer transaction fails, this operation lets you roll back to the previously committed version of the index and commit the transaction.

You can run this operation directly with a tool such as soapUI or Integrator ETL. In Integrator ETL, you can use one of two options: either through the Transaction RunGraph component and its rollback option, or by using the WebServiceClient component, by configuring it to access the Transaction Web Service on the particular data domain, and specifying the rollBackOuterTransaction operation to it.

The following statements describe the rollBackOuterTransaction operation:

If you are running this operation through a tool such as soapUI, ensure that the tool accesses the Transaction Web Service as follows:
```
http://localhost:<port>/ws/transaction/<DataDomain>?wsdl
```
Use this operation only if an outer transaction has been started on the node, referencing a transaction ID in the OuterTransactionIdToRollBack element, as in the following example:
```
<rollBackOuterTransaction>
   <OuterTransactionIdToRollBack>myID</OuterTransactionIdToRollBack>
</rollBackOuterTransaction> 
```
Note: The transaction ID can be either specified to the Transaction Web Service when you start a transaction, or, if you don't specify it, the Web service generates the ID automatically. The operation listOuterTransaction lists the ID. Also, if you are using the Transaction RunGraph connector for running transactions, this connector automatically uses the ID string "transaction".
If you issue this operation with the outer transaction ID that does not match the ID of the currently running outer transaction, an error message notifies you of the transaction ID that is in progress.
If you are using this operation directly (such as in soapUI) and not in the context of Integrator ETL, you can issue it at any point during a running outer transaction. Once issued, this operation ensures that inner transactions running within the outer transaction are rolled back.
If you have updating requests sent to the server that didn't specify the outer transaction ID, these requests wait for the outer transaction to finish (be committed or rolled back). If you roll back the outer transaction, these requests start being processed by the server based on the published version of the data files that is available after the rollback operation.
If you are running a data domain cluster hosted in the Endeca Server cluster, and issue this operation, it is routed to the Endeca Server hosting the leader Dgraph node for the data domain.
Once the operation completes, it stops the outer transaction, and the leader resumes serving queries on the last version of the index available before the start of the outer transaction.
Only one rollBackOuterTransaction operation can be processed at a time.