I have a dummy matrix driver with no data source connected. There is no matrix component used in the protocol, only source and destination tables. The crosspoints aren’t saved, so after a restart a need to remove all my internal DCF connections.
The problem is that in below code the interfaces doesn’t get loaded in the after startup QAction although the startupCheck boolean is set to true. Can someone explain me why?
Hi Jens,
As I understand this is for simulation / demo purpose.
In that case I understand you want to delete all the Connections at startup.
Would it be possible to test by retrieving all of the interfaces instead of already filtering on ParameterGroup
For example:
using (dcfhelper dcf = new dcfhelper(protocol, true, new dcfmappingoptions { pidcurrentconnections = parameter.map_connections, pidcurrentconnectionproperties = parameter.map_connectionproperties, helpertype = syncoption.custom }))
{
foreach (connectivityinterface itf in dcf.getinterfaces(new dcfdynamiclink(string.format(“{0}/{1}”, protocol.dataminerid, protocol.elementid), null))[0].allinterfaces)
{
protocol.log(“interface name: ” + itf.interfacename + ” | ” + itf.dynamiclink);
}
}
Hi Jens,
I’m not convinced it makes sense to remove all the internal connections after element startup. As you mentioned the current crosspoint info (in tables) are not saved, I imagine that as soon as possible after startup this content will be requested (polled) and updated into the element card. (offloaded in the tables)
I think it’s a lot of overkill to after startup clean ALL connections, and after a couple of seconds when you receive the current connection scheme to then (re)create all those connections. In most cases the amount of matrix switches that will happen while an element or DataMiner restarts will be rather low.
Instead, what you probably should do is:
- After element startup: guarantee the latest matrix info is requested asap and pushed into the respective tables.
- Sync your internal DCF Connections: new connections should be added, disconnects should be removed, and changes should be updated. By using the DCF Helperclasses most of that logic is already available to be used.
That way you don’t necessarily remove all your internal DCF connections (!! with possible DCF connection properties on) over and over with each element restart.
This solution will bring less load, and should have functionally a better result.
Good luck! If you have doubts or more questions: please share
Hello,
When using the DcfHelper class there is a safety built into the removal so that it only removes items that were created by that element in the past.
If you want to remove connections that may have been created from a different location you have to set the ‘force’ boolean in the RemoveConnections method to true. That could be the reason for the behaviour you’re seeing.
If the Startup check boolean is set to true, you should be guaranteed all connections & interfaces are present after startup, unless you’re trying to manipulate an interface that was added at runtime.
Though as indicated bij Thijs in another answer. Always removing all information at startup is a bad idea. Manipulating DCF can be heavy so you should avoid a lot of removal & creation where it’s not necessary. Better to leave the information and then remove/create/update as required.