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.)
Thanks!
The purpose of the HTTP functions is...to talk to HTTP servers.
If you already have a database, I would not eagerly abstract away an HTTP layer in front of it.
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.
We use them all the time at customers that have other services at their plant we need to read/write. ERP systems mostly.
layer between Ignition and the database server...
Why is the standard database connection not sufficient?
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.
My scratched out view...
Am I making this too complicated?
@paul-griffith What reasons would you give for this?
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.
