Build better products with our product team
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.
Currently, the incremental load setting needs to be configured at the transfer task level in the Ingest Server. Since Orchestration is now the best product for scheduling reloads in TimeXtender Data Integrator (TDI), it would be much easier to set this option at the package level within Orchestration.This change would allow you to define a single transfer task for a data source in the Ingest Server while maintaining the flexibility to execute that task as either a full load or incremental load using Orchestration.
Hi all, a question from me. We have a customer with a lot of very large tables. We would like to filter these tables in our dev and test systems, to be able to develop and execute faster.Is there any way we can filter tables in the Ingest conditionally? So we can add filters that will not be transferred to production on promotion, or filters that have a condition so that they will only be applied on non-production Ingest instances?
Using jobs is going to be a deprecated feature so we are using Exmon Data Orchestration.However we can not see a process queue or stop executions from out of Exmon.Apparently this can only be seen if you have an additional paid license but this ticket is to make that availble in the default license that comes along with TimeXtender.It is strange that one hand we are forced to be using Exmon but then not have access to the main functionality (starting and stopping processes) to do orchestration properly.Hope you agree on this.
Enter your E-mail address. We'll send you an e-mail with instructions to reset your password.