A challenge that we face as Blue Prism process designers is how to allow external services to communicate with our internal Blue Prism workforce. There are many ways to solve this problem, the one that most of us will attempt is to expose our VBOs as services. While this would work, it does come with some organisational challenges. The first hurdle you may need to overcome is getting buy-in from governance teams (Telephony & Networks, InfoSec, Infrastructure Architecture to name a few) to accept that creating a firewall rule which allows inbound traffic into parts of the corporate data centre is a good idea. Some teams achieve this with mixed levels of success, the more regulated the industry is the more difficult it is to succeed. Having worked in a regulated environment, I have observed that outbound requests are looked upon more favourably than inbound (within reason of course). This is primarily because the organisation is in control of the flow of traffic, the obvious trade-off here is one of latency of the requests (more in a business sense rather than a network sense). The need to poll the 3rd party service periodically to retrieve some data, means data does not arrive as quickly. There is also the lesser issue where the ability to poll for data is not provided by the 3rd party. The scenario we're going to explore is one where we're being pushed data by a 3rd party that needs to be worked on by a Blue Prism digital worker.
We will now shift the focus to what is needed in order to complete the integration. To achieve this using no-code, we will be using some capabilities Azure has to offer. The image below shows the Azure services we will be using, namely Logic Apps and Azure Queues.
An unintended but positive side effect, is that by using this approach, a buffer zone now exists between 3rd parties and the Blue Prism digital workers. This pattern is sometimes called queue-based load levelling. A benefit of which is the ability for the system to cope with demand without flooding our digital workforce with request, thus increasing the availability of the service. The items will be held in the queue and collected by a Blue Prism digital worker periodically. If there is a sudden spike and the queue starts to grow, we then have an option to onboard additional Blue Prism digital workers to process the queue. This "holding area" could also be extended to include additional security controls, like the inspection of message, before reaching your internal systems. By using multiple Blue Prism work queues in conjunction with teams of digital workers with the appropriate skills and computing resources, you could bolster the scalability of the system, .
Hopefully, you now understand the problem and a potential solution. So, let's move onto actual implementation. As mentioned earlier in this article, We will be using Azure to solve this challenge. If you need an Azure account you can signup for a free one here.
The next step is to create a resource group. Instructions on how to do this can be found in the Create resource groups section of Manage Azure Resource Manager resource groups by using the Azure portal. The resource group will serve as the container for the Azure resources we're going to create, namely an azure storage account (and a queue) and a logic app.
Follow the instructions on the Create an Azure Storage account article, then follow instructions provided in the Quickstart: Create a queue and add a message with the Azure portal to create the Azure storage queue.
Finally, follow the instructions on Quickstart: Create your first workflow by using Azure Logic Apps - Azure portal to create the logic app resource.
Once the logic app resource is created, proceed to design a flow that is triggered when an HTTP request is received. The process will contain an "add to queue" action and for completeness, a response should be returned at the end of the process. The resulting process could look something like this:
The HTTP trigger I've built looks something like this:
Once complete you've completed your flow, use Postman to test it. Below is an example of how I've tested my implementation:
After executing the above request, we can also check the storage queue in the Azure portal.
The next steps are to build the Blue Prism processes that poll the Azure storage queue. We will be defining two processes and a single Blue Prism work queue. As mentioned previously, you could distribute the requests from this single azure storage queue into multiple Blue Prism work queues. Each queue could be monitored and processed by several digital workers. Interacting with the internal queue is the same, regardless of how many workers are involved, as Blue Prism ensures that queue items are locked to a digital worker on a first come first serve basis. Interaction with the Azure Queue will be achieved through the use the Azure Queues Rest API VBO. You will also need to import the Utilities - JSON VBO which ships with the product.
Below, is a rustic implementation of a process that polls the Azure queue and places a new item into the internal work queue.
The first sage uses the VBO downloaded from the Digital Exchange to access the Azure queue. Interacting with the queue will require the following Azure storage parameters:
- Storage Account Name
- Queue Name
- Access Key
After identifying that an item exists, we map the MessageBody to a collection using the Utility - JSON VBO. This returns a collection that is used as the payload for the item that is added to the internal Blue Prism work queue. The process continues to poll the Azure queue for new messages until a stop request has been received from the Control Room.
The image below depicts a process of how the other Blue Prism digital workers are simultaneously polling the internal work queue for work.
In the process, the Do Work page reference is where your Blue Prism digital worker would interface with the line of business systems to carry out its work.
After implementing all of the above steps, and executing the above processes, we can verify that everything has behaved as expected by visiting the internal queue using control room. The image below shows a work item that has been completed successfully:
Hopefully, through this article you have gained sufficient insight on how you could go about integrating your on-premises Blue Prism digital work force with a cloud based service.
