Achieving Real-Time Hybrid Automation: Cloud AI Agent to On-Prem Performer without Inbound Firewall Rules

Help Something Else
, , , ,
1

Infrastructure Overview

We are currently running a hybrid UiPath architecture:

Cloud: UiPath Automation Cloud is used for an AI-powered “Agent” that processes incoming emails and classifies data.
On-Premise: The core business systems are hosted in a highly secured internal network.
Security Constraints: Our CISO strictly prohibits any Inbound traffic (Cloud-to-On-Prem). No ports can be opened for external calls into our internal network, this is obvious but still I prefer to mention it.

The Problem: High Latency and Polling Inefficiency

Currently, we use a “Polling” method. An On-Premises Dispatcher/Performer robot checks a Cloud Queue every 15 minutes for new processed items.

  • Latency: This creates a significant delay in end-to-end processing.
  • Resource Usage: We are wasting Robot cycles (and potentially license “thinking time”) on repetitive checks rather than event-driven execution.

Proposed Solution: Event-Driven WebSockets (SignalR)

We are considering shifting to a persistent connection model to achieve near real-time processing:

  1. Robot Service Mode: Installing the UiPath Robot in Service Mode on an internal VM.
  2. Outbound Persistent Connection: The Robot Service initiates an Outbound connection to the UiPath Automation Cloud via Port 443.
  3. Secure WebSockets (SignalR): Utilizing the built-in SignalR/WebSocket capability to keep the communication channel open.
  4. Real-Time Push: When the Cloud Agent finishes a task, the Cloud Orchestrator should “push” the notification/transaction to the “listening” On-Premises Robot Service through the existing outbound tunnel.

Specific Questions for the Community

  1. Best Practice: Is this the recommended architectural pattern for “Real-Time Hybrid” processing when inbound traffic is forbidden?
  2. Licensing vs. Connection: If the Robot Service is connected via WebSockets but is in an “Idle” state (waiting for a push), does it consume an Unattended Runtime license continuously, or only the moment the Job is triggered?
  3. Stability: Are there known issues with long-lived SignalR connections in strict enterprise firewalls (e.g., session timeouts or heartbeat failures)?
  4. Alternative: Is there a better way to trigger an On-Premises robot immediately from the Cloud without using Polling or Inbound Webhooks?

Looking forward to your insights!