Tag: admin

Importing Tasks via Remote Management – Step-by-Step

I recently moved a client’s dev/test environment onto a new server. There were a few dozen reload tasks and rather than recreate them by hand, I chose to use the Import Task feature via the QMS Remote Management service.

I’ve known about this feature but have never had a chance to use it. I looked through QlikCommunity forum and did some googling to get more info but I didn’t find a lot. Specifically, there did not seem to be a single resource that laid out the steps to do the import. Hence the following post…

The process is fairly straightforward and intuitive. Below are the steps I followed. (This is on QlikView 11.2 SR6, by the way. Windows 2008 R2 Enterprise OS.) In my environment there was the remote server — let’s call it the OLD server, and the target server — we’ll call it the NEW server. And I had previously stopped all QV services on the OLD server and set them to Manual.

Preparing the OLD server

  • Turn on the QMS service – I don’t know if this is explicitly required (it would be easy enough to test), but at a minimum I wanted to be able to get into the QMC on my OLD server to look at things
  • Create a local “QlikView Management API” group on the OLD server – be sure to name it exactly that

qms_remote_group_define

 

  • Add members to QlikView Remote Management group – I added my domain service account that runs all the QV services. Although you could add a different account to run the import (you’ll need to supply login info on the NEW server if you do that.)
  • Confirm you have the group setup correctly – use the Users tab in QMC on the OLD server for this

qms_remote_group

 

  • Create an inbound firewall rule to allow domain traffic on port 4799 (this is the default port for the Remote Management service)

qms_remote_inbound_rule

 

Preparing the NEW server

On the NEW server, all the preparation is done within the QMC, in the System > Setup tab. I’m going to walk through the steps as if you want to import ALL tasks (as opposed to selecting specific tasks for import).

  • Go to the Remote Management Services section and click the plus sign to create a link
  • Replace the default server name with the name (or IP) of your OLD server, and click Apply

qms_remote_setup_1

 

  • If you intend to run the import with a user account other than the QV service account, go to the Login tab and enter credentials and Apply
  • Go to the Source Folders tab and you should see a list of folders From the OLD server. For each of these, map them to a folder on your NEW server. Click Apply.
  • NOTE: if you do not map all source folders, you’ll receive an error message when you attempt to import all tasks

qms_remote_folder_mapping

 

  • Go to the QlikView Servers tab and map the name of the OLD server to the NEW server. In my case, because I had done some name-switching, these were the same name, but the mapping is still required. Apply.

qms_remote_server_mapping

 

  • You can optionally choose to disable triggers after tasks are imported

qms_remote_setup_2

 

Importing tasks

Now that the link is established, the task import is quite simple.

  • Go to the Documents > Source Documents tab, right click on any folder or the top-level “gear” icon and choose “Import Tasks”
  • You’ll be presented with a new window with an expandable tree of your source folders. Click the top-level to select all tasks and click OK. You will be prompted to confirm.

qms_remote_confirm

  • Voilà!

 

Caveat

I had read that the triggers of the type: “On event from another task” would not be created unless all tasks are imported. However, even though I did indeed import all tasks, none of the triggers were preserved. This was not the end of the world, but certainly eroded the value of the import. <– Wrong! See “IMPORTANT EDIT” below .

IMPORTANT EDIT – Aug 01, 2014

So…it turns out that the triggers (including the “One event from another task” triggers) were indeed created on the import. But because I had triggers disabled, the “links” did not appear. Once I started selectively enabling triggers, the Tasks screen showed the serial task chains as I expected.

So I hope you find these steps useful if you need to do a migrate. I will undoubtedly be referring to them in the future when I forget the steps! 🙂

Keep on Qlikin’

(keep on Sensin’ ?? )

Bill

Shares

Collaboration Metadata And More

IMPORTANT NOTE

You may need to edit the CONNECT string to provide the full file path to the DLL. The default location in QlikView 11.2 SR3 is on the C: drive – Program Files\QlikView

An edited CONNECT string would look like this:

CUSTOM CONNECT TO “Provider=C:\Program Files\QlikView\QvsAdminDataProvider.dll;host=corp-qlikview-t;XUserId=****;XPassword=****;”;

Thanks to Ronnie Taborn for this solution!

 

 

If you haven’t seen it yet, there’s a nifty feature in the QlikView version 10 to pull metadata from the repository into a QVW.

The metadata are related to applications (QVW documents) in AccessPoint and the server objects that users can create. Specifically:

  • Documents – names, sizes, AccessPoint properties
  • Document attributes – if you assign custom attributes in the QVS Management Console
  • Collaboration (a.k.a. “server”) objects – creator, types, properties

These metadata are not available in the Ops Monitor app (as far as I know), so this new feature is more than just a convenience.

 

Creating the script

Adding these fields to the load script is super-simple, thanks to a new option in the datasource selection drop-down menu – QvsAdminDataProvider.dll (32)

 

  1. Choose the QvsAdminDataProvider.dll (32) from the drop-down menu
  2. Click the “Connect” button to add the connect string into your script
  3. Click Select to bring up the Select Wizard
  4. Choose all fields from all tables and include the Preceding Load option

A few tweaks…

I made a couple of small tweaks to the script for convenience:

Rather than expressing the document size (DocumentList.FileSize) in bytes, I converted it to kilobytes using this code:
round(num(replace(FileSize,'.',''), '#') / 1024, 1) AS [File Size (kB)]

 

And I plucked the username out of the CollaborationMetadata.OwnerName:
subField(CollaborationOwner, '\', 2) AS OwnerName

 

Now reload the script! Your data model should look like this:

 

Using the objects

The simplest use case is to create table boxes and a few selectors. The Document List and Collaboration Objects are well-suited for tabular display. Here I’ve done a little renaming and formatting:

 

What else could we do with this?

Now we can start having fun! With these new metadata available for collaboration objects, we can measure aspects of our QlikView program such as:

  • Which applications get customized the most? (i.e. the most server objects created)
  • Which users are creating the most server objects?
  • What percent of our user base is sharing their server objects?

Here are just a few visualizations to serve as examples:

(this would be more meaningful with more than one user!! 🙂 )

 

Hope these examples get you thinking about ways to incorporate these metadata into the monitoring and improvement of your QlikView program.

Keep on Qlikin’

Bill

 

Shares

Share