What are the items to take into account when developing a DVE integration so that it will be future proof to use in SRM?
What preparations could already be done during the development of the connector to avoid changes when a function needs to be created?
Hi Mieke, from the current little experience we've gained it is important to have in mind what functions the device does and what resources will need to be made available from the device.
In case there are multiple resources of the same type, then this will rely on the instances.
Let's take the example of a chassis with two Embedder/De-embedder modules.
In regular DVEs a DVE will be created for each module.
However when looking at the functionality of these cards there are two functions, which result in 4 resources (2 resources of Embedder function and 2 resources of De-embedder function).
The function definition file needs a link to a table where it'll find the instances. In this case there are two options:
- a table with all 4 instances and a column with the type so that in the function definition a filter can be placed on the type column.
- two tables, each with 2 instances
To make it SRM proof having proper Relations and FK is Key for an easy Function creation in the future.
From the Function Definition prespective your entry point is a Table Pid.
If you only want to feature data on the DVE from the very same Table Pid, you are free to add as much Pids from the same table as you like.
If your Entry Point table will serve as a Parent Table to other data, make sure your Foreign Keys are up to speed in the child tables and your relations are also properly set up on your connector.
This way you will have your connector future proof and adding parameters from any table featured in the tabels relation chain(s) can be added without any connector adjustment.