Hi, I’m looking for best practices in driver development. I have heard several opinions about whether in a new protocol I should add a “retrieved” column to a SNMP table (maybe saving some memory and computational power), or whether the SNMP table should be copied to an all “retrieved” table making it more “future proof” (in terms of version control) at the cost of memory.
What is your opinion regarding to this?
There is always a balance in what we do. If you’re ever unsure about a decision like the posted question then within SysDev we should generally all try and move in one direction. We go with: KISS. Keep it Simple and Stupid.
It’s ok to program in a certain way, using design patterns to make sure maintenance is easier. But it has a nasty pitfall of ‘over-preparing’ for something that ‘may happen’ in the future. This can lead to complicated code for the small thing you’re trying to add right now.
In this case I would say: better to add the retrieved columns behind the SNMP ones and deal with the problem of adding more SNMP columns later when the problem is actually something to tackle.
If you then encounter the problem then remember:
it is not possible to have; SNMP – Retrieved – SNMP
It is however possible to have: SNMP – Custom – SNMP (if you don’t use the basic getnext snmp retrieval) (OK: getnext+multipleget, MultipleGetNext, MultipleGetBulk)
So if you need to add more snmp behind retrieved, the correct flow is
- Simply request and create a new Major Change range. In a lot of cases, it’s only about moving IDX’s which will only impact specific external applications like through the webUI. Most elements & AS’s use the PIDs of columns (except in the case of doing a full external gettable)
- Without Major Change: Change retrieved into custom. Adjust the quickactions to take that into account. (no use of setcolumn)
- Without Major Change: If adjusting the quickaction to set cell by cell is too impactful, the alternative way is then and only then consider moving the snmp to a new table, adjusting current table to be fully retrieved and doing the copy quickaction then.
Hi Flavio,
Would it be possible to provide an example of what you mean of making it “future proof”? The main downside of copying the retrieved data is having extra load to copy it, having the duplicate data available in the SLProtocol process and if we are not careful having it also duplicate in the SLElement process when we are not hiding the root table e.g. the snmp table.
In case you are thinking of the case where the communication method to retrieve the data would change in the future e.g. an API, we need to make major changes in the driver and to keep the impact to a minimum we can reuse the same parameters of the snmp table and remove the snmp definitions from it.
For example
SNMP communication:
Table 100 with 3 snmp columns (101,102,103) filled in via polling the table
Change to HTTP communication:
Reuse table 100 with 3 retrieved columns (101,102,103) filled in via logic after polling a session
Retrieved columns are only required in SNMP tables when some of the data polled via SNMP needs to be parsed or processed in a QAction. As long as this is not the case, you should not add any retrieved columns.
Having a fully “retrieved” table based on SNMP data can be done if you for example want to combine multiple SNMP tables in a single table in your protocol.
The question is not if the snmp table needs or not the retrieved column, that’s a fact, it needs.
The question is:
– Is better to add a retrieved column the snmp table or if it’s better duplicate the entire table into a retrieved one (all snmp columns plus the new column).
Before we used to go for the first option, but apparently now there’s some different approaches.
I don’t see any reason why we would still not go for the first option in this case by adding retrieved column(s) directly to the SNMP table. Interested to know though what the benefit would be of creating a completely retrieved table for this.
For an initial development of the table the way to go is to have the snmp table with the retrieved column added to it. If you ever need to add extra snmp columns to the table then you could have problems if you leave it like that (retrieved columns between snmp columns) and moving the retrieved column with one position breaks the range version compatibility, in that case the snmp table needs to be polled as a hidden table, the old table needs to be changed into a full retrieved table (so PIDs don’t change) and then the snmp columns need to be copied over there.
To summarize:
-Adding new snmp table = display snmp table with retieved column
-Adding extra snmp column(s) afterwards = displayed table becomes fully retrieved, snmp table is now polled hidden and values need to be copied to the displayed table, this to keep version range compatibility but will come at a performance cost
Laurens comment contains the correct answer, this can be closed.