Build better products with our product team
Hi,It seems that it is not posisble to resize the Custom Measure screen. It’s not a big deal, but still it looks like a bug. Especially when creating larger formulas it would be nice if we are able to make the screen larger.Kind regards,Devin
The introduction of the Qlik Cloud endpoint is a significant step forward. To further enhance this capability, it would be highly valuable to enable the automatic generation of Qlik master items (measures and dimensions) directly from the Delivery instance (semantic layer).Currently, it is already possible to define measures and custom fields within the semantic layer. Building on this, we propose extending the functionality by allowing additional properties to be specified for these objects, specifically for the Qlik Sense / Qlik Cloud endpoint.This would enable seamless creation and management of master items in Qlik, improving consistency, governance, and reducing manual effort.Proposed enhancement:Allow defining Qlik-specific properties on semantic layer objects: Measures: Name Description Expression Label expression Qlik Cloud: Master Item: Meaure dialog Dimensions / Custom fields: Field Name Description label expression Qlik Cloud: Master Item: Dimension dialog With this enhancement, master items could be automatically generated and maintained from within TimeXtender, eliminating the need for manual setup in Qlik and ensuring alignment between the semantic layer and the reporting layer. Measures and dimensions in Qlik are bound to a specific app. To better support this, I suggest introducing an additional Delivery instance configuration where the target Qlik app can be explicitly defined by specifying both the space name and app name.Upon deployment of this semantic layer, the system could establish a connection to the designated Qlik app and automatically create or update master items using the Qlik Engine JSON API, specifically the CreateMeasure and CreateDimension methods. The properties defined in the Delivery instance (such as name and description) would be used as input for these API calls.This approach would provide a more integrated and automated way to manage Qlik master items directly from TimeXtender, ensuring alignment between the semantic layer and the Qlik application while reducing manual configuration.
I use the ‘Show Uneven Mappings’ option a lot. But it is only showing the number of mappings in a table, when there is a uneven mapping in one of the columns in the tables. In some cases, I just like to see the total number of mapping in the tables, regardless if there are uneven mappings or not.
In case you have similar data sources which all have the same settings ofFilter Rows Set Up Incremental Load Set Up Primary Key Override Data Types Manage Query Tablesyou have to manually enter the details one by one. When you have a lot of rules to set up, it’s quite time consuming.It would be beneficial if you can easily copy these settings to another data source on the same or a different Ingest instance. I can also think of scenario’s where it would be beneficial to copy tasks between data sources/instances.
I'd like to suggest an enhancement for Timextender connectors (CSV, Excel, JSON, XML): the ability to load data incrementally. In my current setup, I receive new text files daily, and adding a new data area significantly prolongs the loading process. Since CData had it’s own way of incrementally loading text files I think it would be a great opportunity to bring a more efficient handling to the Timextender Connectors.
Copy of item in the TimeXtender Product Focus Group with some edits to summarize. In the world of BI tools, vendors are moving to SaaS solutions just as in other domains. Qlik has done the same and is focussing development on Qlik Cloud (QC). As Qlik is delivering nice improvements with respects to Qlik Sense Enterprise (QSE) and QlikView (QV) in this platform, customers are quite motivated to migrate towards this solution.Improvements of note that motivate customers to migrate are:Can host both QSE and QV apps in one solution Notifications and Alerts are included (costly expansion for QSE) Development of new features is done first here (if developments ever land in the older tools) Qlik Application Automation adds powerful features missing in the older solutions Integration of QDI features into the platformThe idea is of course that you use all the other tools in Qlik's suite and work entirely in the cloud, but you can also push data from on-prem. The options Qlik delivers on this topic are the following:Qlik Data Gateway (analogue to the Power BI Gateway). See: here . Coupled with using the correct APIs, this seems the easiest way to get support to work. This approach is also more performant than Qlik DataTransfer. Qlik Automation can expose REST endpoints that can be called from TX to do things like reload apps. Qlik DataTransfer allows you to create a DataSet in QC that can (on a schedule) reload data from a source (for instance the views created by a Semantic Model in a Datawarehouse instance's Data Area) into QC and reload an app. Qlik DataTransfer can also "watch" a folder and upload files (QVD, CSV, etc.) to the Data Files area and reload apps. Qlik DataTrasfer can also reload apps in QSE and move them to QC. Qlik APIs create/import/reload apps programmatically (with or without data) qlik-cli commandline tool to interact with Qlik APIs Qlik Sense Enterprise customers with QSE deployments can synchronise apps from on-prem to QC based on rules QlikView Publisher customers with QlikView Publisher deployements can publish apps to QC Within our active customers and in a lot of our pre-sales discussions with prospective customers we see a large motivation to move to QC. The question that then pops up is "How will TimeXtender support / work with Qlik Cloud?". Given that there are APIs that would allow programmatic integration with the platform, we feel TimeXtender should be able to support QC as a first-class citizen. This would mean that an endpoint for QC should be implemented that allows the generation of QVD or front-end apps for:customers with only QC --> use the APIs to facilitate this customers with QSE and QC --> use the APIs or use the existing QSE endpoint and programmatically configure the synchronisation capability to synch apps with QC customers with QV Publisher --> can set up the push to QC in their environment as there is probably no API for thisThe current QSE endpoint implementation would also benefit from a review: you point TimeXtender to a QSE node (QSE deployments can consist of many nodes) and TimeXtender talks directly to the Engine Service on this node. This may overrule any load balancing defined in your QSE deployment: you might have reload nodes set up to perform heavy lifting on appropriate hardware but TimeXtender may be talking to the central node of a cluster causing reloads to happen on the wrong node.Qlik publishes APIs to programmatically work with their system and allow any rules set up in the cluster to be applied. Given that QSE can work with QC, it stands to reason that the same approach QSE takes to push apps to QC could be taken by TX.Taking this approach means customers will use Semantic Models and automate from within TimeXtender instead of setting up something manually that will likely pull data from a Datawarehouse layer instead of using a Semantic Model.One of the most powerful points of Semantic Models is being able to define them and push them to whatever tools you support. Needing to bypass Semantic Models for tools likely to be very common is unfortunate. This also makes it easier for customers to transition between BI solutions without needing to re-engineer or to feel that effort spent developing Semantic Models was wasted in retrospect. What problem is this solving?There is no direct support for QC in TimeXtender, work-arounds are much more manual than was the case before Power BI Premium Capacity support or require QSE next to QC and are therefore more costly.As Qlik fleshes out Qlik Application Automation and tools like Qlik DataTransfer, customers may decide that the added benefits of the things QC does will outweigh the automation TimeXtender would bring if you then need to manually integrate the two.TimeXtender has the (Shared) Semantic Layer as a major component of the solution, it would be strange if QC customers would then need to bypass this. And this becomes especially tricky if things like row-level security (Section Access) would then require complicated work-arounds. The current QSE implementation bypasses QSE handling appropriate for clustered environments meaning that deployments with larger Qlik installs need to change the approach and do more development in Qlik instead of in TimeXtender than would normally be required. How is this problem currently solved (inside or outside of TimeXtender)?In the case of QC: Customers would need to deploy Qlik DataTransfer to pull data to the cloud (time-consuming manual process) or monitor a folder with CSV exports (not efficient) or keep a QSE instance (costly) running to be able to push to QC.Another option is to pull data from TimeXtender into QC (potentially through Application Automation) if the database is reachable from QC. This way of integrating data is generally more robust than using Qlik DataTransfer, but does require the database being reachable from outside and needing to write or push script. How does this idea improve the business value for NEW and EXISTING customers?New customers would expect support for the current platform offered by one of the largest BI vendors. Not having to worry about the chosen BI solution or the migration between them would be a great relief.New customers with large QSE deployments would not need finicky workarounds to get their load balancing to work. Existing customers considering migration would not need to worry about how to deal with this and would be able to fulfill the wishes of business quickly. Existing customers would also not need to re-engineer parts of their implementation when they decide to work with QC instead of QSE.For QSE deployments, working with the proper Qlik APIs would make it possible to make much more use of the features provided by TimeXtender and bundle more of the orchestration there instead of needing to dive into QSE. Provide references or explain why this approach is best practiceWe have tried out the architecture where QC and Qlik DataTransfer were chained together to push data to Qlik Cloud (in PoCs). This is in no way a "pretty" process, especially compared to the ease with which you can work with the currently supported endpoints. We have also tried out the Qlik Data Gateway approach and this works well, though currently in a pull scenario.Being able to orchestrate as much of the data chain from source to end-product from TimeXtender is a great USP that should be strengthened further.
Currently, TimeXtender only supports deploying apps (.qvw) to a specified space, while QVD files are stored in the underlying “QVD folder.”It would be a significant improvement if the app deployment (.qvw) could remain unchanged, but the QVD storage location could instead be directed to a dedicated Data space, as defined in the portal’s Data space setting.This would provide better alignment with governance and data management practices.
I’m sure this is already on the roadmap, but we of course need the new Salesforce connector to support incremental loading.
We need data selection rules in our new Salesforce connector. Salesforce has “implied” relationships between e.g. quote line and quote header, and this opens up for a variation to our traditional data selection rule logic. Example…Assume the quote header table contains a country field. Our traditional data selection rule logic allows us to filter this table, e.g.:Country IN (‘AU’,’NZ’).The quote line table does not contain a country field but it’s still possible in the TX REST API to filter the quote LINE table using a quote HEADER filter. In the TX REST API, such a query would look like this:SELECT+Id,Name,CurrencyIsoCode+FROM+QuoteLine+WHERE+Quote.Country+IN+('AU','NZ')We select lines from the QuoteLine table based on a filter referring to the Quote (parent) table, and then Salesforce does the rest.
We suggest enhancing the script generation by allowing a customizable section before the generated LOAD script. This would provide developers with greater flexibility to insert and manage their own logic independently of the autogenerated content.
In the execution view it would be nice with an extra column that shows which schedule groups the package is part ofIt would also be nice if you could you this view as a static view on a screen whitout keyboard and mouse.But when you have to many packages to be shown on a screen you cant see the last packages. So would it be possible to it automatic roll the list when there is to many to show?
In Data Integration, it is possible to define multiple endpoints within a single deliver instance. In practice, all of our endpoints are intended to be accessed through Power BI. By assigning different roles, we can grant end users access to a specific endpoint.It would greatly benefit us if tables within a deliver instance could also be assigned to an endpoint. This would prevent the need to create a large number of deliver instances, which may also result in duplicated tables across those instances.In summary, in addition to assigning roles to an endpoint, we would like the ability to assign specific tables within a deliver instance to an endpoint.
We need a way to roll a solution back to a prior version of Data Ingest and Data Integration. I’ve spoken to several partners, and there is a bit of “TDI upgrade anxiety” at the moment.In the olden (v20) days, I just backed the project repository up but we can’t do that in the modern cloud world … roll-back was in those days a simple matter of removing the upgraded project repository and restoring the backup.If anyone has a solution that overcomes “upgrade anxiety”, then please share 👍
Pasting SQL (especially from AI) is pretty common, I think.When pasting queries or logic into custom views or calculated fields, mapping fields manually is repetitive. An auto mapping button could analyze the SQL and automatically match fields based on names, schema, and database, allowing users to review instead of setup mappings.For smaller queries this might not add much value (just double click the field). Not a big fan of heavy view usage myself but for views and larger transformations this could be a useful feature.If the SQL already runs without explicit mapping, the relationships are implicitly defined, so an auto‑map should in theory just surface that logic rather than change it (correct me if I’m wrong).
A simple text field for version control requires manual input, which leaves room for incomplete entries and adds extra effort.An automated suggestion would pre-fill release notes based on actual changes, reducing the risk of missing or low-quality input and making it easier to trace issues in deployment history. With a small set of predefined settings, versioning rules and numbering could be applied consistently. Even as a small feature, this could be very useful to rollback or distinguish between minor commits and larger changes (such as migrations), based on all changes since the previous deploy. I would expect this to look something like this, but I assume the SEs will come up with something better:Automatic draft generation: pre-filled release notes based on all changes since last deploy Editable suggestion: users can adjust before finalizing, but never start from empty Version numbering rules: configurable (e.g. incremental / semantic / date-based) Traceability: direct link between version notes and actual implemented changes
When you synchronize a data source and there are some problems, or the metadata changes are not to your liking (NoSql sources can be problematic), it would be good to have a choice to accept the metadata changes when you get the synchronization results before they are applied to the project. In some situations, all the tables are removed because of a data source issue and you have to close the project without saving and open it again.
Hi there. Currently we get the long error messages when something fails in Orchestration executions, which tends to need some encryption at times to understand. However, in the new Portal I get this gloriously understandable error message: Is there any chance as of now to get these new error mesages as the email notifications? Best regards,Darri
Enter your E-mail address. We'll send you an e-mail with instructions to reset your password.