Duplicate perspective page

Ignition
1

I am looking at creating a sandbox environment for a current project.
There's already sandbox apis and sandbox named queries created which functions properly outside of perspective module.

Currently, I've got a perspective UI setup and running with various named queries/ apis/ scripting calls, etc. There's multiple pages with multiple components and a lot of data binding using named queries in the UI.

So, all the sandbox perspective page needs to do is point all the named queries and api paths to the sandbox ones rather than the production.
Usually, I've tackled this (outside of ignition) by switching the database/ api connection string which means I can switch between different environments at my own choosing. Usuallly, I put a combo box with allows the user to swtich between the 2 environments and provide a visual medium (like different colors) to let them know that they are accessing a different environment.

But, because there are a lot of named query bindings in the perspective components, I am not sure if passing a param to the page (or using 'Views as Templates') and then based on the param value, change the binding path would be possible/ the elegant solution.

Have you come across a scenario like this? Any thoughts?
Is there another way of looking at this?

I am currently looking at writing an automation script that copies and changes the named queries/ api connection names and points them to 'sandbox' from ignition's 'data/projects/perspective' folder. Wondering if there's a better ways of tackling this.

Thanks!

2

Don't do any of this. Simply set up another Ignition instance (using trial mode if you like) in an environment that mimics the real production environment, with replica databases and simulated PLCs. Ideally, mimic down to the IP address. You should be able to take a production gateway backup and drop it in your dev environment and everything "just work". Then you have a valid "sandbox" that requires no contortions.

2 Likes
3

This does seem like an elegant solution but there's extra cost associated with it.
We'll need to commission and maintain this extra server.
And, every time a change is made in the main perspective ui, the sandbox will need to be updated and the connection names changed manually.

4

It is different costs, in place of risk of disruption of production systems. What is your cost of downtime? How do you currently manage that risk? How much do those management tasks cost? And how effective are they at preventing downtime? How do you manage the changes in projects required to move from sandbox to production? How do you ensure that your QA testing in a sandbox faithfully forecasts how the component under test will perform in production, after those changes for production use?