Using Invoke Workflow on an Reframework Main.xaml Invokes Workflows in the main environment?

Help
, ,
1

tldr: Using Invoke Workflow(blah/Main.xaml) inside blerg/Main.xaml means blerg/Framework/GetTestData.xaml is called instead of blah/Framework/GetTestData.xaml. I need help figuring out a more durable solution than adding an in_relativepath variable with a default of “./” to all our templates and changing the invoke workflow filepaths to include that relativepath variable.

Long Description:
My coworker who’s more experienced with UiPath said we need to make a dispatcher workflow and a performer workflow.

The dispatcher workflow reads files from inside a folder and makes corresponding queueitems, which include a recommended process name among other values.

The performer workflow pulls down a queueitem and then uses that recommended process name to kick off the appropriate process. Currently, I’m doing this using Invoke Workflow. (So the queueitem’s WorkflowName value (e.g. DownloadEmails) is used to select an OrchestratorAsset (DownloadEmails) which has the value of the WorkflowPath (DownloadEmails/Main.xaml).)

The performer workflow was written in the Reframework template and all of our process workflows probably will be too. Even if they weren’t, it would be reasonable for them to invoke subordinate workflows.

When I invoke the Main.xaml for a process workflow, for example a dispatcher workflow that should read files in a directory and add a queueitem to the queue in response, three things happen.

First, I get an error saying “Error getting transaction data for Transaction Number: 1. Can not convert Object to String. at Source: Newtonsoft.Json”

Second, I do not see the line I would expect to be written - if the right file had been called - due to a WriteLine I added at the top of dispatcher/GetTransactionData.xaml

Third, more than one queueitem is labeled as In Progress without there being a “Processing Transaction Number: 2”, which should be impossible if the QueueItems were being addressed sequentially…?

This indicates to me that all of the workflows being invoked by that workflow are happening within the main environment. Therefore, the wrong workflow is invoked. What is a clean resolution for this issue?Am I completely mishandling my dispatcher-performer structure?