Managing Databases for Productions
In order to develop a production, you will need to use or create an interoperability-enabled namespace. While you can rely on a single database for your production, it is often desirable to define a separate database to store the data associated with messages. This data has the potential to increase the database size rapidly during times with higher than usual traffic or if a purge process is not scheduled to run. This practice insulates the database associated with your production’s code from the database with your message data. This page describes the process, including the recommended globals that should be mapped and guidelines for mapping on both new and existing systems.
Globals Containing Message Data
The following table contains the recommended globals which should be mapped to a separate messages database. Select the tab for the product you are using. Additionally, if you have any custom message classes that contain message data, you should consider mapping these to the same message database.
| ^Ens.MessageHeaderD |
| ^Ens.MessageHeaderI† |
| ^Ens.MessageBodyD |
| ^Ens.MessageBodyI† |
| ^Ens.MessageBodyS |
| ^EnsHL7.Segment |
| ^EnsLib.H.MessageD |
| ^Ens.Util.LogD |
| ^Ens.Util.LogI† |
| ^Ens.MessageHeaderD |
| ^Ens.MessageHeaderI† |
| ^Ens.MessageBodyD |
| ^Ens.MessageBodyI† |
| ^Ens.MessageBodyS |
| ^EnsHL7.Segment |
| ^EnsLib.H.MessageD |
| ^Ens.Util.LogD |
| ^Ens.Util.LogI† |
| ^Ens.MessageHeaderD |
| ^Ens.MessageHeaderI† |
| ^Ens.MessageBodyD |
| ^Ens.MessageBodyI† |
| ^Ens.MessageBodyS |
| ^EnsHL7.Segment |
| ^EnsLib.H.MessageD |
| ^Ens.Util.LogD |
| ^Ens.Util.LogI† |
| ^HS.Message.XMLMessageD |
| ^HS.Message.XMLMessageS |
| ^Ens.MessageHeaderD |
| ^Ens.MessageHeaderI† |
| ^Ens.MessageBodyD |
| ^Ens.MessageBodyI† |
| ^Ens.MessageBodyS |
| ^EnsHL7.Segment |
| ^EnsLib.H.MessageD |
| ^Ens.Util.LogD |
| ^Ens.Util.LogI† |
| ^HS.Message.XMLMessageD |
| ^HS.Message.XMLMessageS |
| ^HS.IHE.Comm8F7E.MIMEAttachmentD |
| ^HS.IHE.Comm8F7E.MIMEAttachmentS |
| ^HS.IHE.Comm8F7E.MIMEAttachmentI† |
Globals for Default Database
The following globals should NOT be mapped to the messages database and need to remain in the default database for the interoperability-enabled namespace. They are essential for interoperability to function properly:
-
^Ens.Runtime
-
^Ens.Queue
-
^Ens.JobLock
-
^Ens.JobStatus
-
^Ens.ActiveMessage
-
^Ens.JobRequest
-
^Ens.Suspended
-
^Ens.SuspendedAppData
-
^Ens.Alarm
-
^Ens.AppData
-
^Ens.Rule.Notification
Mapping Globals on an Existing System
If you already have a production in use, the process of mapping the existing globals to your new database is more involved. Again, you should start by creating a new messages database. For globals that feature an incrementing ID as the top-level subscript, you should perform a subscript-level mapping. Choose a higher subscript than the current highest subscript of the global. This will allow the global to roll over to the new database when it increments to the designated subscript. For details on subscript-level mapping, see Global Mapping and Subscript-Level Mapping.
For globals that do not have an incrementing ID as the top-level subscript, including globals that store indexes for a class and globals subscripted by $JOB, you can perform a DataMove to map the subscripts to the newly created database.
