Build better products with our product team
In 20.10.x you can generate documentation at the project scope which normally would encompass your entire implementation. In the TDI, this is no longer possible as documentation is generated separately for each instance.If your implementation is large, generating total documentation will not only take long (it can take quite some time to process the data into pdf) but require a lot of manual clicks.I would like to suggest a similar approach to end-to-end execution package creation: end-to-end documentation. I imagine right-clicking a Deliver instance and then generating a pdf that contains all Ingest + Prepare objects mapping into the Deliver instance + the Deliver instance itself.One of the reasons for requiring this is that customers are required to show documentation for their reporting for the CSRD regulation. Collating this manually from what could be a large number of instances is a lot of manual work that is error-prone.Additionally this same kind of approach should be possible for Perspectives (see: ) and the documentation should also be available in the portal with a new user-access type to allow auditors to only see the documentation (see: )
With the 6814.1 release a new item was announced:A banner on the Home page will now let you know about upcoming system maintenance.I have a question and a suggestion:question: which Home page is meant? The Portal or the Support homepage? suggestion: could the notification also be sent by e-mail to the contact person in the Portal? That way there is less chance of maintenance being missed and causing confusion.
If you run the Database Cleanup Wizard you see all physical objects in the database that are not linked to active objects in the Prepare instance. Any “foreign” objects are also listed. This currently includes security tables generated in the database by Deliver instances with security applied.As these security tables are required and active parts of the implementation (just not belonging directly to the Prepare instance), they should not be listed here. This makes it much easier to avoid accidentally deleting physical tables that are still required.
Hello,When migrating metadata from one instance to another. For example, from Prepare Dev to Prepare Test. Then it is a certain version of in the Dev instance that will be migrated. Is it possible to see retrospectively which version it was that you migrated from.You can write down the number of the version from the source instance in a version note at the same time as deploying for the first time in the instance you migrated to. But if you haven't done it. How do you find out which version it was?It would have been an advantage if that information was automatically included in the version notes of the destination instance.Another question in the same category. How to see the version notes without closing the instance and then right click on the instance and select Open Version..?You might want to be able to see the notes while working in an instance.BRAnders
About Azure key vault: https://docs.microsoft.com/en-us/azure/key-vault/basic-concepts We - as well as many other - add signin information (either just username and password, or whole connection strings) to Azure key vault. Example user scenario: You have a script that need to connect to a database and fetch some data. As you are concerned with security you do not want username and password to be written in the script. Instead you use a secret, stored in key vault, to get a connection string that the script can use. You, as a user with access to keyvault, run the script. The script connects to keyvault and fetches the connection string and uses it to connect to the database. No password or username is floating around. If the username or password changes, the connection string is updated in the keyvault and everything continues to work. For Discovery Hub the scenario is mutch the same - so Discovery Hub should just store the reference to the keyvault and get the password (or the whole connection string) from the keyvault. If the username or password changes - it is updated in the keyvault - and Discovery Hub will continue to work - as it get's the username/password from the key vault. This would free us from needing to update username and password in Discovery Hub when needs to rotate or by other means change the passwords. Best regards, Trond-Eirik
Currently Fabric Lakehouse Ingest is not compatible with TimeXtender SAP Table Data Source.Please add compatibility :)
TX is awesome for removing a lot of the tedious work involved with traditional ETL, but there are still some things it can improve upon.... for instance, multi-select of fields in various cases would help speed up development a great deal. The following are a couple of enhancements I'd like to see: 1.) If I add a bunch of Surrogate Key lookups to a table, they all end up at the bottom. I prefer that all the Keys are at the top of the table, so I then have to drag each one up individually. A multi-select capability for re-ordering would be incredibly useful 2.) Multiselect tables added to the Business Unit or Data Warehouse and drag them to reorder all at once. This would make things much easier with a project that has many tables! 3.) Multi-select fields in table #1 and drag into table #2 to create multiple lookups at once. This one isn't as big of a deal, but would help save clicks. I think there are probably more places where multi-select makes a lot of sense. I'll add more to this post as I come across them.
I have some stored procedures that I would like to run independently, it would be nice to be able to run them as Execution packages.
Maybe this is possible, I know it was in the old version. It would be nice to be able to set different colors for DEV and PROD environments when developing
It is possible to create REST Endpoints for Deliver instances in TimeXtender. This is a really nice feature that makes it possible to share data in- and externally using API calls instead of directly to a database.The current implementation is backed by an IIS instance that uses a machine identity to authenticate to the database backing your Prepare instance. The main drawback of this is that there is one static login/user connecting to your datawarehouse, there are no options for more finegrained security than applying a token or oauth to the endpoint.In my experience many customers would consider using REST to deliver data to third parties. The third parties could be customers or partners that consume parts of a larger dataset. Naturally, this leads to needing to apply table/field or row-level security to filter down the data that can be accessed by a specific token/login.It would be a great addition if a single Deliver instance can be secured such that Power BI, Qlik, Tableau, REST endpoints can enjoy the same security possiblities. Apart from passing through Windows AD / Entra ID / user:pass (SQL Auth), the REST endpoint would need to be able to map database users to tokens / app registrations.The current workaround would be to create a separate Deliver instance for each data / security combination that must be delivered. This will quickly lead to an unmanageable amount of Deliver instances, or for customers to look for other solutions.
Microsoft implemented security in a different fashion with SSAS Tabular when compared with Multi-Dimensional. With multi-dimensional we had the database concept with multiple cubes... but a security role could be defined and used across all of the cubes in the database. Tabular is a bit frustrating in that we have to create a role and define role membership for each model. But this could be TimeXtender's time to shine!! :) I'd like to propose the ability to create a shared security role for the Semantic Models. A role could be defined with membership applied, and that role can then be linked to the models where security can be further defined. Essentially, the shared role would provide a centralized membership list rather than having to recreate it for each model. We have 7 models which are typically deployed and it can be a bit of a hassle to maintain membership lists in 3 environments for each role in each model. Yes, we can do this with AD Groups... most of the time. That capability doesn't really work with Azure Analysis Services, so it becomes very painful there.
The recent Portal update has moved some functionality around and renamed the place where you perform Environment Transfers to Migrations. Given that what you do there is an Environment Transfer and has nothing to do with Migrations and that there are actual migrations between release 20.10.x and 6xxxx, I would really like this page to be renamed: Environments or Environment Transfer.I can understand that from a technical back-end person's point of view you are copying data from one cloud repository to another which could be seen as a migration of some sort. But for the other 99.999999% of the world, this is confusing.
If a table in DSA or MDW has a lot of fields it would be nice to view it sorted alphabetic
Hi, During development it would be nice to have the option to fully truncate a History table, currently I believe the only option is to truncate directly on the SQL database?
If you have different Schemas with many tables in the Data Warehouse it would be very convenient if you can select all tables and views of one schema with just one checkbox and not to have to select every single table to have it in the perspective.
When checking the status of runs in TimeXtender you need to jump around between different dialogues to get to the bottom of an issue. The UX is rather lacking at the moment and could benefit from some quality-of-life improvements: please add the following fields/columns to logging dialogues across the products:Orchestration package:Orchestration package triggering a Job Job calling an Ingest Task or Package that sets a status Ingest Task or Execution Package triggering a status In case of a task, the Data Source the Task belongs to In case of an Execution Package: the instance (and Data Area) the package belongs to This would make it much easier to narrow down where to look in TDI after checking the logging from the Orchestration side, whether using Exmon DG client or browser or coming from a notification sent by Orchestration.Job:Orchestration package triggering a Job Job calling an Ingest Task or Package Ingest Task or Execution Package triggering a status In case of a task, the Data Source the Task belongs to In case of an Execution Package: the instance (and Data Area) the package belongs to Directly seeing the Task or Package setting a status, makes it much faster to jump to the place where action is required versus needing to read through a load of text to discover where to start looking will save a lot of time. Being able to click any of the fields and have the object open in the interface would really improve this. There are also some issues with the Job log dialogue itself:the dialogue is blocking, making it extra annoying to diagnose issues the error messages are cryptic: Ingest Instance <instance name>: The task <task name> CompletedWithErrors execution. It seems like there is an Enum name being passed directly instead of a descriptive stringExecution package:Orchestration package triggering a Job Job calling an Ingest Task or Package Ingest Task or Execution Package In case of a task, the Data Source the Task belongs to In case of an Execution Package: the instance (and Data Area) the package belongs to Steps within the Ingest Task or Execution PackageSimilarly to Job logging, being able to click a field and jump to the object would much improve the user's experience. As this dialogue is not blocking it is not as disruptive as the Job logging dialogue
The current Execution Log dialogue in Ingest is frustrating to use. The default display width and filling of the columns means you are required to widen the window to see if tasks failed or succeeded: “Completed” may look like a positive result when the opposite is true:Please change this dialogue so that all important information is visible without needing to reshape the window and columns. While this is an Idea for a specific dialogue, there are other examples spread throughout the tooling that should not require individual Ideas to tackle.
It would be nice to have the option to sort the tables alphabetically in the MDW.
Hi, It would be highly beneficial to have the ability to use variables in the TimeXtender Portal. I see a lot of potential here, but the most immediate advantage that comes to mind is as a solution for expiring or changing App registrations/client secrets. By creating a variable for the client secret and applying it across all Semantic Layer instances, you could easily update the client secret in a single location when it's about to expire.If anyone has other examples of how variables could be useful in the portal, feel free to share them below!Regards,Devin
Enter your E-mail address. We'll send you an e-mail with instructions to reset your password.