Build better products with our product team
Consider the following setup: PRODUCT-table in ODX PRODUCT-table in DSA PRODUCT-table in MDW When highlighting one of the tables it would be nice to see somewhere central (top bar or bottom bar) what table is actually highlighted when scrolling through fields. It's easy to loose overview when scrolling through a long list of fields or tables and it would therefore be nice to see somewhere which table actually has the focus atm. This would also reduce the risk of errors in case one did an unwanted click somewhere by accident.
For execution packages there should be a WarningStep with possibility to get Mail, In many cases when you are having issues with connections to source data, you need to use ex continue with existing data. In those cases the success message contains info about the warning. But we should not be relying on external systems to filter and monitor success messages for Warnings, to get notification about these events. So I suggest a WarningStep. A step when the Execution package has been able to be completed, but it contains warnings.
Would love to be able to group the tables in the table lists (Data Warehouses and Business Units) by their schema, in an hierarchical fashion.
It would be great to be able to run data profiling on tables from within Discovery Hub.
Would like to have automatic NULL handling available on either source or table level. An automatic function (optional of course) that would cast NULL values to either blanks, 0, etc., depending on datatype.
I would like to have differential check as the initial step in environment transfer, and from that step get a selection of objects I would like to transfer. In my opinion one should not transfer objects still in development to the production environment, which one is forced to do in the current setup. The production environment should be a clean production environment!
The ability to load an execution package with parameters, would be a way to limit the number of business unit. For instance I use the NAV adapter, but need to build several BU in order to separate differenct companies pr country. Having the functionality to execute a package with a "where clause", in this case the dw_account field, would eliminate the overhead.
We are using the Navision adapter extensively with several accounts in Navision/BC. It seems that the Nav adapter uses the Nav Account Name to reference the objects in the Nav database. We are now looking to update and change the Account Name of some of these companies in Nav. We see that it creates issues with incremental tables, history tables and snapshot tables when a company changes name in Nav/BC. So a change of the company name in BC will update the value in the Company table and then rename all the table objects to reflect this change. This would add duplicate records in both incremental, history and snapshot tables. In BC they now have a unique company id field called "Id". So even if the company name changes, this id will be unchanged. A better setup of this adapter would be to use this id as the DW_Account on all objects in TX. Then it doesn't matter if the company name changes in Nav/BC. TX would use this id internally on all objects, but reference the table object with the value in the Company.Name field.
Hi, We are using the Google Analytics connector to pull large amounts of data from the Google Analytics API. We also use the Data Source feature with Additional Connections. This lets us pull data from several Google Analytic Views with a single implemented Data Source and Query Tables. We pull data from seven Additional Connections and it would be really good to be able to enable and disable some of these from time to time, in order to pull data from only one of the Connections. These data pulls uses GA data limits and runs for quite some time on large amounts of data.
Your manual states that the import and export feature is useful "if you want to reuse parts of a project in another project." But this feature only allows for import and export of the whole projects, and not parts to be included in a new project. Selection templates partly solves this for Data Sources, but it does not solve the issue of moving objects from Stage/DSA into another project.
It should be possible to universally set compression settings to ON. So that all newly created objects are automatically compressed. Today we have to manually set this on all new objects.
A possibility to remove all but the latest version of a given project. => Gives faster opening of projects.
Need the ability to put params into the ODX data source settings. For example. to support incremental URL query strings that need changing values.
When you swap a table over to incremental loading manually, it would be really helpful if you got a quick popup dialog box with the following options: 1) Add source table DW_TimeStamp as an incremental field 2) Pick my own incremental field (taken to the incremental field selection pane) 3) Skip picking an incremental field for now With 1) as the default selection. Business unit tables, of course, would only get options 2 and 3. I think this would be a really nice little quality of life improvement that manually setting up incremental loading much faster and easier, and avoid the common problem of an error on deployment when no incremental field has been selected.
The new visual layout of Discovery Hub is very handy! One quality of life improvement that might help speed routine use of the tool would be to list the execution packages under the Execution Package node in the Solution Explorer, and allow them to be executed or dragged to the execution queue from there. That would save having to open the execution package tab unless you wanted to actually make changes to the packages.
No account yet? Create an account
Enter your E-mail address. We'll send you an e-mail with instructions to reset your password.
Sorry, we're still checking this file's contents to make sure it's safe to download. Please try again in a few minutes.
OKSorry, our virus scanner detected that this file isn't safe to download.
OK