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 that store indexes for classes cannot be mapped using subscript-level mapping on existing systems. For details, see Mapping Globals on an Existing System.
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 a New System
If you set up a separate database for the data associated with messages during the initial configuration of your production, the process of mapping the relevant globals is straightforward. Simply create a new messages database and map all relevant globals to your newly created database. For details on mapping globals to a database, see Add Global, Routine, and Package Mapping to a Namespace.
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.
