Hi,
Similarly to what happens with the severity update (Param ID 3), which is automatically filled in by DataMiner, is it possible to have a parameter on the “Service Definition Basic” connector that gets filled in with the service properties?
Kind regards,
Flavio Meneses
Flavio,
This should be possible by implementing the appropriate logic within the service definition connector, since there are, already, calls that could be used to retrieve the properties associated to a given service. Below I show an example of such call using client test tool.
Hi Rene,
Thank you for your answer. Perhaps I could have been a more clear on my previous question.
The issue is not getting such properties. In fact, currently I have already implemented a polling methodology to get those properties. Nevertheless, I was thinking whether it is possible to go for a push approach, where software would fill in the property values in a parameter. Such parameter then could be used to trigger a QAction, which in turn could push to any other DataMiner element (e.g., through interapp communication).
As we are moving to a publish-subscribe era, perhaps this could be a feature…
Element properties do get pushed to the enhanced service element (under General parameters -> [Properties]). However, the service properties do not get merged into the Cube UI for the enhanced element. This could, indeed, be a future enhancement where we either merge the service properties with the enhanced service element or display a general parameters section for the service itself. It could also be that the service properties can be exposed to the Dashboards App.
indeed, property changes push a service update notification, which in turn triggers a QAction. In such QAction we can then get the current property values. Of course we don’t immediately know which property was updated (or if it was any other change that was notified), but I believe this would fit most of the use cases where this would be necessary.
Just to avoid any confusion, I will past here also my reply to Rene (to whom I am grateful for the input ).
“The issue is not getting such properties. In fact, currently I have already implemented a polling methodology to get those properties. Nevertheless, I was thinking whether it is possible to go for a push approach, where software would fill in the property values in a parameter. Such parameter then could be used to trigger a QAction, which in turn could push to any other DataMiner element (e.g., through interapp communication).
As we are moving to a publish-subscribe era, perhaps this could be a feature…”