Does the API support change of polling engine. If so is there sample/reference code available
My apologies on the second link. I must not have had enough caffeine in my system at that point. I was looking for confirmation on if any other dependencies in the DB would need to be updated with the EngineID change. This might be a bit better since it comes from SWI themselves: Polling Engine Load Balancing · solarwinds/OrionSDK Wiki · GitHub
I believe you can use the Set-SwisObject command to set the engineID to what you need it changed to for the nodes. You can see how this command is used in PowerShell · solarwinds/OrionSDK Wiki · GitHub as well as a SQL example to show that changing the ID is the only thing you'd need to do at Change nodes polling engine ID - SolarWinds Worldwide, LLC. Help and Support .
dkeyser,
Thanks for the info.
I should have given my requirement much clear.
e.g. I have a node 'NODE001' being monitored/polled through polling engine 'PE001'. I want that node 'NODE001' to be monitored/polled through a new polling engine 'PE002'.
The second link in your note is suggesting change to the table '[dbo].[Engines]' which certainly not the requirement.
The first link is a direction. I think the node table need to be changed. There is a field engine id in it.
I have used the python equivalent swis.update('Set-SwisObject' ) to update custom properties. Need to check if it can change the engine id.
Additionally, is this the only change we need to perform. (i.e. is there any other dependencies left out. Note that engineid is a foreign key)
I wish there should be a function to do this.
Below code is changing the polling engine for a node.
SWIS.update(g_NodeUri + "/", EngineID = 2 )
Not sure if any dependencies left out.
So you will want to get acclimated to the Solarwinds API, there are not pre-defined functions to perform the vast majority of changes. It is extremely open ended and so the burden is on you to learn how to use it. You can change almost anything you want, the function is swis.update(anything that allows an update) and it is up to you to test the impact before you put those changes into prod.
This is both a challenging but incredibly free API, in that if you make a change it may have consequences that you did not expect, but once you get familiar with the tools it turns out that you can change almost anything you want in any way you want and it more often than not will work out. They won't hold your hand and explain every possible change to you, but the plus side is you can come up with MANY use cases that the Orion devs have not had time to consider or test out and get them working for your environment LONG before the SW team ever gets to your edge case.
I have written many integrations through the API that Solarwinds has not gotten around to building, and they work beautifully to get what my clients need without me waiting on anyone at SWI so I can integrate my clients with nearly any tool, automate any work flow and process, and just generally make my environments work at 150% and do not have to live within any vendor defined restrictions.
