BigFix SOAP API Error: "Error in deserializing body of reply message for operation 'GetRelevanceResult'"

[GarySmith]

Hi

I’ve been using the SOAP API, specifically a call to the GetRelevanceResult method with a custom session relevance query, and its been working for a customer running 9.x of BigFix with no problems. They have recently upgraded to BigFix 9.5.2.56 and have now started getting an error:

Error in deserializing body of reply message for operation 'GetRelevanceResult'
There is an error in XML document (6060, 3712).

The session relevance query is pretty simple, returning data:

ComputerName:Vendor;Product;Version~Vendor;Product;Version

The query is:

(name of computer of it | "" & ":" & concatenation "~" of values of it) of results of properties of BES Fixlets whose (analysis flag of it and name of it = "Custom Software Inventory")

For each device, where there may be zero or more instances of ‘Vendor;Product;Version’. I’ve updated to the same version in my small test lab, and it works fine for me, which makes me think its an issue with the data?

I’ve exported the data output from the session relevance query, and for some vendors the data has the value:

<no manufacturer>

Could it be that this is interfering with the XML format the the SOAP API is using to transfer the results? How would I remove these values in the session relevance query?

Could there be another issue?

Any help would be appreciated.

Thanks

Gary
-=-

[GarySmith]

Okay, so I’m pretty much convinced this issue is due to the data containing the value:

<no manufacturer>

for example:

Some of the data I have is:

Geometer inc;Geometer's Sketchpad;1.0.0
<no manufacturer>;RPM 2.0;2.0
<no manufacturer>;VideoPoint Physics Fundamentals 1.0;1.0.0
<no manufacturer>;WELLON Uninstall;4.3.2

The session relevance query I run:

(name of computer of it | "" & ":" & concatenation "~" of values of it) of results of properties of BES Fixlets whose (analysis flag of it and name of it = "Custom Software Inventory")

This produces:

PC01:Geometer inc;Geometer's Sketchpad;1.0.0~<no manufacturer>;RPM 2.0;2.0~<no manufacturer>;VideoPoint Physics Fundamentals 1.0;1.0.0~<no manufacturer>;WELLON Uninstall;4.3.2

I need to be able to strip out either the:

<no manufacturer>

value, or all instances of ‘<’ and ‘>’. As the individual items are a list of values, and I concatenate them into a single value per PC, this is potentially more challenging…

Does anyone know how I can change my session relevance query to strip out these values?

Thanks

Gary
-=-

[JasonWalker]

Did they upgrade from a 9.5 version or a 9.2 version before this appeared? I’d recommend opening a PMR, but just for background info, the new Unicode functionality introduced in 9.5 has caused problems with several string inspectors in my environment (at this point, all resolved after opening PMRs).

Sounds like there may be a problem with escaping the brackets in the XML response.

[JasonWalker]

As a rather horrible workaround in the meantime, you might try escaping the special characters in the XML data. Have a look at http://stackoverflow.com/questions/1091945/what-characters-do-i-need-to-escape-in-xml-documents

One possibility might be to insert the escapes of the characters in the result - “<” is 3c and “>” is 3e in the ASCII hexadecimal table -

(concatenation "&lt" of substrings separated by "%3c" of concatenation "&gt" of substrings separated by "%3e" of it) of (name of computer of it | "" & ":" & concatenation "~" of values of it) of results of properties of BES Fixlets whose (analysis flag of it and name of it = "Custom Software Inventory")

[GarySmith]

Yes, the customer upgraded from 9.2 to 9.5, and this is when the issue appeared, but it could also be a coincidence, and may have just started collecting data with the at a similar time. But yes, I would have expected that BigFix would have automatically escaped the data to make it safe for the XML response.

I’m not sure of the process of raising a PMR, is it simple to do, where do I start?

[GarySmith]

@JasonWalker thank you, this looks like it will be a suitable initial workaround. I was unsure of how to do the replacement of these values, but the example you included is nice and simple (which makes a nice change for SRQ!)

I beleive the replacement values should be:

<
> 

I presume there was no reason to leave off the semicolon in your example, just an oversight?

I’ve sent the changes to the customer, and will report back if this workaround addresses the issue.

Thanks again for taking the time to respond Jason

Gary
-=-

[GarySmith]

Unfortunately, the updated session relevance query which encodes the < and > characters did not address the issue, and the SOAP API is still failing with the same error message, suggesting that it may be a more integral issue with the API.

[JasonWalker]

Well, that’s rather unfortunate. Sounds like a PMR is what you need. There are some instructions & links here - How to ask for IBM product help: PMRs, RFEs, and more

[jgstew]

You should try the % escape sequence instead of <

a " character is %22 in the relevance escape sequence. In some cases you have to layer the escaping to make it %2522 which is the escape of the % character, then the 22.

My guess is that either % escaping or a layered escaping is required for what you are trying to do to work. It may even be that < is correct, but that you have to escape the & character in some fashion first.

[GarySmith]

Thanks all for the responses.

I’ve done some further work in my test environment where I have imitated the customer’s environment forcing:

<no manufacturer>

into the custom inventory, and when I pull this out using the API, it is automatically escaped, without me needed to do this in the SRQ:

<no manufacturer>

So its back to the drawing board…

So i am currently left with:

Error in deserializing body of reply message for operation 'GetRelevanceResult'
There is an error in XML document (6060, 3712). 

when pulling data via the SOAP API on the customer’s site, for which I have no access, but it works fine in my test environment.

Not sure where to go next, as I cannot experiment on the customer’s site, and I cannot replicate this on my test system.