Are you using LDAP for authentication? I seem to remember running into this when the web applications created as part of enabling Ensemble/Interoperability weren't set to support LDAP.

Compare the settings for the web applications created for your new namespace in Security | Applications | Web Applications with those from other (working) Ensemble-enabled namespaces.

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
REASON(1.23)
USER> set altstr =  ##class(User.Util.StringFunctions).ReReplace(mystr,"->\w+","-CODE")
USER> write altstr
REASON-CODE(1.23)

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.

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?

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.

With some help from a fellow DC member, I wrote the method below. Its intent is to support auto-resolution of managed alerts:

/// Returns the connection status ("AdapterState") of the Business Service or Operation
/// named in <var>pItemName</var>
ClassMethod GetConnectionStatus(pItemName As %String) As %String [ Language = objectscript ]
{
    Set tStatement = ##class(%SQL.Statement).%New()
    Set tStatus = tStatement.%PrepareClassQuery("Ens.Util.Statistics","EnumerateJobStatus")
    If $$$ISERR(tStatus)
    {
        Return "Error in Status Query: "_$system.Status.GetErrorText(tStatus)
    }
    Set tRS = tStatement.%Execute(pItemName)
    If tRS.%SQLCODE = 0
    {
        Do tRS.%Next()
        Return tRS.%Get("AdapterState")
    }
    Return "Status not Found"
}

Here's a little code snippet that the Management Portal uses to get the Arbiter state:

	Set state = $SYSTEM.Mirror.ArbiterState()
	Set thisConnected = $SELECT($ZB(+state,+$$$ArbiterConnected,1)'=0:1,1:0)
	Set otherConnected = $SELECT($ZB(+state,+$$$ArbiterPeerConnected,1)'=0:1,1:0)
	
	If 'thisConnected {
		Set stateString = $$$Text("This member is not connected to the arbiter")
	} ElseIf 'otherConnected {
		Set stateString = $$$Text("Only this member is connected to the arbiter")
	} Else {
		Set stateString = $$$Text("Both failover members are connected to the arbiter")
	}

You'll need to add an Include statement for %syMirror to use the $$$Arbiter* macros.

Note that the ArbiterState() method is undocumented, and its behavior may change in future releases.

Does SYS.Mirror.GetFailoverMemberStatus() give you what you want? It has to be executed from %SYS.

%SYS>set sc=##class(SYS.Mirror).GetFailoverMemberStatus(.pri,.alt)

%SYS>zw pri
pri=$lb("SERVERA.FOO.BAR.ORG/STAGE","SERVERA.foo.bar.org|2188","Primary","Active","172.31.33.69|1972","SERVERA.foo.bar.org|1972")

%SYS>zw alt
alt=$lb("SERVERB.FOO.BAR.ORG/STAGE","SERVERB.foo.bar.org|2188","Backup","Active","172.31.33.70|1972","SERVERB.foo.bar.org|1972")

Not sure why yours is showing OpenSSL v3. I'm running IRIS for Health 2022.1.0.209.0 on a Ubuntu 20.04.4 LTS (GNU/Linux 5.4.0-121-generic x86_64) physical host and I had no issues with installation.

My guess is that it isn't really complaining about openssl, but that libssl isn't at least version 1.1.1.

I'd try running (as root):

# apt install openssl
# apt install libssl1.1

These commands should install pre-compiled binaries. The first one should automatically install openssl 1.1.1f and the 2nd the same version of the libssl libraries.

And yes, while I haven't specifically used VirtualBox, I am a long-time user of VMWare on multiple platforms, with multiple Linux guests and versions of Caché/IRIS. Virtualization has, so far, very rarely been an issue.

It's a bug, and InterSystems is aware. It's still present in 2022.1, but I expect it will be fixed in an upcoming release.

For now, you'll need to change the resource associated with the database(s) to %DB_%DEFAULT (or whatever you prefer) after the creation of the namespace. That can be done through the management portal, under System Administration | System Configuration | Local Databases.