DataSense

You must understand how your components use metadata in a flow to ensure data reliability in your Mule application. This understanding enables you to detect errors early during project design. Additionally, it helps you identify when a component needs metadata that isn’t exposed to it within its scope, thus promoting data reusability.

Consider a flow in which you include an Anypoint Connector preceded or followed by a Transform Message component. The Mule runtime engine uses the working connection to the resource to retrieve and supply DataWeave metadata about the payload and properties. This feature saves you the effort of manually inspecting Mule event structure.

For example, imagine that you must connect your organization’s Salesforce account to Slack to notify your team about a new opportunity. To do this, you can drop both Salesforce and Slack connectors on your Studio canvas and configure them to connect to your organization’s accounts. Then, you can drop a Transform Message component between the connectors. Mule automatically captures the data type and structure information from each provider and prescribes the input and output for your data mapping. With this prescription in place, you can configure the mapping, populating the DataWeave code.

Imagine that you’re obtaining status update data from the Slack connector. You want to log the message you’re sending to Slack, but you aren’t familiar with the property names used by this connector. Instead of referring to Slack documentation, you can insert a Logger message processor after the Slack connector and begin to type in it, which activates autocomplete. For example, if you type #[payload. and press Ctrl+Spacebar, you get a list of all the properties and methods associated with that payload. In the list, you also get the properties returned by your request to the Slack connector.

You can manually define the metadata that all the components of a Mule application expose. You must do this if required (for example, for a metadata type that you defined). Or you must define metadata manually if it’s most cohesive to an annotated value (for example, when a component uses or expects a specific metadata type).

When working with flows and subflows, you must declare their metadata contract to specify the shape of the event you require and the shape of the event you return to the caller. On the contrary, do not define metadata when using the Transform Message component because DataWeave defines the contract between the producer and the consumer of data. In this situation, if you explicitly declare a metadata type, you mask the actual metadata type of the data coming from your Transform Message component.