The Java APIs and libraries discusses in this section are currently only available in STEP Enterprise Edition

High-level functionality

High-level functionality and means to connect to the controller programmatically are exposed in the class ControllerClient. The Javadoc of the remote client API is available at: and examples are available in

As a "headless" user (i.e assuming you're wanting to automate interactions with STEP, which are part your build pipeline, for instance) you will probably want to perform the following tasks programmatically:

  • upload and execute keywords
  • upload and execute plans
  • download existing plans
  • access execution metadata and execution results (report nodes)

That's what the class ControllerClient is intended for.

Main Controller Services

In addition to the class ControllerClient, other classes are made available. Each class interacts with a certain type of entity in STEP and allows either:

- basic CRUD operations on these entities

- the execution of these entities (for those which can be executed)

- querying, browsing or printing these entities

The class ControllerClient relies on them to perform the higher level tasks listed in the section "High-level functionality". Javadoc links will be added in this section in the near future.

Plan Repository

This service can be used to access and save plans remotely.

Artefact Repository

This service can be used to access and save artefacts remotely.

Remote Runner

This service can be used to run plans remotely.


This service can be used to access and print reports originating from a certain execution plans remotely.

Plugin Services


The EvenBroker Service and API allow asynchronous communication and synchronization between keywords, between plans and between keywords and plans. It is particularly useful in scenarios where a user needs to wait for specific events before performing the next task. These events can be created internally (from a keyword or plan) using various types of clients (REST, Java API, the PushEvent artefact, which will be published soon) or externally, by adding an additional layer in order to transform the signature of custom user notifications (i.e a business-specific event signature and endpoint) into a standard step event. The service also exposes methods for testing the present of an event, reading it's content, consuming it, etc. Finally, a standard enterprise artefact called "WaitForEvent" allows users to synchronize the execution of test plan blocks with the occurence of a user-defined type of event.

Code examples


// Event manipulation based on a unique id

Event sentEvent = new Event().setId("a_unique_id");


Event readEvent = client.consumeEvent("a_unique_id");


// Event manipulation based on a "family" of events (no unique id known, it will be generated by step)

Event sentEvent = new Event().setGroup("myGroup").setName("myEventName");


client.peekEventByGroupAndName("myGroup", "myEventName");

Event readEvent = client.consumeEventByGroupAndName("myGroup", "myEventName");


Assuming some event of group "myGroup" and of name "myEventName"is sent by a third party EventBrokerClient, the following plan will wait for the event to be received and then store the content of the event in the variable "result":

Screen Shot 2018-07-11 at 16.58.11.png

WaitForEvent configuration:

Screen Shot 2018-07-11 at 16.58.27.png

Set configuration:

Screen Shot 2018-07-11 at 16.58.32.png

Plan examples

Created by David Stephan on 2019/01/16 09:59
Copyright © exense GmbH