Deployment Architecture
This slide shows a typical Jiffy deployment. The core automation engine, JDI, JDU Studio, Security vault, JAM on typically installed on a single Linux server. The production server is typically a Linux RHEL 7 server with a minimum of 8 cores and 32 GB RAM. The business users access the security vault and JDI through the browser. While the bot designers access the core automation engine and JDI studio through the browser. The bot service runs on every bot machine designed to run the bots.
The JAM module also runs on the primary server and is accessed by the system administrators through the browser.
The cognitive modules are generally setup on a separate server. The cognitive module, Docube has further subcomponents including the in-memory engine, the
visualisation engine, the machine learning libraries and runs apache spark in the background. These servers are heavy servers with at least 16 cores and 64GB ram.
The bot services are installed on bot machines. The bot machines could be physical desktops, Virtual desktops or could windows servers. Each bot machine could run multiple bots but typically we recommend one single bot running on a VDI or Desktop as certain automations that require screen buffer can have conflicts when you run multiple automations in parallel on the same windows login.
On the windows server, you can spawn multiple bots on the same server and run automations in parallel. Each of the bot should ideally be invoked under a separate windows user login.
During the task design, the designer on his desktop accesses the designer workspace connecting to the Jiffy core and designs the tasks. During the task design, he may require to record the UI Elements on the application to be automated. For this he may use the Ui Learn module, which is generally installed on the designer desktops. The familiarised/recorded UI element controls are stored in the Jiffy repository part of the Jiffy core. Please note all the information is finally physically stored on the Jiffy Database. No details or information is stored in the bot machine or on the designer machines.
During Task execution, the tasks designed by the bot designer is assigned to a bot cluster and not to a bot. You can define bot clusters within the core engine. Each block of steps inside a task could be picked by any of the bots in the bot cluster. This enables huge scalability and robustness in case of bot failures.
The Jiffy database is most critical unit where all the information, the bot execution results, bot tasks/scripts, repository of UI elements, reusable components are all maintained. Typically, the JDI data, JDI Metadata from JDI Studio and core Jiffy components are stored in different schemas within the same server.
Windows Server Based Deployment Architecture
In the deployment diagram above the bots are all installed on a single windows server. This enables us to scale bot up and down on a need basis without additional infrastructure cost. Also, the applications patches are very well controlled when the automations are on the windows servers. Any tasks which downloads large amount data also gets significant benefits as the bots are running on the same data centre as the applications under automation.
VDI Server Based Deployment Architecture
This is another sample deployment model. Here the bots are deployed in VDI. This simulates an employee as-is. Typically challenges of getting the client applications installed on the server is mitigated with this approach.
Scalability
Both, the core servers and cognitive servers can be scaled horizontally as well a vertically. For example, a typical server configuration of 8 core 32GB is good enough to run at least 20 bots. The infrastructure could be scaled to 8 Core 64 GB for a 50 bot implementation or the same load could be manged with 2 servers of 8 core 32 GB each. The later will enable failover and load balancing as well.
The same applies to the cognitive server, which are typically deployed in clusters to balance load and data back.
The bot machines are generally horizontally scaled unless you are using a windows server as bot machine. In case of VDI’s another desktop is added to the cluster, the load is automatically balanced.