I’m looking for efficient ways of reducing number of In/Out arguments for some workflows. Especially in data extraction/input type invokes it gets unwieldy really fast (think multiple 20+ arguments of different types in several workflows).
First option would be a Dictionary<string, object>, but it’s prone to typo’s (string based keys) and casting in VB.Net is IMHO ugly (at least compared to C#), which gets in the way of quick and efficient design-time experience.
Secondly there are DTO’s, but they’d need to be .nupkg’d making them less than ideal for quick iterations (especially since every package update requires Studio restart). Lesser downside is a possible explosion of project-specific packages to keep track of.
Tuples are a no-go due to losing namings.
Expando and Dynamic(-like) objects don’t mesh well with VB.Net and I didn’t even manage to get them to work properly in UiPath due to Option Strict On for all workflows anyway.
DataTables/Sets are unwieldy for this purpose and serialization is less than ideal in edge cases.
As you can see I’m kind of stuck on this one…
Any workable approaches outside of Dict’s and DTO’s that I didn’t think of?
All ideas count
If the arguments are usually strings, since they come from extraction or input, you could use a file. I would suggest a csv file. The workflow that extracts the data saves it in a csv, and instead of passing the values, you can pass the path to the csv and read it when the inputs are needed.
This has the disadvantage of slowing down your workflow execution a bit, since the IO actions are usually slower, but might increase the maintenance of the process.
I’m not sure if using a file helps, as it would essentially change the argument set to a string or equivalent, unless it’d be read as a datatable, in which case it’s just an additional step compared to just doing it as a DT from the start (admittedly it omits JSON serialization which might be an issue sometimes).
We’ve did a similar approach putting data into XML, but while it worked, it wasn’t exactly straightforward to use.
I’m still thinking that DTO’s would be the best, if they wouldn’t be so unwieldy to update - maybe there’s a way that I’m missing to use them without recompile-repackage-update-restart cycle on every change?
This is the Entity feature we are going to implement.
Now, indeed you can use a file (I prefer JSON) but this expose you to typos and/or using many variables. If I need the Person.Name in three places it’s either I introduce a new variable PersonName = Person(“Name”).ToString either I’m using the hardcoded Person(“Name”).ToString in all those places.
That’s exactly what I’m struggling with - currently there’s either additional hassle with reimporting packages, losing type safety with Dict’s or namings with tuples. Other solutions are just adding complexity where the driver is to reduce it.
Could you elaborate on the Entity model that’s planned?
I’m wondering what it’s based on (if that’s not a secret ) and how we could possibly adjust our current designs to make the switch in the future as easy as possible.
@adrian There’s another important functional criteria…we should be able to pass these structures to isolated (out of process) workflows…at least if they contain serializable data like int, string, etc.
Invoking workflows and custom activities (including library activities) with arguments requires a lot of manual setup for the arguments.
I wish there was an easy way to copy and paste the arguments (name, direction, type) and the bound variable names from one invocation to the other, either as a group or one by one.
This can be a real time saver when you decide to add one more parameter to a number of sub-flows that have the same (or a similar) signature.
For example if I have multiple sub-workflows (let’s say 5) that handle emails in my process and I design them to work with a number of parameters such as toAddress, subject and body and I realise that it may be a better idea to also have a ccAddress and an attachmentList and so on there is no choice for me other than to visit each flow and manually add the same parameters multiple times. This is even more problematic when the type of the arguments is non trivial (the types have parameters).
One thing we did, was to create a custom c#/vb class library that we had to import into uipath as a separate package. Not to get into the weedy details on how we structured our library, but if you create a Customer type of object in your class library, that has properties FirstName, LastName, Address1, Address2, City, State, Zip etc. You can fill in those properties within your robot and just hand off the Customer object as an argument to whatever workflow you want to hand it off to, with all of the explicitly named property names. The additional plus, is that the intellisense within UiPath will allow you to expose those properties to fill, for the developer to know exactly what is required.