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 Aston,
The NT_* notifies are an internal messaging system that actually have two separate handlers. One is SLDataMiner, and the other is SLProtocol.
The problem is that each process implements the calls that were designed for it, or those that have to be shared between the two as they were developed.
As such, not every NotifyType is supported by both processes and will only work when sent to the intended process. When using QActions, protocol.NotifyProtocol() will send it to SLProtocol, while the SetDataMinerInfoMessage request will send it to SLDataMiner. Some of the messages intended for SLProtocol will then be forwarded to the SLProtocol by the agent hosting the element.
Our documentation explains the notifies that are safe to be called by user code: NT Notify Types | DataMiner Docs.
I've checked the SLDataMiner code, and it looks like NT_FILL_ARRAY_WITH_COLUMN_ONLY_UPDATES (336) | DataMiner Docs is supported, while NT_FILL_ARRAY_WITH_COLUMN (220) | DataMiner Docs is not.
So using this notify, you may have some success in setting rows directly.
Now, the reason that SetDataMinerInfoMessage is complex is because it is a generic wrapper for all internal notify types, which do not have a fixed structure aside from having 2 input arguments and an output argument. As such, the message facilitates different typed input values for both arguments, that can be serialized. It can't accept objects like protocol.NotifyProtocol does, because the data needs to be serialized for the wire first. So your the input argument used, is the one that matches the notify type. It is possible that not every notify is compatible with SetDataMinerInfoMessage, because they were not designed to be used this way.
Thanks, Floris!
Thank you for the insight, I wasn’t aware of there being two handlers at play, I was on the assumption that there was just one.
SetDataMinerInfoMessage will likely still remain a mystery when it comes to expected fields and what options are available with each handler.
You are indeed correct about NT_FILL_ARRAY_WITH_COLUMN_ONLY_UPDATES working with automation scripts while NT_FILL_ARRAY_WITH_COLUMN does not. Based on this I have managed to create a method to set a column from an automation script. I have created an answer on this thread for those who would like to replicate it.
I guess my initial question regarding sniffing out all SetDataMinerInfoMessage calls using the client test tool, will likely come down to the handler. If it was handled by SLProtocol it will likely not be shown whereas if it was SLDataMiner there is a chance to see it via a follow.