Troubleshooting the QlikView Publisher Repository (QVPR)[1]

[Bjorn_Wedbratt]

In this webinar we will discuss

• What is the QlikView Publisher Repository (QVPR)
• How does everything link together?
• What is not in the QVPR
• Key Tables and Fields in the QVPR
• Most Common Problem Areas in the QVPR

For best viewing, we recommend you set the highest video resolution.

Q&A - Troubleshooting the QlikView Publisher Repository (QVPR)

Q: What best pratice to do upgrade on the QDS service & how it impact the QVPR?

A: The key to upgrades, both SR as well as major releases, is to be sure you have a backup of all of your Application Data folder paths for all the QlikView services, as this way if you do need to roll things back, you can be sure you are rolling things back to the exact environment you had previously.  By default, this is going to be C:\ProgramData\QlikTech folder and its contents.

The QVPR is subject to schema changes in the files on any given release, so again, I would recommend the above, but you can also use the QMC\System\Setup\Management Service\Repository tab to take a backup of the Repository there as well, so you have a double-backup of things.

If using XML, the backup is simply a compressed zip file, and if you need to restore, simply extract the zip files back into the QVPR folder and restart the QMS service and you should be right where you left off.

Q: Really don't understand why Power Tools is not supported - clearly Qlik values their usefulness?

A: The 'supported' piece really applies to the tool itself, these were not created by R&D, which is why they are not supported by R&D, but as stated during the presentation, should you have any issues etc., you may post a comment/question on the site where the PowerTool download is located, and someone will answer:  https://community.qlik.com/docs/DOC-5903

Q: Is there a general performance difference between SQL and XML for QVPR? In your experience is SQL less prevalent? In my experience it seems less popular, and it lacks support for things like Governance Dashboard?

A: SQL is definitely much less prevalent, but as mentioned during the presentation, the one instance we have definitely seen performance improvement in things is when you have many QlikView Administrators or Document Administrators, and this is most likely relate to SQL being much better able to handle transactional locks etc.For the XML Repository, we are relying simply on the file system to manage things to a large degree, and that is just not as robust as SQL Server's abilities in the above mentioned cases.  Otherwise, there really should not be much of a difference unless you have a very high volume of tasks/ distributions etc., That is the other instance where SQL would likely be the better option as well.

Q:  Is it complicated to move the location of the QVPR?

A: There are two ways to accomplish things in this case, if C partition is not to be used, you can change the Application Data folder location via the exe.config file for the Management Service.  The config file is located by default in C:\Program Files\QlikView\Management Service, and the parameter in the config file you want to change is:

<!-- Defaults to %PROGRAMDATA%\QlikTech\ManagementService -->
  <add key="ApplicationDataFolder" value=""></add>

The value ="" in between the double quotes is where you would put the path you want the folder to be located.  This will relocate the entire ManagementService folder that by default is located in C:\ProgramData\QlikTech\ManagementService.  Be sure any changes you make to the exe.config files for any of the .Net web services (QMS, QDS, DSC and QVWS) are backed up/documented, such that when you upgrade, you can reconfigure those settings, as the exe.config files will normally be overwritten by new versions on upgrades.

To relocate just the QVPR folder, use the QMC\System\Setup\Management Service\Repository tab and the Optional Base Path setting in that case, the only thing that is moved is the QVPR folder, the rest of the folders/files will remain in ProgramData.

Q: here would I find the .qvpr file, generally?

A: The QVPR is not a file, it is a folder and is located by default in C:\ProgramData\QlikTech\ManagementService

Q: Does the Database holds any clear text passwords?

A: All usernames/passwords stored in the QVPR should be hashed/scrambled, so no clear text. 

Q: Could you just add a node to a cluster and then remove the old node?

A: The way I prefer to do things when making changes is if I am 'replacing' a resource, I use the existing resource and simply change the service URL to point to the new server where the service is now running, as this ensures all of my GUIDs remain as they are and there is minimized risk of messing anything up in the QVPR.  The same would apply to cluster node URLs on the QDS resource too, I generally change the existing URL versus creating a new one and deleting the old record just to be on the safe side, but adding the new node and then deleting the old should be fine as well if it is not the primary node, I would definitely recommend re-using the primary node entry versus adding/deleting, as doing the latter may result in unexpected changes in the QVPR from past experience, so I would err on the side of being cautious/safe in this case. 

Q: Can we migrate from XML to SQL DB, and when should we do it?

A: You sure may, and you do this via the QMC\System\Setup\Management Service\Repository tab, the key is the Migrate data from current repository checkbox.  Use the QMC Help link in the upper right corner of the page, it is context sensitive and should explain things quite well. 

If you still have questions, just open a support case on it, and we can get back to you to further explain anything that may not make sense. 

As far as when to switch to SQL Server, the two instances I have seen that are beneficial are if you have many QlikView Administrators or Document Administrators or you have a lot of Tasks and Source Documents, then SQL Server is likely to provide a bit faster performance in the QMC, but there are some other settings we have in the QMS service that can be changed to try to improve things for XML as well, just FYI.  If you are experiencing slowness in the QMC, I would recommend opening a support case, so we can take a look and determine what the best actions may be for you.

Q: Is there a way to migrate tasks from one server to another, such as DEV to PROD promotion, without recreating the tasks?

A: Yes, I covered this in the presentation at a fairly high level, the trick is to use the XML DB Viewer to search for each of the servers in the one environment and replace those with the correct server in the new environment.  I would not really recommend this for Dev to Prod promotions, but more for new hardward moves etc. 

For Dev to Prod, you want to look into the Remote Management Service feature of the QMC, use the QMC Help to look things over and if you need assistance in implementing things, that is something I would recommend doing a consulting services engagement via your account manager to be sure everything gets properly configured and works as you expect.  The one caveat of this feature is both environments have to be on the same release though, just FYI.  So copying the QVPR might need to be done on upgrade cycles in those cases, and I am always happy to do a WebEx and walk through that with customers and explain what they need to do, but again, another caveat, the two environments need to have the same folder structures/locations etc. as changing those will likely break things when trying to move.  QVS path differences are not an issue provided Mount names are the same, but QDS source paths must be identical.

Q: Why don't I have the Repository Tab?

A: The Repository tab is only visible if you have a licensed Publisher, if Publisher is not licensed, that is what we call the Reload Engine, and with that, there is no Repository tab in the Management Service settings, as there is really nothing to configure.  You do still have automatic backups of the QVPR occurring though, just FYI.

Q: What is the purpose of QMSChunkSize value in the QVMgmtServ.exe.config?

This setting determines the number of tasks that are sent to the QDS each round.  So when there are changes to tasks/distributions, the QMS has to push those to the QDS, and the chunksize determines the number pushed every round of communication between the services.  In 11.20 SR13, I would not expect that you should need to make changes to this setting to be honest, if you are seeing issues where Next Execution timestamps are going missing in the QMC\Status\Task view etc., then this could be in play

Please open a support case if that is the case, so we can do a review with you to confirm if you are experiencing this issue and reducing the setting value may help or not.