One of the key elements of TriggerMesh is the event transformation engine (code named Bumblebee for obvious reasons). It takes events represented with the CloudEvents specification from a source and modifies them before passing the result to a target. Like all parts of TriggerMesh, this transformation is defined using an API object via a declarative manifest and deployed in Kubernetes. Once applied in TriggerMesh, these transformations can be reused by developers in order to reliably modify events in an expected manner at scale. Because TriggerMesh is built on Knative, these transformations auto-scale out of the box, including scaling down to zero.
Some of our customers use MuleSoft® DataWeave and want to transform data Cloud-Natively in Kubernetes while keeping their DataWeave scripts intact. Our new DataWeave Transformation, which is in tech preview and will be open sourced soon, is quite useful if you are trying to bridge legacy integrations in the Cloud era, benefit from a GitOps mindset and migrate to a Kubernetes-based infrastructure while extending the lifetime of your existing investments. The huge benefit is that you can keep your spells intact and create an endpoint that exposes this data transformation without running MuleSoft. You only need TriggerMesh which is open source.
In this blog, we will look at how TriggerMesh can use existing DataWeave scripts to transform your data. We will do this in three steps:
With TriggerMesh, you can transform data Cloud-Natively in Kubernetes while keeping DataWeave scripts intact. This allows you to bridge legacy integrations into the Cloud era, embrace a GitOps mindset, migrate to Kubernetes-based infrastructure, and extend the life of your existing investments. The benefit is that you can keep your spells intact and create an endpoint that exposes this data transformation without running MuleSoft. You only need the open source TriggerMesh.
MuleSoft utilizes their own scripting language called DataWeave. This language is a template engine that allows you to transform data to and from any kind of format. Users of MuleSoft who have made mappings in the graphical interface will have DataWeave scripts (called “spells”) that have been generated by these mappings. If you’ve already got these DataWeave spells, you can drop them into your TriggerMesh installation and immediately use them to transform your data.
Here’s an example of a DataWeave spell:
This DataWeave spell takes an XML payload, gets details of the “buyer” element in the “order” element, and puts those attributes into a JSON format. The script is expecting the input data to look something like this:
Now that we have an example DataWeave spell and the expected payload, we can drop the spell into a YAML file to be applied to a TriggerMesh installation. Here’s what that manifest would look like:
Of particular interest are the following fields
Right now, our sink is sockeye, which is a display for CloudEvents. Here’s how you can run that display:
Note the huge benefit: There is no MuleSoft involved. You just take your spells and put them in a YAML manifest. TriggerMesh fully open source takes over.
Once these manifests are applied to your TriggerMesh installation, we can send a test event. First, bring up the Sockeye display by going to the URL found from running:
Then, get the transformation URL:
Finally, we can send an XML document via curl to the transformation and see the resulting JSON in Sockeye:
MuleSoft customers who want to take their DataWeave scripts to a Cloud-Native environment can do so. The TriggerMesh `DataWeaveTransformation` API allows anyone to run data transformation in a Kubernetes cluster. That transformation is available over HTTP(s) by sending a CloudEvent to it, the transformed data is also emitted as a CloudEvent.