AI and RPA Prep - Messaging Part 4

I am going to write more on integrations and ways of how messaging happens in real time. This is very important when you consider the real time implementations. We said in earlier article that integration is just about 'taking to one another'. But if you think about it, this conversation can happen in lot of ways. I would go through the basics of these in this article.

Before jumping into it, two basic terms we hear in this area - synchronous, asynchronous. Synchronous is real-time. It is same as talking on phone, asking a question and other person is talking back immediately. The conversation is in-tact, there is no break in interaction flow.

Asynchronous is not real-time. A request is received,sender takes his time and then sends the data out to the receiver. This is more like our request for checkbook in bank, then bank takes few hours to days to send the checkbook to you. Even credit report for that matter, you ask then you hang up and end the interaction, after few hours or days you would receive the report in your mailbox or which ever channel you preferred.

Why is it important in AI and RPA? Yes all these have to be accounted for if you are automating conversational components, on how the customers are interacting with your company etc., Automating also involves these aspects embedded in how it is now, how it can be improved. One important decision point is - do not keep it synchronous if it is not required really or is going to take time.

Publish and Subscribe - This is a very old and nice method of conversation. I always use newspaper or magazine as an example. What happens in newspaper or magazine scenario? NY-Times or Vogue just prints out content in newspaper format or magazine format. If you want to read that content, you need to buy the book or paper. In others terms Vogue is publishing the content and You are subscribing it. If it is in a e-mail form or you want to read it often. You can subscribe to Vogue or NY-Times. They deliver it to you whenever there is content.

Similarly, if a system A has content to publish, it will keep publishing it. Systems that want that data for any function, will subscribe to the content there by becoming a consumer. Here, System A is Publisher, Systems subscribing are Consumers or Subscribers. If the content is no longer required, they just send 'Cancel subscription' and they will no longer get it. One important thing here is that there is an agreement that System A would publish in such-and-such format only. It is not customized for System B or System C. It is up to consumers to do that on the receiving end to make it suitable for the down-line systems. This is where your messaging layer in architecture plays a major role. One should note here that publish and subscribe is asynchronous mode of integration.

Request and Response - This is a very common one now-a-days, especially in technical world. We request for content and we receive it. To compare it in real time - you can request for a particular report from your bank and it caters to it, prepares the data and gives it to you. There is again an understanding here that data is given in a particular format and receiver would understand that format. For example, bank report would have abbreviations which are mentioned to receiver and how to decipher them. There can be customization from sender end for a particular receiver if the content is unique and not repeated for many. In cases where there are multiple requests from different receivers for same content, customization is not done. Then, receiver has to do their own customization or we also call it 'massaging' for the down-line systems. This is the most widely used type of synchronous integrations now seen. Important point in designing these integrations is that there should be a contract which is like religious in nature between requesting system/service and responding system /service. It is like a bible (lack of better word) and has to be adhered to.

Push and Pull - This is a great one as well. When we do batch processing or real time, sometimes there are so many down-lines from the actual system in front-end interacting with customers. In real life, compare it to a new member being recruited into the organization. HR system would be initial front-end system that captures his details, creating his employee id. But down-line systems like department, finance, employee-support, insurance etc., have to now have this data too for other purposes. So HR either Pushes the employee information or other systems can Pull the information from HR system. HR system can do it batch-wise end of every business day or so. Push is better than pull in this example. Similarly Push is done in application by either placing content as a formatted file on shared server or place and down-line system would pull the data from that file server. Again, the pushing system does not give customized for each of the systems that are pulling the data. Here like we saw in publish-subscribe, there can be multiple systems pulling data so the data cannot be deleted once it is consumed by just one system. . Important point in designing this integration is that there should be a contract which is like religious in nature between pushing system/service and pulling system /service. It is like a bible (lack of better word) and has to be adhered to..

Event / Trigger based integrations - This is one of my favorite ones. Any time there is a trigger or when an event occurs something has to be done. For example, you have bank account and when a withdrawal of amount greater than 500$ happens, you want to be aware of it. So, a trigger is set that if an event occurs that withdrawal of >=500, then inform customer. This is what happens in back-end. For example, when someone calls IVR and creates a complaint, there needs to be trigger to open a ticket in CSR (Customer Service System). Again, how data is actually sent- can be push in most of the cases.

In some cases, round-robin method is used for doing pull from different systems, for example Sys A needs data from different systems 1...n, it goes polling (term is called polling) from one system to another one by one then again continues from system 1.

Now, why do we have to know these in AI or RPA perspective? Integrations would be there always. To understand when to use which integration and for which use-case is important. So is using synchronous and asynchronous way of interactions. If it is a voice bot or chat-bot then most of the responses have to be synchronous. In cases of ticket based virtual assistants when notification has to be sent back to customers via digital forms would be asynchronous. Some of the use-cases would involve triggering a bot based on event or some trigger like sensors. IOT also comes into play when using these kind of integrations.

I will conclude this part here. Next part we will discuss Digital footprint prep more in detail.

AI and RPA Prep - Part 1

AI and RPA - Part 2??

AI and RPA - Part 3