No this doesnât quite answer the question. Weâre talking about being able to self-reference the workflow that you are in. So, for example, if your workflow is called Workflow.xaml you would be able to call that dynamically by referencing UiPath.WorkflowName or something to that effect.
Therefore every time you want to log a message or throw an exception you could start it with UiPath.WorkflowName + " bla bla bla" rather than having a variable called StringWorkflowName and having to update it every time you create a new workflow.
I donât think that itâs a massive thing but it feels like something you should be able to do and in certain circumstances could be really useful.
Thatâs exactly why I want this. At the moment I have a variable name for a component (sequence) so when I log any messages I can add the component (sequence) name to the log. I also have to remember to update this variable each time I create a new component or rename an existing one. Not a game changer but would be a lot smarter if you were able to get an object returned (kind of like a trace stack) showing each sequence call with properties for current workflow/sequence and parent workflow/sequence and full stack path. Can make debugging a lot smarter and supporting for CoE a lot easier.
Current workflow name is by default logged under filename node in the log json: 13:37:57.9454 Trace {"message":"UiPath.Core.SelectorNotFoundException: Cannot find the UI element corresponding [...]r\n at UiPath.UiNodeClass.FindFirst(UiFindScope scope, String nodeID)\r\n at [...]","level":"Trace","timeStamp":"2017-02-07T13:37:57.9454027+01:00","windowsIdentity":"[...]","agentSessionId":"00000000-0000-0000-0000-000000000000","processName":"Test5","fileName":"TerminationTest","jobId":"e9da7713-174d-4495-b88a-aefc00435fa0"}
But itâs true it could come in handy, especially with exceptions, as theyâd show the fileName for where theyâre catched, not where they were thrown.
Having a call stack would be great too, especially for resuable workflows, where the path how it got there is sometimes as important as where the issue occurred.
What do you mean by logging properties, though? Argument values?
Either way - thumbs up, could be a useful addition.
I mean example properties I could access on the stack object. As for the filename youâre correct, just being able to get the information yourself means you can document your own messages to look for at CoE an be able to dictate the format of them
My use-case is that Iâd like to be able to save a screen-shot to a shared folder if I run into an exception - and would like to add the robotâs name or the flow name to the screenshot filename for some context, like: â[RobotName]-2017-07-11-12-16-33.pngâ
I also want to retrieve name of workflow. I need that so that I can easily add comment on the very beginning and end of invoked workflow for instance. As logging is encouraged when building workflow, I hope this will be a help of everyone
Itâs almost like you were reading my mind, cause I was doing the same thing today.
System.Environment.CurrentDirectory gives you the directory but I couldnât find the workflow name.
I do know that you can get the Sequence name when an exception occurs by using an Invoke inside a Try/Catch with exception.Source in the Catch.
But for workflow name, I ultimately hardcoded it into my Start Log string. I will keep an eye if there is ever a solution presented though.
EDIT: also, a possible idea would be to use GetFiles with the CurrentDirectory and filter it by a keyword, like âMAINâ then that will give you the workflow filename.
I would find it useful to have a general reflection API like one has in .NET / Java. In those environments, the use cases are broad because it is read (get) / write (invoke method) oriented. All of the logging use cases above would be solved. Off the cuff I could think of activities like GetCurrentActivityClass - which would have data for current activity name, id, âŚ, GetCurrentWorkflowClass - return the first activity above in the graph that is a workflow item âŚ
Mircea - it looks like much/all of the information is there internally, just a matter of making it reliably available.
Going through the thread, looks like we still donât have a way to retrieve the xaml WorkflowName. Am i correct?
I am designing a custom activity and i donât want studio user to specify the name of the workflow through properties. Instead i would like to get the name of the workflow that has that custom activity and report on it.
Would be awesome to get workflow name but I think also an identifier for activity would be useful. All in all, similar to a bread-crumb trail of where something went wrong all the way from Main, down to the activity level. I think combining this idea with something like this (Activity Uid in case of application exception) would be great