Soap API

[SornakumarV]

Hi all

Assuming want to run five processes on a five machine. while triggering the single soap api need to start all vm at the same time . how to setup?

------------------------------
Sornakumar V
RPA Developer
Iopex technologies
Chennai
------------------------------

[ewilson]

Hello @SornakumarV,

There are a couple of ways to handle this.

Direct Invocation
When you expose a process as a SOAP web service in Blue Prism, it can be directly invoked from any client capable of making an HTTP Post call using the URL format http://[Runtime Resource IP/Hostname]:[RR Port]/ws/[Process Name Endpoint]. Ideally, your client application would interrogate the WSDL to get the details of the process, it's endpoint info, parameters, etc. You can get the list of exposed processes and their WSDLs by navigating to http://[Runtime Resource]:8181/ws/ (Note: 8181 is the default OOTB port for Blue Prism Runtime Resources).

The downside to this approach is that you would have to have 5 available Runtime Resources and you would have to start the process on each of them by calling them directly.

Load Balancer
​The better approach would be to have a load balancer in front of the Runtime Resources. Your client would submit it's request to the start the process to the load balancer and it would be its responsibility to send that request to a specific Runtime Resource. There are various load balancer schemes with the most common being Round Robin.

Work Queue
You could also go the path of simply submitting work through a simple VBO exposed as SOAP web service. That VBO would push the work into a work queue that could be monitored by your processes running on a schedule.

Resource Pool
Another approach, what I refer to as the "Poor mans load balancer", is the Resource Pool feature in Blue Prism. This depends on what version of BP you're running though. I don't recall the specific version it was introduced in, but I think it may have been v6.4. This feature allows you to group a set of Runtime Resources in such a way that you can submit work to just the controller RR and it will distribute that work to one of the available RR's in the pool. You can find more information about Resource Pools in the documentation (https://bpdocs.blueprism.com/bp-6-10/en-us/helpResourcePools.htm?tocpath=Interface%7CSystem%7CResources%7C_____1).

Cheers,


------------------------------
Eric Wilson
Director, Integrations and Enablement
Blue Prism Digital Exchange
------------------------------

[SornakumarV]

Thanks Eric

------------------------------
Sornakumar V
RPA Developer
Iopex technologies
Chennai
------------------------------

[Denis__Dennehy]

Hello.

The design of an API call triggering Blue Prism needs to be broken down into three parts - it is asynchronous (response not immediate) rather than synchronous (immediate response) design.   The reason for this is that you do not have an infinite number of robots sat idle waiting for web service calls.

So your design will be something like this:

Design Component 1:  Web Service Request
The Blue Prism web service process will simply add a new request to the Work Queue and return a "Request Successfully Received" boolean response.

Design Component 2:  Doing Work
This is where your scheduling logic will kick in so that the robots do the work.  If you want the response to be as close to synchronous as possible then you might want to dedicate your 5 robots to only work requests in that work queue and nothing else.  If you want to get as much utilization out of your robots as possible you can have them do other work but prioritize your API requests via a number of different options (such as a parent process making work decisions based upon SLAs or priorities or a tool such as RPA Supervisor).

Design Component 3:  Finally, you need to design your response method with the requested data or informing that the requested work is complete.  This should ideally be the robot proactively sending the information somewhere.

I am sure there used to be some thing useful on the Blue Prism portal or somewhere about this - maybe it has moved into some Blue Prism BP University training (either Web Services specific or the design training),  otherwise it has disappeared and probably needs adding into one of those other courses.

[Denis__Dennehy]

Agree with Eric's load balancer idea - on all projects where the number of requests expected was going to be extremely large a there was an additional component on the 'non-Blue Prism' side of the solution to better manage traffic and the sending of requests to Blue Prism.

[ewilson]

@Denis__Dennehy makes a great point that I neglected. Direct invocation of a process ends up being a blocking, synchronous request. In other words, the client will make the request and then wait for a response from the process. If the process takes hours to complete, this will result in a network error as the connection will timeout. So addressing this in an asynchronous manner is paramount.

This is where the Work Queue approach shines as it provides that's decoupling. Additionally, there is an asset on the DX known as the Process Dispatch Framework. This also gives you the ability to invoke processes asynchronously. Combining this with a load balancer would be my recommendation.

Note: The Process Dispatch Framework makes use of work queues for tracking and resource pools for distribution of work.

Cheers,​

------------------------------
Eric Wilson
Director, Integrations and Enablement
Blue Prism Digital Exchange
------------------------------