In my previous post, talked about how we can optimize RPA deployments in terms of cost, performance, handling complex use cases and optimally re-use components by using microservices. There are some scenarios, where implementing microservices can be costly in terms of resource expenditure and also cost for third party services. In this post we will try to figure out flow and integration of one of such use-cases.
There are numerous questions about possibility / how-to-do / complexity for RPA with WhatsApp on UIPath forum. It’s quite natural. As even for an advanced developer, it takes substantial time to integrate WhatsApp session messages from providers like Twilio, moreover it’s pricing also a bit high for something that we are used to use as free.
Now, doing the scraping for new messages and sending messages via WhatsApp with UIPath or Blue Prism may not be a piece-of-cake but definitely is doable. For the services like, WhatsApp where APIs are kind of closed or expensive, or only desktop app is available, hybrid solution with UIPath / Blue Prism along with Microservices can be quick and easy to build, deploy and maintain.
Suppose we want to build one food ordering system for a food delivery startup like Zomato / Swiggy etc. Whenever customer would ping to a specific number on WhatsApp, our solution should be able to respond with greetings, ask for preference and present options from different restaurants with their price via WhatsApp messages.
Here we are following micro-bots design pattern to build the solution. We need
- Two micro-bots to be deployed as un-attended bots
- Get messages bot
- Send messages bot
To process the incoming messages, we can either use Apache Flink or Apache Storm for CEP or create small micro applications to interpret and prepare response for each of the messages. We will create a very simple microservice as deployment and maintenance of both Flink and Storm are complex and our solution does not have that much complex use-cases to handle.
This message processor application has to respond immediately, otherwise user may loose interest. Also to interpret user’s preference / choices we have to use NLP. We would use Azure Text Analytics Service for this. For a short discussion around why Azure vs Google Cloud or AWS, please refer to our previous post. This application should process the incoming messages quickly and swiftly.
Get Messages Bot should scrape the new messages and put into a Message Bus. We will use RabbitMQ. It’s fast and can work with a very high throughput with relatively less resources. Other choice for an enterprise service bus may be Solace PubSub+. But configuration wise it’s a bit complex and needs more resources than RabbitMQ. And Solace’s Standard version has a limitation for concurrent connections and messages per second.
Adhering to Single Responsibility Principle of SOLID, we are breaking the message processor application into three different applications. Each of them would interact with each other via the enterprise bus, that we have configured with RabbitMQ. And also to facilitate the processing of the messages and their followups, we would use a State Machine. To understand this, we should first understand, why it’s required. Suppose a user first IMs that, s/he would like to have some dishes from Indian Cuisines. Immediately after that, before getting any responses s/he again expresses her/his interest in Mughlai dishes. So, after this responding with a general recommnedation of Indian dishes won’t look good. We should restrict our search only among the Mughlai dishes. For that we should use a Finite State Machine for this kind of scenario. Though this post does not match our solution domain, but explains the concept in a very straighforward way.
We would need four microservices along with two bots.
- Incoming Message Processor this would take up the messages one-after-another from the Enterprise Service Bus (ESB), pushed by the
Get messages bot, call the NLP service to get the classification words and then it would put the message along with the reponse from the NLP into the ESB.
- Cuisine Search App this would take up the messages from the previous one and search accordingly and put the search result into ESB along with the message and the classification words.
- Response Preparation Processor this would prepare the response out of the search results from the
Cuisine Search Appand put into the ESB to be taken by the
Send messages bot.
- State Machine effectively this would process each of the new messages put by the
Get messages botand manages the state. And all the above three apps and the
Send message botalways should regard the status of a specific message processing of each of the messages. In this way, we can prevent sending unrelated results to a customer.
Now let’s review the flow and interation among the RPA bots along with the micro-services from the following picture.
With this hybrid solution, we have used best of both worlds. Made our life easy and solution a bit cheaper with the use of RPA bots to scrape new messages from WhatsApp web and send messages. Used microservices to accelerate the processing of the messages and finally preparation of the response using AI. By using the AI NLP, taken account of the customer emotion and changing preferences.