QMS API GetUserDocuments - relative path missing

[cbushey1]

Hi there,

New to using the QMS API so bare with me. 

We are already using the GeUserDocuments function to return a list of documents, however we recently instituted publisher and added mounted folders. Since doing this, the relative path value is missing for our documents. Is there a way to correct this or possibly another way to identify the path of the file (we use the path for a list of documents in our own custom site)?

I used the powertools utility and am attaching what it returns (for a single application).

[NadiaB]

Hi @cbushey1 

There are two things to consider here:

1. If you have a code that was working before and is not working anymore, it is necessary to provide the scenario, for example you will need to have the same User Document structure in both environments and verify in one is working and the other is not.  For this test I just created a subfolder in the User Documents folder (my access point folder) and ran the code. You can try that too and verify. The documentation that was provided doesn't mention the specific method call you are using, but it does describes when the relative path should be available, so it was provided as a reference only.

2. If the enviroment configurations are different, and because of that the result is different, then unfortunately is result of the configurations and not because the API is not working properly, any code like the one that was provided to implement the API is considered out of support unless there is evidence that it was working before and stopped working, and the scenario hasn't changed. What caught my attention is that is was mentioned that the same code works on a different environment that also has 12.40,  so it is more possible that a configuration is the problem and not the API.

Let us know if there are any questions.

[cbushey1]

The 2 environments are not the same. I didnt bring it up here because it just confuses the problem. 

The code we are using worked before

1. the introduction of a publisher server (standalone)

2. We changed the user documents location (due to the publisher server being introduced).

What I am not understanding is why we are seeing null for the relative path when we use either our code or the power tools utility when documents do exist. Shouldn't there always be a path defined for the files? I should add that the code does find the files, just not the path.

[NadiaB]

Hi @cbushey1 

That is not what the documentation stands about the relativePath, but if you can show us a different behavior and how your code is showing the relativepath for the other working environments we can look at it.

Kind Regards.

[NadiaB]

Hi @cbushey1 

Could you provide a screenshot of how the value comes from your other environments?

Kind regards.

[cbushey1]

@NadiaB 

If I understand the documentation (and what you wrote) the relative path field will only be filled in when there exists QVWs within subfolders of the root directory specified for the user documents. 

If this is the case, then the relative path should be filled in since my QVWs exist in subfolders of the root directory, however it is blank. 

I am attaching two screenshots, 1 were it works and 1 where it doesn't. The only difference between these two environments is that where it doesn't work we have a stand alone publisher server. What you should notice though, is that the configuration is the same between them, with each having a root directory and subfolders, with QVWs in the subfolders.

[cbushey1]

@Nadia  Did you get a chance to see my reply from last week?

[NadiaB]

Hi @cbushey1 

Let me replicate.

Kind Regards.

[cwolf]

Each document node has a "FolderID" that points to a path (root or mounted). The full path to a document is given by :

Path represented by FolderID + '\' + RelativePath + '\' + Name

If a document is located directly in the root folder or in a mounted folder, the relative path is empty.

[NadiaB]

Hi @cbushey1 

I did a quick test using the PowerTools first before checking with .net. I'm selecting "Service Version" 11.00 IR that is the latest that the Power Tools has, I'm not sure if there a newer version, configuring paths as you mentioned and the outcome is not the one is shown in the picture.

What I found is that the API call will retrieve the structure under User Documents (tree structure that appears in the QMC, QMC\Documents|User Documents).  If you see a tree folder structure there that is what the API is returning.

I'm using the PowerTools available in community but in my previous versions with .net I got the same results in both API versions.

There are different things to consider, one that I'm sure was done is that the Service reference in your .net project has to be updated, the second is to verify what version is being used:

• IQMS: QlikView 11.20 and 12.00
• IQMS2: QlikView 12.10
• IQMS3: QlikView 12.30 (November 2018)
• IQMS4: QlikView 12.40 (April 2019)

https://help.qlik.com/en-US/qlikview-developer/April2019/APIs/QMS+API/html/7b30b3a1-77da-4bbe-bdc2-1...

From the Powertools you might not be able to make changes but in your .net protect you could verify  the service reference and the version being used.

Kind Regards.