Is it possible to create an element/service/view providing the id in the create method itself?
(DataMiner doesn't create the id for you, you specify it yourself)
With profile definitions/ profile instances/profile parameters/resources/... it's possible to specifiy the id.
In this case the id is a guid not a dmId/"Object" Id combination. But it does allow to have the same id for the same profile/resource/... across a dev/staging/production system.
(If you want to rebuild/deploy the same system this might be usefull as well.)
I would actually like to be able to define my entire setup as code (potentially not even using cube to create/deploy the system) e.g https://community.dataminer.services/provisioning-and-managing-dataminer-using-ansible/ or using an install package
On a staging I won’t have all the actual devices, so when deploying to staging I want to be able to setup simulations (snmp/ https://community.dataminer.services/documentation/copy-element-data/
https://community.dataminer.services/download/protocol-debug-tools/
/… )
I also want to make sure that dashboards, low code apps, all other related (future) components keep on working that uses the id.
e.g Including (Function) DVE’s.
With the SRM solution, I can simply export the configuration, place it in a git repo, do some small changes in the git repo and then deploy it.
This makes going between dev/staging/production pretty easy as compared to before.
When using Cassandra/Elastic cluster it might become even possible to deploy your production on more or less nodes.
Hi Tim, this is not possible. I understand the use-case, but in your infrastructure as a code process, I would prefer to use the name, which also has its down-sides of course. Still, it should allow you to validate whether some objects already exist on the destination system before installing a script. If these exist, you could do updates on those detected objects.
When relying on IDs you also cover only the use-case for the production/stating setups. If you would create a more generic app, usable on different systems you would not be able to maintain that 'same id'-requirement.
I think the more important question is what are you trying to accomplish that can’t be accomplished with a DELT export? ID’s in general tend to be something that are determined by the managing system (e.g. a database or dataminer). DataMiner Element Location Transparency should allow you to rebuild/deploy the same system with dmimport packages.