Automating Ignition Gateway Configuration: Risk Assessment and Best Practices

I'm currently involved in a project that requires the setup and configuration of numerous Ignition servers. Our setup process generally includes a consistent set of changes, like creating database connections, tag providers, and adjusting the gateway security settings.

I know that all these configurations are stored in the config.idb folder and found that corresponding tables reflect each setting. Having experimented with this, I noticed that changes made directly in these tables are then visible in the gateway webpage. This gave me the idea to automate this process further, possibly with a PowerShell script or a single query that would expedite the configuration with just a click.

Although this approach could save us a significant amount of time and minimize human error, I'm mindful of potential risks involved with directly updating the configuration database.

Given my experience, I would like to ask:

  1. What potential risks could be associated with this direct update approach?
  2. What precautions should we consider taking to mitigate these risks?
  3. Is there a recommended method or existing tools for automating Ignition gateway configurations?
  4. Are there specific tables or settings in the config.idb that should never be altered directly?
  1. The exact content of the tables is not specified or guaranteed to remain consistent from one version to the next, and many are defined solely by add-on modules. Version changes could break your automation.

  2. Stay with one version across your enterprise until you've fully tested a new one with your automation.

  3. None whatsoever. But you can script it with bash and the command line sqlite3 tool. Probably something similar possible in PowerShell if you have to use Windows.

  4. Anything with binary serialization of java objects. Those cannot be manipulated properly without the module code that normally produces them. Also, make sure you make the SEQUENCES table conform to your inserts.

1 Like

Thank you, Phil

You have certainly given me valuable insights and helped me to better understand the potential risks and precautions of the automation approach I'm considering. I do have a couple of follow-up questions based on your response:

  1. You mentioned tables that include binary serialization of Java objects. Could you provide some examples of these tables and advise on how to identify them?

  2. Regarding your mention of "making the SEQUENCES table conform to my inserts", I think I understand the broad concept. It appears that the SEQUENCES table stores the ID (primary key) column values for all tables, which aren't set to auto increment. So, when I'm executing an insert, I'd need to update the SEQUENCES table to increment the ID of whatever table I'm inserting into. This would prevent Unique key constraint errors if a configuration is added directly from the gateway webpage. Could you confirm if my understanding is correct, or if there's anything additional that I need to consider?

Your insights have been very beneficial, and I look forward to your further guidance.

  1. I'm pretty sure you'll recognize them.

  2. SQLite has had issues with autoincrement columns and recommended not using them (at some point, maybe no longer true). So IA handles it manually, and you must too.

1 Like