For those that use Interoperability/HealthConnect, nc/netcat is also an excellent tool for verifying that remote ports are accessible for HL7 MLLP, HTTP or other protocols that require a TCP socket client connection.

And while this thread is specifically for Unix/Linux, there's a Windows PowerShell analogue named Test-NetConnection (alias tnc) that provides a subset of nc's features.

Something like this, perhaps?

Class User.Util.StringFunctions Extends Ens.Util.FunctionSet

ClassMethod ReReplace(pStr As %String, pPat As %String, pRepl As %String = "") As %String
    Set tStrt = $LOCATE(pStr,pPat,,tEnd) - 1
    // in case the pattern isn't found, return source string
    Return:(tStrt < 0) pStr
    Set tPrefix = $EXTRACT(pStr,1,tStrt)
    Set tSuffix = $EXTRACT(pStr,tEnd,*)
    Return tPrefix_pRepl_tSuffix

USER> set mystr = "REASON->Blood(1.23)"
USER> set newstr = ##class(User.Util.StringFunctions).ReReplace(mystr,"->\w+")
USER> write newstr
USER> set altstr =  ##class(User.Util.StringFunctions).ReReplace(mystr,"->\w+","-CODE")
USER> write altstr

The included IsRecentManagedAlert() method expects a recent alert to have 100% identical SourceConfigName and AlertText values. Probably not suitable for your application.

Unfortunately, I haven't run into a scenario such as you describe where errors from multiple business hosts must be aggregated into one.

I can envision a solution where you would identify this group of business hosts under a single Managed Alert Group, log activity for alerts in that group to a table or global via Ens.Alert's routing rule, and check the table/global for prior activity from that alert group in the in that same rule for the desired time span. Matches could then be suppressed.

Since Managed Alert Groups aren't a property of Ens.AlertRequest, you would need to interrogate the business host (production item) for its membership from the rule.

 So you'd need to create a table/global, write some methods (in a class extending Ens.Rule.FunctionSet) to query your custom table/global for prior alerts and log the current alert, then configure a routing rule to check for the existence of prior activity on the selected Alert Group, log the current activity, and suppress or send the alert based on your criteria.

Check the Learning link at the top of the page. All of the official InterSystems training courses can be found there. Many are free.

Is it a password user?


Try disabling OS Delegated auth.

That worked! Thanks laugh

Does the version of Studio you're using match the version of Ensemble/Caché? Older versions of Studio will fail to connect to newer versions of Caché/IRIS.

I tried running it with Wine a few years ago and it almost worked. Perhaps Wine has improved since then, but I'm now firmly in the VS Code camp laugh

DocTypeCategory and DocTypeName are populated based on the contents of DocType. The DocType property can be changed even though the message is immutable.

TypeVersion is populated based on the value of the MSH:12 field in the message body. If you're attempting to modify the properties of an inbound message received from a business service, I don't think you'll be able to change TypeVersion with "Existing" set in the DTL editor because you can't modify MSH:12.

Are you working with messages newly arrived through a service that haven't undergone any prior transformations?

%Net.MailMessage has an IsHTML property; set that to a value of 1 and you can use HTML in your WriteLine() calls to format your text.

Hi Blake,

This might get you started in the right direction:

Set tRuleName = "<rulename>"
Set tTarget = $ORDER(^Ens.Rule.Targets(tRuleName,""))
Set tArr = 0
Set tCnt = 1
While tTarget '= ""
    Set tArr(tCnt) = tTarget
    Set tTarget = $ORDER(^Ens.Rule.Targets(tRuleName,tTarget))
    Set tArr = tCnt
    Set tCnt = tCnt + 1

Replace <rulename> with the name of the rule as it appears in the router configuration pane.