ScienceLogic ServiceNow Integration

[Deepak107]

Can anyone please share how to Integrate Sciencelogic with ServiceNow.

I want to pull events from Sciencelogic to ServiceNow. I have configured Event Management Mid Web Server Contexts, Mid Web Service Event Listener, Connector Definition and Connector Instance. But I'm not able to pull events.

Please help me with this

Thanks

Anirudh

[Deepak107]

HI,

I want to pull events from a third party monitoring tool into Servicenow events(em_event) table. I built a custom javascript connector. But it's throwing the error "failed to run 3PC java.lang.ClassCastException: org.mozilla.javascript.Undefined cannot be cast to org.mozilla.javascript.NativeObject". How to fix this error?

How to build a custom connector using Javascript?

Please help me with this!!

Thanks

Anirudh

[Andreas R]

Bump. Would love to know why my connector is throwing failed to run 3PC java.lang.ClassCastException: org.mozilla.javascript.Undefined cannot be cast to org.mozilla.javascript.NativeObject as well.

[Alexander Mitov]

Hi,

Developing a pull connector is a process that involves a lot of research regarding the monitoring tool's capabilities, knowledge of the methods used to pull the data (JDBC, REST, SOAP etc) and knowledge of Javascript/Groovy (and in some cases Java). 

Service Now already has published detailed articles in the product documentation for this Create a custom pull connector. Also there are several OOB connectors of this type that you can use as examples: SCOM (Groovy - REST API), OMi (Javascript - REST API), NNMi (Javascript - SOAP API) and others.

First I would recommend that you get yourself familiar with the monitoring tool and how you can extract data from there. If you use REST API for example, check what limitations it might impose to the data you want to retrieve. PRTG for example has a defined limitation on how many alerts you can pull via alert REST API calls per minute. The OOB connector for PRTG circumvents that by pulling alert information via REST but from the log API. Test and make sure you can retrieve the type and amount of data you need.

The next step is to design the pull connector architecture. What parameters you will need to pass to the queries, how to define them in the connector instance, how to set the collection intervals (and last event signature), how to set limits for each event collection to ensure you don't overload the MID server or the monitoring tool.

Then the development and testing starts... You can adhere to the Service Now documentation about the connector development. If you skipped the previous two steps, it will be like shooting in the dark - you may spend a lot of time with no results.

Last step would be to create event rules (and alert rules if needed) to align the retrieved events and resulting alerts with your requirements.

If you have planned for everything from the fist two points and you're only having issues with the development, please share more details on what you need to do (calls to retrieve the information for example), what you did so far and the script that you are having trouble with.

Cheers,

Alex  

[Andreas R]

I've actually made some good progress since I made my comment. The current status is that I've built a connector in JS that produces test data versus a known CI. The thing I'm the least clear on as of now is the concept of last event signature. I'm currently using the timestamp of the last metric collected but after that I'm not sure how to actually use that information for anything meaningful since it isn't fed back into the connector.

I'm also curious about the choice between JS and Groovy. I'd clearly like to make this connector as performant as possible but looking at the SCOM connector it has both kinds of script, so I'm a little unsure on how they relate and how to choose what to do with which.

Some clarification on these points would be valuable 🙂

Also, would appreciate it if the docs would specify data types for fields on objects, since they're vague at best. If ServiceNow expects a timestamp as a string (as can be seen in the MetricCollector script) that information belongs in the docs.