Build better products with our product team
As part of our offerings, we have a managed service where we have a set of boxes on one for the Ingest instance and TimeXtender Data Integration (TDI) application on one domain, but also have SQL servers on a different domain. We utilize a specific user for monitoring but because we haven’t added it into the “Roles” part of the Ingest instance in TDI, the permissions for the user keeps on getting removed. It would be good for the Ingest instance to look across domains.
When creating a tabular model, I might use the same DWH view twice. E.g. when creation a supply chain model, there should be a 'shipping location' and a 'receiving location' with both dimensions built on the same DWH view 'locations'. Once one of both dimensions is built in a tabular model, it would save time when one could just copy/paste the dimension and just change the name (besides the name, both dimensions are identical).
For TimeXtender SaaS packages the Execution Jobs show up in random order. I would suggest it to be in Alphabetical Order
Hi,I just discovered that when you have a table (let's say Table A) and another table (Table B) has a conditional lookup from Table A, then when changing the schema of table A won't lead to a red table nor a differential check of table B. Hence by means of differential deployment only Table A will be deployed, there where Table B also needs a deployment.I think it would be wise to fix this, since this can cause unexpected execution failures.Kind Regards,Devin
When creating a data source, a synchronize task is automatically created and you are prompted to set up a transfer task. Storage management tasks may be the most important task of all, and i.m.h.o should automatically be added to every data source or the user should get a prompt to add one. I have seen several clients now with endlessly growing ODX storage because they have no cleaning tasks and are unaware that transfer tasks are cumulative. Kind regards,Andrew
It would be great to be able to differentiate between different types of activity in the execution logging in Exmon Orchestration. At the moment you can only see complete runtimes of TimeXtender jobs, this includes some different types:Queue for ExecutionEngine slot Queue for ODX source slot Transfer Cleanse Etc.As discussed here: Allow multiple jobs to be run concurrently | Community (timextender.com) you can currently wrongly assume an Execution is slow when it is simply waiting for another Job to finish
So when working on the data sources in the portal, especially where we have multiple data sources. For example. I would have multiple SQL connections to different databases then different REST API connections. It would be good to either group them up by connection type and or client just like how the environment feature would be.This is an example of multiple REST API connections
In ODX Server, it is possible to have both a Display Name and a Short Name (DW_SourceCode). In Business Units, you only have a Short Name (DW_SourceCode).One of our customers decided to use Business Units instead of ODX Server in TimeXtender Classic because ODX Server in TimeXtender Classic will be phased out. Now, we need to be very creative with the data source names in Business Units, as we can only use a maximum of 15 characters.It would be great if we had the option to set both a Display Name and a Short Name in the Business Units as well.
Currently the data selection area in the Ingest instance, where you select which source to look in when you want to map data from the Ingest instance to the Prepare instance is fixed in size. This becomes difficult when you have more than a few sources. Please size the windows according to the number of sources and give the user the ability to resize this.
One of my customers operate with a virtualized data warehouse, i.e. their “gold” tables are in fact rather complicated views. They showed me today how they use kada.ai to establish data lineage (outside TX).It would be nice to have automatic mapping of view fields in TX … whether we develop it in-house or enter into a commercial arrangement with someone like kada.ai like what we’ve done with CData.It would also be nice to be able to override field mappings on tables, e.g. if a field gets updated by a script.
To improve the possibility to do impact analyses and make searching and finding easier I would like a funcionality withing the Perspective menu which is available when right clicking the table.this functionality should temporarily create a dynamic perspective on a table and show all the tables it is connected to in each of the data area's.I find it easier to wor through the perspective then through the impact analyses / data flow / data lineage.
When I am building Semantic Models, in about 9999 out of 10000 cases, I do not use the Prepare instance System Fields in the tables I add to a deliver instance. It would be great if those four fields are deselected by default in the field selection interface.Additionally having an option to turn the adding back on would, off course, be great.
Currently, it's challenging to determine if Pre/Pro scripts, Custom Data, or (Custom) Table Inserts are used in a table. I currently use descriptions to indicate this information. However, it would be better if these details were displayed using icons on the table, similar to how the Date table and Aggregate Tables are shown.This idea builds upon a idea previously proposed.
When you open the Ingest instance tab, all data sources are expanded by default. This can look messy if you have many data sources and tasks.You can easily collapse them by using CTRL + left arrow, but it would be better if all data sources were collapsed by default when opening this tab.
Hi,when looking at your MDW relations it is often useful to use the Relation Diagram, for instance from a Fact table, to see what tables are linked together.Usually you are interested in the tables linked to the table you are looking at as well as what field(s) are used to form the relation. In the current Relation Diagram, all tables are fully expanded and there is no indicator on what fields form the relation.My suggestion would be to add (at least) two improvements:collapse related tables by default - I want the table I am generating the diagram from expanded, all others collapsed. See the screenshot below for an example. Add a setting to influence this. add a visual indicator to fields involved in the relation. Ideally I would like to see the collapsed tables show only the keys fields. Add a setting to influence whether relation key fields should always be shown, all fields should be shown, or fully collapsed.
Dear all,Some clients have a lot of data. some of the data is from 2010 or even earlier.Each day my ODX or BU runs, it has to check ALL the PK's for changes and this takes a long time.I've created some scripts / SQL snippets and whatnot to just load the current year (current and last year) and then eventually bringing them together in the semantic layer.It has become quite complex for these big tables because I'm load two seperate tables, but want to make sure that they both get the same transformations and business rules and I do not want to maintain two seperates pieces of script (because mistakes are easily made).What I propose is a functionality which let you choose which data from the source or DWH tables to refresh / check in the incremental load and stuff and which data in the table to ‘archive’ and only load when explicitly asked for (full load, manual stuff). So in TX you are handling one table and one script and one custom transformation but are governing the current table with the data you want to reload or have checked every day and one archive table which contains all the history which does not have to be checked or loaded each day.
Dear Sir,I know it sounds like a dream:TimeXtender as a SAAS as a Workload within Microsoft Fabric.Workloads has just been announced by the Fabric Team, so it is now possible to bring Microsoft analytic partners inside the Microsoft Fabric environment.This sounds like a win 😉 win situation for everybody.Regards from Amsterdam,Arthur
As in the legacy version when releasing the project all tables that changed are marked dirty (red). When releasing in the new version (TimeXtender 6675.2) this does not happen, no tables are marked even though they have changed.
Please order the fields in Alphabetical order. We see that fields are now ordered randomly. Not Alphabetical nor as sorted in the source.This makes it hard to find fields in large tables
Currently it is not possible to use instance variables on a data selection rule, if the table comes from an Ingest instance.We use this a lot in TimeXtender Classic (with business units), to reduce data that has to be processed towards a Deliver instance. For example: only data from the last two years.Would also be helpful if variables can be used in Ingest instance itself, see Current workaround is that we hard-code most of them, which is not really what we want :)
Enter your E-mail address. We'll send you an e-mail with instructions to reset your password.