Services and Service Versions

Sentinet supports and enforces versioning; each service or API registered in the Sentinet Repository is automatically assigned a sequential version number maintained by the Sentinet infrastructure. Versioning enables API solutions with the agility to adapt to continuous change, while maintaining solutions in a consistent state. For example, a service can be transitioned to a new version while an older version (for example promoted to Obsolete state) is still deployed and is actively hosted. Sentinet can ensure legacy consumer applications to continue using older service versions, providing these with enough time to adapt to a new service version, while new consumers are targeting only the new service version. Using Sentinet monitoring features, administrators can identify when there are no more active legacy consumers and then decommission (retire) the older service version by promoting it from Obsolete to Retired state.

Sentinet allows for very flexible interpretations of service version definitions. It can be a service version with a new implementation and no contract-breaking changes, a new service version with contract-breaking changes, or a completely new service treated as a new version of an existing service. Sentinet manages logical relationships between a service and its versions and helps maintain this relationship at runtime.

A service registered in the Sentinet Repository serves as a "container" for its service versions. A service container may contain any number of service versions or no service versions at all (empty container), but a service version is always part of its unique service container.

Figure. Example. CustomerSearch service contains 4 service versions.

A service container has a single friendly name that shows as the name of the Repository tree item (for example the highlighted tree item on the Figure above shows the friendly name, CustomerSearch). Each service version also has its own service version friendly name. By default, friendly names are the same for the service container and its service versions, and this default friendly name typically matches the service or API name specified in the service metadata (WSDL or Swagger). The friendly name can be individually changed during service metadata import, or when modifying the service or the service version properties. The service friendly name must be unique within a given Repository Folder to avoid ambiguity when searching Repository for services or when building analytical reports. The service friendly name must be provided for the services and APIs that are registered manually (as opposed to services and APIs registered from existing Swagger or WSDL documents).

Figure. Service friendly name shown in the Sentinet Administrative Console.

Figure. Service version friendly name shown in the Sentinet Administrative Console for the Version 1 of the Customer Search service.

Each service version also has a dedicated and optional Version field. If this field is not populated, Sentinet shows by default internal sequential version number in the Repository tree in the format Version {N}, otherwise it shows Version {version}, for example Version 1.3.

Figure. Service version with populated Version field.

Sentinet can also show service version taken from the service version friendly name.

Figure. Service version friendly Name, which is used to show version in the Repository tree.

Which format to use for service version display in the Repository tree is controlled by the User Preferences settings. It can be formatted by using:

1. Sentinet internal sequential version number.
2. Service version friendly name.
3. Service version’s optional Version field (recommended).

Note

Sentinet Developer Portal will always show Service version friendly name for API name, and Version field for API version if it was populated in the Sentinet Administrative Console, otherwise internal sequential service version number.