When building DataWeave transformations for your Mule application, you will run into situations in which you will need to invoke external logic that may be encapsulated in a Java POJO, Groovy, Python, Ruby script, or really any lookup that uses a CSV file or database table as part of the transformation.
When integration involves different applications, systems, or databases, we face a common challenge: how do we bridge between data formats and how can we provide interoperability for fields that store dates and date/time values?
Logic handling using DataWeave is essential for simple mediums and highly complex transformations, in which the mapping requirements necessitate generating outputs based on values provided in the input payload.
With as many systems of record available in the cloud– from SaaS applications like Salesforce to Netsuite – the need for a cloud-based enterprise messaging solution has now become necessary to support high availability, scalability, and reliability patterns in an Integration Platform as a Service (iPaaS) solution, such as MuleSoft’s CloudHub.
At MuleSoft, we work with a number of hospitals, healthcare systems, insurers, and other healthcare organizations. These organizations use different computer systems–from billing and Electronic Health Records (EHRs) to laboratory and pharmaceutical management systems. A common and critical use case that we come across is how we can enable these organizations and their partners to seamlessly exchange data with one another across different systems.
So far in this 3-part series, we have looked at variables (Part 1) and functions (Part 2) in order to leverage them to our advantage. In this third and final part of the real-world DataWeave series, we will look at another common problem area, that of performing nested loops in data structures.
Blockchains are slowly creeping their way into the enterprise and gaining acceptance. As Harvard researchers reveal, “No matter what the context, there’s a strong possibility that blockchain will affect your business. The very big question is when.” But what are Blockchains?
In the first part of this series we tackled the issue of defining and also using variables within DataWeave as opposed to using the legacy set “Variable” module. Today, I need to raise the topic of functions in DataWeave as a key thought when working with MuleSoft has to be “can I reuse this?”
Over the last few years at MuleSoft, I have had the opportunity to work with many different customers covering a wide range of use cases, inevitably requiring data transformations of one sort or another. I have observed some recurring patterns and “gotchas” when DataWeave is used in the real-world and I will address these in this 3-part series.
Everyone is very excited about chatbots as the future of messaging, customer service, information delivery, etc. Facebook touts Messenger bots as AI (e.g. Jarvis) and the press gets excited about how they will change the world. But really, bots are essentially an ESB that listens for keywords and routes responses back to the user. This project will show you how to build one using Anypoint Platform.
This example project provides a framework to build a Facebook Messenger Bot that can leverage APIs built on Anypoint Platform.
