Build better products with our product team
Hi,it would be nice to have the worksheet name as a data column.Best regards,Peter
I’ve created a dynamic perspective based on an schema.If I try to create an execution package to execute all the tables in that perspective, it’s not possible.Is it a bug?
Hi team, In many projects, I need to integrate legacy historical data with current updates — essentially allowing TimeXtender to continue tracking Type 2 Slowly Changing Dimension (SCD) changes as if it had always managed the full history. Currently, this isn’t natively supported. To make it work, I have to either misuse incremental/history features, write custom scripts, or use a mix of both. In SQL, this problem isn’t that complex. But in TimeXtender, the logic becomes tricky when you're sourcing data from a pre-existing SCD-2 structure.Logically, you’d want to: Load everything initially as Type 1, Then filter for IsCurrent = 1, And apply your Type 2 fields accordingly. But this doesn't work cleanly in TimeXtender, since the natural/primary key definitions are different for full-history and current-only records. Scenario 1: Import Static History Once + Load Only IsCurrent Going ForwardInitial Run: Use Valid_From as part of the primary key. Map Valid_From and Valid_To from the source to SCD_From and SCD_To in TimeXtender. This seeds the full historical record set. After Initial Run: Switch to using only the BusinessKey as the primary key. Add a data selection rule like IsCurrent = 1, or point to a separate current-only source table. Now TimeXtender tracks changes using standard Type 1 and Type 2 logic on new data. This approach is straightforward and works well for historical seeding followed by real-time tracking. Scenario 2: Sync Ongoing SCD-2 Source (Still Changing Slowly)Initial Load: Use BusinessKey + Valid_From as the primary key. Subsequent Loads: Use only BusinessKey as the primary key. Then apply logic based on the Valid_From date (within BusinessKey): Case A – Valid_From <= last known SCD_From: Update Type 1 fields if values have changed. Insert a new Type 2 row if a Type 2 field has changed. Case B – Valid_From > last known SCD_From: Option 1: Order rows by Valid_From and map to SCD_From/SCD_To. Option 2: Take the most recent record only, and apply Type 1/2 change logic as needed. This scenario is more complex and requires careful handling of edge cases like overlapping dates or reissued statuses.Use Cases When the source system has incomplete SCD-2 tracking. Migrating from a legacy DWH that has historical data TimeXtender needs to continue. Blending multiple systems, where each handles history differently. Replacing a legacy system with built-up history by a new system that doesn’t track history.
Hi TimeXtender CommunityI’m exploring how TimeXtender integrates with Microsoft Fabric, specifically OneLake, for a project we’re planning. We’re looking at using Apache Iceberg as a table format for datasets stored in OneLake, with data in Parquet format. I’d like to understand if TimeXtender currently supports native read and write operations for Iceberg Parquet datasets in this environment. If this isn’t supported yet, are there plans to add native Iceberg support in future releases, and if so, is there a timeline for when this might be available?Any insights into how TimeXtender handles Iceberg datasets, or workarounds for integrating with them in Fabric, would be greatly appreciated. Thanks in advance for your help.
Is there any way to stop the Test connection when it’s hanging?
A common pattern in staging Data Areas is to rename fields when you are denormalising data. An example you may remember from TimeXtender Core Training is renaming the Name field in the ProductModel table to be ProductModelName as you do not have the table context if you start looking up data.In the Ingest instance we now have the Metadata manager to avoid needing to remap things if we have a name change between input (source naming) and output (Ingest structure). In the Prepare instance, this is not yet available. If I rename a field and change the mapping (move from ADLS Gen2 Ingest to Fabric Ingest for instance), a Smart Synchronize will not recognize that the ProductModelName field was originally the Name field. This means you will then need to expand the Mapping folder, highlight the mapping and drag the correct Name field from the rightmost column onto the ProductModelName field in your table.It would be much better if TDI kept track of source item name and target item name separately and used this information to make the Smart Synch smarter. This way it could know that the ProductModelName field was originally called Name in the original mapping, the new mapping also has a Name field and can therefore automatically be mapped. If there is doubt, the same kind of interface we are used to for other synchronisation resolutions can be used to show the user what TDI is going to do and indicate any areas where user input is required.
The new enhanced TimeXtender connectors for CSV and Excel allow aggregation of similarly structured files.We need an additional field when loading aggregated files: the URI (full path and filename) so we know where each record is coming from. Sample use case: If filenames contain the date of the file, the latest file’s records can be found by parsing the URI.On that note, it would also be nice with a row number field. For aggregations, it should restart at 1 when a new file is loaded. DW_Id might (?) be OK for single files but it’ll be a bit finicky for aggregated files.
It’s very important at our company that master data is reviewed with 4 eye principle before being published to production. Would be very beneficiary for us to use the tool for better use if 4 eye principle was incorporated - instead of having to make functions for each table which can easily break
Hello, We have a case where a customer runs the ERP system Visma Net.Visma Net has positioned itself towards the same size of companies as, for example, Business Central.Visma Net have support for the Scandinavian countries and the Netherlands. Maybe more. According to Visma's website, there are 2,000 companies that use Visma Net.Here are some links to swagger documentation etc.:https://integration.visma.net/API-index/https://community.visma.com/t5/Forum-in-Developers-Visma-net/Visma-net-ERP-API-Developer-Portal-Startup-Guide/m-p/544710/thread-id/2965https://developer.visma.com/api?use-cases=Bookkeeping&api-technologies=RESTA Data source would be a good start for a blueprint, and Visma is a Nordic company just like TimeXtender. And the demand for European alternatives seems to be increasing in these times
To enhance the credibility and long-term value of the TimeXtender Solution Architect certification and TimeXtender Pre-Sales certification, I propose the implementation of the following measures: Introduce an Expiration Date for Certifications Each certification should have a defined validity period—e.g., two (2) years from the date of issuance. After this period, recertification would be required in order to maintain certified status. This ensures that certified professionals stay current with the latest platform updates, methodologies, and best practices, thereby maintaining the quality and relevance of the certification. Assign a Unique and Verifiable Certification ID Every issued certificate should include a unique, traceable ID. TimeXtender should enable a verification mechanism through publicly accessible verification page where stakeholders can confirm: The validity of the certificate The identity of the certified individual The issuance and expiration dates Rationale and ValueImplementing these changes would contribute to: Increased trust from clients and partners relying on certified professionals Stronger incentives for continuous learning and skill development Differentiation from competitors who do not offer the same level of certification governance Greater visibility for TimeXtender into the active certified community over time
A lot of customers are trying / using Fabric Onelake and want to connect to Delta Parquet files.We have a few customers on 20.10 and would like to do the same.Would it be possible to add support for the TX Onelake Delta Parquet provider to TX 20.10.Link to the existing documentation : Link to a previous question on this topic : Best regards,Peter
Since the update for datasource synchronization to the metadata manager, all tables from the datasource are now displayed in the ingest table selector. Previously, only tables that were part of a transfer package were shown.When a datasource contains a large number of tables, it's difficult to scroll through and find the relevant ones. Please add a filter to the table selector to display only tables that either contain data or are part of a transfer task.Additionally, consider visually distinguishing these tables — for example, by using a different icon or making the table name bold.
With this option it’s possible to view the version notes of an instance:It would be very useful to be able to edit the “Version note” field in the next screen:
Hi,When using specific license of Orchestation it is not possible to stop an execution via the process queue: There is a workaround for this by using: https://ENVIRONMENTNAME.exmon.com/dg/Ti/QP/ProcessQueueBut would be great to just have a button for the process queue in each license.
In the creation of “Custom Fields” in a SSL table it is possible to use fields and measures from other tables, but they do not appear on the screen and cannot be used as parameters, and obviously do not appear in the linage.
When successfully migrating an instance in the TimeXtender Portal it would be nice to receive a confirmation message with a timestamp directly in the Migrations view. Now it looks like this, and the information is only available in “Admin”/”Activities”: Current view Sometimes I have to go there and check wether I did actually initiate the migraton or not, A confirmation message, as suggested below, in the view instantly after migration would facilitate this monitoring:
It would be a lot more manageable to be able to assign access rights on Environment level instead of instance level. Especially for larger customers which have a lot of developers and instances per environment.
Currently, when adding the same data source to multiple ODX instances, TimeXtender requires each instance to use a unique short name. This often leads to awkward or overly long naming conventions just to differentiate between otherwise identical sources.It would be much more user-friendly and scalable if TimeXtender allowed reusing the same short name across different ODX instances, with an option to group or filter them by instance. This would allow: Teams to avoid inconsistent or verbose short names like CRM_EU_ODX1 vs CRM_US_ODX2. Short names to remain meaningful and clean (CRM, ERP, etc.), while clarity is maintained through instance-level organization. Better alignment with how distributed teams manage similar data sources across environments or regions—especially in global setups or OTAP environments that still need access to production data. This improvement would help reduce clutter, improve readability, and make large-scale data environments much easier to manage.
Hi,As a part of Blueprint generation for Prepare Instance, can we have a selection of specific Data Area instead of entire prepare instance. Regards,Kaustubha Pimplikar
A really handy feature is the possibility to change a source provider to allow for the evaluation of alternatives. If the portal does not know how to deal with a parameter, it tells you and allows you to decide what to do with it.It would be great if there were buttons/links allowing you to copy the entire parameter contents to the clipboard so that you can easily paste them into their destination field in the new connector.As an example: if I want to evaluate the SAP ADF connector, I can use an existing SAP Table connection to base this on. One of the parameters I then need to work on is the table filter list. This can be a very long field which is annoying to copy paste. Additionally in this specific case, the original field separates tables with spaces, whereas the ADF connector expects each table to be on a new line.
Within TimeXtender, you can assign different colors to each OTAP environment. This helps distinguish between the different environments. It would be great to add this feature to Data Quality and Orchestrator within both the desktop application and the portal.
Many customers have ‘stacked’ sources: many instances of the same source (BC / Dynamics, etc.) that in the TX Classic release can be easily handled with Additional Data Sources. Here you define the data selection in the ‘master’ source and have the same data extracted from the underlying clones.In TDI you would currently need to have separate sources for each and use the, very restrictive, mapping set feature to auto-map tables with identical (field, data type) structure to the same Prepare table.The possibility of cloning data sources and using connection strings / json settings, makes the creation of many of the same sources easier. There are still two issues remaining however:Each additional source needs the data selection set and maintained separately If one of many ‘stacked’ sources updates by adding or changing metadata, this will break mapping setsThe first issue could be solved by allowing to clone Metadata Manager settings from one ‘master’ source to secondary sources with the same structure. It should be possible to do this before the initial metadata sync task is automatically triggered. In this situation I would expect that the Metadata Manager shows you:What is successfully found in the target from the source mapping What was not found in the target from the source (maybe due to a schema name difference, etc.) What exists in the target additionally to what is in the sourceIf in future one of the sources updates to add a new field, it should be possible to clone this across easily once the other sources also get this field. I expect you would mark one source as the ‘master’ for its set, and others as receiving mapping changes. The second problem occurs when there are deviations between data sources that cause Mapping Sets not to work. If one of the sources has an additional field in a table with respect to the others, it will not work. In my opinion a mapping set should be an intersection of common fields, not an exact match. This way new fields added won't break Mapping Sets already existing and the feature becomes more widely useful. If a source in a Mapping Set no longer has a field, just drop the mapping and warn the user.
Hi,Please consider adding Ingest Instance version control. This would make it possible to recover deleted data sources. A data source can have many hours of work put into it in the form of query tables, incremental and filtering rules, etc. which is deleted beyond recovery if the data source is deleted.
Enter your E-mail address. We'll send you an e-mail with instructions to reset your password.