--- schema_version: "1" id: 322ea816902c6b0f7c1809baba67b22817d264eb4d16b9f2f8f8383b9c1fd55c title: Creating Scopes with Mule SDK collection: mulesoft version: current locale: en-us portal_url: https://docs.salesforce.com/mulesoft/current/en-us/mule-sdk/latest/scopes.md canonical_url: https://docs.mulesoft.com/mule-sdk/latest/scopes source_site: docs.mulesoft.com content_type: documentation content_hash: 934ebf3f690c0fa18ec53bc1ef6db0d4531ddf34f3ff465fa72868c8b0c75855 description: MuleSoft Documentation Site release: "1.13" latest: true --- --- product: Mule SDK version: 1.13 is-latest-version: true keywords: mule, sdk, scopes, scope, components --- # Creating Scopes with Mule SDK > For the full documentation index, see: https://docs.mulesoft.com/llms.txt Scopes are similar to [Operations](https://docs.mulesoft.com/mule-sdk/latest/operations), but their execution includes the execution of other child [Operations](https://docs.mulesoft.com/mule-sdk/latest/operations). This means that a Scope is basically an operation that receives one or more arguments that are simple [Parameters](https://docs.mulesoft.com/mule-sdk/latest/parameters) along with a single `Chain` component and the `CompletionCallback`. A `Chain` represents the child [Operations](https://docs.mulesoft.com/mule-sdk/latest/operations) that you declare inside the Scope and provide an abstraction to execute them. ## Declaring a Scope You can see the basic structure of a Scope with this decorator example. It has the `Chain` to be executed and the `CompletionCallback` to invoke once the scope execution is done _(yes, all Scopes are declared as [Non-Blocking Operations](https://docs.mulesoft.com/mule-sdk/latest/non-blocking-operations))_: ```java @Extension(name = "Docs") @Operations(LogDecorator.class) public class DocsModule { } ``` ```java public void logDecorator(Chain operations, CompletionCallback callback) { LOGGER.debug("Invoking child operations") operations.process( result -> { LOGGER.debug(result.getOutput()); callback.success(result); }, (error, previous) -> { LOGGER.error(error.getMessage()); callback.error(error); }); } ``` Of course, if you receive a `Chain` of [Operation](https://docs.mulesoft.com/mule-sdk/latest/operations), you need to execute them in some way, and that is what the `process(successCallback, errorCallback)` does. With it, the example executes the `Chain` in a non-blocking fashion and listens for the results in case of success or error. Here, the `successCallback` is called with the execution result when a successful execution is completed by _all_ the [Operations](https://docs.mulesoft.com/mule-sdk/latest/operations) in the `Chain`. The `errorCallback` will be called if an error occurs during the execution of _any_ child [Operation](https://docs.mulesoft.com/mule-sdk/latest/operations), with both the error and the last successful result as arguments. Here is how you use the scope in a Mule app: ```xml ``` This executes the `http:request` child operation wrapped by the `LOGGER` invocations. Any number of [Operations](https://docs.mulesoft.com/mule-sdk/latest/operations) can be executed inside the scope, including other scopes or routers. ## Adding Parameters Scopes can receive other simple `@Parameters` and `@ParameterGroups`. They are _simple_ because Scopes are not allowed to receive _complex_ parameters that are declared as child elements. For example, if you want to customize the log level of the decorator, you will be able to receive that as a Parameter: ```java public void logDecorator(@Optional(defaultValue="true") boolean debug, Chain operations, CompletionCallback callback) { if (debug){ LOGGER.debug("Invoking child operations") } operations.process( result -> { Object message = result.getOutput(); if (debug){ LOGGER.debug(message); } else { LOGGER.info(message); } callback.success(result); }, (error, previous) -> { LOGGER.error(error.getMessage()); callback.error(error); }); } ``` With a minimal change in the Scope’s API: ```xml ``` By default, a `Chain` is executed using the Message that was received by the container Scope, but other definitions of the `process` method allow the user of the scope to customize the `payload` and `attributes` that will be used to execute the `Chain`. ## Using Stereotypes `Stereotypes` can be used to limit the [Operation](https://docs.mulesoft.com/mule-sdk/latest/operations) that are allowed to exist inside a `Chain`, which enforces consistency in its usage. Only the [Operations](https://docs.mulesoft.com/mule-sdk/latest/operations) that have the given `Stereotypes` can be declared inside the Scope. ```java public void assertAll(@AllowedStereotypes(AssertionStereotype.class) Chain assertions, @Optional boolean failOnError, CompletionCallback callback) { assertions.process( result -> { callback.success(Result.builder().output(true).build()); }, (error, previous) -> { if (failOnError){ callback.error(error); } else { callback.success(Result.builder().output(false).build()); } }); } ``` ```xml ``` ## Config-less and Connection-less Scopes have some restrictions that differentiate them from [Operations](https://docs.mulesoft.com/mule-sdk/latest/operations). By definition, Scopes are not allowed to depend on or receive a particular [Configuration](https://docs.mulesoft.com/mule-sdk/latest/configs) or [Connection](https://docs.mulesoft.com/mule-sdk/latest/connections). ## Only One Chain The `Chain` component is key in the definition of a Scope, so it is _required_ to have one and _only_ one `Chain` argument. ## Always Non-Blocking All Scopes must be defined as a `void` method receiving a `CompletionCallback` for communicating their Result, which means that all the Scopes are non-blocking by default. See [Non-Blocking Operations](https://docs.mulesoft.com/mule-sdk/latest/non-blocking-operations).