I have an element which needs to simulate 255 DCF interfaces and each DCF interface needs to have 4 properties.
Setting up the simulation executes following steps in one single QAction flow:
- Fill in interfaces table by using FillArray method
–> Software will create a DCF interface for each entry in that table - Get the DCF interfaces
- Assign properties to each DCF interface
The problem is that in step 2 the DCF interfaces aren’t known yet in SLProtocol.
How can I make sure that all the DCF interfaces are available before continuing?
Hi Jens,
Since it looks like you are trying to set up a simulation I am guessing this will not be done constantly so you could go with the approach of:
- In step 1, store the references to the interfaces table
- Perform step 2 in a Retry loop, where you attempt to retrieve all interfaces and compare them with the ones you need. If some are still missing, you add a small sleep and try again afterward (while stipulating a maximum time to wait)
- If the previous retry mechanism was successful, you can now assign the properties
From what I have seen in the past 10 seconds (10 retries * 1 second) may not be enough for all of the 255 interfaces.
Typically, for this amount of interfaces, it is going to take a bit more time, something like a few minutes.
Seems that there is an issue when I fill in the table that generates the DCF interfaces and try to assign properties to it in the same QAction instances. The work-around was to execute a new instance of that QAction to set the properties.
A (subscription) event is sent whenever a change happens to an interface. You could subscribe to InterfaceInfoEventMessage (filter this on your simulation element) and count them.
Note that this is an internal API and we do not recommend using this, as it is not officially supported and we cannot guarantee that it will still work in the future. As a rule, you should avoid using subscriptions, as these are subject to change without notice. We recommend to instead always use the correct UI or automation options provided in DataMiner Automation or through our web API.
Thank you for the suggestion Sebastiaan. This is something that I will definitely try in protocols. I think that it’s a bit tricky to use this in automation since I see this more as a linear flow and this would involve a kind of multithreading.
I tried it with a sleep of 1 second and max of 10 retries but it still isn’t known