You are viewing an older version of this topic. To go to a different version, use the version menu at the upper-right. +

Mule DataSense

Mule DataSense uses message metadata to facilitate application design. With this functionality, Mule Studio proactively acquires information about data, such as data type and structure, in order to prescribe how to accurately map or use data in your application.

Rather than forcing you to manually discover information about the data your internal and external resources employ, Mule intelligently discovers this information and uses it to make application design suggestions. For example, if your application must connect to Twitter, Mule DataSense captures information about the type and structure of data that Twitter employs, then uses the information to advise you of the type of data you should send to, or expect to receive from Twitter.  


This document assumes that you are familiar with the Visual Editor in Mule Studio, the Anypoint Connectors, and the Anypoint DataMapper transformer that you can use to create applications in Studio. Further, this document references Connectors and Global Elements. Review the Getting Started with Mule Studio chapter to learn more about developing with Mule ESB’s graphical user interface.

DataSense Functionality

As part of the phased implementation of DataSense, Mule ESB with Studio 3.4 introduces two features that initiate proactive discovery of metadata from external resources:

  1. Connection Testing

  2. Perceptive Flow Design 

Connection Testing

This functionality enables you to test connections to external resources. As you model your application in Studio, you have the opportunity, when configuring connectors, to test the functionality of its connection to a service or database.  Rather than waiting until you run the application to test the connection, you can test early to confirm functionality before moving on.

For example, if you are configuring an Anypoint Connector to communicate with Salesforce, you can enter the required configuration values (login credentials, host and port, proxy settings), then simply click to test connectivity. Mule submits a call to Salesforce to confirm the connection exists and is functional.

Perceptive Flow Design

Building upon the certainty that connection testing establishes, Mule takes one more step to make designing your application easier with Perceptive Flow Design. If you model a flow to include an Anypoint Connector, preceded or followed by an Anypoint DataMapper transformer, Mule uses the working connection to the resource – a SaaS provider, for example – to retrieve metadata about message payload and properties. Capturing the data type and structure that a SaaS employs, Mule feeds that data into the DataMapper, thereby informing the DataMapper of the expected input or output.  This functionality facilitates mapping of data from one data format and structure to another which saves you the development time you would otherwise spend trying to discover the structure and format yourself. 

For example, imagine you are tasked with the job of connecting your organization’s Salesforce accounts with Twitter to publicize specific performance indicators. One of your first tasks would be to examine the available documentation from both SaaS providers to determine what type of data structures they use so that you can, eventually, figure out how to map one structure to the other. Rather than plod through that exhausting exercise, you can utilize Perceptive Flow Design. Drop two connectors onto your Mule Studio canvas – Salesforce and Twitter – then configure them and test their connections. After confirming connectivity, simply drop a DataMapper Transformer between the connectors. Open DataMapper to find that Mule has intelligently captured the data type and structure information from each SaaS 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.

DataSense Best Practices

To take full advantage of the functionality DataSense has to offer, design-time best practice dictates that you should build an application in the following order:

  1. Begin by dropping endpoints and connectors into your flow through which data flows into, and out of, your application. For example, start by configuring an HTTP endpoint, followed by an Anypoint Connector.

  2. Configure the endpoints and connectors — and the global connectors they reference — so that, where possible, you can establish connections and use DataSense to extract any metadata about the expected input or output with the external source.

  3. Insert other elements into your flow to enrich the message, set, copy or remove variable or properties, route messages, etc.

  4. Lastly, insert DataMapper transformers into your flow to adjust the format or structure of the message so that each connector receives the input it expects.

The objective of this design-time strategy is to set the pieces of the integration puzzle in place, then "glue them together" with DataMappers. Rather than designing a flow sequentially, this type of "align, then glue together" strategy ensures that you are utilizing DataSense, wherever possible, to pre-populate the information about the structure and format of the input or output data into a DataMapper.  

For example, if you configure a Salesforce connector in your application, then drop a DataMapper after it, the DataMapper uses the information that DataSense extracted to pre-populate the input values for mapping, so that you only need to confirm (or adjust) the input selections, then proceed to mapping to your desired output.  In other words, DataSense makes sure that DataMapper knows the data format and structure with which it must work so you don’t have to figure it out manually. Whenever you can use DataSense, you are taking a development shortcut, removing the hassle of manually discovering the format and structure of data contained within a message. 

See Also