SEMP API Versions

This section provides an overview of the latest versions of the SEMP API, its supported and unsupported features, and the approach taken to ensure version compatibility as new features are introduced.

Current Version

The current version of the SEMP API is v2. This SEMP version does not yet support all event broker commands—currently, this version supports most Message VPN-scoped configuration commands. For commands that are not yet supported in SEMP v2, you can continue to use the Legacy SEMP API.

For information on how and when changes to the SEMP API version may occur, see Future Releases and Compatibility, below.

When SEMP v2 and Legacy SEMP/CLI are used to request concurrent changes to the same object, the Legacy SEMP/CLI change might be applied between the individual changes associated with the SEMP v2 request. The end state of the object might then be a mix of both the Legacy SEMP/CLI and SEMP v2 requested changes, or the SEMP v2 request might fail and return an error. If possible, we recommend that you avoid using both Legacy SEMP/CLI and SEMP v2 to make concurrent changes to the same object.

SEMP v2 to SolOS Version Mapping

The following table lists the of SolOS and the corresponding versions of SEMP v2.

SolOS Version SEMP Version
10.10.1 2.44
10.10.0 2.43
10.9.1 2.42
10.8.1 2.41
10.8.0 2.40
10.7.1 2.40
10.7.0 2.39
10.6.1 2.39
10.6.0 2.38
10.5.1 2.38
10.5.0 2.37
10.4.1 2.36
10.4.0 2.35
10.3.1 2.34
10.3.0 2.33
10.2.1 2.32
10.2.0 2.31
10.1.1 2.30
10.1.0 2.29
10.0.1 2.28
10.0.0 2.27
9.13.1 2.26
9.13.0 2.26
9.12.1 2.25
9.12.0 2.24

Future Releases and Compatibility

The SEMP v2 API is being released iteratively. With each release, more commands and functionality are added. Refer to the specification files to see what is currently supported. To obtain the specification, see SEMP API Reference.

For commands and operations not yet supported in SEMP v2, use the legacy SEMP API.

In order to ensure that the SEMP API provides a stable API for clients, the following policies will be followed when introducing new features and functionality. New features and functionality will be delivered as part of new event broker loads.

This means that client libraries generated with an older SEMP specifications will continue to work with newer event broker loads. However, a client library generated from a new schema may contain changes to interfaces to support new features. So it is not true that client libraries generated with newer SEMP specifications will maintain the same compile time method signatures.

Compatible Changes

The following changes are considered backwards-compatible and do not require a major SEMP version change to introduce:

  • Adding a new resource.
  • Add a new attribute to a resource.
  • Relocating or renaming an existing resource. The old URI will be marked as deprecated but will remain valid until the next major version of SEMP.
  • Relocating or renaming an existing attribute. The old attribute name will be marked as deprecated but both the old and new attribute will be valid until the next major version of SEMP.
  • Changing a return error code. Error code values and their meanings will never be changed. However, over time Solace may introduce new error codes that will be returned for a given method/URI combination. On a best-effort basis, for the same conditions, Solace will strive to return the same error code. When conditions change (for example, due to new features being added) newer error codes may be returned. Therefore client applications should be written to act sensibly when they receive error codes they do not understand.
  • Adding, changing, or removing enumerated values for non-identifying attributes in the Monitoring API.

Incompatible Changes

The following changes are not backwards-compatible. To make these changes, a new major version of SEMP will be released.

  • Removing an existing URI.
  • Removing an existing attribute.
  • Removing an existing query parameter.
  • Changing a default attribute value. SEMP exposes users to the default value of an attribute through POST and PUT. Given such, a change to a default value is not a backwards-compatible change, in that a user, if relying on the old default, will experience different behavior.
  • Adding a restricting attribute property (that is, making an existing attribute one of "required", "read-only", "write-only", or "requires-disable") is in general a non-backwards compatible change.

Emergency Changes

Emergency changes may not be compatible changes, but they are required due to security vulnerabilities or a violation of the specification.