Review the following issues carefully to determine if they affect your system:
Your web browser pop-up blocker may interfere with a number of dialog boxes in the Management Portal, such as source control configuration. Ensemble users have seen this in particular with Safari, which has pop-ups blocked by default. This issue will be resolved in future versions of Ensemble.
As a workaround, use one of the following methods:
If you import an XML export containing a business rule or routing rule that you exported from a version prior to 2012.1, the import does not add that rule definition to a project in Studio. You receive an error message indicating that the rules does not exist on the server. This occurs because the process attempts to add the old .RUL
form of name to the project, but the business rule has been converted to a class. The class containing the rule is created and you can add the class to your project manually.
When you use the message browser after an upgrade and you specify a Start Time
, exact matches against the start time are not shown in some circumstances. If the time you enter ends in one or more trailing zeroes when the seconds are expressed to three decimal places and there is a message created before upgrading at that exact time, that message is not included in the search result.
You could resolve the problem by rebuilding the TimeCreated
index of the Ens.MessageHeader
class, but InterSystems does not recommend this for most customers. It requires the system to be idle during the rebuild, which can take several hours for message warehouses with 100 million messages. Since most searches are for recent messages, this is expected to only present a problem for a short period after upgrading. Similar behavior exists when using SQL searches against the Ens.MessageHeader
class. This issue also exists in Ensemble release 2009.1.
InterSystems has identified a known problem with the Xerces parser version used in the current and past releases for Ensemble. The symptom related to Ensemble business rules is that Ensemble wrongly reports errors when importing a previously exported production from an XML file. The symptom occurs only when the XML file contains definitions of general business rules that define assign
actions in addition to simply returning a result.
There are two techniques for working around this problem. One makes import simple and places the burden on the person exporting the production. The other makes export simple and places the burden on the person importing the production. You only need to use one of the following equally effective techniques:
Use the following approach to facilitate the import task:
Find each general business rule that defines assign
actions in addition to returning a result.
Export each of these rules to a separate file. Make sure you are exporting one rule per file.
Export everything else in the production, including other rules, to a different file.
Import (and compile) each of the exported files individually.
Use the following approach to facilitate the export task:
Export everything to one file.
Upon import, do not use Studio. Instead, start Terminal, change to the namespace where you need to import, and enter one of the following commands (either works):
The HL7 schema definitions loaded into Ensemble were generated directly from the respective standards (HL7 2.1, 2.2, 2.3, 2.3.1, 2.4, 2.5, 2.5.1, 2.6, 2.7, and 2.7.1). With only a few exceptions, they replicate any errors, omissions, or discrepancies that exist in these standards as published by the Health Level Seven organization.
Under certain conditions, loops that contain scopes and have a large number of repetitions can cause an error. If possible, define the scope so that it includes the loop rather than being defined inside of the loop.
Application access to arbitrary %CSP pages, including DeepSee, is controlled by a security global. By default, only the SAMPLES and ENSDEMO namespaces can access DeepSee pages, including dashboards. To enable DeepSee access in another Ensemble namespace and its associated web application, select System Administration
, and Web Applications
and then select the namespace that requires DeepSee access, check the DeepSee
checkbox on the General
tab and click Save
You should set this checkbox for any namespace that uses DeepSee dashboards or other DeepSee pages. Note that for HealthShare installations, the web application names start with /csp/healthshare/.
Alternatively, you can enable DeepSee access for all namespaces and web applications by entering the following command in an Ensemble terminal window:
When Ensemble or any other application opens an outbound port for a TCP connection, it specifies the listening port number on the target server, but the operating system creates a temporary, or ephemeral, outbound local port in the port range that it uses for ephemeral ports. Typically, the operating system does not reuse a port until it has reached the end of the port range. If a service specifies a listening port that is within the range that the operating system uses for ephemeral ports, that port may not be available when the service starts, which causes an error.
To avoid potential port conflicts, you can do a web search on ephemeral port
to find the ephemeral port range used by your operating system. You should avoid having a service listen on any port within that range. Some users have encountered this error when they have stopped and then immediately restarted a production that uses many TCP connections.
Check the status return value.
If there is an error, notify the user and take appropriate error recovery.
In most cases, productions are defined and run in the same namespace, but you can use Caché package mapping to make a production class visible in a namespace other than the one it is defined in. If you use package mapping and a production is visible in more than one namespace, you should designate only one of these namespaces to compile and run the production, You should not compile, modify, or run the production in any other namespace. If you run or modify the same production in more than one namespace it can cause failures that are hard to diagnose. Under no circumstances should you do this. If you do not use package mapping to map a database to a namespace you do not need to be concerned about this issue.
If you are using a custom function in a rule, it must have been compiled before the rule is compiled. If the custom function is being imported at the same time as the rule, you cannot explicitly control the order of compilation. To avoid this situation, you can compile any custom functions used in rules before you compile the remainder of the production. Typically, you could encounter this situation when you are deploying a production to a new namespace or system.
If the custom function is already defined in the namespace and has been compiled before, the order or compilation does not matter even if the custom function has been changed. But, if the custom function has not previously been defined in the namespace, Ensemble encounters an error and fails to compile the rule even if the function would be compiled later in the same import.