SV Server REST Management API

The SV Server REST Management API enables you to write applications to perform all SV Server functionality (interact/control) without using the Service Virtualization user interface.

Overview

There are currently two versions of the SV Server REST Management API available: API version 1 is intended for internal use only; API version 2 can be utilized by anyone.

The OpenAPI documentation of the APIs is available from https://host:6085/api/swagger.

Note:  

  • While limited OpenAPI documentation is provided for SV Server REST Management API v1, this version is not meant for public use. Incorrect usage of SV Server REST Management API v1 can result in unexpected problems, and no support will be provided for problems caused as a result of using it.

  • Most API actions require you to authenticate to the SV Server via HTTP Basic authentication.

Back to top

Using the SV Server REST Management API

SV Server REST Management API version 2 is organized into the following groups of operations: Agents, Services, and Download.

Agents

You can list basic details about the agents deployed on the server which you have permissions to view or use. You can enable or disable an agent, delete it, change its name, or export the agent XML configuration.

Note: You can import an exported agent to a different Service Virtualization environment upon saving the obtained XML configuration as a file, compressing it using Zip, and changing the file extension to *.agce.

Services

Managing Services (operations starting with “/v2/services”):

  • You can list basic details about all services deployed on the server. For an individual service, you can retrieve additional details including the endpoints and agents used, the Protocol, Data Models, and Performance Models.

  • You can also change the virtual service Runtime mode using the PUT /v2/services/{virtualServiceId} operation. The available Runtime modes are Offline, Recording, Simulating, and PassThrough. When switching Runtime mode, you usually have to specify a Data Model and a Performance Model ID (make sure to specify both whenever necessary). You can also turn Message Logging on or off, as well as the Simulation Report. Transitioning a service to a new Runtime mode may involve short service downtime and it may not be instant. Before starting to use the service, we recommend querying the service state using other API methods until it reaches the Deployment State of Ready.

  • You can undeploy and remove a service from the server altogether using the DELETE operation. This differs from switching the service to Offline mode where the service definition remains in the database and is not run, but can be transitioned to active mode again.

  • You can export services into *.vproja files using the /v2/services/{virtualServiceId}/export operation. The operation does not return the file itself as a result, but rather a File ID. It can take some time to generate the file. Use operations starting with “/v2/download” to check progress or download the resulting *.vproja file.

Deploying Services (mostly operations starting with “/v2/deployer”):

You can deploy services from a *.vproja archive file, which you can obtain by exporting project files to an archive file in SV Designer, or you can export deployed services from SVM, or using the methods of this public API.

To deploy services you need to create a Deployer. The Deployer unpacks the *.vproja archive file, and enables you to make changes to it such as specifying a different agent mapping. When the project is ready to be deployed, you can initiate the deployment.

To deploy services:

  1. Upload the *.vproja file using the “/v2/uploadProject” operation. This gets you the Deployer ID.

  2. Call the GET “/v2/deployer/{id}” operation repeatedly to check whether the project was correctly extracted and prepared in the memory.

  3. When the project is ready, call the “/v2/deployer/{deployerId}/startDeployment” operation to start deployment. Optionally, narrow down the list of deployed services, or specify the agent mapping when it can’t be inferred automatically.

  4. Call the GET “/v2/deployer/{deployerId}/deploymentResult” operation repeatedly to check whether the services were successfully deployed.

  5. Change the Runtime mode of the deployed services as required, and start using the services.

Download

Operations that start with “/v2/download” facilitate the download of files that are not ready immediately. Certain operations such as “/v2/services/{virtualServiceId}/export” retrieve the File ID, instead of the file itself.

To download the file:

  1. Make sure the file is available for download by calling the “/v2/download/{fileId}/info” operation.

  2. Download the file using the “/v2/download/{fileId}/result” operation.

For additional details, see https://host:6085/api/swagger.

Back to top