Running bot details

Is it possible for a running bot to retrieve details about its own running instance?

For example, I’d like for a bot to be able to log:

  • Project details (from the json project file)
  • Current xaml file being processed
  • (extra credit if I can get the calling tree from Main workflow)



I think some of what you are asking is possible…

–For json, use Read Text File, then Deserialize Json. There is probably information online on how to use json files.

–For current xaml file running, you could hardcode it into a string for each file, or there is some that solves it here:How to get the current running Xaml file name dynamically - #11 by vvaidya
However, if that workflow fails, none of the arguments get passed back with that info, so you would need to surround each worfklow with a Try/Catch to ignore errors (but you can still store them into a variable like error=exception, inside the Catch)

Also, in version 2018, there are Job activities like Start Job or Get Jobs. I’m not sure if you get much info from it other than the available jobs (I have not used it yet).

–I’m not sure what you mean by the extra credit part. You can Get all the .xaml files in a project folder if you would like by using System.IO.Directory.GetFiles() and it let’s you filter it to only .xaml. – there are examples online

Hopefully, I answered something.


@ClaytonM - I was looking for runtime properties, it didn’t occur to me to manually load the project file and parse it. That should be a decent workaround for that, thanks.

Regarding the other bits, here is our situation.

We are able to enforce use of an “init” activity in our organization, so I am able to collect some information about the running workflow (we log that centrally). I know what I can get from our environment, I’m just unsure what process information we can grab about the running bot. I am not talking about querying the Orchestrator API, I am talking about any running robot (launched from Designer, for example).

The “extra-credit” part I was talking about was thinking about the calling tree from one workflow to the next, so it would indicate that the activity was called in c.xaml, which was invoked by b.xaml, which was invoked by a.xaml (etc).