Ensemble 2015.1 and introduced the following new features and enhancements:
Push notifications for mobile devices
Improved database storage for namespaces
Pass-through calls can use the CSP gateway
Enterprise and production monitor enhancements
The following changes in this release may affect the operation of your existing system. Review these following issues before upgrading a previous instance of Ensemble.
When you create a new namespace, credentials passwords are stored in a secondary database, which is, by default, not accessible to user accounts. For most productions this does not create a compatibility issue because Ensemble provides access to the password when it is needed by the business host. This change provides increased protection for stored passwords. Note that InterSystems recommends that you encrypt any database containing credentials passwords.
There are some conditions where this change can cause a compatibility issue. This section describes these conditions and ways you can avoid problems.
Some Ensemble licenses limit the number of databases allowed. This new credentials database is counted towards the limit.
When you create a new namespace, Ensemble creates a secondary database and names it by appending SECONDARY to the globals database name. For example, if you create the INVENT namespace with the INVENTG database for globals and the INVENTR database for routines, Ensemble also creates the INVENTGSECONDARY database for credentials passwords. In previous releases, Ensemble stored the credentials password in the ^Ens.Conf.CredentialsD, but in this release, Ensemble stores credentials passwords in the global ^Ens.SecondaryData.Password and maps that global to the secondary database.
For existing namespaces, upgrading Ensemble does not create the new secondary database, but when you first access credentials, the passwords are moved to the new global. If you call the %Library.EnsembleMgr:CreateNewDBForSecondary()
method, Ensemble creates the secondary database for credentials passwords, migrates the password to the new secondary database, and maps the ^Ens.SecondaryData.Password to the secondary database. You should only call the CreateNewDBForSecondary()
method when the production has been stopped.
In most cases, these changes do not impact production code or accessing credentials through the management portal, but it does create the following compatibility issues:
Any job running code to read credentials now needs resources protecting the secondary password database. For example, the INVENTGSECONDARY is protected by the resource %DB_INVENTGSECONDARY, to read the credentials a process must have read access to the %DB_INVENTGSECONDARY resource. Note that jobs started as part of the production run under the user _ENSEMBLE and these jobs are able to read credentials
Any job running code to write credentials now needs %Ens_Credentials:"W" resource. Note that the management portal escalates permissions when writing credentials. Consequently, you do not have to change the permissions of portal users who are able to enter credentials with the previous version of Ensemble.
If a web application reads or writes credentials, including by calling an InProc business operation, the web application needs to be given the necessary resources, at least for the duration of the read or write of the credentials.
If code is running in another context and needs access to the credentials password, the user account needs to have the necessary resources.
If you call the CreateBusinessService()
to create a business service that sends a message directly to an InProc operation that requires access to the credentials password, the user account needs to have the necessary resources.
If in an existing namespace you have created a mapping that moves ^Ens.Conf.CredentialsD to another database, you must create the same mapping for ^Ens.SecondaryData.Password.
If you are running an instance of HealthShare, it does not create the secondary database for credentials passwords unless you explicitly call the CreateNewDBForSecondary()
method. Do not call this method for a namespace used in a HealthShare Information Exchange.
The Runtime and JobStatus data is now stored in the global ^CacheTemp.EnsRuntimeAppData
subscripted by namespace. In previous versions, this data was stored in the global ^Ens.RuntimeAppData
. In addition, metrics data, which is used for display in the production monitor, is now stored in the global ^CacheTemp.EnsMetrics
. In previous versions, this data was stored in the global ^Ens.Metrics
. In most cases, these changes do not cause a compatibility issue, but you should ensure the following:
No productions are in the troubled state when you upgrade to a version of Ensemble that has this change.
If your code explicitly accesses these globals, you must update the code to access the data in the new location.
Since these globals are now stored in a non-journaled database, the values are not available to mirror members.
Some Ensemble licenses limit the number of databases allowed. This new database for temporary globals is counted towards the limit.
When using JDBC SQL adapters, stored Procedure large object (LOB) output parameters are now returned as streams. In previous versions, these output parameters were returned as strings, which caused errors when the LOB exceeded the maximum string size. You should modify any code that accesses these output parameters to handle streams instead of strings.
As a temporary workaround, you can set globals to return string values for these output parameters. But even with these globals set, if the size of the LOB exceeds the maximum string size, the output parameters are returned as streams.
To configure Ensemble to return LOB output parameters as strings when size permits, set one of the following globals to 1:
The Ensemble portal Import
buttons now use the same file format as Studio. In previous versions of Ensemble the portal export format was incompatible with the Studio export format.
If you exported a lookup table with the portal from a previous version of Ensemble, you must use the Import Legacy
button on Ensemble 2015.1 or later to import it. If you are exporting a lookup table from Ensemble 2015.1 or later and intend to import it with an earlier version of Ensemble, you must import it on the earlier version using Studio; you cannot use the portal import.
In previous releases, deleting an X12 object would not delete its child objects. In this release, when you delete an X12 object, all its child objects are deleted.
Under some circumstances in previous releases, a Data Transformation would not report an error if you included the iterator key within the parentheses in a foreach. This error is now correctly reported.