Skip to main content
cancel
Showing results for 
Search instead for 
Did you mean: 

Fabric Ideas just got better! New features, better search, and direct team engagement. Learn more

A better way to debug a multi-pipeline architecture

Let's say you got 2 or more pipelines called from an orchestrator pipeline.  And let's say you have up to 80 activities per pipeline called (so the assumption here is 'a lot' and no trivial sequencing) with multiple uses of Copy Data activity.

 

The following would be nice to have:

 

1. enable logging in the Settings tab of Copy Data activity without needing to provision beforehand some ADSL Gen2 storage account

2. having a inspector attached to any activity and being able to inspect the activity and/or data flow state changes during debug time

3. being able to step in/out (just like in Visual Studio) with all the relevant parameters with their values nicely displayed in a user-friendly manner to the side or bottom or top of the screen

4. being able to create variable and parameter watchlists

5. having a pane that shows which activity is accessing/modifying which variable during debug time

6. having a pane showing what is happening when multiple variables are accessed in parallel and activities are  running in parallel

7. showing a snapshot of top or tail of a SQL result set for any Scrip or Copy Data activity.

 

 

and so on.  You get the point.  Basically the idea being to have the necessary and most useful IDE tooling integrated with the Fabric pipeline design surface so that we can more easily and quickly drill down into what might seem strange behavior due to a potential bug before immediately rushing to open a new support ticket when it might not be necessary.  

 

This idea stems from the fact that too much of what's going on under the hood is transparent to the end user. And since users do not necessarily have the time (I sure don't) to get lost in the 100s of pages of documentation to sleuth around in order to surmise some sort of theory as to why stuff doesn't seem to work, not to mention that the documentation itself might not even be up to date yet, this idea might help the more advanced users perform root cause analysis faster and more accurately, and thus provide more useful feedback not only to support, but also the community at large.  

Status: New
OSZAR »