PushDCIData struggles

Started by cbwecomm, August 24, 2025, 09:47:57 AM

Previous topic - Next topic

cbwecomm

There seem to be very little info or examples of this...  I'm trying to update some tables and I can't seem to find any solution after trying everything I can think of.   Does anyone have a working example?

    testTable = new Table();
    testTable.addColumn("GUID");
    testTable.addRow();
    testTable.set(0, 0, node.guid);
   
    result = PushDCIData(node, dciId, testTable);

Filipp Sudanov

There's UI drawback that tables show same list of Origins as single-value DCIs, but in reality only Agent, Internal, SNMP and script sources are availble for tables. So it's not possible to push into table DCIs, but you use Script origin. 

cbwecomm

Hmmmm, Ok that's unfortunate.  Is that a difficult limitation to overcome, or something that just needs some time and programming to fix?  (being able to push data into table DCIs from NXSL scripts outside of the Agent, Internal, SNMP)

I'm not sure if a Script Source will work, because that's going to run on a schedule correct?   I was hoping to use Table DCI's to push information into on demand (or, when a script is run manually via an Object Tool); not something that needs to run on a schedule..also, different nodes might need different columns, and the columns might be or might need to be updated at different times.   I guess I can do a "one script does everything" but that could end up being thousands of lines to cover every situation, and the table DCI would likely end up with a large number of tables that are unnecessary also.  I was trying to make this efficient and streamlined by only running smaller scripts as necessary, and only reading/writing into the tables as necessary, as well. 

I might be able to do this under Agent, but some of my scripts work under the Node context and so I guess I would have to somehow pass a node ID to the Agent, so the agent would be able to pull and push information to the Node's table DCI?

Part of what I'm trying to do (or, one of the challenges I'm running into) is that the "perfect" way to do certain things, ends up putting data and values all over the place.  Sometimes it seems Custom Attributes are best/easiest, other times it seems recommended to use Persistent Storage, sometimes Server Side Custom Attributes make the most sense, etc.   It certainly works, but it feels like this can get out of hand quickly with complex scripts and configurations and a large number of nodes.  A lot of things would work great in Persistent Storage, but it is basically a two column list that seems to grow into tens of thousands of items easily if it were to be used by even a few scripts on a large number of nodes. 

I was trying to contain everything random in a table DCI, with the necessary columns (which also take advantage of security permissions which Custom Attributes dont, and are specific to the node (which Persistent Storage is not). 

Are there any other recommendations? 

Thanks!

Filipp Sudanov

This can be discussed with developers, but we need to understand the use case in details. 

So the idea is to keep like misc metainformation about the node? Would be nice if you can share a screenshot of what you keep there (via PM if needed). 

As a brainstorm - this can be just stored in node's comments as markup-formatted table. Or yes, to use Table DCI for that. You can have a context dashboard that automatically opens in a tab and displays contents of that table. 

Yes, tables with script source are collected on schedule. Also you can force collection by using 
forcePoll() method of DCI class (https://netxms.org/documentation/nxsl-latest/#_instance_methods_8)

Yes, in this case you'll have one script for all nodes. Buy you can call other scripts from that script. And you can pass parameters to that script (in metric field in DCI's properties)