NetXMS Support Forum

Technically it's possible, but there are lot of licensing limitations, especially for using Google maps in desktop applications. My initial implementations was based on Google maps, but then I read terms of use and switched to OSM. Limitations that I can remember so far are:

1. You cannot access tiles directly - you have to issue rendering request each time you have to display map. For example, if you resize map window, you have to do new request to server with new map size.
2. Caching is forbidden
3. Map size is limited to something around 600 pixels
4. You cannot glue pieces of the map together to create a bigger map - that means that you cannot create large full screen view with geo map
5. You have limits on rendering requests per day
6. Google requires that application which uses Google maps should be publicly available - it's not clear if it's enough that source code can be downloaded, or monitoring service itself should be publicly available.

Of course, if you purchase commercial access to Googe maps, you will not have those limitations. If somebody wishes to integrate access for commercial Google map services, we can do it.

Best regards,
Victor

Hi!

Ideal would be read-only access to device with SNMP. If it's not possible, output of nxsnmpwalk for given OIDs would suffice. If you can do that, then I'll take a look at Nexus MIBs and let you know what OIDs are needed.

Best regards,
Victor

Yes, pushing results is another option. You can push events using nxevent tool, or push DCI values using nxpush.

Best regards,
Victor

I don't see any problem with DCI configuration. However, from the agent trace I see that server does not connect to agent at all. What DNS name/IP address set as primary host name for the node object (on communication tab in properties)? Try to do forced configuration poll (right click on node, then Poll -> Configuration). Maybe connections initiated by server process blocked by firewall?

Best regards,
Victor

You should get string value from that script with nxget. Agent will return first line of output, not return code of the script. As your DCI has integer type, you are probably expect to get some numeric value. For example, to write line to a log and return value of 1, you script should looks like

@echo "Test" > C:\test.txt
echo 1

Best regards,
Victor

You should not use start there - it starts given command asynchronously, not waiting for it's completion. Agent will never get the output of the command. How you CMD file looks like? Also, you can try using form

ExternalParameter = cmd.exe /c C:\NetXMS\Test\Launch.cmd

Best regards,
Victor

I can think of the following ways:

1. Schedule external script using system scheduler and write result to a file; then you can get into DCI content of that file, which can hold execution result of and external script, and fact of such file presence and/or last modification time.

2. If you have long-running script which should be executed with fixed intervals, you can use external parameters provider. It works by running given script periodically and caching the results. Then, when server requests value of provided parameters, result from cache is returned immediately.

There are also a lot of possible variations - like starting external script from server using actions, and so on.

Best regards,
Victor

P.S. I start thinking that having some kind of scheduled jobs in the server could be useful in situations like that.

NetXMS server does 3 retries after timeout error, resetting agent connection before each retry, because most common cause for timeout on getting parameter is communication problems. Long-running external parameters are bad anyway, because server uses one connection for reading data from agent, and parameters are read in order. So, if one parameter request takes too long, collection intervals for others will shift.

Best regards,
Victor

Ok, so it looks like agent returns something. I suppose that you don't have wc command, and so it just returns first line of dir output. Next question is why you don't see DCI value in management console. Can you post a screenshot of DCI configuration?

Best regards,
Victor

Try to run the following command on management server:

nxget <agent_ip> Test

What result you get?

Best regards,
Victor

Yes, I plan that next release will be 1.2.0. Current 1.1.x branch is stable enough to consider it new production version and drop 1.0.x branch.

Best regards,
Victor

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!

No, it isn't. Actually I don't touch this file for years. Many of featrures listed in that file already implemented, but some really important still not Currently I maintain my ToDo in internal Jira. Current list of open issues scheduled for 1.2.0 release looks like this:

Bug

    [NX-75] - Button "Test" is not working on DCI transformation property page
    [NX-80] - Reports not working on Windows
    [NX-89] - Cannot delete non-existent object from event processing policy

Improvement

    [NX-3] - Ability to set native agent port on node creation
    [NX-4] - Add support for INFORM messages in trap receiver
    [NX-7] - Apply policy to node by clicking on node and selecting policies from list
    [NX-18] - Improve dashboard configuration tools
    [NX-57] - Add certificate authentication to Java console
    [NX-85] - Implement drop column functionality for SQLite
    [NX-87] - Add web interface to WIndows installer

New Feature

    [NX-2] - Autodiscovery: user should be able to set default settings for discovered nodes (e.g. no agent, no snmp)
    [NX-5] - automatically create ChildStatus DCI when Network Service object created for Node
    [NX-10] - Use Spanning Tree data for network discovery
    [NX-33] - Implement configuration export in Java console
    [NX-35] - Implement concept of "normal" interface state
    [NX-38] - Add additional page for containers where threshold violations for underlying nodes are shown
    [NX-43] - Allow per-DCI SNMP version settings
    [NX-50] - Add possibility to add parameters and/or specify entry point in scripts called via %[] macro
    [NX-51] - Ability to copy/paste scripts in script library
    [NX-63] - Timed alarm acknowledgement
    [NX-71] - Add new policy type for distributing log parsers
    [NX-88] - Implement data export from log viewer
    [NX-90] - Implement alarm comments

Best regards,
Victor

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

Do this node have correct IP address on interface object too?