Hi @Pablito! I will work on this solution!
My impression was that one of the reasons why we have an in-memory Data Table is to create a
source-agnostic data structure.
When I put my project through the debugger, I could not see any visible difference between the Data Table loaded from the Excel vs. the one that was created using the “Build Data Table” activity.
In other words, the Dynamic forms binding mechanism should treat all Data Tables the same when binding regardless of how that DataTable was created and render the form.
A few questions:
I see that we are defining static column mappings here. So does this make it static binding then? If the Excel is too wide, then the Form design becomes labor intensive. I have Excel sheets that run almost up to column “AJ”!
What happens if the business owners decide to change the format/design of the underlying Excel sheet? (I’m in the middle of an Attended Automation design and one of our Excel formats changed midway between two meetings!)
We are going through two levels of translation - Excel to Data Table, and then Data Table to JSON - how will this solution work in terms of high-volume performance (Example: 65000 records with 40 columns say?)
Thanks for posting the solution with such clarity!