Imagine this: Your Automation Anywhere Control Room (CR) runs in the cloud, but your critical systems like SAP, internal databases, legacy on-prem CRMs -- are locked behind your firewall. How can you seamlessly connect your cloud automation to these on-premise assets?  In this article, we’ll explore how you can use API Tasks to securely integrate on-premise systems in a hybrid environment.  

The integration challenge 

Many organizations today have a hybrid IT landscape: cloud-based automation platforms like Automation Anywhere working alongside on-prem systems & data centers. Integrating these can be challenging. On-prem systems often sit behind corporate firewalls & are not accessible directly from the public internet. Control Room administrators worry about security, network latency and compliance when sending data between cloud and on-prem environments. Automation developers may have resorted to running bots on-prem just to bridge this gap.  
E.g, installing a bot agent inside the network to interact with SAP via its GUI, since direct cloud access was not available. 

These challenges boil down to a few key points: 

• Network Connectivity: Cloud services must communicate with on-prem servers through firewalls. By default, an Automation Anywhere API Task running in the cloud (Automation Cloud Service) won’t reach a private endpoint unless you explicitly open a path. 

• Security & Access Control: Exposing an internal API or database to a cloud automation requires careful security measures – you’ll need to allow only authorized traffic and protect credentials. 

• Latency & Reliability: Traditional approaches (like scheduling a bot on a local runner via the Control Room) might introduce latency. If a process needs real-time data from on-prem, waiting for a bot runner to spin up or a scheduled interval can be too slow. On the other hand, directly opening connections through firewalls can raise reliability questions. 

• Maintenance Overhead: Keeping a pool of on-prem bot runners purely for integration tasks means managing infrastructure (servers or VMs) and software updates, which is costly and time-consuming. 

In short, integrating cloud automations with on-premise assets has historically required a trade-off between security and agility. Automation Cloud Service is a great way to bridge this gap. 

How Automation Cloud Service bridges the gap securely and efficiently 

Automation Cloud Service provides a solution by allowing cloud automations to call into on-prem systems via APIs in a secure, controlled manner. They essentially let your cloud CR reach behind the firewall without you having to host full bot runners on-prem or write custom middleware. Here’s how they achieve this: 

• Cloud-managed but Connectivity-aware: While Automation Cloud Service API Tasks run in Automation Anywhere’s cloud, you can configure secure network access to your on-prem endpoints. Automation Anywhere provides a list of outbound IP addresses for Automation Cloud Service traffic. So, as a CR admin, you simply whitelist those IPs on your firewall or API gateway. This means only calls coming from your trusted Automation Anywhere cloud instance can hit the internal system while keeping unwanted traffic out. 

• Use of HTTPS and modern APIs: API Tasks typically invoke enterprise web services and Large Language Models. By using HTTPS endpoints with proper authentication, data is encrypted in transit & access is gated. Essentially, you are extending your on-prem API surface to the cloud automation in a zero-trust fashion. 

• No on-premises infrastructure required: Because the logic runs on the Automation Anywhere cloud, you eliminate the need to maintain on-prem automation servers for these tasks. This means if you suddenly need to handle a spike of requests, the Automation Anywhere Cloud can spin up more API Task capacity (within your concurrency limits) to handle it. This is far quicker than provisioning more VMs locally. 

• Real-time, Event-driven execution: API Tasks can be triggered in flexible ways. E.g. via a CR API call, as part of a larger process, or from an Automation Anywhere form, or an event trigger or simply as an endpoint. This flexibility lets you design event-driven integrations.  

• Scalable and Concurrent: Efficiency also comes from the ability to run tasks in parallel. Traditional bots might be limited by the number of machines available. API Tasks, on the other hand, can run concurrently up to a certain limit (& more if you scale your license).  

• Maintaining data compliance: API Tasks do not arbitrarily pull your on-prem data into the cloud CR storage. The data fetched is used within the automation & can be passed along or logged as needed, but you remain in control of what gets exposed.  

Real-world use cases: Connecting Automation Cloud Service to on-premise systems

I’m sharing a few use cases where Automation Cloud Service enable cloud-to-on-premise integration. The key pattern is: if your on-prem system offers any sort of API or can be accessed via a network call, an API Task can likely integrate with it. From mainframes (wrapped with REST gateways) to custom in-house apps, you can automate interactions without resorting to screen automation or manual work. It’s faster, more reliable and far easier to scale out when demand increases (e.g, multiple API Tasks can run in parallel to handle high load, whereas multiple UI bots could trip over each other or require multiple machines). 

