6 Replies Latest reply on Apr 18, 2017 9:47 AM by jrayment

    API Feasibility - Provisioning Ticket -> Swinds Node Data Consistency

    jrayment

      Can custom node fields be updated by entering a ticking system case number, making a call to ITSM and searching for ticket and then querying mapped fields?

        • Re: API Feasibility - Provisioning Ticket -> Swinds Node Data Consistency
          bluefunelemental

          Sure but what is your complete workflow?

          if you manually enter an itsm ticket number on a node custom property and a script matches that to the actual ticket then what happens next and why? What if a node is on two itsm tickets?

           

          would you prefer to link an itsm ticket to a Solarwinds alarm so it's 1:1 then you can lookup field values on the node based it being the alert object?

            • Re: API Feasibility - Provisioning Ticket -> Swinds Node Data Consistency
              jrayment

              Hey blue,

               

              tdanner articulated this better than I did:

               

              1. Accept as input from the user a ticketing system case number

              2. Call the ITSM system with that ticketing system case number to get some values about the device referenced by the case

              3. Call Orion to apply the values from the ITSM system to some custom node properties

                • Re: API Feasibility - Provisioning Ticket -> Swinds Node Data Consistency
                  bluefunelemental

                  Oh I finally read the subject line and see this is about provisioning vs alerting - sorry.

                  So what is your ticketing system? I am meeting with my team this Friday to  review doing this for our system- remove all the custom property manual process and pull from the cmdb. I am not planning on using a ticket # but rather a serial or UUID or IP as the foreign key so I get matches on everything possible.

                   

                  Heres my my thoughts on design:

                  1. Add custom property for values from ticketing system or cmdb

                  2. Script, such as Powershell running on a windows scheduled task, which calls the Swis API for nodes then for each calls the cmdb/ticketing system and pulls in values into a series of powershell objects.

                  3. script results so that for each object call the swis API and modify custom properties as pulled from other system (might need to handle ignoring where existing values match already)

                   

                  alternatively you could reverse this and call the ticketing system for ticketing that match your filter then push values into swis API. This might lower your transactions and you could trigger it to occur more frequently or even near realtime.

              • Re: API Feasibility - Provisioning Ticket -> Swinds Node Data Consistency
                tdanner

                That is a very dense question! It sounds like you are considering writing a tool that will:

                 

                1. Accept as input from the user a ticketing system case number

                2. Call the ITSM system with that ticketing system case number to get some values about the device referenced by the case

                3. Call Orion to apply the values from the ITSM system to some custom node properties

                 

                If that's not right, please correct me.

                 

                If it is right, then the relevant Orion APIs are finding a node based on how it is referenced in the case (this will turn into some kind of SWQL query - the details will depend on how you identify a node from a case) and updating custom properties. Both of those are very common operations.

                1 of 1 people found this helpful