When it comes to Installing Blue Prism and configuring its various options, there isn’t any dearth of material in our portal. This blog post however focuses on a slightly different area, setting up an Azure environment for Blue Prism.
While I introduce this topic, I would want you to remember that this article is not a best practice guide, or a way to go about Azure for an enterprise. This is for those developers who have heard of cloud but haven’t really attempted a hands-on experiment on cloud, and for those who wants a basic setup for a POC, Pilot…etc or may be to learn more about Azure. Please do explore the Blue Prism trial edition that comes as a single package to learn more about Blue Prism; but read further in this blog to learn more about Azure from the context of Blue Prism and the most minimum components needed for an average Blue Prism implementation in an Enterprise mode.
Let’s begin by looking at the high-level steps,
Foundation: This is where we setup the basic groundwork needed for proper communication between all Blue Prism components. We configure Virtual Networks, Subnets and the minimum ports needed to be opened for a proper communication
Ring Fencing: Here we configure the security features in Azure that helps us protect the implementation.
Heart of Blue Prism: The database is at the core of all Blue Prism implementation, it holds, secures and manages all data. We explore Azure SQL as an option for the Blue Prism Database.
Building Blocks: These are the machines where Blue Prism components operate. We see the various configurations / templates available for this purpose.
Install and Configure: We don’t really talk about this. There are enough and more documents that help with the installation.
What we plan to achieve through this blog is the following architecture.
Before we begin, I think its important to refresh our memories on the basics of the Azure portal. You can access the portal @ http://portal.azure.com
For the first timers, you will need to register and account on the portal, create a subscription and only then move forward.
Everything big starts small.
The very first step is to create a virtual network in Azure.
A virtual network is a channel for communication between virtual machines or other components enclosed within it. You can further segment categories of resources within a virtual network using a component called subnets.
Once you are in the portal and have a subscription created, click on “Create a Resource” and search for Virtual Networks.
While we create a network, special attention has to be given to the address space used. Factors such as whether the VNet is integrated to an organisations own network, if vpn will be used, other VNets in the portfolio all have direct impact on the address space.
Read more about VNets here: https://docs.microsoft.com/en-us/azure/virtual-network/virtual-networks-overview
You should be presented with the below blade to create a VNET.
The Key factors to consider while filling up this form are
Once your VNet is created, the very next step is to create a subnet associated to this VNET. A subnet as its name might imply is a subset of the VNet and creates another isolation for provisioning resources within this group.
The important thing to remember while creating a subnet is the address space and a sensible name.
It is best to have one subnet for each type of Blue Prism component; one each for DB, App Server, Interactive Client and Runtime Resource.
There are additional configurations like DNS, DDOS and monitoring that can greatly enhance the installation and please feel free to explore them as well.
Once we have the basic networking components created, the next step is to explore Network Security Groups (NSGs) and associating them to the subnets we created earlier.
Do remember that NSGs are one of the first layer of protection that can be added for our implementation. Azure provides even more security perimeter with services such as Firewalls, load balancers…etc too which are typically configured for large scale and highly secure implementations.
NSGs can help us control communication access to a subnet or any similar network components it is associated with. Read more about NSGs here: https://docs.microsoft.com/en-us/azure/virtual-network/security-overview
Similar to how we searched for the VNets, search for Network security groups and you will land in the below blade.
Once a proper name and other parameters are given and the NSG is created, open the NSG blade and do the following configurations,
Define Inbound and outbound rules: This is where you configure the ports that can communicate externally.
If the intention is to have each component is in its own subnet and NSG, then you will need to remember to open the Blue Prism ports in these rules. By default, these are 8181 and 8199 on TCP.
Remember that, the lower the priority number, the higher the precedence off the rule.
Associate a subnet: click on the associate button to tag the NSG to the subnet we created earlier.
To set up the heart of Blue Prism, we are going to use Azure SQL as an option.
Azure SQL provides a layer of extraction and help us to avoid complex installations of SQL, virtual machines…etc. In very few steps, we can have a performant SQL Database setup.
Do remember that features such as replication, few controls at hardware level are limited in the PaaS offering. For an large scale implementation do explore SQL in the IaaS mode or the Azure Managed Instance offering.
Read more about Azure SQL here: https://azure.microsoft.com/en-in/services/sql-database/
As usual, you start by creating a resource called “Create SQL Database” and follow the steps as show in the screen shot below.
Create a Server
Select a right configuration. You are free to choose a right size based on your requirement. Although we recommend using VCore based sizing, its easier in this case to use a DTU based model of configuration.
Do remember that DTU based models don’t clarify the exact CPU, memory or IOPS you would get and hence best to not use this option for an actual implementation. In this case we are attempting something for a POC, pilot or to learn more about Azure and DTU makes it easier for us.
Networking: Typically, you would want your DB to be inaccessible external. Hence No Access is the safest option here.
The final step of the puzzle is the actual Azure VMs. There are way too many options to configure an Azure VM and we only explore the simplest options.
Read more about VMs here,
You would ideally need a VM for the app server, another one for the Runtime resource and the last one for the Interactive client.
All VM creation follows the same general principle.
Below is the VM creation blade with the key part to consider being the availability set (not mandatory for Blue Prism), but this helps in scaling easily
The next step is the disks and networking. You will need to give special focus to networking since this is where you will be selecting the subnets you previously configured and protected using NSGs.
Finally, there you have it. You have a working platform to install Blue Prism. Use the RDP file to remote into the respective VMs and carry out installations.
The next steps are very straight forward which is explained in detail in our Enterprise Installation Guide available on the portal.
Azure is an ocean of possibilities for implementing Blue Prism. The reference architectures in the below link will help you as a starting point to understand more about implementing an Enterprise grade instance.
Other references you might like to read on,
Learn about load balancing multiple VMs. This can be applied to the Blue Prism app servers and run time resources (specifically when processes are exposed as web services)
Understand how availability sets help is improving availability of the implementation
I hope this blog helped you to understand how simple it is to deploy Blue Prism on Azure. Do share your thoughts and feedback!
This content has been recommended for you based on your profile information (e.g. interests & location)
Please update your profile information to view recommended content