We have a Developement Gateway that has multiple tag providers on it. We want to use a "global" UDT that is pushed to each tag provider by an EAM task so that all tag providers are using the same tags/structure, etc. The issue comes when the tags are then pushed to each production site. We have History providers that are named uniquely per site to maintain separation when they are running on a mutual gateway such as the development gateway. I am trying to come up with a way to have one source that could be referenced by each instance to get the default database or some other means of naming the History Provider. The best thing I have come up with is to create a parameter that would then need to be populated for each instance created. This seems to be kind of clunky. I know I could use the multi-instance wizard which would make creation a bit simpler. But if I wanted to use that tag provider as a template, it would mean manually updating each and every instance.
Seems like there should be a way to get the instance to reference the default database much like queries can do that if the default database field is left blank.
Any suggestions would be greatly appreciated.
This only works within projects, not for global scope (like tags). Global scope does not have a default database.
You need a parameter. You should automate instance creation (system.tag.configure) to set that parameter where needed.
2 Likes
I'm dealing with a similar challenge and a similar architecture. One persistent dev machine that connects to simulator devices in a lab and then has tag providers representing each project site, then eventually those projects move through the devops pipeline to standalone production outstations with their own devices/data sources and which we may never see again. For now, I'm doing lots of manual regex/find-replace in tag structures.
1 Like
Consider making your persistent dev machine and its device simulator exactly mimic your production environment, right down to IP addresses. And so too with any Test and QA environments in your devops chain. So there is no substitution at all when deploying. I would argue that testing and QA is invalid if you have to change the deployment package.
1 Like
The problem is we have one lab with various relays and controllers to source and simulate data, and we have dozens of sites which we work on simultaneously until handover. We need to use VMs or containers to have test/QA environments for each of these sites. Thankfully, we get to commission all of our sites in the production environment before they are actually operating - so we're still not pushing to an active production environment even in that last step.
1 Like
You state this like it is a problem. You aren't already using VMs or containers? This sort of this becomes much easier if you do.
1 Like
Interesting idea. I have never done that but I can research it a little. My only other solution is to update each instance so that it overrides the UDT so subsequent changes to the global UDT don't affect the instances.