NetXMS Support Forum

Hi all,

It would be great if NetXMS could create containers, conditions, nodes, bind objects, etc., within a Auto Bind filter script  . In this way, we could not only filter by IP, but after create a group of containers will hold node, customize and autobind it. So automatic network discovery would be complete.

For example, suppose I want self-discovery a node IP 192.168.1.100, and when it has been discovered, NetXMS create a new node name "New Node", just under a "Routers" existing container, but previously creating two sub-containers "City -> Zone" hanging from "Routers".
My desire Auto Bind script could be something like:
If $ node->ipAddr == 192.168.1.100    {
   CreateContainerGroup ("Services.Routers", "City",)   //Step by step
   CreateContainerGroup ("Services.Routers.City ","Zone ",)   //Only one step
   CreateNode ("Services.Routers.City.Zone"," New Node ", 192.168.1.100);
   return 1;   //Apply Auto Bind
   }

return 0;   //Nothing to do

This will require a few new functions for Accessing Object Data:
CreateContainerGroup (<path from root>, <container name>, <bind to object name>)
CreateNode (<path from root>, <node name>, <ip address>)
CreateCondition (...
...

I hope someone else had this need.

Thanks in advance

Hi!

Scripting slowly moves to more and more areas of NetXMS I agree that creating and binding objects from scripts is a very good idea. I'm not sure, however, that auto bind script is the best place to create additional objects. For network discovery purposes, additional hook will be better. For example, it can be done that way that for each newly added node system executes some script from library. Or take more generic approach, and allow script execution as action in event processing policy - that way you will be able to execute your script on each SYS_NODE_ADDED event, as well as do many other things for other events.

Best regards,
Victor

Hi Victor, thanks for your reply.
I completely agree with you, event processing policy is the best place, but now the binding process should be made by calling corresponding function from script.
I'm trying to use NetXMS in a fairly extensive network (more than 400 locations) and manual deployment work (object by object) is quite hard, since many of data to be incorporated into NetXMS come from external data sources.
It would be extraordinary through scripts we could automate any action we can do through menu options: create, modify, binding, removing objects, ...and if it were possible to read and write text-delimited files on the server, we could do anything in NetXMS. Sounds great.
Best Regards.

To handle a large amount of objects could also be interesting to have a special tool to read a formatted text file and load it on the NetXMS server in batch mode.

Hi!

Is there any news about these requirements?

Best regards.

No news, sorry. I keep this in mind, but there are always something to do. Now I'm trying to create to-do lists for each release and follow them. 1.1.8 is already scheduled, so I have added to 1.1.9 to-do.

Best regards,
Victor

Nothing happens, too many things 

As a workaround, I am currently using a AutoIt script in the new java console. That script reads a external text file and create new containers, node, conditions, assigned to them several properties, transformation scripts, etc..
But I have real difficulties with interfaces list, for example to select all interfaces of a node or an interface with a certain IP, to define DCI's for one or more interfaces, etc..
Perhaps this would be easier showing all interfaces in a SysListView32 tab control in addition to deploy it in a SysTreeView32 control.

I'm actually slowly moving towards ultimate goal - be able to do all this from NXSL scripts. Starting from 1.1.10 you already can run NXSL script as an action. Now I just need to add all necessary Create... functions.

Best regards,
Victor

Hi Victor.

So all these limitations disappear?

QuoteMost notable one is very limited access to data outside script boundaries. For
example, from NXSL script you can neither access files on the server, nor call external programs,
nor even access data of any node object, other than the one the script is running for.

Best regards

Hi!

Not all. I think that NXSL script should not access external files or programs. If you need that in actions, you can run external script as an actiopn. But access to other objects are possible now. There are few functions which allows you to search for nodes and other type of objects.

Best regards,
Victor

Hi!

Since 1.2.0 version there are few NXSL functions for object manipulation:

CreateContainer
RemoveContainer
BindObject
UnbindObject
FindObject

I'll add descriptions for them in wiki (http://wiki.netxms.org/wiki/NXSL_Function_Reference).

Best regards,
Victor

Hi Victor.

Awesome!!!, thank you very much for these new features.
By the way, bindobject can bind one container to another container?

Best regards.

Yes, BindObject can bind all objects that can be bound from console - nodes, subnets, clusters, and another containers.

Best regards,
Victor

Wow!! Happy as a lark

Please, can you check out BindObject wiki entry?

Best regards.