Build better products with our product team
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.
Instead of using PowerShell script to create a new file for each execution, it would be nice to append a unique identifier (like timestamp) to the filename using the CSV endpoint.
Hi team, The tool for generating end-to-end perspectives and packages dynamically works well, but would be more powerful if the option to exclude creating ingest tasks when generating for a deliver instance. Use Case:Several delivery instances need tables dynamically included in a process Most delivery instances use many of the same dimensions Solution: create an execution package at Prepare with include steps of the ‘Dynamic’ end-to-end perspectives generated from the delivery instances. Then generate ingest tasks from the consolidated, merged prepare packageAlways creating a separate ingest tasks for each delivery is cumbersome, and makes many tasks containing the same tables.
What it’s the reason to this message:It would very useful to be able to do it.
Hi,I was surprised that I couldn’t find this suggested as an idea yet, but it would be very helpful to have “Deploy only modified” selected by default, or at least to have the option to set this as the default at an instance/project level.I think most of us have forgotten to enable it at least once, resulting in every table deploying and executing.Kind regards,Devin
It would be very useful and time-saving if we were able to merge/combine two Perpare instances in the Portal.We are in the process of re-structuring Prepare instances for a client, and two of their subidiary companies’ data need to be put in the same database, which means two instances need to be combined into one. Both have the same data area names, which have the same schema names. For now we're unfortunately stuck with cloning one instance and integrating the other by completely rebuilding it. This will take a lot of time in an already time-consuming rework of the client's data estate.For this idea, the most basic version would allow us to merge instances with matching area's and schema's, where the objects within them could (hopefully) simply be put together.Maybe a more advanced workflow could even be possible, allowing us to map and rename the areas and schemas while performing the merge, like this: Object Source Instance Source Area Source Schema Target Area Target Schema 1 Prepare A Staging st DSA dsa 2 Prepare B Staging st DSA dsa 3 Prepare A Report rp MDW mdw 4 Prepare B Report rp MDW mdw
I've encountered this a few times where I need to change an underlying source fact table because of a design change in the development of a semantic model. Currently, you have to add a new table, configure all relationship again and create all measures again. This requires a lot of manual work that is prone to errors. Being able to substitute a source table with another table or a view with the same field names could be very useful.
In the Ingest you can look at execution logging and specify in which timerange this can be done. Your Ingest instance will be limited to 90 days or less of logging but the calendar picker used allows you to go back much further.It would be better to limit this to the range of data available in the repo.
It would be very helpful to auto-create a folder for each instance when syncing TDI in the TimeXtender Orchestration tool. Certainly in a multi-environment setup (dev, uat, prd), where objects with the same name will appear multiple times in TX Orchestration.
Hi TimeXtender Team, I'd like to propose a new feature for Exmon MDM that would be more time efficient when working with large amounts of duplicate tables.Currently, when the same table is duplicated across multiple projects and categories, any structural or configuration changes (such as adding/removing columns) must be made individually in each instance. This is time-consuming, increases the risk of inconsistencies and is less thorough. Feature Request:Introduce the ability to apply changes to all duplicates of a table simultaneously or some kind of tool that realizes which tables are duplicates and can make changes to the tables.Benefits: Saves time and manual effort. Ensures consistency across MDM environments. Reduces human error and improves maintainability. We believe this could be a valuable improvement for many organizations using Exmon MDM at scale.Short term workaround:We'd like to know if there is a possible workaround to make the implementation of changes less time consuming or if a workaround can be made available in a short timespan.Thanks for considering this request, and please let me know if more details would be helpful. Best regards,Vincent van VendelooAccordis
Hi team, We've encountered that JSON with a nested array inside takes the lowest node of the XSLT generated by the table builder down to the level of said array, instead of keeping it at the desired base node. When running the generated XSLT in a table flattening endpoint the output does not reflect the actual data structure and number of rows of the input. Is it possible to implement a change in the table builder so that a nested array no longer "breaks” the data and keeps the base node at the "original” level? See the related for more detailed information. Best, Luuk Bouman
Most of the time, a field in a view will be called the same thing as the field it pulls from in the source table. Adding an automatic map feature based on Name would make using Map Custom View Fields a lot easier and more friendly.
It would be a great idea of having the option to add a global parameter to the client secret in PowerBI refresh packages in TimeXtender DG. It is a lot of manual work to change it in every package when the secret client expires.
Hi, It seems not possible to close the below projects with the dropdown button. Looks like a bug, would be nice if this will be fixed.
Hi, It would be helpful to improve the error message of TX Orchestration in the email when a Package fails, mainly for PowerShell scripts. For example when a Powershell script fails, we receive an email from a package that failed, with an error message:"ERROR: Databricks job encountered an internal error” However, when we look in the portal log information, it provides a lot more information for debugging. Including this already in the email saves time and would greatly assist in debugging and identifying the source of the issue. Regards,Devin
CData connectors can generate a row number in their sources which can be extracted as a field. If you are converting from CData to TX native sources, this can be an issue if that field has been used as a primary key. It would be nice to have the option of including this kind of metadata as a field:row number path + filename of source file (useful for aggregating sources)
As you can see in the image it’s crazy to find the table. It must be sorted:
It would be usefull to see the include fields in the screen:
Currently, when using the TimeXtender Dynamics 365 Business Central – SQL Server connector, it is not possible to leverage Azure Data Factory (ADF) and Integration Runtime (IR) for connecting to this data source.This limitation means the connector can only be used when there is direct access to the Business Central SQL Server database. However, in some customer environments, direct access is not available/allowed. In such cases, the only option is to use the Azure Data Factory – SQL Server connector. Unfortunately, this alternative lacks key features provided by the Business Central connector, such as option fields, translations, and SIFT tables.It would be highly beneficial if both connectors could be combined to enable ADF/IR support while retaining the Business Central-specific features.
Enter your E-mail address. We'll send you an e-mail with instructions to reset your password.