

As part of the TriggerMesh 1.24 release, we announced our new connectors for Solace PubSub+. TriggerMesh can now read and write to this highly versatile messaging platform.
In this post, we’ll demonstrate how you can use TriggerMesh to trigger an AWS Lambda function when an event lands on a Solace queue. The post focuses on running the event flow on a computer with Docker, but we’ll also show how you can easily transition to run this in a Kubernetes-native way, by leveraging TriggerMesh’s declarative Kubernetes CRDs, such as the one for the Solace source component.
The Solace source will subscribe to a Solace queue and forward events to the TriggerMesh broker. The TriggerMesh broker will route events to a Lamba target component, which invokes the AWS Lambda function by passing it the event from Solace.
An easy way to run Solace is to use their provided docker-compose file.
Open the Solace console at http://localhost:8080. The default user/password is admin/admin.
In the console, create a queue called source-queue.
In a terminal, make sure you have installed TriggerMesh’s CLI called tmctl, then create the 4 TriggerMesh objects that will let us route events from the source-queue to the target-queue.
It is crucial that you specify the eventTypes filter for the trigger as shown here. If you don’t, responses from the Lambda function back to the broker will get sent back to Lambda again, and so on, creating an event loop which could impact your AWS bill in a negative way.
Also, I’m not giving explicit names to these components here, so they’ll default to names like <brokername>-<component type>, for example solace-awslambdatarget. Be sure to adapt these commands if you chose a different broker name, or if you’ve customized the names of components.
I’m using host.docker.internal as the hostname here for the Solace source because tmctl is running on Docker Desktop on Mac. You can adjust this according to your environment.
Run tmctl describe to check that these 5 pieces are up and running.
Run tmctl watch in a separate terminal so that you can see events land in the broker.
Now send an event to the source-queue from the “Try me!” tab in the Solace console. Make sure you send a valid JSON payload like so:
Check that the event has made it to the TriggerMesh broker by viewing the CloudEvent logged by the watch command (note that the event type is io.triggermesh.solace.event):
Below that event, you might also notice an additional event: it’s the Lambda function’s response back to TriggerMesh. You can potentially use that response to trigger other actions, thereby allowing you to use the response returned by the lambda function. In my example, there is nothing interesting about the response, the Lambda returns Null.
Finally, let’s check that our Lambda function was successfully triggered. I’m looking at the Lambda’s logs in CloudWatchLogs here, in which we can see the Hello world! message encapsulated inside a CloudEvent:
First of all, you’ll need a Kubernetes cluster with TriggerMesh installed. You can find instructions on installing TriggerMesh on Kubernetes in the documentation. We’ve tested this on development clusters like Kind, Minikube, and Kubernetes for Docker Desktop.
Once your cluster is ready, you can export the event flow you just created with tmctl as a Kubernetes manifest that is ready to run:
Here is an example of the Solace source component that is produced by the dump command:
You should be able to apply this manifest to your cluster using kubectl apply -f manifest.yaml, with a few considerations first:
If you need help, you can easily reach the team on our public Slack. We love interacting with users and will answer any questions as best we can.
And for a more general onboarding into everything TriggerMesh, head over to our quickstart guide which will help you to get up and running in minutes on any computer that has Docker.
Thanks for reading and we hope to see you again soon!