External Functions Available to DataWeave
|
DataWeave 2.1 is compatible with Mule 4.1. Standard Support for Mule 4.1 ended on November 2, 2020, and this version of Mule will reach its End of Life on November 2, 2022, when Extended Support ends. Deployments of new applications to CloudHub that use this version of Mule are no longer allowed. Only in-place updates to applications are permitted. MuleSoft recommends that you upgrade to the latest version of Mule 4 that is in Standard Support so that your applications run with the latest fixes and security enhancements. |
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
|
Starting in Mule 4.1.4, DataWeave incorporated the Mule Runtime functions into its Mule function module. MuleSoft recommends that you start using the 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. Mule apps running on Mule Runtime versions prior to version 4.1.4
cannot use the |
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.
The following example logs the value of the property http.port.
<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.
<flow name="simple">
<logger level="INFO" doc:name="Logger"
message="#[var myVar = Mule::p('http.port') --- myVar]"/>
</flow><flow name="simple">
<logger message="#[p('http.port')]"/>
</flow>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
| Name | Description |
|---|---|
|
A string that identifies the target flow. |
|
The payload to send to the target flow, which can be any ( |
|
Optional. Timeout (in milliseconds) for the execution of the target flow. Defaults to |
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.
lookup Function in Mule 4.1.4 or Later<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>lookup Function in Mule 4.1.3 and Earlier<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>hello world|
Always keep in mind that a functional language like DataWeave expects the invocation of the MuleSoft recommends that you invoke flows with the Flow Ref ( |
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.
<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><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()].