External Functions Available In DataWeave
A number of functions are available in addition to DataWeave’s, provided by both the Mule Runtime and Modules/Connectors in your app. These functions can be used within DataWeave scripts and provide functionally beyond the language, specific to the component exposing them.
These functions are always available since they are injected by the Mule Runtime.
p function provides access to properties, whether these are:
Mule property placeholders
You can read more on configuring properties and how they are handled here.
The following example will log the value of the property
1 2 3 <flow name="simple"> <logger message="#[p('some.property')]"/> </flow>
lookup function allows executing a flow within your app and retrieves the resulting payload, taking the flow’s name and an input payload as parameters.
The specified flow will be executed using the current attributes, variables and error, only replacing the payload for the parameter one, which must be a Java type.
Learn more about
causedBy function allows matching an error by it’s type as an error handler would. This is useful when matching by a super type is required but specific sub type logic needed as well, or to handle 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, yet specific actions are set up for
1 2 3 4 5 6 7 8 9 10 11 12 13 <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.
Functions provided by Modules or Connectors will only be injected if said component is used in the app. Unlike the Runtime functions, using them requires providing a namespace, which will usually match the component name.
For example, in an app using Batch one can use the following expression:
Check each component documentation for a list of exposed functions.