Enhance AutomateC.exe /getlog switch to fetch parameter column details from Blue Prism logs

[Prashanth__Andy]

The AutomateC.exe utility in the current iteration can fetch just the plain log lines from the Blue Prism logs using the /getlog switch. 

The following images shows the difference between what is visible in the Log Viewer for a target session vs. what is actually returned when the AutomateC.exe /getlog command is executed on the same session. 


As seen below , the log info returned via AutomateC.exe does not contain the information from the Parameters column that is normally visible in the Log Viewer.



Purpose for this Request:

We have a practical need where we have to execute a series of processes that are pre-configured in a configuration source. The number and order of the processes will vary with the type of Business process that is being currently executed via Blue Prism. 

In Blue Prism there is currently no way to dynamically call a Process at runtime by passing the process name as a parameter. The AutomateC.exe is the only avenue using which processes can be called by generating command lines at runtime by passing in the name of the process and their input parameters.

Most importantly, if we can pass in input parameters to a process that is being executed via AutomateC.exe, it is only natural that this utility be versatile enough that it is able to return the output parameters returned by a process that has executed in a specific session.


Thank you!
-Andy Menon

[Prashanth__Andy]

Please upvote! 15 votes gets this on Blue Prism consideration list. Thank you!

[Prashanth__Andy]

Yay! Finally!

We have hit 15 votes!

Thank to all who voted! 

[robert.nicklin]

Hello @Prashanth__Andy,

Thank you for taking the time to raise an idea.

Having reviewed the details of this request, I believe that the capability you're describing here was made available in the v7.2 release of the Blue Prism API. This means that, when consuming Blue Prism 7.2 or later, you should be able to achieve this objective by using the API rather than command line, which is the intention for the API moving forwards.

Separately, it seems to me that the use case that you describe could (alternatively) be achieved by constructing a parent process to orchestrate the running of your consecutive sessions, could it not? This would potentially offer you an alternative way to run several processes on the same resource concurrently where the output from the first process is interrogated to make decisions/choices on what subsequent processes are ran. This would provide an option for you on previous versions before an eventual upgrade to Blue Prism 7.2 or later.

Based on this review and the points mentioned above, I'm going to move this idea into a status of Not Planned for the moment, though I'd be interested to hear more on the use case if you'd care to share more, either here or directly.

Regards,

Rob

[Prashanth__Andy]

Thank you for the detailed response Robert. I have pursued the alternates and yes, it is possible to use APIs. But, I feel that I have to tap into the APIs for such a minor piece of functionality.  As for the Master process; currently the ability to start one process from another is hardwired. Meaning the list of processes must be selected from a dropdown. In addition, this action does not have the ability to be parameterized with a process name, although selecting a process gives us the ability to input parameters and fetch outputs as you rightly stated. 
But from experience there are situations where a master process must decide on whether or not to execute a subordinate process. And all of that logic has to be coded in the Master process. And if 5 or 10 processes must be executed by the master in a specific sequence, then all of those 5 stages must be hard wired into the master process. All of the logic to trigger a subsequent process must be coded as preceding stages as well. 

Should this order change or more processes are injected somewhere in between the sequence, it means we have to alter the master process and redeploy.

I have been fairly successful in prototyping a system where a sequence of processes can be fired off by one after the other using AutomateC.exe from a single stage without having to hard code any process names. The process names and their parameters are determined at run time, and triggered off by the Master Process. The logic or rules to fire off a subsequent process can be easily integrated as a generic step in this "Master Template". 

I have a couple of options on how to fetch the output parameters and currently thinking through it.  Once it materializes as an idea, I will prototype it as usual.

Thanks