🚨 The EventBridge integration is in Early Access and we're working with a small number of design partners to productize it. We are aiming to be included in the AWS EventBridge SaaS partner directory in the near future. If you want in as a design partner, please get in touch with your customer success representative!
The EventBridge integration allows customers to receive notifications and requests from Control Room directly to AWS EventBridge event bus on their account.
Currently, the following types of events are supported:
- Self-hosted On-Demand Worker requests. This allows implementing the on-demand worker API without exposing a REST endpoint on the internet.
The integration is configured at Control Room organization level. Integration configured for an organization can be utilized in any workspace belonging to the organization. Initially, the integration is configured by the Robocorp team, without a self-service interface.
Enable the integration on AWS account as follows:
- Determine identifier of the Robocorp Control Room instance your organization is deployed on. If you don't know, get in touch with your customer success representative.
- Determine identifier of the Control Room organization for which the integration will be configured. The ID can be viewed in Control Room Organization Configuration on the Settings tab.
- Create an AWS EventBridge Event Bus on your AWS account.
- Add an Event Bus Policy that grants Control Room access to put events to your Event Bus. Note that the policy is specific
to the Control Room instance and your organization identifier.
us1 (North Virginia):
- Send the following information to your Robocorp Customer Success representative:
- ARN of the event bus receiving the events
- ID of the Control Room organization
- We'll be in touch with further instructions once the configuration is complete
Example of a commplete Event Bus Policy:
The events originating from Robocorp Control Room are designed according to the AWS EventBridge Event Structure reference. This section describes the general principles and guidelines for implementing the event consumers.
sourceis specific to the integration configuration and may contain e.g. unique identifiers. Content of the source field is expected to change once the integration is published as AWS EventBridge SaaS partner integration, and we encourage not building any rules that depend on the
sourcefield at this point in time.
resourcesarray identifies the Control Room Organization and Workspace involved in the event. Currently, the
resourcesarray always contain a single element of format
robocorp-control-room/organization-[organization_id]/workspace-[workspace_id]. For convenience, the organization and workspace identifiers are always included in the detail object as well; therefore it is not mandatory for the event consumers to parse content of the resources array.
detail-typespecifies the type of the event in question. The value of the
detail-typefield alone always identifies the semantics and the structure of the event. We specify the events per
detail-type, and we recommend basing any parsing and functional routing logic on the
detail-type field implicitly includes version of the message format. Once a message has been published,
breaking changes to the format will not be introduced. However, additional fields may be introduced to existing messages
and therefore the client implementaton must tolerate additional fields.
This section describes the individual event types supported by this integration.
Control Room uses this event to request a compute resource to be started for execution of a step run.
detail-type is set to value
On-Demand Worker Request.
detail object contains the following fields:
metadataobject contains non-sensitive metadata of the request and has the following properties:
organization_ididentifies the Control Room organization
workspace_ididentifies the Control Room workspace
process_ididentifies the Control Room process
step_ididentifies the step inside the process
on_demand_worker_ididentifies the On-Demand worker configuration in Control Room
step_run_ididentifies the step run the worker is created for
process_run_ididentifies the process run which the step run belongs to
process_run_numbernumber of the process run in question
worker_idis an unique identifier for the worker to be started
max_execution_secondsspecifies the maximum duration of the task execution. This value is dictated by the timeout specified for the step in question. The client can utilize this value with a safeguard timer that ensures all tasks get eventually terminated.
encryption_schemedefines mechanism used to encrypt the subsequent payload. Encryption scheme can have the following values:
AWS-ENCRYPTION-SDK: AWS Encryption SDK See HERE (TBD) for an example implementation of the decryption.
encrypted_payloadcontains base64-encoded encrypted data block of the sensitive payload. Once decrypted, the payload contains the following properties:
worker_link_tokenis one-time-use token used to link the worker for allocation of the workload. The receiving implementation must pass the token to Robocorp Worker running in the compute to be launched.
- 🚨 [DEVELOPMENT MODE ONLY]
payload(if present) contains a plaintext version of the payload. This allows testing and building the infrastructure without having to implement the decryption.
Full payload example: