Hi Dojo,
I've bumped a few times in element tables where the user can add a new row:
the "export table" is always defined - sort of DataMiner default behaviour,
but importing rows from a CSV file is not always present (it seems to be depending on the implementation of the specific protocol):
Are there any guidelines available?
Where viable, I'd like to always have the possibility to ADD NEW ROWS from CSV upload or "Add N Rows" like the one recently added. Keen to find out if this has to become a feature suggestion or it can be normally sorted within the related protocol.
Hi Alberto,
The possibility to export a table is default DataMiner behavior. The possibility to add new row(s) is something that is custom defined in the protocol.xml, for more info see help how this is achieved.
Importing a table is not standard DataMiner behavior because of the following reasons:
- Data is usually entering through communication with a device, e.g. through SNMP. It would not really make sense here to import the data through csv and then it gets overwritten with the next poll.
- Functionality of the protocol.xml could be depending on data in other tables (e.g. table A has a column from which value depends on other columns of tables B and C). Simply overwriting that column from table A could be displaying something that doesn't make sense anymore. The functionality to determine the value in table A could only get triggered with a change of polled tables B or C and if those values are stable then no trigger goes of.
- Changing multiple values at the same time could require extra input with values that depend on each other. Like when clicking on "add row" that a popup is shown with the needed items to be set.
- Exporting data is based on the client cultural settings, e.g. datetime format. When importing the data again it would need to be in the exact same format.
Because of above reasons it's better that the protocol.xml implements the functionality that needs to happen when a (config) table import is feasible. This way the importing is properly handled (e.g. input value validation between 2 different columns) and all other related data in the element is handled accordingly.
I can think of examples when an add row would not immediately mean that there should be an import table functionality. For example an SNMP table could have an add row functionality that is again having device communication involved. Having the import table functionality is something that would be hard to support by default in DataMiner, so this requires custom implementation in the protocol.xml which is the responsibility of the developer and is something to be agreed between the developer and the end user that orders the protocol.xml what functionality needs to be included.
I get your point, Laurens – indeed it makes sense if this is handled within the specific protocol. In such a case, are there any guidelines to achieve this?
Any caveats to be considered for a CSV upload implementation?
You mentioned the regional settings for date formats – how does this work when CSV upload is implemented?
I admit I might be biased by my previous use-cases, yet from the subject line, can’t really think of many cases where if the user adds a row, then he will not need to add multiple rows at once.
Limit case: could we consider a row as a mini-table with multiple columns and just one row?
:/
Thanks for the comprehensive feedback, Laurens – appreciated.
Would there be any guidelines for cases where this is viable and a big improvement for the protocol (from a user experience perspective)?
Based on your list, I’d say point 1 & 2 are clear examples where the import should not be implemented. I’m sure a workaround is available for case 4, as many protocols already implement this mechanism when config parameters for the device can be entered via DataMiner (e.g. NX4600 https://catalog.dataminer.services/result/driver/4250 had a table supporting the CSV upload to specify the multicast groups & sources that the encoder should listen to, in order to receive the video feed – entering each single line via GUI wouldn’t be the smartest of the exercises from an automation point of view, especially if the info is already formatted in a file that can be imported – I used to define one row via GUI, export the table, reimport the table with all the required rows – fast and easy).
Which leads us to case 3: essentially, whenever an “Add Row” is implemented in the protocol for a given table (where the export is always available by default), wouldn’t it make sense to always build the “Import Table” command so that multiple rows can be entered at once?
Use cases are the one listed above for e.g. multicast sources to be added on a device as part of configuration parameters, but also any element with a table that is essentially a GUI for what would be an “INSERT” into a DB-type of element.
I’ve been working recently with a bespoke (non-SL) protocol that really lacks this feature – so I’m looking for options & guidelines for the dev team, to get the feature implemented. Any steer will be helpful.