4 Replies Latest reply on Mar 4, 2015 3:27 PM by tdanner

    Behavioral difference between SWISv2 and SWISv3, SOAP issue with valid SWQL query

    joiellis

      I've been writing a perl api layer for our internal applications for the past year and I have accumulated quite a few unit tests.  Today while switching from using a SWISv2 connection to using SWISv3, one of my unit tests started failing with a  (500 Status read failed: Connection reset by peer) fault string.  Upon checking the v3.0/Orion.InformationService.log file, I find that my existing unit test, which passes with a v2 connection, fails with v3.

       

      It turns out my SELECT has a column named twice in the query (displayed here as the perl string)

       

      'SELECT NodeID, Uri, ObjectSubType, DNS, SysName, NodeName, IPAddress, NodeDescription, Vendor, SysObjectID, Location, Status, EngineID, Description, Displayname, NodeDescription FROM Orion.Nodes WHERE NodeDescription LIKE \'%D-Link%\''

       

      Interestingly, duplicating the column name does not cause a problem in SWQL Studio at all, it happily displayed both instances of the field without issue.  It's only the SOAP interface that's having problems with this.  Hence, I vote that this is a new bug in the SWIS interface that fails to properly support the full SWQL syntax.

       

      I have already fixed the issue in my unit test, but this points out that here's another v2 vs v3 behavioral difference, and how I really wish that SWIS would pass the error message from the log back to the client rather than just closing the connection with no feedback.  It's rather a pain having to go digging through logs trying to debug things.

       

      I'm using SDK 1.8 with Orion Platform 2014.1.0, NCM 7.2.2, NPM 10.7, UDT 3.0.2, IVIM 1.9.0, VNQM 4.1

       

      The v3.0 log shows this:

       

      2014-04-03 16:12:16,852 [57] ERROR SolarWinds.InformationService.Serialization.XmlSerializer - Error serializing query results <soap:Envelope xmlns:wsu="http://docs.oasis-open.org/wss/2004/01/oasis-200401-wss-wssecurity-utility-1.0.xsd" xmlns:soap12="http://schemas.xmlsoap.org/wsdl/soap12/" xmlns:wsap="http://schemas.xmlsoap.org/ws/2004/08/addressing/policy" xmlns:wsp="http://schemas.xmlsoap.org/ws/2004/09/policy" xmlns:soap="http://schemas.xmlsoap.org/soap/envelope/" xmlns:swis="http://schemas.solarwinds.com/2007/08/informationservice" xmlns:wsdl="http://schemas.xmlsoap.org/wsdl/" xmlns:msa="http://schemas.microsoft.com/2003/10/Serialization/Arrays" xmlns:soapenc="http://schemas.xmlsoap.org/soap/encoding/" xmlns:sys="http://schemas.datacontract.org/2004/07/System.Xml" xmlns:xsd="http://www.w3.org/2001/XMLSchema" xmlns:swpb="http://schemas.solarwinds.com/2007/08/informationservice/propertybag" xmlns:wsa="http://schemas.xmlsoap.org/ws/2004/08/addressing" xmlns:wsa10="http://www.w3.org/2005/08/addressing" xmlns:msc="http://schemas.microsoft.com/ws/2005/12/wsdl/contract" xmlns:wsaw="http://www.w3.org/2006/05/addressing/wsdl" soap:encodingStyle="http://schemas.xmlsoap.org/soap/encoding/" xmlns:wsam="http://www.w3.org/2007/05/addressing/metadata" xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance" xmlns:wsx="http://schemas.xmlsoap.org/ws/2004/09/mex">

        <s:Header xmlns:s="http://schemas.xmlsoap.org/soap/envelope/">

          <To s:mustUnderstand="1" xmlns="http://schemas.microsoft.com/ws/2005/05/addressing/none">https://172.16.10.22:17778/SolarWinds/InformationService/v3/OrionBasic</To>

          <Action s:mustUnderstand="1" xmlns="http://schemas.microsoft.com/ws/2005/05/addressing/none">http://schemas.solarwinds.com/2007/08/informationservice/InformationService/QueryXml</Action>

        </s:Header>

        <soap:Body>

          <swis:QueryXml>

            <swis:query xsi:type="xsd:string">SELECT NodeID, Uri, ObjectSubType, DNS, SysName, NodeName, IPAddress, NodeDescription, Vendor, SysObjectID, Location, Status, EngineID, Description, Displayname, NodeDescription FROM Orion.Nodes WHERE NodeDescription LIKE '%D-Link%' RETURN XML AUTO</swis:query>

          </swis:QueryXml>

        </soap:Body>

      </soap:Envelope>

      SELECT [T1].[NodeID] AS C1, ((N'swis://solarwinds-npm.pavlovmedia.corp/Orion/Orion.Nodes' + N'/NodeID=') + EscapeSWISUriValue([T1].[NodeID])) AS C2, [T1].[ObjectSubType] AS C3, [T1].[DNS] AS C4, [T1].[SysName] AS C5, [T1].[Caption] AS C6, [T1].[IP_Address] AS C7, [T1].[Description] AS C8, [T1].[Vendor] AS C9, [T1].[SysObjectID] AS C10, [T1].[Location] AS C11, [T1].[Status] AS C12, [T1].[EngineID] AS C13, [T1].[MachineType] AS C14, [T1].[Caption] AS C15, [T1].[Description] AS C16

      FROM [dbo].[Nodes] AS T1

      INNER JOIN [dbo].[NodeWebUri] AS T2 ON ([T2].[NodeID] = [T1].[NodeID])

      WHERE ([T1].[Description] LIKE N'%D-Link%')

      RETURN XML Auto

      System.InvalidOperationException: Invalid path: Property name already exists - [Nodes[EntityType=Orion.Nodes]/@NodeDescription]

         at SolarWinds.InformationService.Serialization.XmlResponseSerializerAutoStrict.MakeSchema(IEnumerable`1 columnsMetadata)

         at SolarWinds.InformationService.Serialization.XmlResponseSerializerAutoStrict.EmitHierarchicalSchema(XmlWriter writer, IEnumerable`1 columnsMetadata)

         at SolarWinds.InformationService.Serialization.XmlResponseSerializerAutoStrict.Serialize(XmlWriter writer)

         at SolarWinds.InformationService.Serialization.XmlSerializer.OnSerialize(XmlWriter writer)

        • Re: Behavioral difference between SWISv2 and SWISv3, SOAP issue with valid SWQL query
          tdanner

          The reason you are not seeing the error in SWQL Studio is the error is occurring in the "RETURN XML AUTO" serializer. In the "RETURN XML RAW" serializer (which is what SWQL Studio uses by default), the error does not occur. You can reproduce the error in SWQL Studio by including the "RETURN XML AUTO" clause at the end of your query.

           

          I'll open this as a bug internally.

          1 of 1 people found this helpful
          • Re: Behavioral difference between SWISv2 and SWISv3, SOAP issue with valid SWQL query
            joiellis

            Thank you!  That makes sense.

             

            I've found another query which works fine with v2 but fails with v3 'RETURN XML AUTO', but this one tosses a different exception than the first one above.   This is code we've been using for months to generate topology data as Graphvis DOT inputs.  I switched it from using v2 default, to 'v3 return xml auto' and it hasn't worked since.

             

            SELECT DiscoveryProfileID, DataSourceNodeID, LastUpdateUtc, SrcNodeID, SrcInterfaceID, SrcType, DestNodeID, DestInterfaceID, DestType, NCP.Sitecode as SrcNodeSitecode, NCP.LocID as SrcNodeLocID, NCP.MDFDevice as SrcNodeMDFDevice, NCP.Service as SrcNodeService, NCP2.Sitecode as DestNodeSitecode, NCP2.LocID as DestNodeLocID, NCP2.MDFDevice as DestNodeMDFDevice, NCP2.Service as DestNodeService, N.Caption as SrcNodeCaption, N.IPAddress as SrcNodeIPAddress, N.Status as SrcNodeStatus, N.DetailsUrl as SrcNodeUrl, N2.Caption as DestNodeCaption, N2.IPAddress as DestNodeIPAddress, N2.Status as DestNodeStatus, N2.DetailsUrl as DestNodeUrl, CI.IfName as SrcPortIfName, CI.Caption AS SrcPortCaption, CI.DetailsUrl as SrcPortUrl, CJ.IfName as DestPortIfName, CJ.Caption AS DestPortCaption, CJ.DetailsUrl as DestPortUrl

            FROM Orion.TopologyData

            INNER JOIN Orion.NodesCustomProperties AS NCP ON ( NCP.NodeID=SrcNodeID )

            INNER JOIN Orion.NodesCustomProperties AS NCP2 ON ( NCP2.NodeID=DestNodeID )

            INNER JOIN Orion.Nodes as N ON ( N.NodeID=SrcNodeID )

            INNER JOIN Orion.Nodes as N2 on ( N2.NodeID=DestNodeID )

            INNER JOIN Orion.NPM.Interfaces AS CI ON ( CI.InterfaceID=SrcInterfaceID )

            INNER JOIN Orion.NPM.Interfaces AS CJ ON ( CJ.InterfaceID=DestInterfaceID )

            RETURN XML AUTO

             

            If I remove the 'RETURN XML AUTO' at the end, then it works with a SWQL V3 query, just like the other one.  Writing my unit tests to check for these is difficult because the errors don't get returned to the calling code, they only get written to a log file on the server.  It would be a major improvement if something could be down to catch these exceptions and return them to the client rather than sending a nearly empty 'Server 500' error at the HTTP level.

             

             

            For this one, the log contains:

            SELECT [T1].[DiscoveryProfileID] AS C1, [T1].[DataSourceNodeID] AS C2, [T1].[LastUpdateUtc] AS C3, [T1].[SourceNodeID] AS C4, [T1].[SourceInterfaceID] AS C5, [T1].[SrcType] AS C6, [T1].[MappedNodeID] AS C7, [T1].[MappedInterfaceID] AS C8, [T1].[DestType] AS C9, [T2].[Sitecode] AS C10, [T2].[LocID] AS C11, [T2].[MDFDevice] AS C12, [T2].[Service] AS C13, [T3].[Sitecode] AS C14, [T3].[LocID] AS C15, [T3].[MDFDevice] AS C16, [T3].[Service] AS C17, [T4].[Caption] AS C18, [T4].[IP_Address] AS C19, [T4].[Status] AS C20, [T5].[WebUri] AS C21, [T6].[Caption] AS C22, [T6].[IP_Address] AS C23, [T6].[Status] AS C24, [T7].[WebUri] AS C25, [T8].[IfName] AS C26, [T8].[Caption] AS C27, [T9].[WebUri] AS C28, [T10].[IfName] AS C29, [T10].[Caption] AS C30, [T11].[WebUri] AS C31, [T4].[NodeID] AS C32, [T6].[NodeID] AS C33, [T8].[NodeID] AS C34, [T8].[InterfaceID] AS C35, [T10].[NodeID] AS C36, [T10].[InterfaceID] AS C37

            FROM [dbo].[TopologyData] AS T1

            INNER JOIN [dbo].[Nodes] AS T2 ON ([T2].[NodeID] = [T1].[SourceNodeID])

            INNER JOIN [dbo].[Nodes] AS T3 ON ([T3].[NodeID] = [T1].[MappedNodeID])

            INNER JOIN [dbo].[Nodes] AS T4 ON ([T4].[NodeID] = [T1].[SourceNodeID])

            INNER JOIN [dbo].[Nodes] AS T6 ON ([T6].[NodeID] = [T1].[MappedNodeID])

            INNER JOIN [dbo].[Interfaces] AS T8 ON ([T8].[InterfaceID] = [T1].[SourceInterfaceID])

            INNER JOIN [dbo].[Interfaces] AS T10 ON ([T10].[InterfaceID] = [T1].[MappedInterfaceID])

            INNER JOIN [dbo].[NodeWebUri] AS T5 ON ([T5].[NodeID] = [T4].[NodeID])

            INNER JOIN [dbo].[NodeWebUri] AS T7 ON ([T7].[NodeID] = [T6].[NodeID])

            INNER JOIN [dbo].[InterfaceWebUri] AS T9 ON (([T9].[NodeID] = [T8].[NodeID]) AND ([T9].[InterfaceID] = [T8].[InterfaceID]))

            INNER JOIN [dbo].[InterfaceWebUri] AS T11 ON (([T11].[NodeID] = [T10].[NodeID]) AND ([T11].[InterfaceID] = [T10].[InterfaceID]))

            RETURN XML Auto

            System.InvalidOperationException: More than one root element in the generated schema - [TopologyData,NCP,NCP2,N,N2,CI,CJ]

               at SolarWinds.InformationService.Serialization.XmlResponseSerializerAutoStrict.MakeSchema(IEnumerable`1 columnsMetadata)

               at SolarWinds.InformationService.Serialization.XmlResponseSerializerAutoStrict.EmitHierarchicalSchema(XmlWriter writer, IEnumerable`1 columnsMetadata)

               at SolarWinds.InformationService.Serialization.XmlResponseSerializerAutoStrict.Serialize(XmlWriter writer)

               at SolarWinds.InformationService.Serialization.XmlSerializer.OnSerialize(XmlWriter writer)