DataSense

Understanding how your components use metadata in a flow is key to ensuring data reliability by enabling early detection of errors during project design and data reusability in your Mule application by detecting when a component requires metadata that is not being exposed to it within its scope.

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 to DataWeave metadata about the payload and properties, saving you the effort of manually inspecting Mule event structure.

For example, imagine that you need to connect your organization’s Salesforce account to Slack to notify your team about a new opportunity. To accomplish 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 are obtaining status update data from the Slack connector and you want to log the message you are 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 then press ctrl + space bar, you get a list of all the properties and methods associated with that payload, including the properties returned by your request to the Slack connector.

Although all components of a Mule application allow you to manually define the metadata that they expose, you should do so only when it is absolutely required (for example, for a metadata type that you defined), or when it is most cohesive to an annotated value (for example, when a component uses or expects a specific metadata type).

For example, 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 your return to the caller. On the contrary, you should not define metadata when using the Transform Message component because DataWeave defines the contract between the producer of data 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.