Web service - validate my logic

[riderc1]

I am using BP 6.2.1 and am wanting to implement web services and have a few questions/seeking advice. Here is a simple description of my environment:
We currently have a single runtime license and it is currently only used less than an hour a day. Once I implement my new solution I've been working on, the time usage will increase a lot - it might be running 24x7 for a few weeks each month. So, the workload will vary but we do want to maximize the value of our license so we are not "over buying". In other words, I will have a hard time justifying an additional runtime license.

My current solution uses the BP scheduler and runs at the same time ever day. My BP process consumes a few RESTful API's to collect dates and other information. It grabs the API info, writes to a BP work queue, then another BP process runs after the polling is complete. This works fine for my original solutions.

My new solution I'm working on is much more dynamic and a scheduled task is not well-suited. The problem is that I'm waiting on another department to do certain things and basically give the OK for Blue Prism to run and do its thing (which can take an hour or more each time this happens). My company has a workflow manager - this will be our source of information. The workflow tool has an API - I will be using it.
What I'm proposing to do is have a SOAP service send information to Blue Prism (background object) and write the information to a BP work queue. I'm working on this right now and expect to have a test ready soon. Ideally, I can also have a web service tell a BP process to wake up - it has work to do.

My questions (sorry for the long back story!):
1. If my object is a background process, can a single runtime license accept SOAP info/update a work queue while a process might be running in the foreground (likely running for a long time).
2. Does my approach seem reasonable? The data I'm expecting will never be ready at the same time - it will trickle in. There is a lot of work, so I don't want to wait until all data is available and kick off a scheduled task (like my original solution I created - it's a small amount of data and only takes a half hour to complete - the new solution is lots of work that takes a long time to run).
3. I also want my original task to run at least once a day. Let's say I have it run from 12:00am until 1:00am. That gives me other process the ability to run 23 hours a day.
Thanks in advance for any thoughts/advice. I'm worried I'm going to run into license problems and it's not easy to obtain an additional license.

 

[riderc1]

1. If my object is a background process, can a single runtime license accept SOAP info/update a work queue while a process might be running in the foreground (likely running for a long time).
This works fine. No license issue since the business object is set to background. I tested it while a process was running in the foreground.

I ran many tests today and have been happy with the results so far. I have web services using business objects and processes.

My situation might not be a normal use case for Blue Prism. I currently envision a solution in which I have a service that manages Blue Prism. Based on testing I've done so far, this solution can do the following:
1. Populate Blue Prism work queues.
2. Use a web service to launch a Blue Prism process. We currently only have a single license, so this will be a synchronous work flow.
3. Integrate into another work flow system used at the company I work with. This will make our auditors happy since they don't have to learn a new system.

 

[mondo]

Hi riderc1, interesting stuff!
I'm actually working on something that's very similar by the sounds of it. So far, I'm using an exposed process to parse data from the incoming webhook to add it to a queue in Blueprism, but I think I'll be redesigning this to a background object, the same as you have implemented.

Ideally, I can also have a web service tell a BP process to wake up - it has work to do.

This is the block we have come up against in our office. Getting the work from the case management platform to a Blueprism queue isn't too bad but then how does Blueprism know that there is work there to be done without an operator having to kick it off or having it regularly scheduled? Some of our processes here are time sensitive and ideally, Blueprism would be able to commence work on a queue as soon as it is populated. I have not developed a solution to do so however. Have you made any progress in doing so?

I have considered a workaround, in which a process is created to poll queues every minute or so, and if a queue has cases in it, its process is triggered. Like you, we must consider the most economical use of licences and so far, dismissed the solution, as it seems ridiculous to achieve a basic function to require 24/7 use of a licence. But if I understand you correctly, use of background objects does not contribute to license usage? This would open up such a concept as a method to kick off processes without the need for additional licences.

 

[DaveTheRPAguy]

Hi Mondo,

I feel you on the need to come up with a solution that can monitor queues periodically and spin up sessions when necessary. It does seem excessive to use a whole license (one session) 24/7 just to do that. Just wanted to add to the conversation here in case it helps you out.

First thing I can say is that background objects do still contribute to license usage. Any session that runs in Control Room, regardless of the mode it runs as still adds to the concurrent license consumption. I kind of like that idea, but I doubt Blue Prism will ever make it work that way because then everyone would try to turn their entire processes into background mode, which is definitely possible for many of them.

Second thing is that I think it might be worth it to use 1 license (1 session) to monitor queues if you make that session monitor ALL the queues. That way, if you had perhaps 50 processes running in production, you are only using 1 session to monitor queues for as many of them as are necessary. (Since many processes are done in batch once a day or whatever and don't need active monitoring)

Third thing is that the way to legitimately avoid license consumption by a process that polls queues is to use a scheduled script that uses AutomateC CLI commands to retrieve queue information and then spin up sessions of various processes as needed. I suppose you could even have a Blue Prism process that is run through Scheduler periodically to kick off that script running, though I'd have to think that one through on whether it would cause any weird issues.

Hope this helps.

Respectfully,
Dave

 

[riderc1]

Hi Mondo - the business object with background mode works while a process is running (with a single license). The object just writes to the Blue Prism work queue (while the process uses data from the queue to run).
My plan is to manage Blue Prism with my own service (either PHP or .NET - I'll be using other business services we already have in place). My thinking is as follows:
-My business service (not Blue Prism) gets its data.
-It uses a web service to send it to a business object in Blue Prism. My object writes the data to a work queue.
-I will probably have my business service (not Blue Prism) tell the Blue Prism process to run. The socket will tell me when its done.
-I am also considering creating another business object that I can query to see if Blue Prism is busy. I think I can get this from the work queue business object - didn't finish this part yet. If I have this, my business process could query Blue Prism to see if its busy. If yes, wait until its done. I guess I could also check my thread to see if the Blue Prism Process is done,
-Another option - add an Action to your processes that use a REST api to tell the business service if its done (or runs into error).
I will be developing this set up in January likely. It think this makes Blue Prism quite a bit more useful if this all works!
Please let me know if you move forward with any ideas. I find it hard to find get information on RPA solutions. I am the only person in my company working on it, so have no one to bounce ideas off of.

 

[mondo]

Hey guys, thanks for the responses, didn't see them over the holidays!

@DaveTheRPAguy

First thing I can say is that background objects do still contribute to license usage...

Yeah, this was my assumption, just was suddenly excited in case riderc1 knew something I didn't!

Second thing is that I think it might be worth it to use 1 license (1 session) to monitor queues if you make that session monitor ALL the queues.

I agree, there definitely comes a point that the value of the solution is worth its cost. Speaking for myself, we have a pretty modest amount of processes in production, so I'm on the fence as to whether its worth pursuing at the moment.

Third thing is... CLI commands to retrieve queue information...

This is also true. Some use of /exportqueue could read out the status of different queues and kick off processes as necessary. Might be a bit messy and like you say, one would have to ensure that there aren't unforeseen conflicts between the two systems.

@riderc1
Ok, so your main diversion from the usual path will be using your external application to trigger BP processes. I'm definitely interested to see how it goes for you, as it may be possible for us to use our case management system (the system that sends the webhook to Blueprism) in a similar fashion. I'm in the same boat as you - working on this solution solo - so let me know if you need to put ideas by someone and I'll update here if I progress anything on my end.

 

[riderc1]

@DaveTheRPAguy[/USER]

Yeah, this was my assumption, just was suddenly excited in case riderc1 knew something I didn't!
.

In my testing, I had a BP process executing a task while a web service sent information via a web service call to BP. This worked fine. I know this is kind of simple, but it does give a way to populate the work queue so your main process can keep on working and be ready to process additional information.

I took time off from the holidays as well. I am remembering what I was planning on doing . However, I noticed my Win32 process has changes its UI. This means I have to update my Regions to make it function. I'm more worried about software updates than anything else.

When i get back to my web service/case management tasks, I will try to share some of the information. My biggest frustration with RPA has been the lack of a team to work with. I've done solo development in my past many times, but this is alien to everything else we are working with at the company.