The TIBCO EBX® web interface supports the following browsers:
Microsoft Edge chromium | As Microsoft Edge chromium is updated frequently and it is not possible to deactivate automatic updates, TIBCO Software Inc. only tests and makes the best effort to support the latest version available. |
Microsoft Edge | Minimum supported version is 44 Compatibility mode is not supported. |
Microsoft Internet Explorer 11 | Compatibility mode is not supported. Performance limitations: page loading with IE11 is two times slower. This issue is observed when forms have many input components, and particularly many multi-occurrence groups. Graphical layout: graphical rendering in IE11 can slightly differ from other browsers (for example, the alignment of some labels, icons and other components can be off by a few pixels). |
Mozilla Firefox ESR 68 (see details) | As Mozilla Firefox is updated frequently, TIBCO Software Inc. only fully supports version ESR 68. See Mozilla Firefox ESR for more details. |
Google Chrome | As Google Chrome is updated frequently and it is not possible to deactivate automatic updates, TIBCO Software Inc. only tests and makes the best effort to support the latest version available. |
The minimum screen resolution for EBX® is 1024x768.
Browser page refresh is not supported by EBX®. When a page refresh is performed, the last user action is re-executed, and therefore could cause issues. It is thus imperative to use the action buttons and links offered by EBX® instead of refreshing the page.
The 'previous' and 'next buttons of the browser are not supported by EBX®. When navigating through page history, an obsolete user action is re-executed, and therefore could cause issues. It is thus imperative to use the action buttons and links offered by EBX® rather than the browser buttons.
The following features must be activated in the browser configuration, for the user interface to work properly:
JavaScript
Ajax
Pop-ups
Avoid using any browser extensions or plug-ins, as they could interfere with the proper functioning of EBX®.
Some browsers may have a limitation on the number of iframes that can be embedded. If this is the case, it limits to the number of items that can be pushed in the breadcrumb. Please check the browser documentation for more details.
EBX® supports the following configurations:
Java Runtime Environment: JRE 8, 11 or 17.
Note: JRE 8 will come out of support in an upcoming release. We advise to upgrade the runtime to a recent LTS version, to take advantage of the performance improvements it offers.
Any Servlet/JSP container that complies with Servlet 3.0 (inclusive) up to 5.0 (exclusive): for example Tomcat 7.0 (inclusive) up to 10.0 (exclusive). Any Java Application Server with Java EE 8 (inclusive) to Jakarta EE 9 (exclusive): for example WebSphere Application Server Liberty 18 (inclusive) up to 21 (exclusive), WebLogic Application Server 14c or higher, JBoss EAP 7.4 or higher. See Java EE deployment overview.
The application server must support the JSON Processing 1.1 (JSR 374), or allow the uses of the implementation embedded in the ebx.jar library. For example, Tomcat does not provide any library to support this specification (only the embedded one can be used), WebSphere Application Server allows reversing the classloading system (making the embedded one a priority), WebLogic Application Server 14c or higher supports this specification, JBoss EAP allows including or excluding the available libraries.
The application server must use UTF-8 encoding for HTTP query strings from EBX®. This can be set at the application server level.
For example, on Tomcat, you can set the server to always use the UTF-8 encoding, by setting URIEncoding to 'UTF-8' on the <Connector> in the server.xml configuration file. Alternatively, you can instruct the server to use the encoding of the request body by setting the parameter useBodyEncodingForURI to 'true' in server.xml.
Limitations apply regarding clustering and hot deployment/undeployment:
Clustering: EBX® does not include a cache synchronization mechanism, thus it cannot be deployed into a cluster of active instances. See Technical architecture for more information.
Hot deployment/undeployment: EBX® does not support hot deployment/undeployment of web applications registered as EBX® modules, or of EBX® built-in web applications.
WebSphere Application Server's Java SDKs under version 8.0.4.10 are incompatible with the embedded Apache Calcite third-party library. It is highly recommended to use the latest Java SDK available and compatible with the application server.
The EBX® repository supports the relational database management systems listed below, with the suitable JDBC drivers. It is important to follow the database vendor recommendations and update policies regarding the database itself, as well as the JDBC driver.
Oracle Database 12c or higher (but excluding 18c). | The distinction of The user with which EBX® connects to the database requires the following privileges:
|
PostgreSQL 10 or higher. | The user with which EBX® connects to the database needs the CONNECT privilege on the database hosting the EBX® repository. Other than this, the default privileges on the public schema of this database are suitable. Also, see this limitation regarding the evolution of datamodels in mapped modes. |
Amazon Aurora PostgreSQL 2.3 (compatible with PostgreSQL 10.7) or higher. | The comments in the above section for PostgreSQL apply. |
Google Cloud SQL for PostgreSQL 10 or higher. | The comments in the above section for PostgreSQL apply. |
SAP HANA Database 2.0 or Higher. | When using SAP HANA Database as the underlying database, certain schema evolutions are not supported. It is, for example, impossible to reduce the length of a column; this is a limitation of HANA, as mentioned in the SQL reference guide: "For row table, only increasing the size of VARCHAR and NVARCHAR type column is allowed." |
Microsoft SQL Server 2012 SP4 or higher. | When used with Microsoft SQL Server, EBX® uses the default database collation to compare and sort strings stored in the database. This applies to strings used in the data model definition, as well as data stored in history tables. The default database collation can be specified when the database is created. Otherwise, the collation of the database server is used. To avoid naming conflicts or unexpected behaviors, a case- and accent-sensitive collation must be used as the default database collation (the collation name is suffixed by "CS_AS" or the collation is binary). The default setting to enforce transaction isolation on SQL Server follows a pessimistic model. Rows are locked to prevent any read/write concurrent accesses. This may cause liveliness issues for mapped tables (history or relational). To avoid such issues, it is recommended to activate snapshot isolation on your SQL Server database. The user with which EBX® connects to the database requires the following privileges:
|
Microsoft Azure SQL Database | EBX® has been qualified on Microsoft Azure SQL Database v12 (12.00.700), and is regularly tested to verify compatibility with the current version of the Azure database service. When used with Microsoft Azure SQL, EBX® uses the default database collation to compare and sort strings stored in the database. This applies to strings used in the data model definition, as well as data stored in history tables. The default database collation can be specified when the database is created. Otherwise, the database engine server collation is used. To avoid naming conflicts or unexpected behaviors, a case- and accent-sensitive collation must be used as the default database collation (the collation name is suffixed by "CS_AS" or the collation is binary). The user with which EBX® connects to the database requires the following privileges:
|
H2 2.1.212 or higher. | H2 is not supported for production environments. The default H2 database settings do not allow consistent reads when records are modified. |
For other relational databases, please contact the Support team at https://support.tibco.com.
In order to guarantee the integrity of the EBX® repository, it is strictly forbidden to perform direct modifications to the database (for example, using direct SQL writes).