Build better products with our product team
The new inline script feature in Fabric notebooks is great. Inline sits right after data cleansing, just before the data frame gets persisted (append or overwrite, as applicable).But sometimes we need scripts that are executed either before table notebook execution starts or after it has finished. An example of the latter is when something needs to be done on an entire incremental table and not just the delta data frame.This can be achieved for example by dummy tables with inline scripts and a lot of manual object dependencies (to get the execution order right), but that’s an inelegant solution with a high risk of missing required object dependencies.Furthermore, dummy tables count towards the painful Fabric workspace limit of 1000 items.It would be good if we, in addition to the current inline scripts, could also have pre- and post-scripts as wrappers of the main notebook. This would handle object dependencies / execution order and we wouldn’t have dummy assets that count towards the 1000 items limit. The pre- and post-scripts should become part of the main notebook even though the developer most likely won’t benefit much from any notebook context (as opposed to the current inline script feature).
It would be really user friendly if you could move the steps in the hierarchy up and down afterwards and behind the scenes there would be a dynamic sort column that would represent the order that is shown in DE.Then you could let the user control the sorting in DE and it would automatically be like that in the reporting layer. Now I usually create a Sort column and the user has to manually fill in values for each step created to control the order.
It would really time efficient if it would be possible to import a hierarchy. It takes a lot of time to create hierarchies using the current function where you have to create all steps manually and all rows manually, one row at a time.If we can get the hierarchy on a certain format like this and import it
We need a feature in Lakehouse solutions whereby we can easily trigger a full load of an incremental table. At the moment, I go to the Prepare Lakehouse and delete the table in question (just the valid table, not the _X tables).
It’s not possible to reorder inline scripts (Prepare Lakehouse) … the last script added stays last.I’m a bit OCD-ish and find it easier to navigate large projects when items/assets are sorted alphabetically 😀Please enable script movement / reordering in the Inline Scripts node (like everywhere else).
Many TimeXtender users find the current way of dealing with data type changes quite unnatural to work with. There are many cases where you want to change the data type in Prepare (separate from the painful way to deal with typing in Ingest).A user's instinct is to change the type of a field through ‘Edit field” but this will lead to errors usually. I.e. changing a string to a datetime. Needing to define a new field with the target type and setting up a transformation on that field is a lot of work. You would expect to be able to define a CAST to deal with this ‘between’ Ingest and Prepare, or between Raw and Valid.My suggestion would be to allow a cast to happen between the raw and valid table. This should both support straight casting, int to varchar or similar, and more complex ones like using (try) convert to change a text field into a date. It would be great if you could set up pattern-based text-to-datetime conversions from the UI instead of needing to write sql. It would also be good to wrap conversions in try and be able to specify a fallback value.One of the main reasons for doing this in Prepare vs. Ingest is that data type conversions are expensive in Ingest and obviously less flexible.
When migrating an instance it would be helpful to have an automatically filled in version note on the destination instance. Something like :“migrating <instance type> <source instance> <version> to <destination instance> <version> by <username>”
It was a bit difficult to come up with a good title for this idea, but I think it could be a very valuable feature. Let me explain what I mean.In many cases, you build dimension tables in the MDW/Prepare instance that are used in almost every SSL/Deliver instance. Examples include dimensions such as Date, Item, Customer, and so on.When you add a column to one of these dimensions and want this column to be available in all SSL/Deliver instances, you currently have to add it manually to each one, which can be a lot of work.It would be great if we could define a kind of Master Dimension and link the SSL/Deliver instances to it. Whenever something is added or changed in this Master Dimension, the update would automatically be applied to all linked SSL/Deliver instances.
The number of project versions in TX gets large quite fast. With thousands of versions, the TX application and projects tend to open and execute slower for each version.Cleaning out this log without having to delete all versions would be nice. Either by allowing deletion of a selected number of “old versions”. Or even better, set a “project retention” setting to keep only versions for the last 12 months or so.Today this process is cumbersome with multiple steps like:Backup the repository database Open the project and export it to XML Close the project Create a new empty repository Run a set of SQL queries on the repo in order to copy Environments and Global Databases.Drawbacks of this is:You loose ALL versions Manual step is prone to errors Risk of repo becoming corrupt if something goes wrongSince the TX applicaton and executions runs a lot slower with big repos, this cleanup process should be included as standard functionality.
Currently, the CSV datasource has no option to move files that have been processed by the Ingest, to a different location. For example, we would like to move loaded files to a ‘Processed’ folder after loading them. In the old (CDATA) datasource, this was possible.
Microsoft only allows 1,000 items in a Fabric workspace.We need a cleanup tool for Fabric-based solutions, just like we’ve got the SQL cleanup tool for SQL-based solutions.
In TimeXtender Classic (v20.10), it is possible to add additional connections. This is a very powerful feature that many of our customers are using.It is especially useful when you have many similar data sources (such as NAV/BC or Exact software). In our customer base, it is often the case that there is a separate database for each country, region, or office. Some of these customers frequently acquire new companies or open new offices. In such cases, these data sources can easily be added to the main data source connection. The transformations then also apply to these sources, all the way up to the semantic layers.In TDI, we do not have this option, even though it is a very powerful feature. For some of our customers, this is the only reason holding them back from migrating from Classic to TDI.A possible workaround in TDI could be to clone the data sources and adjust some settings. However, in that case, all tables still need to be mapped to the Prepare instance. You then have two options:Manually map all tables: You can use smart mapping, but it still requires a lot of work. Use mapping sets: This can be a very powerful feature, but in the current setup, you need to manually synchronize all mapping sets for all tables.An option to synchronize all mapping sets at once could also be a solution. Alternatively, and perhaps preferably, it would be great to have the ability to create additional connections in TDI as well.
I would like to be able to view the request and response of a API data source connection endpoint.Maybe this is possible, but i can’t find it anyware. You know like i the network tab of the webdeveloper tools in any browser or Postman/Bruno.
Not sure if this is a bug or not. But when I have a package A with the update threshold of 23 hours, so it should be shown as yellow on the process map unless it hasn’t ran for >23 hours. But if I have that package as a part of an Object group and some package within that package groups has ran recently then this package A is marked as yellow.So it’s like when the package is part of an object group it overwrites the settings on the package level. Probably the reason is that the idea is that all of the packages within the object group should run at the same execution.We have cases where for example we have an Object group with maybe 10 tables that run every night. Then we have more specific incremental loads that run part of a process that includes maybe 4 of those 10 tables, then the rest appears outdated on the process map even though it is not.
Hi! Current state:When using orchestration , it's possible to link and synchronize a process with a process map. This is a great feature for monitoring and controlling a process!Problem:However, when building an overview of dependent processes (e.g. two or more processes that run within the same schedule), it would be very helpful to link multiple processes directly to a single process map. This would allow us to monitor and control them together from one central place.Workaround/ Solution finding:Our current workaround is to create an extra process that contains the individual processes as sub-steps, and then link that wrapper process to the process map (without scheduling it). While this technically works, it becomes messy over time and requires maintaining the same logic in multiple places. This increases the risk of errors and makes orchestration harder to manage.I did notice that within the process map builder, there is an option to add a process map to another process map (so nested maps). However, the task status indicators (success, warning, failed) do not reflect the actual status of the nested process map (see screenshots down below). Because of this, it's not reliable for monitoring or controlling multiple processes from a single map.Feature suggestion:Managing multiple processes from a single map would be easier if one of the following changes were implemented: Allow linking multiple processes directly to a single process map. Nested process maps reflect accurate status indicators for monitoring and control. Screenshots:Web interface (deployed):Nested map is always (even with failed tasks) a single green check. Redirects on click to the nested map.Editor view:From editor view it seems like it should show a list of indicators connected to the nested map.
It seems notebook views do not yet support CTEs.They do support nested sub-queries but that conversion can become quite messy if a CTE is used in other CTEs.Pretty please 👍😀
I have a data quality check that is monitoring SFTP folder to see If there is a new file (It would be great if I could use that to trigger processes So for example it run this DQ test every 5 minutes and when it returns an exception I want to trigger a package/process in Orchestration? Currently it’s giving me an “error” if there’s a new file.
Most ODATA metadata feeds include standardize column data type definitions for the endpoints. Currently, TimeXtender ignores this and interprets datatypes itself based on the first page of actual data, or the entire set of data when exhaustive metadata scan is enabled. This is unnecessary and leads to datatype errors and/or extremely long import-metadata times. TimeXtender should just interpret the metadata from the ODATA feed, or at the least, allow us to define datatypes for ingestion ourselves in ODATA/REST.Example metadata ODATA feed:Example TDI interpretation:
In SSAS Tabular 2017 there is a new measure property, "Detail Rows Expression" to define a custom drill-through DAX query. Similarly, there is a property for the table, "Default Detail Rows Expression". Having these properties configurable within Disvoery Hub would be great. Details here: https://www.sqlbi.com/articles/controlling-drillthrough-using-detail-rows-expressions-in-dax/
It would be nice to get a data visualization like SSMS Lizard to view the data of tables and views.Preview Table Preview View
Enter your E-mail address. We'll send you an e-mail with instructions to reset your password.