• State Verified Answer
  • Locked Locked
  • Replies 4 replies
  • Subscribers 23 subscribers
  • Views 526 views
  • Users 0 members are here
Options
Related
This discussion has been locked. The information referenced herein may be inaccurate due to age, software updates, or external references.
You can no longer post new replies to this discussion. If you have a similar question you can start a new discussion in this forum.

SWIS v2 VS v3 in QueryXml()

joiellis

I have a growing selection of scripts which have all be using SWIS v2 connections.  I've begun encountering features that are lacking in v2 and supposedly present in v3.  However, when I change the endpoint to tell my library to use a v3 connection, I start getting total junk back from SWIS.  Either I get empty result sets, or I get a perl hash back that completely lacks the key/value pairs I get with a v2 connection.  Rather, I get a bunch of ordinal number keys instead of usable names. 

I'm guessing there's a new namespace missing from the v3 stuff, but I can't figure out what's missing or what's needing to be changed.  I'm using the InformationService.pm file provided in the 1.7 SDK.

Calls to simple things seem to work ok, but every call I make via QueryXml() is returning junk.  Note that these very same calls work perfectly when I change the endpoint back to a v2 connection.

If I single-step into a unit test and dump the results array, then I see this (with a v2 connection;)

   862  HASH(0x5e4b1c0)

      'DNS' => ''

      'Description' => 'D-Link Systems, Inc.'

      'Displayname' => 'ALBIPIE-BNWF4-S2'

      'EngineID' => 2

      'IPAddress' => '10.149.8.200'

      'Location' => 'University House . Birmingham, AL'

      'NodeDescription' => 'D-Link DES-3052 Fast Ethernet Switch'

      'NodeID' => 24495

      'NodeName' => 'ALBIPIE-BNWF4-S2'

      'ObjectSubType' => 'SNMP'

      'Status' => 1

      'SysName' => 'ALBIPIE-BNWF4-S2'

      'SysObjectID' => '1.3.6.1.4.1.171.10.63.8'

      'Uri' => 'swis://./Orion/Orion.Nodes/NodeID=24495'

      'Vendor' => 'D-Link Systems, Inc.'

      '_Col1' => 'D-Link DES-3052 Fast Ethernet Switch'

If I change to a v3 connection (simply by inserting the '/v3' into the endpoint string and reruning the script, I send up with this:

         862  HASH(0x5bd9900)

            'c0' => 24495

            'c1' => 'swis://solarwinds-npm.pavlovmedia.corp/Orion/Orion.Nodes/NodeID=24495'

            'c10' => 'University House . Birmingham, AL'

            'c11' => 1

            'c12' => 2

            'c13' => 'D-Link Systems, Inc.'

            'c14' => 'ALBIPIE-BNWF4-S2'

            'c15' => 'D-Link DES-3052 Fast Ethernet Switch'

            'c2' => 'SNMP'

            'c3' => ''

            'c4' => 'ALBIPIE-BNWF4-S2'

            'c5' => 'ALBIPIE-BNWF4-S2'

            'c6' => '10.149.8.200'

            'c7' => 'D-Link DES-3052 Fast Ethernet Switch'

            'c8' => 'D-Link Systems, Inc.'

            'c9' => '1.3.6.1.4.1.171.10.63.8'

You can see it's the same node, but the keys are wrong.  The ONLY change between these two executions is adding '/v3' into the endpoint string.

I expect this is something obvious, but I can't find any references to similar issues here on Thwack or anywhere else, for that matter.

I'm betting there should be a different set of namespaces in InformationService.pm when a v3 connection is in use but I can't find any documentation for what this might be.

Can anyone point me to the documentation I'm missing?

I'm also wondering what, exactly, is the difference between the services on port 17777 vs the services on port 17778.   I thought that 17777 was v2 and 17778 was v3.  Yet there are examples here where everyone seems to be using 17778 for both v2 and v3 connections.

When I try to use a /v3/ endpoint with port 17777, I get an SSL error.

  • 0

    I spent an afternoon re-reading my old SOAP/Perl/LWP books and I've narrowed down the source of the issue.  The sample perl library bundled in the SDK is based on the v2 wsdl, and there is nothing there for the v3 wsdl.  The v3 version changed the namespaces in use, but the only call that I've seen break, so far, is the QueryXML stub, because SOAP::Lite is lacking namespaces required to properly deserialize the queryResults object.  Read, Update, BulkUpdate all work fine using the v2 stubs, as far as my unit tests can tell.

    My confusion between ports & SWIS versions stems from confusing wording in the SDK documentation.  Port 17777 is a raw socket SOAP service. Port 17778 is an HTTPS SOAP service. Both of them support v2 and v3, I  think, but you change the URL/URI in the SOAP query to indicate the version you want.  (I misunderstood and thought 17777 was purely v2, and 17778 was purely v3.)

    Has anyone created a set of perl SOAP::Lite stubs using the v3 wsdl yet? 

  • 0 in reply to joiellis

    Sorry for the late response.

    The different in serialization formats you are seeing between v2 and v3 is because the two versions have different defaults for the RETURN XML clause. In v2 the default is RETURN XML AUTO, which format uses the entity and property aliases as the XML element names. It also uses a hierarchical format when the query uses navigation properties. In v3 the default is RETURN XML RAW, which uses fixed XML element names that are unrelated to the aliases used in the query. They are "row" and "c0", "c1", "c2", etc.

    Both services support both formats, they just have a different default when the query does not request a specific output format. To request the AUTO format that your existing scripts expect, just append "RETURN XML AUTO" to the query.

    You are correct about the port numbers: 17777 uses Microsoft's proprietary net.tcp "binary xml" protocol (with TLS encryption for privacy), which is more efficient than SOAP over HTTPS but not interoperable with runtimes other than .NET. 17778 offers the same services over standard SOAP/HTTPS.

  • 0 in reply to tdanner

    Thanks for the response! 

    I can't find any references to the 'return xml auot' and 'return xml raw' options on the SWQL query.  Could you add that to the PDF file for the next release of the SDK?

  • 0 in reply to joiellis

    That's a good idea. I'll include that.

SolarWinds solutions are rooted in our deep connection to our user base in the THWACK® online community. More than 195,000 members are here to solve problems, share technology and best practices, and directly contribute to our product development process.

SolarWinds Customer Success Center Certification Media Vault Link Accounts
About THWACK Blogs For Government Edit Settings Free Tools & Trials
Legal Documents Terms of Use Privacy California Privacy Rights Security Information
©2024 SolarWinds Worldwide, LLC. All Rights Reserved.