Import Datatable Schema on Invoke Workflow or Activity

When we invoke a workflow, or use any kind of activity that requires a Datatable as In argument, it would be nice if somehow we can see what are the schema desired (if any) for the datatable.
Similar to what is possible to do on another RPA Tool, (Whose name is something related to a colorful geometry).

Hi @lucas.stern,
Could you give me example of this. It will be easier to understand what you mean.

PS. I like the way you told us about “you-know-who” :smiley:

Hi Pablito.
Well, it’s hard to to explain that without the a print directly from the tool.

Imagine you developed a workflow, and that workflow has an OUT argument of type Datatable, you invoke that workflow inside another one, and now has to get that argument and save to a variable (UiPath does not work with pointer and references it does?). After thatm you want to check a value of a specific collumn of that datatable, but, if you don’t know the Collumn Name beforehand, you have to enter the child workflow to check , or get that name while debugging.

What I’m suggesting is a way to know the schema of the datatable when invoking another workflow, or activity, giving us more speed when developing.

I hope I managed to be a little more clear now, but ask if anything…

Hi @lucas.stern,
Sure, I think you have explained it good :slight_smile: I will push your suggestion to our devs for review.

1 Like

@lucas.stern the DataTable schema is not available at design time. I understand where your request is coming from and how it might help, but consider the scenario where a DataTable could have any schema (e.g. reading from a random CSV file). That information is simply not available until you run the workflow.

Yep, I Agree and totally understand.
Its a nice feature to have, but we are talking about a whole different architecture. Currently I am typying my datatable schema inside the annotattions of the variables, this way I can see what to expect when using it as a Library inside a process.

But yet, i guess this is a discussion that could be more focused in how to properly document your code (talking about a developer perspective, and code-reading techniques)…