About Perceptive Flow Design

Perceptive Flow Design is an Anypoint Studio functionality that lets you visualize the mapping of data from one data format and structure to another.

Consider a flow in which you included an Anypoint Connector that’s preceded or followed by a Transform Message component. Mule Runtime uses the working connection to the resource to retrieve metadata about the payload and properties and feeds this data into DataWeave, providing the expected input or output. This avoids you the trouble of manually inspecting the Mule Event’s structure yourself.

For example, imagine that you need to connect your organization’s Salesforce accounts with Twitter to publicize specific performance indicators.

By dropping two connectors on your Studio canvas – Salesforce and Twitter – and configuring them to connect to your organization’s accounts, you can then drop a Transform Message component between the connectors and inspect its Mule Properties View to find that Mule Runtime has intelligently captured the data type and structure information from each provider, and prescribed the input and output for your data mapping.

With the prescription in place, all you need to do is configure the mapping, filling in the blanks of the DataWeave code.

Now imagine you are obtaining status update data from a Twitter connector and that you want to log the tweet text but you aren’t familiar with the property names used by this connector. Instead of having to look up Twitter’s documentation to find out the name of the property you need, you can just place a Logger message processor right after the Twitter connector and write in it. If you start writing #[payload. in the logger’s Message field, and then press ctrl + space bar, you will get a list of all the properties and methods associated to the payload, including the properties returned by the request that you’re performing on the Twitter connector.


Declaring Metadata

Mule 4 introduces a new prescriptive way to build reliable and reusable flow artifacts and apps. You can build, for example, more reliable applications by achieving earlier detection of errors during design time.
To make this possible without changing runtime semantics, Mule 4 uses metadata. Metadata should act as a prescriptive guidance to build more reliable and reusable applications.

We recommend you to use metadata declaration only when: . It is absolutely required, for example, metadata for a value being defined by you. . Or when it is most cohesive to an annotated value, for example, when metadata for a value is being used or expected by a component.

For example, the transform message component should not define a metadata contract. Dataweave acts as a data mediation device between the producer and consumer of data, and those boundaries are the ones that should define the contracts.

Being More Specific About Your Metadata Declarations

Using the transform message component’s output metadata as expected metadata could be wrong. By explicitly declaring a metadata type, you are masking the actual metadata type of the data coming out from your transform message component. DataWeave transform message implementation can completely infer this output data type.
The best practice is to define expected metadata where this data is used or consumed, and it is not automatically inferred (static/dynamic metadata).

At the same time, defining the input metadata for your Transform Message component also masks the actual incoming metadata coming into your transform message component to be used on mapping.
It would be best to define metadata where data is produced, and again, only when it is not automatically inferred (static/dynamic metadata). For example, in the source or the extension operation that generated the actual message payload.

With this concept in mind, always remember that whenever data lives outside the scope of a reusable artifact, you should also declare it as part of that artifact’s contract.
Flows and subflows, for example, are expected to declare their metadata contract, just like any other processor.

You should declare your input and output metadata specifying the shape of event you require, and the shape of the event you return to the caller. Output event declaration, if not specified, is automatically inferred from flow content when the flow is not recursive.

As with connectors, there are some special cases where flow metadata declaration can be automatically inferred based on related contracts. This is the case of resource flows for APIKit or SOAPKit. In these cases, corresponding API contract is used to infer a metadata contract for a resource flow.
As a direct consequence of this, there is no implicit metadata propagation of the whole event context through a flow reference (flow-refs) to a flow. If the flow or sub-flow is expected to be reused, this flow has to declare its data contract in terms of the input and output event.

Was this article helpful?

💙 Thanks for your feedback!

Edit on GitHub