Although I have blogged before on issues that might be overlooked during a Millennium® upgrade, a recent discussion with a client revealed another issue: one with the transaction database (TDB). A common oversight in this area might need a simple fix.
The TDB is a flat file found on each Millennium application node that tells the executables (application servers) what transactions they can process and if the transactions are Request/Reply (RR), Reliable Delivery Message (RDM) or Remote Procedure Call (RPC). Let me start with some background on these three types:
- With RR transactions, the clinical information remains intact even if the transactions are lost or discarded. For instance, using CPM Script to retrieve or read data from the database is an RR transaction. If the transaction is lost, the person asking for the information just has to ask for the information again.
- An RDM transaction is like an order. If the client crashes or the application executable or application node fails, there has to be a mechanism in place to recover or replay that transaction when the system is fully functional again.
- The RPC transaction was added with Millennium 2007.x. It allows the Java servers and Java client applications to process transactions originating from both the local hardware and remote calls. It was the first extension to the Common Request Model in quite some time.
Until recently, the TDB was a connection-based service. PowerChart or the front-end application connected directly to the TDB’s port. The TDB is now a shared service. The TDB server communicates with Citrix servers and fat clients over a network port that it allocates when it starts up. Once the communication port is selected or opened, the TDB server tells the Millennium Service Manager on the application node which port it will be listening to for incoming transactions (requests). The Citrix servers and fat clients must be on the same code level as the application node so that when PowerChart or any front-end Millennium application starts up, it will connect to the Service Manager and be told what port to use to connect with the TDB.
I have found that sometimes during an upgrade, the fat clients or outlying Citrix servers are overlooked. In the case of the TDB, fat clients and Citrix servers that aren’t upgraded might be connecting to the wrong port. If a connection fails because the TDB was not listening on that port, the Service Manager logs a message stating that event CMB_ServiceUnavail1Net occurred. The service name (such as TDB_SYSTEM@PROD) is logged, the Citrix server or fat client’s TCP/IP address is included, and the port the client was trying to communicate with is logged. You can see these messages by looking in the cmb_0000 message log and search for the event CMB_ServiceUnavail1Net.
An example would look something like this:
The message under the Record column indicates that the Citrix server or fat client whose TCP/IP address is 10.10.10.10 is trying to communicate with the TDB on port 1240. Because this happened after a Millennium upgrade, the client just has to use tracert or traceroute (depending on your operating system) to find out how far the problem server or client is from the application node, i.e., how many network router hops you have to make. The Citrix server or fat client needs to be scanned for components after the Millennium client upgrade in order to be in sync with the newer application node code. This is the most common problem and is simple to correct.
Prognosis: Reviewing message logs after an upgrade can highlight issues that make Millennium appear unusable or unstable to the clinicians whose Millennium servers or fat clients have not been upgraded.