BluePrism attended processes? Why not?

One of cons customers find out on Blue Prism, is the fact attended processes are not supported out-of-the-box.
Well this is not so true because you can play with BP in order to someway create attended processes.
If you are an enterprise and you don't use SharePoint, please raise your hand... i see no one.
So we can use SharePoint (or Office 365 as well) to interact with BP with a tiny additional effort. Moreover, if we create a solution using NCSSs (No Code Sandbox Solutions), we can do the work fast and without great impacts on pre-existing solutions.
I will refer to the producer-consumer model during this article, so, if you haven't read it... read it :-) http://valeriovalrosso.blogspot.it/2017/04/a-simple-blue-prism-multi-robot-example.html

 

Solution 1

There are 2 possible scenarios from the real world:

1. Robot polls for new item to process directly from a SharePoint list
2. Call the robot as a web service from SharePoint and consume the service

 Scenario 1

A typical real world scenario 1 example is the one above:

• User does something on list items
• User interacts with the list items through the workflow
• Robot polls continuosly on the list in order to find items to process (in this case also processed by the workflow) and put them into a queue
• Robot consumes items and writes back something to the list item about the automation results

An important advice is to write on the new item list the fields: "Robot Machine Name" and "Robot Machine User". This will be a useful information during debugging sessions because, in a multi-robot scenario, you will use more than a robot that will do the action on the SharePoint portal, and will make debug sessions easier.

Solution 2

The second scenario, here below, calls directly the robot from the workflow (or from JavaScript or other techniques, it depends on what you wanna do).

 Scenario 2

To do so, you need to expose the process and create some code in order to call the robot web service.
In my example i created only one process which does nothing for 1 minute, here the wsdl BP created for me, and a small piece of code below, which shows how to call the BP web service.

The wsdl BP produces for you

Consuming using C#

You have to remember that web services aren't exposed on all resources, so you'd better to design which machine (in a multirobot scenario) is the "producer machine", and maybe use a configuration list on SharePoint to configure the value dinamically.

Moreover could be a good idea to split the producer-consumer model, exposing only the producer, leaving the consumer in the loop.

Since multiple invoked processes could be executed at the same time (as you can see below), think about just using the producer to fill the queue with the information from SharePoint and avoid the full automation when the service is called, because it could became a dangerous bottleneck and you will have to deal with concurrency on the same machine.

Concurrency

So the message is: even if you can play with different technologies, mind you have to think in a multi-thread way now.

Conclusions

Like everything in the world, different approaches have pros and cons

Scenarios	PROs	CONs
Scenario 1	- Easier support to multiple robots - Scalable	- Pay attention to polling
Scenario 2	- You can put an item in queue and give an immediate response	- Binding to a single "root" producer machine

An that's all my friends.