I've cobbled together a little TamperMonkey/GreaseMonkey script that diddles with the style sheet without having to make unsupported changes to your installation's configuration. Adust the devattr, qaattr and prdattr variables to suit your color tastes, and the match arguments for the hostnames to identify your servers.

// ==UserScript==

// @name         Management Console Banner

// @namespace    http://tampermonkey.net/

// @version      0.2

// @description  Seems to work for both Chrome and Firefox

// @author       Jeff Drumm, HICG LLC

// @include      *://*/csp/sys*

// @include      *://*/csp/healthshare*

// @grant        none

// ==/UserScript==

function addGlobalStyle(css) {

    var head, style;

  head = document.getElementsByTagName('head')[0];

    if (!head) { return; }

  style = document.createElement('style');

  style.type = 'text/css';

  style.innerHTML = css;

  head.appendChild(style);

}

var devattr = 'color-stop(0.0,rgb(95, 246, 18)), color-stop(0.5,rgb(20, 204, 51)), color-stop(1.0,rgb(232, 227, 226))'

var qaattr = 'color-stop(0.0,rgb(248, 252, 10)), color-stop(0.5,rgb(204, 199, 20)), color-stop(1.0,rgb(232, 227, 226))'

var prdattr = 'color-stop(0.0,rgb(255, 2, 49)), color-stop(0.5,rgb(204, 18, 18)), color-stop(1.0,rgb(232, 227, 226))'

var curattr = ''

if (window.location.hostname.match('^ensprod.*')) {

    curattr = prdattr;

} else if (window.location.hostname.match('^ensqa.*')) {

    curattr = qaattr;

} else {

    curattr = devattr;

}

addGlobalStyle('.portalTitle { background: -webkit-gradient(linear, left top, left bottom, ' + curattr + ') !important; } ');

Mmmyyyeaaaaaah, You're going to want to do that in a DTL:

Create a rule that appends the text to the target.AlertText property:

You can add conditionals to provide different alert explanation values based on the SourceConfigName or by parsing the source.AlertText text to find something interesting.

Finally, stick the DTL in the Send rule for whatever operation you're sending alerts to.

 Second followup: R/O mode did something bad to the "Update SQL query statistics" task that comes standard with Caché. Caused it to dump millions of <PROTECT> records into the Audit database, which ballooned in size and ran the application directory out of disk space. Terminating  and restarting the job had the same effect. Not sure what's going on, have a ticket open with the WRC now.

That's a great suggestion, Eduard, and far simpler than my code-based solution. My only concern is that I will be extracting the messages from the retired Ensemble message database so that it can be deleted, and I'm not sure whether the task I've written to do this will require any temporary, behind-the-scenes global storage on the database itself. Easy enough to test, though, as I have two other environments with the same configuration (Dev and QA).

You could do it with an SQL query:

DELETE FROM Ens_Util.LookupTable WHERE TableName = '<name of table>'

You can create the query either via the Management Console (System Explorer | SQL | Execute Query tab) or from the SQL Shell

JEFF>d $system.SQL.Shell()
SQL Command Line Shell
----------------------------------------------------
 
The command prefix is currently set to: <<nothing>>.
Enter q to quit, ? for help.
JEFF>>delete from Ens_Util.LookupTable where TableName = 'facLookup'
1.      delete from Ens_Util.LookupTable where TableName = 'facLookup'
 
3 Rows Affected
statement prepare time(s)/globals/lines/disk: 0.1893s/11322/125529/16ms
          execute time(s)/globals/lines/disk: 0.0021s/29/408/0ms
                          cached query class: %sqlcq.JEFF.cls27
---------------------------------------------------------------------------

You could write a simple classmethod that starts and stops the offending component when an inactivity alert is received. It would do little more than executing:

Do  ##class(Ens.Director).EnableConfigItem("service name",0,1)

Do  ##class(Ens.Director).EnableConfigItem("service name",1,1)

That would almost certainly reset the inactivity timer. As long as the class it's in extends Ens.Rule.FunctionSet, you'll have it available in the function selector in the Rule Editor drop-down list.

Just add this to %ZLANGC00.mac:

/// Display Management Portal Port
ZMPORT
ZMP
  W ^%SYS("WebServer","Port")
  QUIT
JEFF>zmp
57772
JEFF>

Or This:

/// Display Management Portal URL
ZMURL
ZMU
  Set sc=##class(%RoutineMgr).GetWebServerPort(.Port,.Server,.URLPrefix,.URL)
  W URL_"csp/sys/UtilHome.csp"
  QUIT
JEFF>zmu
http://WIN7X64-VM02:57772/csp/sys/UtilHome.csp
JEFF>

Why waste valuable Prompt characters? laugh

Thanks to @Herman Slagman and @Robert Cemper for letting me blatantly steal their ideas wink

The Inactivity Timeout is a fixed value, and you can't easily reset it for different times of the day. You can, however, fairly easily control which times of the day alerts are actually sent, based on a variety of criteria:

The TimeIsBetween() and DayIsAWeekDay() functions in the screenshot above are relatively simple custom methods in a class that extends Ens.Rule.FunctionSet, which makes them selectable in the rule editor's function editor dropdown. I wrote them simply for the improved readability they provide for the routing rule.

In the rule above, alerts for the HIE_ADT_out interface are sent only between 7am and 7pm to the Integration team; on weekdays only the help desk is included. Any that fall outside of that timeframe are discarded.

Well, I've verified that the DTL I provided works against the  HL7 2.4:ORU_R01 document type, so my assumption is that your messages don't conform to that specification.  If they don't have the structure below, they won't be parseable:

And if that's the case, you would need to create a custom message schema matching their layout to work with them in the DTL editor.