I have a few questions related to salesforce connector built by Qlik (not from other party such as QVSource, etc.).
We're currently using Qlikview 11.12.0 with Qlikview SalesForce Connector v11 and considering upgrading to the latest Qlik SalesForce Connector available from Qlik website (13.1). However, from reading the "QlikSalesforceConnector13.0_InstallationAndUserGuide.pdf", it seems we can only have 1 query at a time using the same "user account".
Can anyone help clarifying if this "user account" refers to either:
1. the "domain service account" hosting the Qlikview Server?; OR
2. the SalesForce account used in the connection string? (I''m guessing the answer is this, but I'd like to make sure).
3a. Are we limited to 1 query per user account, regardless of which SalesForce Environment we're trying to do query on?
Assuming we have 3 SalesForce Environments: Test, UAT, & Production. Can we run parallel extractions, using 2 different QVW extraction files, run from the same Qlikview Server (meaning the same Qlik domain service account), one extracts "Account table" from "Test" environment, and the other extract "Account table" from "Production" environment.
If we cannot do scenario 3a above, is any scenario below possible?
3b. The same Qlikview Server, have 2 extract QVWs hitting the same "Production" environment, BUT with 2 different SalesForce accounts in each of the connection string.
3c. 2 Qlikview Server (both servers having the same Qlikview domain service account), have 2 extract QVWs hitting 2 different environments, BUT using the same SalesForce account in the connection string.
4. Do you have any experience extracting "Case", "Work Order", "Opportunity" tables using SalesForce Connector 13.1, and even though there's nothing in the log (as if the extraction process is completed successfully), it only returned partial number of records (for example, only return 156,000 records instead of the total 210,000 records)?
Sorry for posting these long questions, but I'm hoping to
I am not a QV user with years and years of great experience and I cannot help you with great detail since I did not explore every single bits of the new connector. But I still want to share my frustrated experience with you.
We used to have the old connector which is capable of loading SF data from both Dev server and Production server (local) at the same time using same login detail.
But since we updated to version 13. We found that (by practise) it is only possible to run the reload once at a time. We haven't try two different login detail in two different server though.
We have seen a lot of the following error message:
Error: Invalid Session ID found in SessionHeader: Illegal Session. Session not found, missing session hash: [MASKED]
This is expected, it can happen if the session has expired and swept away, or if the user logs out, or if its just someone trying to hack in.
We also found that it is much easier to be time out in the new connector. We perform full reload during the weekend. For large tables like field history table, there is no way it can be load in one go. At the moment, we are dividing each table into years and we put the connection script in front of every single load. I assume that will force QV to re-initiate a new connection every time it loads the table (or part of the table).
For the incremental reload at every night, we found that the result is very unreliable. Even though it shows that there are new records updated in the log file, it will always have missing data. The only way to solve it is to perform a full reload.
To load the achieved data, it is suggested to change the mode to Query All but not Bulk API.
It would be great if you can let me know after you have found out what would be the best practice to use the new connector.
Thank you for sharing your story. In my case, we didn't get an error message like you did. The extraction process didn't return error message on the QVW log, and it proceeds as if all is completed successfully. We noticed that we didn't get the total count of rows as the file size was lower than expected (every few days or so).