Introducing SEMP v2 – Solace Message Routers configuration reinvented!

Solace has always had a programmatic interface for managing Solace message routers, called the Solace Element Management Protocol or “SEMP.”

Among the many exciting developments we’re announcing today is the reinvention of SEMP as a REST API that will simplify the creation of self-serve portals, enable the integration of messaging into CI/CD pipelines, and be more natural in cloud deployments. I’ll try to give you a better understanding of this new version (which we call SEMP v2) and how it will be used.

What is SEMP v2?

SEMP v2 is a modern REST API for managing Solace message routers. It is an entirely new object-oriented management interface to replace what we will now call the Legacy SEMP interface or SEMP v1. The following diagram tries to put it in context of the other Solace message router interfaces.

At a high level, for SEMP v2, the following paradigms apply:

It takes an object based approach to resources. For example, a queue is a single object.

Access to resources is via specific URLs. For example, a client username looks like
/SEMP/v2/config/msgVpns/default/clientUsernames/bob

HTTP methods indicate actions to take on resources. For example, POST to create, GET to retrieve, DELETE to remove.

It uses structured JSON Payloads for contents

It is described by a specification called OpenAPI (Formerly Swagger) that lets you automatically generate client libraries in many languages including C#, Java, Node, Objective-C, Python, Ruby, Scala and Swift.

Why SEMP v2?

When we set out to rejuvenate our SEMP management API, a modern REST API was a natural choice. But we also wanted to make sure that SEMP v2 was better in many ways. So our goals for SEMP v2 were:

• Reduce the amount of code you need to write.
• Simplify your applications through atomic “all or none” operations.
• Provide rich online documentation.
• Let developers code in any language using generated client libraries.
• Enable easy integration with popular DevOps and CI/CD tools like Ansible, Puppet, and others.

Above all, we wanted to make SEMP easier to use. Two key ways we did so are new API reference documentation and by simplifying your code. Let’s look a bit deeper at both of these.

Developer Friendly API Reference

Here’s an example of the developer documentation you’ll now be able to see. For each SEMP resource, there is an explanation of the operation, the resource JSON structure for the request and response and notes about various object attributes and any special characteristics. It’s a clear one stop shop for understanding the API resources.

Simpler Code

You’ll soon be able to check out developer samples in GitHub, SEMP v2 requires a lot less code to complete a given task than SEMP v1. Here’s an example of creating a queue with the following characteristics:

• Non-Exclusive access
• Delete Permissions
• Enable TTL handling
• Allow up to 5 consumers
• Provide 5 GB of message spool
• Enabled the queue for messaging

You initialize the SEMP client library, set up the MsgVpnQueue object and call the SEMP API a single time to create the queue on the Solace Message Router. Those of you who’ve used SEMP v1 to do the same thing can attest to how much faster and easier that is!

Rollout Plan

The API is being released iteratively with an initial focus on enabling Message-VPN configuration. SEMP v2 will be available first on the Solace Message Router Appliances this month and in the Virtual Message Router just after Christmas.

With each release, more commands and more functionality will be added. For commands and operations not yet supported, you can still use the legacy SEMP API.

Documentation will include information such as:

• SEMP Getting Started Tutorials – Easy walk through tutorials to introduce you to using SEMP directly through HTTP or through the generated client library.
• SEMP Concepts Guide – Documentation explaining the SEMP API and how it is used
• SEMP API Reference – Developer reference documentation for each resource in the SEMP API