• 1. SAP Integration: SAP systems often contain critical data which is locked on-prem. Traditionally, bots interacted with SAP through the GUI or intermediate files. With Automation Cloud Service, you can use SAP’s published APIs from https://api.sap.com/ such as OData services or BAPIs via REST/SOAP to interact directly. Example: An API Task could retrieve the latest inventory counts from an on-prem SAP ERP by calling a REST endpoint exposed by SAP’s NetWeaver Gateway. It gets the JSON/XML response and can immediately take action e.g, trigger a restock process. This happens within seconds, without spawning a desktop session. By using SAP’s secure API & whitelisting Automation Anywhere’s IPs on the SAP gateway, the integration remains secure.  

• 2. Legacy database queries: Legacy databases (Oracle, SQL Server, etc.) often remain on-prem, yet business processes require their data. With Automation Cloud Service, you have a couple of options: 

  • We have provided guidance for connecting an API Task to a private database by using a public-facing load balancer as a proxy. Your API Task can then use the Database package actions to run a query on that database over the secure channel. See Configure API Task for Private Database Access 

  • If exposing the DB port isn’t preferred, you can create a small internal API (or use an existing one) that the API Task calls. For example, an internal web service /getOverdueInvoices could query the database & return results. The API Task calls this service & gets back the data in JSON, which it then parses and uses in subsequent steps … maybe to create summary reports. 

Best practices: Securely configuring on-prem Automation Cloud Service connections 

Here are some best practices to ensure everything runs smoothly and securely: 

• 1. Whitelist Automation Anywhere Cloud IPs: As mentioned earlier, obtain the official list of Automation Anywhere API Task outbound IP addresses from here and whitelist them on your firewall or API gateway. This restricts inbound access to your internal APIs so that only Automation Cloud Service can call them. Further, Automation Cloud Service uses a multi-tenant SaaS model, where each customer (tenant) has logically isolated data and workloads. This means Tenant A cannot call or even discover Tenant B’s API Tasks. 

• 2. Use HTTPS and Authentication: Always expose your on-prem APIs over HTTPS (TLS encryption) to protect data in transit. Configure authentication for the API so the API Task must present valid credentials. In Automation Anywhere, you can store credentials in the Credential Vault & retrieve them securely at runtime.  

• 3. Leverage a DMZ or Proxy: Directly punching a hole through the firewall is not recommended. You should consider setting up an intermediary. The example of using a Network Load Balancer (NLB) in a public subnet is a great pattern. The NLB only allows specific paths/ports and can enforce its own access rules. Your actual on-prem server (database, application, etc.) stays in a private network, accepting connections only from that proxy. Essentially, the proxy/NLB acts as a controlled gatekeeper. 

• 4. Educate & involve IT Security: Bringing your IT/security team on board early will pay dividends. They can help set up a secure architecture (for example, guiding where to place a proxy or how to best expose an API). They will also be more comfortable knowing that proper controls (like IP whitelists, encryption & monitoring) are in place.

Embrace Automation Cloud Service to supercharge your cloud on-premise automations

Adopting Automation Cloud Service for on-prem integration can be a game-changer for automation developers and admins alike. It simplifies architectures, speeds up processes and often delights the IT folks (because it uses modern integration principles instead of brittle screen hacks). We’ve seen how Automation Cloud Service provides a secure, efficient bridge between cloud and on-prem, and looked at concrete ways to use them from databases to systems of record and beyond. 

As you plan your next automation, ask yourself: “Does this system have an API we can call?” If yes, consider building an API Task for it. You might find you can deliver the solution faster and run it more reliably than ever before. And with Automation Anywhere’s continued investment in cloud-native features, the capabilities and performance will only get better.  

So go ahead and bridge that gap. Let your API Tasks talk to your on-prem systems in their language (APIs) & watch your hybrid automation take off. With the right approach & the tips we discussed, you’ll drive greater adoption of Automation Cloud Service in your organization and unlock new levels of efficiency. 

Reference links 
- https://docs.automationanywhere.com/bundle/enterprise-v2019/page/at-private-db-access.html 
- https://docs.automationanywhere.com/bundle/enterprise-v2019/page/apitask-ip-addresses.html 

Vineet Pujari 
Product Manager 
Automation Anywhere