export to native qlikview format from 3rd party solutions
We are a company that build database marketing/campaign automation software. One of our new customers is using QV and we want to build an export to QV.
Why does QV not have a software developer lib which make exporting in native qlikview format possible? There is a lib with wich you first can export to QVE (exchange) format and you need to import this file in QV (an unnecessary complex, not logical and not thread save way). I don't uderstand why this format is made because xlsx works as fast as QVE and much easier with more columntypes as QVE etc.
For Tableau there is a lib which makes it easy to export direct in the native Tableau format and reports are updated automaticly in a fast way
That is what i meant. QVX is a exchange format and not native. it stores the data as utf8 text format as also xlsx does. So the user of qlikview first needs to import this format to native format. I just want to export in native format so the reports are updated.
If you want to speed it up you should take plain text-files and no xml-formats for exports respectively exchanging data. A native API to create qvd-files from third party tools didn't exists but maybe you could use: QVX & QVD Converter Java library.
You can use the QlikView OCX to build a QV app -- a QVW on the fly. If you use Qlik Sense, there are more friendly API options available to generate an app from code.
" import this file in QV (an unnecessary complex, not logical and not thread save way)"
leads me to believe that you are just trying to compare QV with something you know, and have not taken any time to understand the QV architecture. "unnecessary complex" to you, but robust and effective to those of us who use it regularly.
QV has a visualization layer and a data layer defined by the load script. The two merged together form an application (qvw file). The "reload" process executes the script to bring fresh data into the application.
I don't imagine that you want to be responsible for generating the visualization layer every time or managing your customer's modifications to visualizations.
Let's take a look at how QV customers work with external data today. The QVW file lives on the Customer's QV server, and the reload process is executed on schedule set by the customer.
If the data is an extract type, some external process runs on schedule at the data provider to generate a flat file in a known location. The reload process picks up this extract file on schedule, typically via FTP. Depending on the level of trust and connectivity between the customer and the data provider, the two processes may be coordinated or the data may be pushed.
For some data, such as Salesforce, customers use a connector in the reload script which eliminates the need for any intermediate extract at all, as the data is provided by an interface in Salesforce. If you don't want to create a connector for your system, there is a generic REST connector that can retrieve data from your system via REST if you can support that.