---
schema_version: "1"
id: 43aeb6da246bc7045b84bca175b561539074ea5f79794eb8685ceb300ef90a36
title: Try Scope (<try/>)
collection: mulesoft
version: current
locale: en-us
portal_url: https://docs.salesforce.com/mulesoft/current/en-us/anypoint-code-builder/acb-component-try.md
canonical_url: https://docs.mulesoft.com/anypoint-code-builder/acb-component-try
source_site: docs.mulesoft.com
content_type: documentation
content_hash: 3822bd659fa72db3253a048d0e52b1b5e2f95457f9f6bdead8213ae56eefe24d
description: MuleSoft Documentation Site
latest: true
---
---
product: Anypoint Code Builder
version: master
---

# Try Scope (<try/>)

> For the full documentation index, see: https://docs.mulesoft.com/llms.txt

Handle errors that might occur during the execution of components inside the scope.

The Try scope catches and handles exceptions thrown by the components that you add to the scope.
Error handling within the scope is similar to error handling within a Flow component. Instead of
configuring a separate flow, you can use Try within a Flow component.

Every payload modification or variable addition, modification, or removal is propagated through the
rest of the execution. This propagation includes modifications that take place inside the error
handlers.

The Try scope supports transactions. A transaction is a series of actions that must execute
successfully. Configure components within the Try scope as a single unit that either succeeds or
fails, depending on whether errors are propagated and the transaction rolled back, or handled and
the transaction committed. In either case, the flow that contains the Try scope continues.

## Component XML

This component supports the following XML structure:

```xml
<try
  doc:name="Try"
  doc:id="dieaig"
  transactionalAction="${action}" />
```

Try scope (`<try/>`) attributes are configurable through the UI and XML.

<table><colgroup><col> <col> <col></colgroup><thead><tr><th>Attribute Name</th><th>Attribute XML</th><th>Description</th></tr></thead><tbody><tr><td><p><strong>Try</strong> (default)</p></td><td><p><code>doc:name</code></p></td><td><div><div><p>Editable name for the component to display in the canvas.</p></div></div></td></tr><tr><td><p>N/A</p></td><td><p><code>doc:id</code></p></td><td><div><div><p>Automatically generated identifier for the component.</p></div></div></td></tr><tr><td><p><strong>Transaction type</strong></p></td><td><p><code>transactionType</code></p></td><td><div><div><p>Specifies the type of transaction. Accepted values are:</p></div><div><ul><li><p><code>LOCAL</code></p><div><p>Default. A single or local transaction.</p></div></li><li><p><code>XA</code></p><div><p>A transaction that groups operations from multiple resources and follows the Extended Architecture (XA) standard.</p></div></li></ul></div></div></td></tr><tr><td><p><strong>Transactional action</strong></p></td><td><p><code>transactionalAction</code></p></td><td><div><div><p>Defines how to handle a transaction. Accepted values are:</p></div><div><ul><li><p>Ignore (<code>INDIFFERENT</code>)</p><div><p>Default. If a transaction is active, the scope joins it. If not, the scope does not create a transaction.</p></div></li><li><p>Always Begin (<code>ALWAYS_BEGIN</code>)</p><div><p>A new transaction is started every time the scope is executed.</p></div></li><li><p>Begin or Join (<code>BEGIN_OR_JOIN</code>)</p><div><p>Relevant only when execution order might vary (for example, due to asynchronous actions occurring outside the flow). If current flow processing has already started a transaction, the scope joins it. If not, the scope initiates a new transaction.</p></div></li></ul></div></div></td></tr></tbody></table>

## Examples

The following examples show how to configure the Try scope to handle transactions in different
situations.

### Example: Different Transactional Actions in Try Scope

The following example shows a `jms:listener` operation configured to initiate a transaction at flow
level, a Try scope that tries to initiate or join the transaction (depending on its configuration),
and a `jms:publish` operation configured to run outside of the transaction:

```xml
<flow name="someFlow">
	<jms:listener config-ref="JMS_Config" destination="test.in" transactionalAction="ALWAYS_BEGIN"/>
	<!-- Processors -->
	<try transactionalAction="${action}">
		<!-- Processors -->
		<!-- Join if possible is the default value for jms:publish operation -->
		<jms:publish config-ref="JMS_Config" destination="test.out" transactionalAction="NOT_SUPPORTED"/>
		<raise-error type="APP:SOME"/>
		<!-- More Processors -->
	</try>
	<!-- Processors -->
</flow>
```

If the operations within the Try scope do not produce an error, the scope finishes the execution and
commits the transaction, independently of the configured `transactionalAction` value.

