Return newly created objects when using Add

[jeremysmith1]

It would be cool if when you did something like prtgClient.AddGroup() it would return the newly created group.

This would add an extra network call when creating it. I could see this being undesirable.

Would a PR with the change be welcomed?

public void AddGroup() -> public Group AddGroup()

[lordmilko]

I think I had originally considered adding an optional argument bool resolve = false to AddSensor / AddDevice / AddGroup that when true would perform the resolution the PowerShell version currently does, but decided since C# is inherently more cumbersome to deal with than PowerShell, it's not that hard for people to just do a GetGroup or whatever themselves...besides, most people who wanted to create new devices and groups would probably be using PowerShell, right?

Well, the fact people are asking for this in C# indicates to me that is not the case! I will look into adding this into PrtgAPI 0.8.1, which should ideally be out in a week or two with enhanced NotificationAction properties, and will no longer erroneously create the PowerShell folder in your Visual Studio solution containing all the about_ help files.

In the meantime, you can easily create dodgy extension method on PrtgClient that is probably good enough to resolve your newly created objects for now

static class PrtgClientExtensions
{
    public static Group AddGroup(this PrtgClient client, int parentId, string name)
    {
        client.AddGroup(parentId, name);
        return client.GetGroups(new SearchFilter(Property.ParentId, parentId), new SearchFilter(Property.Name, name)).First()
    }
}

[jeremysmith1]

Haha. Just wrote the same extension method.

I would like to contribute if I could. I don't like bringing things up then leaving. You can email me at smith.jeremy.james@gmail.com

An interface would be great for prtgclient for unit testing purposes as well.

Thank you for your work.

[lordmilko]

PrtgClient takes an IWebClient in its internal constructor that is used to mock API responses, which is then instantiated with a MockWebClient that takes an IWebResponse capable of handling the logic of processing one or more functions or implements the logic of a specific scenario (such as object resolution). An IPrtgClient interface would be a maintenance nightmare, due to the sheer number of public methods and overloads defined on PrtgClient.

Considering the interrelationship between C# and PowerShell, the requirements for unit tests and integration tests as well as documentation, I probably prefer for people to tell me what's not working for them and I'll figure out the best way to make it happen!

Regards, lordmilko

[lordmilko]

Hi @jeremysmith1,

PrtgAPI 0.8.1 has now been released. AddSensor, AddDevice, AddGroup and AddNotificationTrigger all now resolve their resultant objects by default. AddSensor now returns a List<Sensor> in the event your NewSensorParameters may have resulted in the creation of multiple sensors

Object resolution can be disabled by setting optional parameter resolve to false. In the event object resolution is disabled, the method will return null.

Please see the release notes for a full list of changes

Please let me know if you have any issues

Regards, lordmilko

[jeremysmith1]

Awesome. I will try it out.

Were you able to set up a callback for the object creation? Or do you need to make a 2nd remote call, similar to the extension method written above?

[lordmilko]

I'm not sure what you mean by a "callback" in this scenario, but since no information about the created object is returned from PRTG, object resolution requires a minimum of three requests

1. Get all objects with the specified name under the parent object
2. Add the new object
3. Get all objects with the specified name under the parent object again

PrtgAPI will then compare the set of objects before and after the new object was created to identify who the newly created object was. If there was no difference between the first and second set of objects, PrtgAPI will try 4 more times after increasingly larger delays in the event your server is running slow and taking a while to create the object. If the object fails to resolve, an ObjectResolutionException is thrown

Then, if your object was a sensor, PrtgAPI will validate whether any of the created objects have a space prepended to the front of the name - since there is a bug in certain versions of PRTG wherein PRTG will add a space to the front of a new sensor's name (even happens in the web UI). If a leading space is found, PrtgAPI will helpfully remove it for you and then re-retrieve the sensors for you

As such, worst case scenario adding an object requires 9 requests. Best case scenario: only 3!