Build better products with our product team
To send the notifications it would be useful to use a html template with substitution variables.
It would be very useful to assign aliases to the tables to see it in the tablet’s tree.Some time it’s names are very cryptic (MARA, KNA1, KNVV,…)It would be useful too, sort it in folders.
ContextWhen starting on a new TimeXtender implementation, you are usually making a lot of transformations and changes to tables. If you are new to TimeXtender, or coming from a 20.10.x deployment, you may not realise that all tables pulled from ODX (in ADLS) to DWH instance will automatically be incremental. This means that after an initial Deploy & Execution any subsequent changes will not materialise unless you force a Full Reload of the table.In a running implementation, where you are changing less at the same time (usually) this is slightly less annoying. It is still needlessly confusing in my opinion. ChallengeNew users and users that are used to the “old way” may not realise that the Automatic setting for Data Extraction on a table means that they will be incremental. The fact that this is the case is only visible if you expand mappings and notice the I on the mapping icon. This can result in surprises: either nulls for new fields for existing data, or old values for modified transformations. This means that you really need to cover this in a training context before you start any deploy and execution actions, substantially frontloading complexity.If a table has multiple mappings, some of which may not be incremental, it becomes even more confusing. Current solution / work-aroundCurrently you either need to change the Data Extraction setting of tables to Full from the default Automatic, or do a “Review Tasks” followed by selecting the full load steps required (I am not certain whether always selecting all options for a table is always safe, you may need to specifically select the required steps). If you are doing a more complex change where you want to Deploy and Execute multiple objects, this becomes tedious Proposed solutionMake it explicit when Automatic makes a table incremental by giving a visual cue. There are probably three states:Full load (none of the mappings are incremental) Incremental (all of the mappings are incremental) Mixed (at least one of the mappings is incremental)I'm sure someone can come up with nice pixel-art to make clear icons.In addition it would be good if an optional warning can be added / extra options can be added when performing a Deploy & Execute after a change. Something like “This table has incremental mappings, not all records may reflect changes” and an extra checkbox in the Deploy & Execute menu “Perform full load”. This should be an option in the TimeXtender settings so that people who are used to walking uphill to school in a snowstorm can do things the hard way.
Could another option be created for deletion in History tables. Either the option to push all the data from the lastest active record into the tomstone record or a field [SCD Last Active Record] that acts like an indicator that this record was the last active record before the deletion. This way the last active record is easily selectable. In some of our sources we don't have a reliable enough date we can use to match with dimensions to find the correct surrogate key. We therefore want to display the latest active record of a dimension.
Add execution logs on semantic models. This way we can see the Execution Overview Log and we can easily check how much time it takes to execute the model and the rowcount of the tables.
A possibility to remove all but the latest version of a given project. => Gives faster opening of projects.
Currently, it is not possible to hide a measure in the semantic model (SSAS). It's especially useful when creating a custom measure that references another measure that you don't want to be visible .
It would be great to be able to run data profiling on tables from within Discovery Hub.
It would be a great help to have logging of all steps of the cleansing stored procedure (start / end time). We have tables with a lot of lookups, but sometimes some of those lookups take a lot of time. This logging would help us to identify the slow lookups and do something about it.
Hello TimeXtender Team, we have a lot of queries regarding the connection with the Theobald IS DELTAQ functionality, this is a much needed feature on DiscoveryHub! Unfortunately the way through SSDT is often a rather daunting option.Is there already a plan to implement this or all Theobald IS functions in the DiscoveryHub? Regards
It would be much easier to order the steps in the execution package, if we were able to drag and drop the objects around.
Is it possible in the Multi-Environment to transfer just one Project Perspective. This could be really usefull when you are developing with multiple persons one project. Not all Project Perspective are at the same time ready to transfer from development/test to a production server
It would be really nice if we could make the email notification an execution package uses dependent on environment. Right now, if you want to vary say, the recipients of a success or failure message based on environment, you must create a separate version of each package for every environment you have. If this was combined with Ulfar's suggestion here, then the entire execution package concept would be hugely streamlined. As it is, it's not unusual to need at least one execution package per environment per business area, often leading to having to create and maintain dozens of mostly redundant execution packages. I think implementing these two solutions would be a huge "quality of life" improvement for the tool.
Just like we have Business Functions for the unfamous "Mind Destroying Expressions" (MDX) ;-) https://support.timextender.com/hc/en-us/articles/210439443-Business-Function-Library It will be pretty cool to offer the same library parametrization support for DAX that's available for MDX on the OLAP MD semantic model.
I loaded some records from a view which obviously is built off of a table. When I looked at the records in the destination table, the DW_SourceCode field had the value 'View'. I was expecting the underlying DW_SourceCode field from the source table. Response from TX: The current behavior of custom views is to simply populate the destination table DW_SourceCode with the value "View." Unfortunately, you can't map any field onto DW_SourceCode in the destination table, but you can add it as an additional custom field. This feature would be nice for tracking and being able to query the underlying source dataset.
There currently is not any built-in functionality to execute a process on failure of an execution package. In fact, one of our clients has had to build an external process to watch the log table in the repository database to look for a failure and then execute other processes. I think a simple solution to this would be to allow for Running a Package upon Failure. That execution package could execute stored procs, outside SSIS packages, etc which would allow for various types of interaction, including sending short SMS Text Messages of a failure, creating a trouble ticket in an IT Management System, etc.
Since the business unit settings dialog is rather poor on options I would like suggest some additions. When using the BU as an ODX it would be good to have it automatically organized. By having the options to always sort tables alphabetically by default and group tables into folders by schema, that would give better visibility in large projects in my opinion.
A source identifying field is needed in a setup where the ODX is in simple mode and there is a need to merge data from multiple tables into a single staging table. If there is no source identifying column in the tables we are forced to remove simple mode from these source tables to be able to add a custom field with a fixed value to distinguish between the data in the staging layer.
Today we have the option of an automatic prefix on the data source that concatenates the data source name with the schema name. Having the option to only prefix with the source schema name would be a nice option when building a clean ODX where you have a schema for each data source. That would allow tables with the same name in different schemas without also having the data source name in the prefix.
It would be very useful if you could add a default data row for a dimension table in a similar way you add custom data but without getting a custom data table and where you can set DW_Id = -1, which is common. The input ui could be in the same dialog as the custom data input or a separate dialog. The ways to do it now are either: 1. Creating a post-deploy script for each dimension table where you do SET IDENTITY INSERT ON and then an insert statement with all the values. 2. Adding a new custom field to use as a surrogate-key column, persisting dw_id from staging and inserting default values with custom data option. Numer one is very un-DWA and boring to maintain and number two is somewhat going around things to get the desired resaults and having a custom table for each dimension table just to hold the default value is maybe unnecessary. Attached image is a quick mockup :) Best regards,Andri default-values.png
Enter your E-mail address. We'll send you an e-mail with instructions to reset your password.