Entity - Efficiently reduce number of arguments

i_planned
collections
studio
r_18_2
entity

#1

Hi All,

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 :slight_smile:

Regards,
Andrzej


Create a custom object
Option to create complex datatypes
How to create Custom Objects
Create own variable types (classes/data structures)
Project Level Variable
Loading 'singleton' like project level objects from Config
#2

Hi Andrzej,

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.

Andra


#3

Hi Andra,

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?

Regards,
Andrzej


#4

I think this feature must provide:

  • reduce the number of arguments
  • reduce the number of variables
  • autocomplete to avoid typos

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.


#5

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 :wink: ) and how we could possibly adjust our current designs to make the switch in the future as easy as possible.

Regards.


#6

Hello Andrzej

To be sincere, in most of the cases, good design can save you passing around large amounts of arguments between two workflows.

It is rare that you need to have the same data so comprehensibly in two places in large amounts
Usually, there is better data flow organisation that can save this situation

Regards
Alex


#7

@Alex_Dragoi: Can you be more specific about “good design”? Yes, sometimes many parameters need to be transmitted top-down through multiple workflows.


#8

@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.


#9

Oooh, did Alex just diss the Andrzej? :stuck_out_tongue_winking_eye:


#10

Duplicate by Thorsten.


#11

nah this is the original … since that thread is considered a duplicate of this one…


#12

Yeah, everyone is waiting for Entity or some form of global variables since 2017.