Build better products with our product team
Currently, if you’re using app registrations to authenticate to Azure components, you have to enter the app ID and secret for every instance. It would be much better if you could register these settings in a ‘global’ location in the portal and then map to this information from the instance settings pane.In the current situation, if you need to change an app registration or if the secret has expired, you need to update it in many different places.It would be great if we could just change it in one location, and all instances that use the app registration would be automatically updated.
When creating a Custom Measure in a Semantic Layer for Power BI XMLA endpoint one should use the Default endpoint. However here we cannot reffer to other (previously) created measures, which is a big disadvantage related to what is possible for Tabular endpoint. It would be great if one is able to reffer to other measures for default/ XMLA endpoints.
If you are running Jobs in the 6xxx release, you may encounter the situation where you want to stop a job. I tried asking X-Pilot how to do this and got this result:I have not been able to right-click on any Job, running or otherwise. As far as I can tell the Jobs API does not have any stop-job call. For ODX Server executions I can pick them up from the queue and stop them (if I can figure out the correct one) for DWH executions I think my only option is to kill an appropriate session in the backing database.Am I missing something here?
Currently you can decide which users get access to which TimeXtender instances from the Portal. This is a great way to secure your setup and declutter other User's interfaces. To be complete, this should also be possible for Jobs.You may not have access to certain instances and therefore get red Jobs in your interface:In my opinion the user should simply not have access to those Jobs, as they involve instances the user cannot access.
The new TX REST source is great: it is still complex, but easier to deal with than CData by far. There are some additions that would make it easier:When troubleshooting the TimeXtender REST connector, you need to hold on until you can get some data successfully extracted before you can use the file cache feature to see what is coming back and how it is being transformed. Unfortunately, you may not reach this stage and need to guess what the problem is. It may be as simple as having a typo in the URL being called (or Path in the parameters), but you do not have a log of the calls being made.As an example: I was dealing with an API that has a call structure like this: api.someorg.nl/api/v1/data?$expand=Something&from=2024-01-01T00:00:00.000Z&to=2024-01-31T00:00:00.000Z&<other params> . What I hoped would work was setting expand / to / from / other params up as Query Parameters and using dynamic values for the dates. This did not work because the URL in the Path then became: api.someorg.nl/api/v1/data which returned the metadata for the call without expanding the underlying structure (otherwise it worked fine).If I had been able to see the actual calls, I would have had an easier time diagnosing this. It is probably useful to have another option that logs the sequence of calls to a separate file so that you can avoid turning on file caching for large calls. If this log also adds the return status of the call, this would allow more fancy setups where an individually failing call in a set can be retried later based on the result.
The new TX REST source is great: it is still complex, but easier to deal with than CData by far. There are some additions that would make it easier:When setting up your source you are usually first focussed on getting the connection and extraction technically working. Subsequently, you will start formalising the setup. Currently, if you want to change the name of an endpoint in the TimeXtender REST connector you need to make a new endpoint and copy all the parameters. After this, you can delete the original endpoint. This seems a lot of work compared to allowing the endpoint name to be changed.
The new TX REST source is great: it is still complex, but easier to deal with than CData by far. There are some additions that would make it easier:I have a number of APIs to deal with that require flattening as well as dynamically generating the Path to include to- and from-dates. Apart from pulling regular extractions we also want to be able to request historical data and backload it. It would be really handy to be able to clone one of the REST endpoint setups and adjust a few parameters instead of needing to fill out all the fields.I know I can probably do something complex and create a manual table and a function that queries that to generate the list of to- and from-dates, but that is overkill if you just want to make some endpoints for a full year or similar.
My client, who is using 6346.1, is working with a “dev” and a “prod” DW instance but have several times accidentally worked in prod, thinking they were in dev. In version 20 and older there was a great way to visually tell in what environment you were in. You could use different user interface themes and accent colors for different environments.Unfortunately, this is not an option in 6346.1, since the theme color is not set at instance level.Please add this feature back if possible.
I’ve got a customer where we load 550+ tables into the ODX (ADLS Gen2). The data source is Dedicated Pool, and because of intermittent errors in Azure, a few tables fail every day. I use the On Demand feature in v21 in combination with retries in traditional TX packages to minimize the number of fails.It would be nice if we could use Exmon’s Orchestration platform to handle retries of ODX transfers at table level.
It would be helpfull for some of the client's that are working with TimeXtender Data Integration to have the ability to have the desktop version work with a older/newer version of the Ingest instance for around 2 versions difference. When TDI is installed on local machines instead of vm's it's hard to keep everyone's personal instance up to date. Or enable a silent install on the background!
Hello all,When TimeXtender Data Integration deploys the extraction of a data source via Ingest instance or deploys the extraction of a table in a prepare instance from the data lake, a pipeline with a Copy Table activity is created. The Copy Table activity is configured with the following default settings:The settings are shown when you check the progress of a running pipeline: Can we increase the performance by overriding the default settings set by TDI?Maximum DIU’s: we can set a value from 2 to 32 Degree of copy parallelism: we can set a value from 1 to 32Curious to hear if there are any developers that have experimented with these settings. I’m planning to do some testing for myself as well.
If we use a Provider: “Azure Data Factory - SQL Server”It’s not possible to use “Enable data on demand” it’s greyed.It’s necessary for us.
Dear comunity,I really want to swap my two instances (dev and prd) so my dev is on the left and my prod is on the right. Is this a setting in the portal or should I create an Idea?
It would be nice if XTend 2025 would be in Lisbon, Portugal: Nice weather Good food Affordable Gorgeous cityyour upvote is appriciated
Currently, when we want to transfer instances in the portal, every instance we want to transfer needs to be transferred separately. When you have a DWH and 20+ semantic layers, this means a lot of clicking. It would be nice to be able to group several transfers into someting like a job or a package or a set or similar, so you can do the transfer more easily.
Currently, the Azure AD data provider only does the 'basic’ calls to the Graph API getting the fields from Azure AD (Entra) that are in the standard result set.In some cases you want to get additional fields from for instance the user table like: Department, CompanyName, OnPremiseSamAccountName etc. This is achievable using the $select parameter in the API: Unfortunately, the Azure AD data provider does not support customizing the request through RSD files.It would would be very helpful when we are able to customize the calls through RSD files so we can access to all data from Azure AD instead of having to resort to a normal REST data provider to get this information.
Hiwould it be possible to have the customer name added to the title bar on the portal start page? For those who log in to many different customers in one day it.BRAnders
Hi team, When connecting to an API it is normal to need to define SQL/Data Lake friendly datatypes. They may differ from the datatypes at the API endpoint, if those exist at all. In the TX data source, there are currently two ways to automatically define this metadata: Default: use one page of data Perform exhaustive metadata scan: uses all data in the endpoint to determine data/lake SQL data-typesOften API's document their datatypes which may be different from the inferred datatypes, certainly with the ‘default’ setting above, as there may be unexpected values in the field later on. This leads us to use costly exhaustive metadata scans, or define generalist ‘override datatypes’ rules which often lead to excessively large datatypes to cover the highest possibilities.In the CDATA REST data source, we could use schema files to manipulate data-types on a per-field basis. It would be nice to have this option in the TX REST data source. The XSLT table builder seems like an appropriate place, since at that point we are defining the field metadata for the API. Kind regards,Andrew
We are preparing a migration from TimeXtender Classic to TimeXtender Data Integration. Recently we added the Deliver Instances in the TimeXtender Portal (28) and noticed that the start-up time of TimeXtender Data Integration desktop application (‘Verifying connection the instance’) increased significantly. It now takes about 3-5 minutes. As this moment we only created the development Deliver instances. Test and production still have to be added. We’re a bit worried that more instances would slower the process even more.
How about adding an option to the Authentication method of Prepare instances and add both System Assigned and User Defined Managed Identity for Prepare instance connections
In ODX, when you right click a data source and select [Set Up Primary Keys...], all tables listed under ‘Rules will be applied on these tables’ are ordered randomly.When you’re working with large databases and rules are applied on lots of tables, it is time-consuming to find a particular table and check the PK rule applied.
Enter your E-mail address. We'll send you an e-mail with instructions to reset your password.