What is the benefit to using any of the HTTP functions in Vision or Perspective?
Currently we are developing just for our plant, so all the clients and sessions are (currently) used on site only.
My latest rabbit hole took me into the HTTP stuff, which led me into possibly programming an API? layer between Ignition and the database server...
Looking for some guidance if we should go that route. IF the powers that be decide they like out setup better than what they are currently overpaying for, then what? Would that necessitate building that extra layer?
And, IF we go that route, it seems like there would be more gateway traffic - how much can it handle? Perhaps splitting the process/logic between HTTP requests (API layer?) and Ignition would be better?
(I am not sure I am using the correct term for that layer between Ignition and the database.)
Simple example from some time back:
Customer has a third party vibration monitoring platform that exposes warnings and statuses via HTTP, we scripted a HTTP layer to periodically retrieve updated statuses from the vibration monitors to add to the other motor data on screen for single pane of glass operator interfaces.
Well, I am trying to learn how to use Visual Studio instead of the SSMS. I have a production DB and Dev DB, which are vastly different. I also have several projects that need to use/reference some of the same data. So, I asked AI some questions and this rabbit trail landed me at the following:
Use a Dev - Test - Prod setup for databases and Ignition Projects
Use Visual Studio to make the database changes to Production easier and with less problems
(Using separate projects for each database allows for quicker/easier changes)
VS also makes version control easier, but I have not quite embraced that yet - still working out the kinks/details
Use an API layer because of the overlap in data needs between the projects
Build a VS solution for each Ignition Project
an API call could be used by both gateways but to different databases
and AI kept going with all the other stuff I could do and why I should do it.
I figured that if more than one Ignition project used the same DB calls, maybe the AI has a valid point. To be honest, with how the needs and wants of our users are scaling up, it is a bit overwhelming trying to figure out a good way, moving towards the right way, of building this from the DB to the UI.
You don't have a dev DB in this case. A Dev DB is a mirror of the schema of the production DB with only changes that are ready to test on a live system are rolled onto. When you move features from dev to production, they should have the same exact schema on both databases.
Using containers/virtual machines/whatever you want to replicate your technology stack as faithfully as possible between environments. Putting in the API layer as you've described is adding a single point of failure and significantly increasing complexity of deployment and management.
