Build better products with our product team
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.
The current flow in Ingest Metadata Management is to ask the source what it contains, which will either get exact field types from DBMS-style sources or run a sample from many file- or API-based sources. In the latter variant, this is often a frustrating process: the actual type of a field may only be apparent in a record past the sampling threshold, or doing this might be slow.In the CData connectors, you would specify types in .rsd. This was annoying, but would at least result in what you needed. The current functionality leads to issues.Oftentimes we actually know what the type is beforehand and want to simply specify it instead of needing to load a lot of data. An example is an API that has a field that is actually a numeric(p,s) but mostly manifests as an integer. If there are more than one of these type of issues at the same time, it may be impossible to design a filter that allows for a one-shot metadata sync. Another example is a CSV file where Ingest detects nvarchar() fields where I know they are varchar(). As nvarchar() are a wider type, the resource consumption is much larger.I believe the flow is currently something like:source type → Ingest inferred type → (Override type) → Ingest storage type → (Implicit cast from Ingest to Prepare) → Prepare storageI would like to see a few extra options with respect to metadata:let me change types as delivered from source in the Metadata Manager. I am not sure there is value in setting the Ingest inferred type and then overriding after, so I suggest directly setting the Ingest storage type turn off type evaluation entirely. I might want to do this once and then keep up manually or just input the types myself, depending on the source. This means a metadata sync would only need to ask for tables/views/fields and should therefore be faster allow adding a filter only for metadata sync so that I can limit the amount of rows to evaulate for typing separately from transfer task filtering
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
It would be very useful to get a new Advenced option “Previous version..” in:Custom Views UserDefined Functions StoreProceduresTo select the version that we want see to see it or to replace.
It is more useful to sort them so you can find them:
Hi,In Process Orchestration it would be nice to have the option to setup notification mails (success and failure) on Object Groups and Processes.Now this is only supported on Package level.It might also be useful to have this option on each step / object of the object group.Gr.Peter
Currently, there is no option for incremental loading in the TimeXtender REST API. Most API's support partial loading with filters in URL params. We have multiple customers that are facing very long load times because all dat has to be fully loaded every day, while this is not necessary because most of the data has not changed.So, it would be very helpful if we could set up incremental loading the same way that this is done on rdbms data sources, so pass a date(time) or numeric value for incremental loading using REST parameters.
Given that is now possible to edit Semantic Models in the Power BI service, I would suggest to change the differential deployment check that TDI performs on these endpoints, so the data structure of the model is compared against Power BI instead of (or next to) the repository.Currently, some issues arise through the following steps:A Semantic Model is changed by some business user in the Power BI service (tables, relationships or measures are changed, added or deleted) Differential deploy in TDI will then compare the endpoint against the repository to determine if changes were made. There are no changes detected (because they were made in Power BI and not TDI) so we get the ‘No changes to deploy’ window. Going through with execution in TDI is subsequently ‘succesful’ even though entire tables can still be missing in Power BI, and we would have no way of knowing this is the case.The workaround currently is to always force deploy an endpoint as this re-creates the Semantic Model in Power BI conforming to the definition in TDI. And of course making sure that Power BI workspace members never edit the semantic models. But I still believe TDI should handle the possibility with more clarity.So the idea is to change the differential deployment check, so the semantic model definition is compared against the actual target model in Power BI alongside the repository.Secondly there should be a failure notification when executing a model with missing tables in Power BI.
User Defined Functions were recently added as a feature of Power BI Semantic Models.UDF's can be created at Semantic Model level and reused in Measures and Calculation Groups.Adding this in TDI SSL's would be helpful in defining logic and calculations in a single place.Additionally it may be useful to have DAX snippets for these UDF's so a companies’ definitions can be re-used across SSL's in the same project.
Enter your E-mail address. We'll send you an e-mail with instructions to reset your password.