The transaction and the messages are handled differently when a `<raise-error/>` component is added,
depending on the `transactionalAction` of the Try scope:

- Ignore (`INDIFFERENT`)

  In this case, the transaction continues while executing the operations inside the Try scope. When
  the error is raised, it is propagated to the source (which does not handle it with an
  `<on-error-continue>` error handler). The transaction is rolled back, and the message is available
  again in the JMS queue. This rollback does not affect the completed `jms:publish` operation, which
  was outside of the transaction scope because `transactionAction` was set to its default,
  `NOT_SUPPORTED`.

  Had `transactionAction` been set to `JOIN_IF_POSSIBLE`, the `jms:publish` operation would have
  been rolled back.

- Always Begin (`ALWAYS_BEGIN`)

  This raises an error because an active transaction already exists.

- Begin or Join (`BEGIN_OR_JOIN`)

  In this case, a transaction was already initiated so the scope joins the active transaction. The
  result is the same as in `INDIFFERENT`.

### Example: Error Handling at Flow Level

The following example includes an error handler at flow level:

In the following example, an error handler is added at flow level:

```xml
<flow name="someFlow">
	<jms:listener config-ref="JMS_Config" destination="test.in" transactionalAction="ALWAYS_BEGIN"/>
	<!-- Processors -->
	<try transactionalAction="${action}">
		<!-- Processors -->
		<!-- Join if possible is the default value for jms:publish operation -->
		<jms:publish config-ref="JMS_Config" destination="test.out"/>
		<raise-error type="APP:SOME"/>
		<!-- More Processors -->
	</try>
	<!-- Processors -->
	<error-handler>
		<on-error-continue/>
	</error-handler>
</flow>
```

The behavior in this example is:

- Ignore (`INDIFFERENT`)

  The transaction continues. Because the error is handled by an `on-error-continue` error handler,
  the transaction is committed. The message read from the `jms:listener` source is consumed, and the
  message processed by the `jms:publish` operation is actually sent.

- Always Begin (`ALWAYS_BEGIN`)

  Raises an error because an active transaction already exists.

- Begin or Join (`BEGIN_OR_JOIN`)

  Displays the same behavior as `INDIFFERENT`.

### Example: Error Handling Inside the Try Scope

In the following example, the error handler is inside the Try scope and the error occurs after the
execution of the scope:

```xml
<flow name="someFlow">
	<jms:listener config-ref="JMS_Config" destination="test.in" transactionalAction="ALWAYS_BEGIN"/>
	<!-- Processors -->
	<try transactionalAction="${action}">
		<!-- Processors -->
		<!-- Join if possible is the default value for jms:publish operation -->
		<jms:publish config-ref="JMS_Config" destination="test.out"/>
		<!-- More Processors -->
		<!-- There could be a component that raises an error, it will be handled by the error handler -->
		<error-handler>
			<on-error-continue/>
		</error-handler>
	</try>
	<!-- Processors -->
	<raise-error type="APP:SOME"/>
</flow>
```

Depending on the configured `transactionalAction`, the behavior in the Try scope is one of the
following:

- Ignore (`INDIFFERENT`)

  The transaction continues but the error is not handled by an `on-error-continue` at the flow
  level, causing the transaction to be rolled back, and the message to not be sent.

- Always Begin (`ALWAYS_BEGIN`)

  Raises an error because an active transaction already exists.

- Begin or Join (`BEGIN_OR_JOIN`)

  Displays the same behavior as `INDIFFERENT`.

## Error Handling

When designing your flow, group those operations that are likely to experience errors inside a Try
scope. The Try scope enables you to isolate potentially troublesome operations in your flow and
assign them an error-handling method. You can also configure the operations inside the Try scope to
be processed as a transaction.

The Try scope has an error handling strategy that you configure in the same way you configure error
handling for a flow.

The Try scope can distinguish among various error type conditions and apply different behaviors. If
an error is raised by a component inside a Try scope, then the Try scope’s error handler is
executed. At this point, the error is available for inspection, so the handlers can execute and act
accordingly:

- On Error Continue

  Executes and sends the result of the execution to its container Try scope, which uses that result
  to complete the execution successfully. Any transactions at this point are also committed.

- On Error Propagate

  Rolls back any transactions, then executes and uses that result to re-throw the existing error,
  causing its container Try scope’s execution to fail.

## See Also

- [Single Resource Transactions](https://docs.mulesoft.com/mule-runtime/latest/single-resource-transaction)

- [XA Transactions](https://docs.mulesoft.com/mule-runtime/latest/xa-transactions)