Remote Services
Remote Services in Orkes Conductor provide a centralized interface for defining, testing, and managing HTTP and gRPC service endpoints. Without additional configuration, these services can be reused across multiple workflows using built-in system tasks like HTTP, HTTP Poll, and gRPC.
Here is an overview of how to use the service registry in Conductor workflows:
- Define a remote service
- Discover or add endpoints
- Configure circuit breaker pattern
- Test endpoints
- Add services to workflows
Define a service
A service can be registered for use in HTTP, HTTP Poll, and gRPC tasks. The configuration steps differ based on the task type.
- HTTP services
- gRPC services
To define a service:
- Go to Definitions > Remote Services from the left navigation menu on your Conductor cluster.
- Select + New service.
- In Service registry name, enter a unique name for the service.
- Set Service type to HTTP.
- Enter the Swagger specification URL (ending in .json) in the Swagger URL. For example: https://petstore.swagger.io/v2/swagger.json.
- Select Save.
To define a service:
- Go to Definitions > Remote Services from the left navigation menu on your Conductor cluster.
- Select + New service.
- In Service registry name, enter a unique name for the service.
- Set Service type to gRPC.
- In Host, enter the service's host URL.
- In Port, specify the port where the service is running.
- Select Save.
Discover or add endpoints
After defining a service, you can either automatically discover its endpoints or add them manually.
a. Discover endpoints
- HTTP services
- gRPC services
To automatically fetch the endpoints within the services:
- Open your service definition.
- Select Discover methods to fetch all endpoints automatically.
Once fetched, the corresponding schemas are automatically registered under Schemas in Conductor.
Depending on the gRPC configuration, you can:
- Discover endpoints automatically (if reflection is enabled in the gRPC server).
- Upload compiled proto descriptors (if reflection is disabled in the gRPC server).
To automatically discover the endpoints within reflection-enabled gRPC services:
- Open your service definition.
- Select Discover methods to fetch all endpoints automatically.
To generate the compiled binary protobuf files for reflection-disabled services:
- Install protoc if not already installed.
- Generate the compiled binary protobuf files using the
protoc
utility:
protoc --proto_path=. --descriptor_set_out=compiled.bin *.proto
- Open your service registry definition in Conductor, and go to Proto Files.
- Select + Upload Proto File, and upload the compiled.bin file.
Once uploaded, Conductor extracts and registers the services, making them ready for use in workflows.
b. Add endpoints
- HTTP services
- gRPC services
To add a new endpoint to the HTTP services:
- From your service definition, select + Add New Method.
- Enter the following endpoint parameters:
Parameter | Description |
---|---|
Resource Name | The action or purpose of the endpoint. |
Path | The method name for the endpoint. |
Method Type | The method type for the service. Supported values:
|
Input Schema | Select from existing input schemas in Conductor. |
Output Schema | Select from existing output schemas in Conductor. |
- Select Add.
To add a new endpoint to the gRPC services:
- From your service definition, select + Add New Method.
- Enter the following endpoint parameters:
Parameter | Description |
---|---|
Resource Name | The action or purpose of the endpoint. |
Path | The method name for the endpoint. |
Method Type | The method type for the service. Supported values:
|
Input Type | Select from existing input schemas in Conductor. |
Output Type | Select from existing output schemas in Conductor. |
- Select Add.
This saves the endpoint within the service definition.
Configure circuit breaker pattern for individual services
Circuit breaker patterns help prevent cascading failures by halting calls to unhealthy services, thus protecting the workflows.
The Circuit Breaker pattern has two circuit states:
- Closed - Normal operation state where all requests pass through normally.
- Open - Failure state where the requests fail fast, thus protecting the service.
To configure the circuit breaker pattern for a service:
- Go to the Circuit Breaker Configuration tab in your remote service definition.
- Toggle on Circuit Breaker Configuration.
- Configure the following parameters:
Parameter | Description | Types |
---|---|---|
Failure rate threshold | The failure rate threshold is a percentage between 0 and 100; when the failure rate equals or exceeds this value, the circuit breaker opens to block further calls. Default is 50. For example, setting the threshold to 50% means the circuit will open when half of the calls fail. Set it to 0 to disable this behavior. | Float. |
Sliding window size | The size of the sliding window, which is used to record the outcome of calls when the circuit breaker is closed. The value ranges between 1 and 1000. Default is 100. | Integer. |
Minimum number of calls | The minimum number of calls required within a sliding window before the circuit breaker evaluates the error rate or slow call rate. The minimum value is 1, and the maximum value should not exceed the Sliding window size. Default is 100. For example, if this value is 10, then at least 10 calls must be recorded before the failure rate can be calculated. If only 9 calls have been recorded, the Circuit Breaker will not transition to open even if all 9 calls have failed. | Integer. |
Wait duration in open state | The time in ms that the circuit breaker must wait before transitioning from open to half-open. The value ranges between 1000-300000. Default is 1000. | Integer. |
Permitted number of calls in half open state | The number of calls allowed while the Circuit Breaker is in the half-open state. The value ranges between 1 and 100. Default is 100. | Integer. |
Slow call rate threshold | The percentage threshold for calls classified as slow. A call is considered slow if its duration exceeds the Slow call duration threshold. If the percentage of slow calls within the sliding window equals or exceeds this threshold, the Circuit Breaker transitions to the open state and begins short-circuiting calls. The value ranges between 0 and 100. Set to 0 to disable slow-call triggering. Default is 50. | Float/Decimal. |
Slow call duration threshold | The duration threshold (in ms) above which calls are considered slow. Calls exceeding this time increase the slow call rate. The value ranges between 1000-60000. Default is 100. | Integer. |
Max wait duration in half open state | The maximum wait duration (in ms) the circuit breaker can remain in the half-open state before transitioning back to the open state. A value of 0 means the circuit breaker will remain half-open indefinitely until all permitted calls are completed. The value can range between 1 and 300000. Default is 1. | Integer. |
Automatic transition from open to half open enabled | If set to true, the circuit breaker automatically transitions from the open state to the half-open state, and no call is required to trigger the transition. If set to false, the transition to half-open occurs only when a call is made. | N/A |
- Select Save.
Test endpoints
Once the endpoints are fetched or added, you can test them before adding them to your workflows.
To test registered endpoints:
- From your service registry definition page, select the test (▶) icon next to the endpoint.
- Make the required configuration changes, and select Execute.
The test returns the server response and generates a link to a sample workflow execution.
Add services to workflows
Once the services are registered, you can add them to HTTP, HTTP Poll, and gRPC tasks in your workflows.
To add a service to workflows:
- For HTTP/HTTP Poll tasks
- For gRPC taskss
- Go to Definitions > Workflows.
- Create a new workflow or select an existing one.
- Add an HTTP/HTTP Poll task.
- Select Populate from remote services.
- In Service, select the registered service.
- In Service method, select the required endpoint.
- Select Populate.
This auto-populates the HTTP task parameters in the workflow.
- For HTTP Poll tasks, configure the additional parameters such as Termination condition, Polling interval, and Polling strategy.
- (For HTTP task) In the Hedging config, set the Maximum attempts, which specifies the number of parallel requests the system should make when executing the task. The system returns the response from the first successful attempt, which helps reduce tail latencies for remote services. Hedging sends multiple parallel requests; hence, use this feature only with idempotent services to prevent unintended side effects from duplicate executions.
- Select Save > Confirm.
- Go to Definitions > Workflows.
- Create a new workflow or select an existing one.
- Add a gRPC task.
- Select Populate from remote services.
- In Service, select the registered service.
- In Service method, select the required endpoint.
- Select Populate.
This auto-populates the gRPC task parameters in the workflow.
- Enable/disable the fields Use SSL and Trust Certificate as per the requirement.
- In the Hedging config, set the Maximum attempts, which specifies the number of parallel requests the system should make when executing the task. The system returns the response from the first successful attempt, which helps reduce tail latencies for remote services. Hedging sends multiple parallel requests; hence, use this feature only with idempotent services to prevent unintended side effects from duplicate executions.
- Select Save > Confirm.