AllAccepted answers
Jeffrey Drumm · Jul 23, 2019

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.

Jeffrey Drumm · Jul 20, 2019

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

Jeffrey Drumm · Jul 16, 2019

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.

Jeffrey Drumm · Jul 16, 2019

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.

Jeffrey Drumm · Jul 16, 2019

Just an observation ... generally speaking, the reasoning behind the repetition delimiters in OBX:5 is to provide a form of line-orientation to the resulted report; sort of like <br/> tags in HTML.  The receiving system can use these as guidelines for displaying text that should display as separate lines. The repetitions are rarely more than 80 characters long, the "standard" reading width for a fixed-pitch terminal. "Empty" delimiters ("~~") often serve to indicate paragraph endings, aka "blank lines."

Separating the repetitions into individual segments is also a common method of keeping report formatting intact. However, I've yet to see a vendor expecting each segment to represent a "paragraph."

I'm concerned that the vendor you're working with will be presenting the result report in a format other than as intended by the source.

Jeffrey Drumm · Jul 16, 2019

Is that screen shot from the Ensemble Message Viewer? If yes, than what you're seeing is Ensemble's visualization of an empty field/component/subcomponent/repetition. The tilde (~) character is the repetition delimiter at the field level; InterSystems uses the "·" character as an indicator that the repetition was left empty. There's no actual character there to split on, but you can certainly iterate through repetitions within OBX:5 and build a new message segment for each.

The DTL would be something like this:

Jeffrey Drumm · Jul 9, 2019

OK, it's quick and dirty and I'm probably doing something that will make the old-timers here laugh hysterically, but it works. The caveats are:

  • It only cares about word wrapping on the space character. Punctuation adjacent to non-space characters will stay with the adjacent characters.
  • It totally ignores things like \.br\ tags. they're just text as far as it's concerned.
  • It returns a $LIST, where each list element is a line of text from the source string, no longer than the width specified. You can iterate through it with $LISTNEXT or $LISTGET and populate your OBX segments, but you'll probably have to do that in a CODE rule.

So anyway ...

ClassMethod WordWrap(pTxt As %String, pWidth As %Integer) As %List
{
    If $LENGTH(pTxt) > pWidth
    {
        set tLine = ""
        Set tCnt = 0
        Set tWordList = $LFS(pTxt," ")
        Set tListLen  = $LISTLENGTH(tWordList)
        Set tWordPtr = 0
        Set tWordCur = ""
        While $LISTNEXT(tWordList,tWordPtr,tWordCur)
        {
            If $LENGTH(tLine_tWordCur) > pWidth
            {
                Set $LIST(tList,*+1) = $ZSTRIP(tLine,">W")
                Set tLine = tWordCur_" "
                Set tLastCnt = tCnt
            }
            Else
            {
                Set tLine = tLine_tWordCur_" "
            }
            Set tCnt = tCnt + 1
        }
    }
    Else
    {
 	Set tList = $LB(pTxt)
	Set (tLastCnt,tListLen) = 0
    }
    If tLastCnt < tListLen
    {
         Set $LIST(tList,*+1) = $LTS($LIST(tWordList,tLastCnt + 1,tListLen)," ")
    }
    Return tList
}

Have fun!

Jeffrey Drumm · Jul 3, 2019

So ... before you go changing those globals (if you haven't done so already), try

TIE> do ##class(Ens.Queue).AbortQueue("queuename")

Once you've turned down all of the inbound services/processes. If that doesn't work, use my previous suggestion.

I do think you should shut down the services and processes feeding the routers. And it wouldn't hurt to shut down the routers as well.

If the count is still at 1 after you do that, set the value to 0. And I actually think that the job IDs are from the source services and processes, not the routers themselves.

Jeffrey Drumm · Jul 3, 2019

I'm reasonably confident this will fix the issue without any side effects ...

TIE> Set ^Ens.Queue("ClinicomMsgRouter",0,"count")=0
TIE> Set ^Ens.Queue("PathologyRouter",0,"count")=0
Question though ... do you have the pool size for these routers set higher than 1? I'm concerned about the number of job entries  under each queue. This could have an impact on FIFO, and may have something to do with the erroneous queue counts.