Unlock a world of possibilities! Login now and discover the exclusive benefits awaiting you.
We are developing and testing a complex schedule of reload tasks for our many QVW applications and their data.
Obviously we are defining all of these tasks using the QlikView Management Console GUI. Our Server/publisher database is currently using XML files not a SQLServer DB.
My question is: Is there away to promote or copy this schedule from our development environment to UAT and then Production without having to re-key tasks through the GUI?
I have had a quick look at the XML 'database' in the Publisher\CommandCenter\QVPR subdirectiry and it is pretty daunting, filled with GUIDs and obviously there is no documentation from QlikView about any of this.
Has anyone developed a release process for this, would it be easier or what is the difference if we were using SQLServer to host the repository?
Any help appreciated
Paul,
Yes, this can be somewhat daunting, but a lot less so once you understand what needs to be modified. If you folder structure is the same on both servers, it's really not all that bad. The following assumes a clean install on your production server (Server2) and all tasks set up on your development server (Server1). Unless you have separate license keys, don't license Server2 yet, because that will attempt to create a cluster and will corrupt your QVPR.
Step 1: Stop all services on Server2
Step 2: Rename the QVPR folder on Server2 to something else, and copy the QVPR folder from Server1 to Server2.
Step 3: Change all references to Server1 in the following files to Server2:
C:\ProgramData\QlikTech\Publisher\CommandCenter\QVPR\DirectoryResource.xml
C:\ProgramData\QlikTech\Publisher\CommandCenter\QVPR\DistributionService.xml
C:\ProgramData\QlikTech\Publisher\CommandCenter\QVPR\DSCResource.xml
C:\ProgramData\QlikTech\Publisher\CommandCenter\QVPR\QDSCluster.xml
C:\ProgramData\QlikTech\Publisher\CommandCenter\QVPR\QlikViewServerResource.xml
C:\ProgramData\QlikTech\Publisher\CommandCenter\QVPR\QVSCluster.xml
C:\ProgramData\QlikTech\Publisher\CommandCenter\QVPR\QvWebServiceResource.xml
Step 4: Start all services on Server2 and stop all services on Server1.
Step 5: License Server2.
It's possible that I've missed a couple files, but that should do it I think. Test it out.
Regards,
Paul,
Yes, this can be somewhat daunting, but a lot less so once you understand what needs to be modified. If you folder structure is the same on both servers, it's really not all that bad. The following assumes a clean install on your production server (Server2) and all tasks set up on your development server (Server1). Unless you have separate license keys, don't license Server2 yet, because that will attempt to create a cluster and will corrupt your QVPR.
Step 1: Stop all services on Server2
Step 2: Rename the QVPR folder on Server2 to something else, and copy the QVPR folder from Server1 to Server2.
Step 3: Change all references to Server1 in the following files to Server2:
C:\ProgramData\QlikTech\Publisher\CommandCenter\QVPR\DirectoryResource.xml
C:\ProgramData\QlikTech\Publisher\CommandCenter\QVPR\DistributionService.xml
C:\ProgramData\QlikTech\Publisher\CommandCenter\QVPR\DSCResource.xml
C:\ProgramData\QlikTech\Publisher\CommandCenter\QVPR\QDSCluster.xml
C:\ProgramData\QlikTech\Publisher\CommandCenter\QVPR\QlikViewServerResource.xml
C:\ProgramData\QlikTech\Publisher\CommandCenter\QVPR\QVSCluster.xml
C:\ProgramData\QlikTech\Publisher\CommandCenter\QVPR\QvWebServiceResource.xml
Step 4: Start all services on Server2 and stop all services on Server1.
Step 5: License Server2.
It's possible that I've missed a couple files, but that should do it I think. Test it out.
Regards,
I have servers licensed and running in multiple environments and want to migrate the QVPR from one to another. Besides the servername and the Distribution Service ID, is there anything else I need to be concerned about?
There was an announcemt a few months back about NOAD supporting QlikView, it's seems to me like something they might be able to do.
Hi Vlad, do you find any automatic way to migrate from a QVPR to another? Could you please share your experience? Thank you
You can migrate tasks from one environment to the other using the "Remote Management Services" in the QMC.
Remote Management Services ‒ QlikView
-Rob
The attached link you referenced states that Remote Management cannot be used to migrate task from QV 11 and QV 12.
Is this a correct statement or is this precautionary on Qlik's part???
Thanks in Advance,
Dan
This is correct, the QMS service for both environments must be the same release. In this case the best option is likely to migrate the QVPR files over to the new environment from the old. There are some caveats to this though, if you are changing file paths etc. in the new environment, that makes things a bit more tricky as those have to be sorted out in the QVPR files in addition to changing the service URLs to point to the new servers.
Here is an article that outlines things pretty well, and I had added the caveat about changes to certain things as well, take a read through that and see if that may do the trick here:
https://support.qlik.com/articles/000014618
This is not really difficult, but it can be unnerving if you have not done it previously. Just remember, as long as you have QVPR backup, if something goes wrong in trying to migrate, you just wipe and start over again. The key thing I will mention is the service URLs, be sure those get changed before you try to start the QMS in the new environment with the migrated files, as if you do not, that may interfere/corrupt the existing environment.
Regards,
Brett
Greetings @Brett_Bleess !
Apparently the article https://support.qlik.com/articles/000014618 is no longer available (or has a new URL) in thesupport repository. Can you please post the new URL for that article?
Cheers,
++José
Thanks Jose, that is very odd, as I am sure I got that from the actual article, so something changed somewhere. I have sent off a note to someone to see if they can look into it, may take a few days, but hopefully we can get it sorted out.
Cheers,
Brett