Ensemble 2016.1 introduced the following new features and enhancements:
Service Registry and Enhanced Tools to Use Ensemble as an ESB
Activity Volume Statistics and Monitoring
SuperSession Identity Propagated Between Productions
Incremental X12 Enhancements
Minor Improvements to Ensemble Graphic Editors
Production and Component Restart Improvements
Message Bank Enhancements
New Filter on Message Bank Viewer
Rule Can Access Information About Transformation
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.
In this release subclasses of EnsLib.REST.Service need to get query parameters from attributes not from the URL. In previous releases, it was also possible to get it from the URL when the incoming request came through the CSP port. This change was required to fix problems matching the incoming URL with the URLMap. The query parameters are available as attributes of the stream object passed to OnProcessInput or from the %request object.
Note that we recommend directly subclassing %CSP.REST and not subclassing EnsLib.REST.Service. If you directly subclass %CSP.REST you can use the full features of that class. In order to use a subclass of %CSP.REST in an Ensemble production you need to call CreateBusinessService.
In most cases, the _Ensemble user, which is used by Ensemble internally should be set to not expire and to have the password not expire. In this and future releases, upgrading Ensemble will reset the AccountNeverExpires and PasswordNeverExpires properties to true and notes the changes in the ensinstall log. If your environment requires that one or both of these properties be set to false, you must reset them after upgrading Ensemble.
In this release when a business process encounters an error, the termination error includes the text from the underlying error. If you have error handling code that is comparing the error text, you may have to modify your code.
In this release, Ensemble checks the access to the default database before starting the production. If the default database is read-only, the management portal displays an error and does not start the production. In most cases, this condition is caused by a configuration error and the production would have failed after startup. Although it is not a recommended practice, it was possible to use global mapping to create a production that would work with a read-only default database. This configuration will not work in this release. You must modify the configuration so that the default database allows write access before starting the production.
In previous releases the inbound and outbound TCP adapters set to be always connected (StayConnected = -1) handled startup differently. If an initial connection is not made within the alert grace Period, the outbound adapter reported an error but the inbound adapter did not. The inbound adapter only reported an error if the adapter was set to have only one listener and an existing connection ended.
In this release the TCP Inbound Adapter set to be always connected behaves the same during start up as the outbound adapter. It reports an error if the initial connection is not made within the alert grace period. This error may be triggered when systems are being brought back online after an outage leading to an Alert On Error if configured. If there is a lag in making the TCP connection in the normal startup, you can avoid this error by increasing the alert grace period.
In previous releases, when a production was stopped, any asynchronous messages on the ^Ens.Queue global queue was moved to the ^Ens.Suspended queue and when the production was restarted, they were moved back. For productions with many messages in the queue, this behavior could cause stopping and restarting a production to be slow. In this release, you have the option to avoid this move and the consequent delay in restarting. To avoid the move of suspended messages, set ^Ens.Configuration("Queues","KeepInQueues")=1 per namespace. The default is 0 which is to leave the current behavior.
This change does not have a compatibility impact on your code in your production even if you request the new behavior. But, if you have code that examines suspended messages stored in the database globals while the production is stopped, you should update your code to handle the new option.
This release includes improved validation of ebXML messages; consequently, some messages that were not valid passed validation in previous releases, but are now treated as errors. Specifically, an ebXML message is considered not valid if both the MessageId and ConversationId are empty. In previous releases, these messages could pass validation.
In order to successfully close the Java Gateway after a ping operation, this release sends additional send and receive messages to the gateway. This causes additional entries in the log.
In previous releases, if there were any errors in the distribution list, the message would not be sent to any recipients. In this release, the message is sent to all recipients except to those addresses with an error. To have the outbound adapter return to the previous behavior and not send email to any recipient, set the ContinueAfterBadSend setting to false.
If an FTP adapter is configured to delete the file on the server and fails to then Ensemble should consider the file processed and not reprocess it. In past releases, this behavior was correct if the adapter could not delete the file because of permissions. But, if the adapter could not delete the file because of network problems, it incorrectly treated the file as new and reprocessed it. This problem has been fixed in this release. The adapter will not reprocess the file. If you have coded your production to deal with the past incorrect behavior, you should remove this code.
In previous versions, if a router timed out before processing a message, it would not set the message header correctly and the message header could not be purged. This error is fixed in this release. If you have developed a procedure to handle the unpurged messages, it is no longer needed for this condition.
In previous versions, the BPL wizard did not detect the error of having two calls with the same name. This condition could cause an unexpected call. In this version for synchronous calls that have a response, this error is detected by the BPL wizard. Consequently, BPLs that had this error would have compiled successfully in previous versions, but will trigger an error in this version.
In previous releases, the TCP counted adapter ignored the incoming length value if there was no character encoding; consequently, if the actual length did not match the specified length, the adapter accepted the message. In this release, the adapter makes this check and rejects the incorrectly formatted message. This change makes the behavior of the TCP counted adapter with no character encoding match its behavior with character encoding, where it has always checked the incoming length.
In previous releases if a business process with a pool size of 0 was disabled, all business processes that use the shared actor pool would be disabled. Typically, you only want to disable a specific business process, not all that use the shared actor pool. In this release if you attempt to disable a business process with a pool size of 0, Ensemble displays a warning and the business process is not disabled.
If you attempt to disable a business process with a pool size of 0, the business process is not disabled and is displayed as green on the production configuration diagram, but the enabled check box is not selected.
If you do want to disable a business process with a pool size of 0, you can do this by setting the pool size to a positive integer. If you do want to stop all business processes using the shared actor pool, set the Actor Pool Size
to 0 in the production settings tab.
If you attempt to create a new business process that is disabled and that has a pool size of 0, the business process is created disabled, but the pool size is set to 1. This situation occurs if you:
In these cases, the disabled business process is set to have a pool size of 1 instead of the specified 0.
The Ensemble Event Log page was failing to enforce the security requirement that the user needs USE permissions on the %Ens_Purge resource to purge event log entries. This is now corrected and the security requirement is now enforced. If a user without the permission clicks on Purge the alert "You are not permitted to perform this action" will be shown and the purge will not be carried out.
In previous releases, if you specified a search table in an EnsLib.EDI.XML.Operation.FileOperation or EnsLib.EDI.XML.Operation.FTPOperation, the search table index was not created. In this release, the search table index is created. Note that when the message bodies are purged, the search table data is also purged.
In previous releases completed business process instances might not be purged if the TimeCreated value was null. This situation only occurred if the debug flag was set to retain business process instances and custom code updated the TimeCreated value, which should not be set by user code. In this release, even in this case, the completed business process will be purged as expected.