Build better products with our product team
At this moment it is not possible to use Azure AD Integrated Authentication on MDW instances. You can select this setting in the portal but it is not working in the Desktop Client.More and more customers want to use AD integrated authentication (MFA) in their applications. Azure Active Directory enables you to have single place for user management instead of different SQL accounts for each SQL server/database. It is also recommended by Microsoft to use AD Integrated Authentication. One reason is that this makes it possible to trace different user activity on the SQL server. This is not possible when all developers use the same SQL account when connecting to the SQL server. Please make it possible to use Azure AD Integrated Authentication on data warehouse instances.
Hi,The new feature in 6429 to group instances in environments is excellent. Copying in the portal also works well. Especially with the ability to select data warehouse instance mapping when we transfer semantic models.This brings up a couple of new possibilities.The first concerns semantic models. it would be an advantage if you could choose to keep the roles you set up in an instance. They often become different in the environments. A little check box in the transfer dialog that gives the choice to keep roles and row level security setup in the destination instance.The second idea concerns the application. It would be great if you could choose which environment you want active and visible in the application.BRAnders
I can’t see it’s possible to set up instance specific data area roles where some end users can access the PROD data warehouse and other end users can access the DEV data warehouse.The feature is available (and very useful) in v20 but I can’t see it in v21.
Hi team, For some of our clients it would save time and administration if we could create our own roles to assign to users, instead of individually assigning access to instances in a solution. For example, some business users might want to be able to check logic in our ‘test’ SSL (deliver) instances, but need no access to the data warehouse or other SSL instances in ‘dev’ or ‘prod’. When there are many instances, it would be much faster to define a role, select the instances that the role has access to one time, and then assign the role to users as needed. Currently, we would need to open each instance in the portal and add each user. The user list for each instance is managed independently. Kind regards,Andrew
We’re currently investigating a migration from v20 to v21. Our project has 25+ semantic layers, each having a development, test and production version.At this moment all semantic layers for development are created in the TX Portal. Its seems that we have to repeat these create actions twice: for the test and production environments. It would be a huge timesaver if we can clone these for the other two environments. We only have to alter the PBI workspace name.
Hi,It would be great if it were possible to copy parts of one instance to another.If, for example, you could be presented with a list of the Perspectives that exists in the source instance and be able to choose which of them you want to copy with their contents to the destination instance.It would make it easier, and more risk-free, to have continuous deployment/copying of parts of a solution when several developers work on different areas in the same instance.BRAnders
Hi, We would like to have the ability to export data to an API in another cloud service from Timextender's API server Endpoint. I think this feature was called Push or reverse ETL in Xpert BI.BRAnders
For larger deployments the current Portal runs into some issues:instance icons are only useful when there are low number of them strings for names are truncated if they are too long you cannot filter you cannot sort there are no mouse-overs showing the full description or nameImagine a larger TimeXtender implementation:3 environments 2 ODX 6 DWH 100 SSLYou get a huge page of icons that is hard to work with and makes it easy to make mistakes. If you did not come up with a good naming conventions you might have:Development - SSL - SalesManagement Development - SSL - SalesMarketingThe UI will truncate the names and you might have two ‘Development - SSL - SalesMa' instances, but you only want to promote the Marketing one. You can assume the sorting is alphabetical, but I would not bet on it.These kind of issues could be solved by:Adding a list/table option for displaying instances making it possible to see all attributes and make more effective use of screen real-estate Make it possible to sort by any attribute (i.e. Environment first, name second, etc.) Make it possible to filter the instances displayed. If I am pushing Dev to Test, I don't want to see Prod instances Add mouse-overs to get a full display of attributes in Icon mode
As the Exmon products are now part of the TimeXtender suite, it would be good to have the status of Exmon cloud services added to https://status.timextender.com so that users can check whether a service outage on the Exmon side is the reason something is not functioning.
While it is great that you can easily copy instances around, it is also quite error prone.We have 30+ SSLs, all having a dev, test and prod instance. When promoting an instance in the TX Portal, it is too easy to make a mistake and copy Dev SSL A to Test SSL B.It would be nice if you can somehow link instances over environments, so that the default copy instance action is transferring Dev SSL A to Test SSL A.I want to emphasize that the current possibility to copy instances freely around is still a powerful feature (eg. when you need to copy prod back to dev), but a default source-target setting should prevent users from making mistakes.
Currently there are multiple places where logging is stored. For instance, if an execution fails, you probably have to look in one or more of these places to see what precisely went wrong:Exmon package logging Emails from Exmon should contain more detail. For example, a job that is ‘Completed with errors’ lets Exmon send an email saying that the job as a whole failed to run without any further info. TimeXtender Data Integration Job Logging Ingest Instance Transfer Log Prepare instance/Deliver instance execution package logIt would be great if all these logs can be analyzed at one centralized place, and have a more detailed view than some current logs, like:
When performing instance transfers in the TimeXtender portal, there are some checks you need to do beforehand:Make sure the involved instances aren't opened by developers Make sure there are no executions running or soon to be running on involved instancesFor the first check, there is no current functionality to directly check this. There are a few workarounds:If all developers log into specific VMs to run TimeXtender Data Integration, you can check Task Manager to see which accounts are logged in (and forcefully sign them off in the worst case) If you have Team development enabled on Prepare instances, you can use the Work Items feature for each opened Prepare instance to see what users have active sessions If your developers run TimeXtender Data Integration from their own laptops or you are transferring Deliver instances, there is no foolproof way to check. Transferring while people are actively working in instances involved in the transfer can lead to problems, so it is critical to be able to check beforehand. For the second check, you want to be able to see what is running and what is upcoming on the schedule. The only way to see this is to look at the Jobs monitor to see if anything is running at all, and then find out which instances are involved and subsequently which Execution Engine / ODX Service this is coupled to. You can make this easier by having naming conventions, but this becomes difficult for larger environments or transfers.If you are running TimeXtender Orchestration, it is slightly easier to manage but you are dealing with two different applications.I propose adding a centralized overview of all Instances with the following attributes:Environment the instance belongs to Execution Engine / ODX Service the instance is running against Whether Team development is enabled or not Which users have active sessions on the instance Which users have a lock on an instance Which Job / Tasks are currently running on the instance When the next Job / Task will be triggeredIn addition, it would be wonderful if some actions could be applied:Disconnect a user's session / send a message asking to disconnect Stop a currently running Job / Task Pause the scheduling / prevent Jobs / Tasks from being triggered
When an ODX table is mapped to a DSA table you can now only use column filters. It is not possible to set a (custom) table filter.example:You can filter on "date GREATER OR EQUAL 2023-01-01"but you can't use a filter like "field1 + field2 > 1000"or a filter like TRIM (field) = 41 is not even possible.
Possibilities to structure the defined jobs in TimeXtender would increase the user experience. For instance when having a multi-environment (DEV, TEST, PROD) it would be good to separate the jobs in folders for each environment. The suggestion is therefore to allow the user to create job folders where the user can organize the created jobs.
Hi,It would be nice to be able to choose the culture (language) when the semantic model is added to the portal. This applies to the endpoints Power BI and Tabular.Can you choose the right culture, in our case sv-SE, then the sorting order will be correct in tables. Also for the letters Å, Ä and Ö which now are sorted as A and O respectively.BRAnders
In our portal we have several customers set up, and each of them require unique email addresses.This means that we have to ask our IT team to set up aliases for each of the customers, e.g. richard.ray.cust1@…., richard.ray@cust2@… etcI am suggesting a single email address that can be used across customers whereby you would login as normal and then be presented with a drop down of the customers that you have access to, plus of course the top level “Parent” portal where the customers are created.
Snapshot fact tables are common in many data warehouse projects. Often the data that they store can not be re-loaded as the dw does the snapshotting and is it's only storage. I dont think there is a bulletproof way to do this currently in TX in terms of performance and data safety. There should be dedicated settings for snapshot tables. I've used incremental loading but that's not a safe way and I always take a backup of any snapshot tables before a deployment just to be safe. I've also tried using the history setting but I found the performance to be really bad for big tables as the unnecessary comparison logic is such an overkill for what needs to done. My suggestions for how this setting should work: 1. It should make sure that the valid table is never ever truncated or dropped (unless with a flashy warning dialog asking you to confirm)2. You would set the snapshot value field.3. It would do a delete for the incoming snapshot value before inserting the dataset. Extra----4. It's features could be expanded to have configuration for defining the snapshotting value based on the exection time or a parameter, having it do a daily/weekly/monthly snapshot. 5. It could do a daily snapshot but then have a setting to only store the latest along with week-end/month-end snapshots.
Dear Sir,I know this sounds crazy.I would like to merge multiple projects iin TX version 20.10.51.64, bring them together into one single TX project.I know this is a feature of the migration tool, when migrating to an instance in the new TX SaaS version. That is great, I need same functionality in version 20.10.51.Is that possible ? Is there a way to do this ?Hope this makes any sense. Regards,Arthur
Hi,Our team is currently trying to limit access of our developers in projects that they do not work on. Everyone is currently a Data Estate Admin portal, so they can see every Instance/Data source connection. We tried to test some roles out by having someone only have the role of Company Admin. They now can correctly only see the Instances to which they are assigned to and the Data source connections that are mapped to the Instance. If they click on the Data Source connection, the user gets directed to the Homepage.We would like the developers to have role in which they can also see/edit the Data sources connections to the Instances they have access to. Is it possible to achieve that with the current TX Portal? Thanks in advance!
I believe the title is self-explanatory.Please add Multi-Factor Authentication for the Exmon portal and desktop applications (Exmon DG and Exmon DM).
Currently, you can use a maximum of three environments in Exmon (if enabled in settings). The environments have fixed names: DEV, TEST, and PROD. These names do not always match the naming conventions used by customers.It would be great if we could rename these environments.
Enter your E-mail address. We'll send you an e-mail with instructions to reset your password.