4 Replies Latest reply on Dec 3, 2013 12:47 PM by tdanner

    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.

        • Re: SWIS v2 VS v3 in QueryXml()
          joiellis

          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? 

            • Re: SWIS v2 VS v3 in QueryXml()
              tdanner

              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.