Good afternoon, Community!
In addition to the corporate standards for creating a project at UiPath Studio, I asked myself, is it possible to get a value for the type of process to run?
Get a value in the variable, whether the process starts in debug mode or runs in run mode. Using the value of this variable would very helpful to construct processes that have a dynamic distribution on sources of data, work with accounts, etc.
Please clarify whether this function exists at the moment?
Good afternoon, Stefan!
This is certainly the first idea to come, but the use of interface interaction in this case does not seem optimal.
I’m looking for a solution that is really similar to the one used in .NET. Displayed in this post.
I do think there is another way to Understand if it is a Debug or a Run. The Idea struck me after I have looked into @codemonkee post.
Using the Workflow Analyzer, we can set what should be the LogLevel at Run Or Debug. So, If we are to provide different Log Levels for Both, We can Retrieve these values from an Orchestrator API Call for RobotLogs and then further filtering with Conditions we can get to know if the First Log Message was a Trace or Info or any other as we have specified in the Workflow Analyzer Settings, which would then Decide it was a Run or a Debug.
But this would require a Log Message at the Beginning of the Process/Workflow without Specifying it’s LogLevel as shown below :
The CurrentTime value would be useful to filter out the Robot Logs retreived.
I do think this is a long approach to achieve the desired outcome. But I do think it is possible.
That is what I am not sure whether or not it is directly exposed. I was doing some research the other night, but haven’t found anything concrete. In theory, because you can build custom activities that include Project settings that it stands to reason that which Runtime Mode (Release or Debug) you are in can be captured perhaps as as an Activity within your custom package itself.
We kind of do something similar to achieve this sudo runtime, we create a global variable that holds the type of run that is being performed (Non-Prod vs Prod in our case) and expose an Input Argument that can override the global variable if needed with the default being a non-prod use case. This allows us to override it for other “Modes” on a per process or per job level. And as needed we wrap certain activities or variables in a conditional based on the mode we are running under.
Further to that we use the Add Log Fields Activity to add addition variables as custom log fields at the start of a process so that all log activities has the extra meta data we are looking for. We also take it a step further by having a requirement that all jobs have at least 1 queue item, or if working on multiple items that a queue item is created for each. This allows us to better report on a per transaction basis with Queue Item output in a consistent way which we further enrich the Transaction Logs with additional custom fields.