We have a project currently in production running Ignition 8.1.43, and we are planning to start a new phase of the project next month in a new customer.
The customer has requested API integrations, and from our evaluation, Ignition 8.3 seems more appropriate for this use case. Please correct me if this assumption is not accurate.
A new team member mentioned that upgrading to 8.3 would require the SQL Bridge Module and the Industrial Historian Solution Suite, even though:
-
Our current 8.1.43 project does not use SQL Bridge
-
We already use Tag History
-
We already have Microsoft SQL Server connections
-
We do not have either of these modules installed today
Given this context, I would like to clarify:
-
Are SQL Bridge or Industrial Historian Solution Suite required to upgrade from Ignition 8.1 to 8.3?
-
Are there any scenarios where these modules are mandatory for API integrations?
-
Is Tag Historian + database connections + scripting sufficient for this architecture in 8.3, as it is in 8.1?
Any guidance or confirmation from the community would be appreciated.
Thank you in advance.
You shouldn't need anything different for modules than what you currently have.
SQL bridge is primarily for transaction groups. NOT for connections to SQL servers. No change there.
You've got a historian module of some sort already. The Suite just adds more modules that if you don't need, you don't need.
3 Likes
This (not as an indictment on you, just as a general statement) means literally nothing. It's underspecified; "API integrations" could mean virtually anything.
If this means consuming a REST API, then the base Ignition platform can do that out of the box via system.net.httpClient.
If this means providing a REST API that exposes system state and configuration C/R/U/D, then yes, 8.3 is appropriate.
If this means providing a custom REST API, then you can use the WebDev module (purchased directly or as part of a solution suite) in 8.1 or 8.3.
But "API" is a term so broad it's meaningless. It also includes OPC UA, Modbus, Bacnet, JDBC, SECS/GEM, etc, etc, etc. One program putting a CSV file in a certain location and another program reading from it is an API.
4 Likes
That's exactly the scenario we need.
1 Like