Hi All,
I am attempting to determine the expected payload for a SetDataMinerInfoMessage message, the current NotifyType I am interested in replicating is NT_FILL_ARRAY_WITH_COLUMN.
This call is intended to be called with the NotifyProtocol method within a protocol, but this option is not available for Automation Scripts. As I am unable to find an equivalent alternative for automation scripts the next best thing would be to use the underlying SetDataMinerInfoMessage call instead.
The trouble with SetDataMinerInfoMessage is that it contains many fields: What, IInfo1, IInfo2, bInfo1, bInfo2, StrInfo1, StrInfo2, Uia1, Uia2, Puia1, Puia2, Sa1, Sa2, Psa1, Psa2, UiaNotifier, ElementID, Var1 and Var2. Depending on the call you make the fields that are required vary massively with little consistency between each call.
I have used this call many times and managed to work out the expected payload by following a cube session in the client test tool. This works well for calls made by the client, but it doesn't appear to work for QActions. If I follow SLManagedScripting, I can see other SLNet messages such as GetPartialTableMessage, but not any of the SetDataMinerInfoMessage.
This leads me back to my goal of working out NT_FILL_ARRAY_WITH_COLUMN which can only natively invoke in a QAction. So my question is, is there a way to sniff out SetDataMinerInfoMessage calls?
Alternatively, I would settle for documentation breaking down each NotifyType with the expected payload for its corresponding SetDataMinerInfoMessage. But I imagine this is not likely something you would want to provide to customers as it's not intended to be called directly.
Any help will be greatly appreciated.
Thanks
Hi,
We do not recommend the use of SLNet calls in scenarios like this as these are internal calls that are not officially supported and we cannot guarantee that they will still work in the future.
We recommend instead always using the correct UI or automation options provided in DataMiner Automation, QAction, or through our web API.
In the specific case of the SetDataMinerInfoMessage, it is a call that can perform multiple distinct operations which use all those fields you listed.
Those fields are not very easy to document for such a reason and for your specific use case, I would advise either using a combination of IDmsTable.GetPrimaryKeys with IDmsTable.GetColumn and IDmsColumn.SetValue to perform the sets in a loop or to serialize the data and send it to the element as a single set and then have the element itself do the NotifyProtocol call from a QAction.
The advantage of the first option is that the connector does not need to be modified at the cost of some performance due to the need for more calls.
Thanks João,
I totally understand that there is a level of risk associated with using internal calls. I am going to be a bit cheeky and mention that DmsTable already uses a bunch of SetDataMinerInfoMessage calls for AddRow, RowExists, SetRow and DeletRow.
There is always going to be a risk no matter what calls are made. For example, if a breaking change is made in the DmsTable library any protocol/automation script made by a customer would then have to be updated to fix any issues.
As a customer, we know about this first hand when we updated SRM and it broke dozens of automation scripts. We can accept the risk if it is the better solution at the time the decision was made. (Sorry, this is not a dig at you, just seen this argument mentioned multiple times).
Regarding your proposed solution, this is 100% how I started to approach it, but it dawned on me that this is not going to be good for large tables. If you have 10,000 rows, updating each cell in a column, that’s 10,000 requests to SLNet, the DataBase, any clients connected to the element, and anything subscribed to the table such as services.
I would rather take the slightly risky option of using the corresponding SetDataMinerInfoMessage for setting an entire column currently available for Protocols.