cancel
Showing results for 
Search instead for 
Did you mean: 
Create Post
Level 11

Orion and Service now integration

We have a requirement to integrate our Orion system with our ticketing system (Service Now).  I am aware that there is a plug-in that is designed to serve this purpose, but we are unable to use the plug-in, so that isn't currently an option available to us.

We would like to auto-ticket from Orion directly into service now, with a list of priorities P1-P4, but for now just P1/P2 incidents.  We've looked into using tables from SQL, and we thought we had found one that was viable, but sadly using a RAG system (Red/Amber/Green) we soon found out that the table had multiple versions of red, which was causing havoc within the ticketing system.

We've approached SW Support for assistance on the issue, and have been told to use the plug-in.  As per above this isn't an option available to us.  Does anyone have any experience that they can share on setting up auto-ticketing from Orion to service now, what fields were used, what SQL tables or queries.   Did you use a 3rd party company to set it up?

We have about 1000 alerts within our system at present, and about 1000 devices that we currently alert upon, due to the nature of the environment, we believe we would need to customise each alert for each device, as some devices are more important than others, and then we would require correlation.  For instance, a port going down on switch A may only be a P3, but a port going down on switch B maybe a P1.

Any help or advice is greatly welcomed, even if it's simply we used x company to do this for us.

Thanks

5 Replies
Level 9

We have integrated SolarWinds with our ServiceNow instance - no use of outside/3rd parties.  Depending upon what we desire, we use one of the two methods listed in other replies, either calling the ServiceNow Incident Trigger Action or using a customized PowerShell Script in the Trigger/Reset Actions.

May I ask, why can you not use the plug-in?

The only other option available would require you to have and use ServiceNow's Event Management Module (EMM).  EMM provides 2 additional capabilities:

  1. Using a PowerShell script Trigger/Reset Action to send an "event" to ServiceNow.  The EMM would run Event Rules to transform it into an Alert and Alert Management Rules to change the EMM dashboard, etc. It also creates tasks including Incidents, etc.  The EMM uses Flow Designer for it's orchestration mechanism.  We do this for customized WPM Transaction alerts.
  2. Use the built-in SolarWinds Connector to "pull" events into ServiceNow.  This requires a Mid-Server to be setup. You would then setup Event Rules to do the alerting/incident creation.

Hope this helps.  Feel free to PM me if you have any questions.

 

Tom

 

Thank you for your reply, and offer of assistance.  I'll likely PM you to discuss further, but I will try and answer your queries first.

As stated above, our in-house SNOW developers wont use any plug-in as they want to control the flow themselves, they feel by using a 3rd party plug-in (SW/SNOW), that they will lose this functionality.  We have multiple instances of SNOW across multiple regions, they would like to keep all the versions the same to make their jobs easier and more efficient.  Unfortunately, this is non-negotiable from their POV, so I have to engineer a different solution.

EMM - I am aware of this, but I dont have access to it, so it would require the in-house team to complete the work, they may again be reluctant to perform this task, but I can certainly raise it with them.  IIRC from last discussions, they wanted the intelligence to be SW side, and not SNOW side.

1. PS Script, would you be able to provide an example of a script that could be used?  Im not ofay with powershell as im not a windows server engineer, however we do have those skills within our organisation, and python skills which I would imagine could also be used.

2. Again, would you have an example of this, i'm not aware of the built-in SW connector, this sounds like a plug-in which again wouldn't be a suitable option, unless I am not understanding this correctly.  We would be unable to setup an additional server at present, but again it could be a solution that we could integrate going forward.

Thanks again!

Point1 - We've approached SW Support for assistance on the issue, and have been told to use the plug-in.  As per above this isn't an option available to us.  Does anyone have any experience that they can share on setting up auto-ticketing from Orion to service now, what fields were used, what SQL tables or queries. Did you use a 3rd party company to set it up?

Ideally rather than looking at SolarWinds, you should be looking at what options are available on ServiceNow end, for ticket creation. Couple of scenarios are mentioned below:

A) You just send out an email notification from SolarWinds to ServiceNow and ServiceNow will create a ticket on its end.

https://community.servicenow.com/community?id=community_question&sys_id=9bc30ba5dbd8dbc01dcaf3231f96...

B) Other options could be like using SNOW's Rest API to create tickets and call these via a script in SolarWinds Alert Trigger Action.

Note: If you cant use the SW<->SNOW plugin as you have mentioned already, then there is a drawback with any other type of integration that you go with, you will only be able to create/resolve the ticket on SNOW side, but* you will not have any reference of the ticket (like say ticket number) in SolarWinds.

Point 2 - We have about 1000 alerts within our system at present, and about 1000 devices that we currently alert upon, due to the nature of the environment, we believe we would need to customize each alert for each device, as some devices are more important than others, and then we would require correlation.  For instance, a port going down on switch A may only be a P3, but a port going down on switch B maybe a P1.

You have to clean this up my friend, its very difficult to manage an environment like this, you should handle your customization via custom attributes and make the alert as generic as possible. (For example: say you have Node Ticket Severity: P3, Interface Ticket severity: P2 etc), play around with custom attributes on Nodes/Interfaces do not create more number of alerts as it becomes more cumbersome to manage.

Hope it helps.

Firstly, thank you for your response, i'll try and answer some of your questions/queries;

1. We cannot use any plug-in from either SW or SNOW, our developers want to keep it all in-house so they can control the flow.  Appreciate this makes things much more difficult but this is the situation we have and part of where the problem lies.  

2. "

B) Other options could be like using SNOW's Rest API to create tickets and call these via a script in SolarWinds Alert Trigger Action.

Note: If you cant use the SW<->SNOW plugin as you have mentioned already, then there is a drawback with any other type of integration that you go with, you will only be able to create/resolve the ticket on SNOW side, but* you will not have any reference of the ticket (like say ticket number) in SolarWinds."

The above may be a possible solution, we only want to be able to log tickets into SNOW, so ticket reference within SW itself isn't an issue, it's not functionality that we currently have, so it wont be missed.

3. You're absolutely correct about the amount of alerts, but this is what the business has asked for, we have multiple smaller businesses within one business, and each has requested their own sets of alerts essentially, hence there are so many alerts.  Clean up task, and custom attributes is a massive undertaking, and whilst in the long run this would likely be a good thing, I am unable to complete this task, as I work alone within the system, so it's not feasible at present for me to complete this task.

Level 12

I used the Orion alerting system to call a powershell script that loads the data into a ServiceNow table.  I am not familiar with the ServiceNow processes that deal with the data once it's up there.

The powershell script takes parameters such as -Node, -Monitor, -priority, -message, -oncall, -status, etc.  In the script I do some translation between Orion terms and ServiceNow terms, then build the JSON from the parameters and make the rest call to ServiceNow.

So here's an example action in an alert for a SAM monitor

powershell "c:\cmds\Send2ServiceNow.ps1 -State Down -AlertObjectID '${N=Alerting;M=AlertObjectID}' -CorrelationID '${N=Alerting;M=AlertActiveID}-${N=Alerting;M=AlertObjectID}' -Node '${N=SwisEntity;M=Node.Caption}' -Monitor '${N=SwisEntity;M=ApplicationAlert.ApplicationName}' -OncallGroup '${N=SwisEntity;M=CustomProperties.OnCallGroup}' -Message 'Monitor ''${N=SwisEntity;M=ApplicationAlert.ApplicationName}'' on Server ''${N=SwisEntity;M=Node.Caption}'' is down or not responding.'"