---
schema_version: "1"
id: e814588be7a0b04b8d9f22665480e214bf40b7c5c474897cf53d6784adc7cad5
title: External Functions Available to DataWeave
collection: mulesoft
version: current
locale: en-us
portal_url: https://docs.salesforce.com/mulesoft/current/en-us/dataweave/latest/dataweave-runtime-functions.md
canonical_url: https://docs.mulesoft.com/dataweave/latest/dataweave-runtime-functions
source_site: docs.mulesoft.com
content_type: documentation
content_hash: 66932454cb390eaddf79bb059053e30e1f2dee4dcf3c719220e613731b013ef3
description: MuleSoft Documentation Site
release: "2.13"
latest: true
---
---
product: DataWeave
version: 2.13
is-latest-version: true
keywords: lookup, causedby, p, properties, functions
---

# External Functions Available to DataWeave

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

In addition to the built-in DataWeave functions, Mule Runtime and some modules, connectors, and Core
components provide functions that you can use in DataWeave scripts. The functions are specific to
the modules, connectors, and components that provide them.

## Mule Runtime Functions

These functions are injected by the Mule Runtime:

- `p`

- `lookup`

- `causedBy`

> [!NOTE] Starting in Mule 4.1.4, DataWeave incorporated the Mule Runtime functions into its Mule
> function module.
>
> MuleSoft recommends that you start using the `Mule` namespace when using these functions in Mule
> apps that are running on Mule Runtime 4.1.4 or later. To use them, you simply prepend the
> namespace to the function name, for example, `Mule::p('http:port')`, instead of `p('http:port')`.
>
> In addition to its continued support for the use of Mule Runtime functions in your DataWeave
> scripts and mappings, the Mule module also enables you to use Mule Runtime functions in your
> [custom DataWeave modules](https://docs.mulesoft.com/dataweave/latest/dataweave-create-module).
>
> Mule apps running on Mule Runtime versions _prior_ to version 4.1.4 cannot use the `Mule`
> namespace or use Mule Runtime functions in custom modules, only in DataWeave scripts and mappings.

For DataWeave runtime properties, see the DataWeave functions [props](https://docs.mulesoft.com/dataweave/latest/dw-runtime-functions-props)
and [prop](https://docs.mulesoft.com/dataweave/latest/dw-runtime-functions-prop).

### Accessing Properties (p Function)

The `p` function provides access to properties, whether these are:

- Mule property placeholders

- System properties

- Environment properties

For more on configuring properties and how they are handled, see
[Configure Properties](https://docs.mulesoft.com/mule-runtime/latest/configuring-properties).

The following example logs the value of the property `http.port`.

Example: Property Function Usage for Mule 4.1.4 and Later

```xml
<flow name="simple">
  <logger level="INFO" doc:name="Logger"
    message="#[Mule::p('http.port')]"/>
</flow>
```

Note that you can also use the function when defining a DataWeave variable or function. This example
uses the `p` function in the `myVar` definition. You can do the same thing with pre-4.1.4 runtimes
simply by omitting the `Mule::` namespace.

```xml
<flow name="simple">
  <logger level="INFO" doc:name="Logger"
    message="#[var myVar = Mule::p('http.port') --- myVar]"/>
</flow>
```

Example: Property Function Usage for Mule 4.1.3 and Earlier

```xml
<flow name="simple">
  <logger message="#[p('http.port')]"/>
</flow>
```

See also, the [p](https://docs.mulesoft.com/dataweave/latest/dw-mule-functions-p) function introduced in the Mule function module in Mule 4.2.

### Execute a Flow (lookup Function)

Similar to the Flow Reference component, the `lookup` function enables you to execute another flow
within your app and to retrieve the resulting payload. It takes the flow’s name and an input payload
as parameters. For example, `lookup("anotherFlow", payload)` executes a flow named `anotherFlow`.

The function executes the specified flow using the current attributes, variables, and any error, but
it only passes in the payload without any attributes or variables. Similarly, the called flow will
only return its payload.

Note that `lookup` function does not support calling subflows.

#### Parameters

<table><colgroup><col> <col></colgroup><thead><tr><th>Name</th><th>Description</th></tr></thead><tbody><tr><td><p><code>flowName</code></p></td><td><p>A string that identifies the target flow.</p></td></tr><tr><td><p><code>payload</code></p></td><td><p>The payload to send to the target flow, which can be any (<code>Any</code>) type.</p></td></tr><tr><td><p><code>timeoutMillis</code></p></td><td><p>Optional. Timeout (in milliseconds) for the execution of the target flow. Defaults to <code>2000</code> milliseconds (2 seconds) if the thread that is executing is CPU_LIGHT or CPU_INTENSIVE, or 1 minute when executing from other threads. If the lookup takes more time than the specified <code>timeoutMillis</code> value, an error is raised.</p></td></tr></tbody></table>

This example shows XML for two flows. The `lookup` function in `flow1` executes `flow2` and passes
the object `{test:'hello '}` as its payload to `flow2`. The Set Payload component (`<set-payload/>`)
in `flow2` then concatenates the value of `{test:'hello '}` with the string `world` to output and
log `hello world`.

Example: Using the `lookup` Function in Mule 4.1.4 or Later

```XML
<flow name="flow1">
  <http:listener doc:name="Listener" config-ref="HTTP_Listener_config"
    path="/source"/>
  <ee:transform doc:name="Transform Message" >
    <ee:message >
      <ee:set-payload ><![CDATA[%dw 2.0
output application/json
---
Mule::lookup('flow2', {test:'hello '})]]></ee:set-payload>
    </ee:message>
  </ee:transform>
</flow>
<flow name="flow2" >
  <set-payload value='#[payload.test ++ "world"]' doc:name="Set Payload" />
  <logger level="INFO" doc:name="Logger" message='#[payload]'/>
</flow>
```

Example: Using the `lookup` Function in Mule 4.1.3 and Earlier

```XML
<flow name="flow1">
  <http:listener doc:name="Listener" config-ref="HTTP_Listener_config"
    path="/source"/>
  <ee:transform doc:name="Transform Message" >
    <ee:message >
      <ee:set-payload ><![CDATA[%dw 2.0
output application/json
---
lookup('flow2', {test:'hello '})]]></ee:set-payload>
    </ee:message>
  </ee:transform>
</flow>
<flow name="flow2" >
  <set-payload value='#[payload.test ++ "world"]' doc:name="Set Payload" />
  <logger level="INFO" doc:name="Logger" message='#[payload]'/>
</flow>
```

Output

```json
hello world
```

> [!WARNING] Always keep in mind that a functional language like DataWeave expects the invocation of
> the `lookup` function to _not_ have side effects. As such, the internal workings of the DataWeave
> engine might cause a `lookup` function to be invoked in parallel with other \`lookup\`s, or not
> invoked it at all.
>
> MuleSoft recommends that you invoke flows with the Flow Ref (`flow-ref`) component, using the
> `target` attribute to put the result of the flow in a `var` and then referencing that `var` from
> within the DataWeave script.

### Matching Errors by Types (causedBy Function)

The `causedBy` function matches an error by its type, like an error handler does. This is useful
when matching by a super type is required but specific sub-type logic is also needed or when
handling a `COMPOSITE_ROUTING` error that contains child errors of different types.

The error to match against can be implicit, but the type is always a required parameter.

In the following example, a global error handler is set up to handle `SECURITY` errors in a general
way, while specific actions are set up for `HTTP:UNAUTHORIZED` and `HTTP:FORBIDDEN` errors.

Example: Error Matcher Function Usage in Mule Runtime Version 4.1.4 and Later

```xml
<error-handler name="securityHandler">
  <on-error-continue type="SECURITY">
    <!-- general error handling for all SECURITY errors -->
    <choice>
      <when expression="#[error Mule::causedBy 'HTTP:UNAUTHORIZED']">
        <!-- specific error handling only for HTTP:UNAUTHORIZED errors -->
      </when>
      <when expression="#[Mule::causedBy('HTTP:FORBIDDEN')]">
        <!-- specific error handling only for HTTP:FORBIDDEN errors -->
      </when>
    </choice>
  </on-error-continue>
</error-handler>
```

Example: Error Matcher Function Usage in Mule Runtime Version 4.1.3 and Earlier

```xml
<error-handler name="securityHandler">
  <on-error-continue type="SECURITY">
    <!-- general error handling for all SECURITY errors -->
    <choice>
      <when expression="#[error causedBy 'HTTP:UNAUTHORIZED']">
        <!-- specific error handling only for HTTP:UNAUTHORIZED errors -->
      </when>
      <when expression="#[causedBy('HTTP:FORBIDDEN')]">
        <!-- specific error handling only for HTTP:FORBIDDEN errors -->
      </when>
    </choice>
  </on-error-continue>
</error-handler>
```

Notice that the error parameter is used both explicitly and implicitly.

## Connector and Component Functions

When using connectors and components in a Mule app, you can inject functions. Unlike the Runtime
functions, these functions require a namespace, which usually matches the component name.

For example, in an app using Batch you can use the following expression:
`#[Batch::isSuccessfulRecord()]`.

## See Also

[DataWeave Core Functions](https://docs.mulesoft.com/dataweave/latest/dw-functions)

[DataWeave Types](https://docs.mulesoft.com/dataweave/latest/dataweave-types)

[DataWeave Selectors](https://docs.mulesoft.com/dataweave/latest/dataweave-selectors)