To get the XML rule definition from SQL you can write/define a stored procedure that returns the XML rule definition, then....parse the XML. Something like:

Class Community.Rule.XDATA
{
ClassMethod GetXML(RuleName As %String) As %String(MAXLEN="") [ SqlProc ]
{
    Set xdataOBJ = ##class(%Dictionary.XDataDefinition).IDKEYOpen(RuleName,"RuleDefinition")
    Quit xdataOBJ.Data.Read($$$MaxLocalLength)
}
}

Then from SQL:

select Community_Rule.XDATA_GetXML('Your.Rule.Name')

I really doubt it's possible to search for Data Set values, that information is stored in a binary file in the filesystem, not in the database.

You can use this query in your method:

select * from Ens.Job_Enumerate()
where  ConfigName ='T_SPM_SIU'

From documentation:

General Rules

Every identifier must be unique within its context (for example, no two classes in a given namespace can have the same full name).

Identifiers preserve case: you must exactly match the case of a name; at the same time, two classes cannot have names that differ only in case. For example, the identifiers id1 and ID1 are considered identical for purposes of uniqueness.

Would you mind specify what kind of rule?

Edit to add: note that rules are defined as XML, there is no table available to directly query a rule

To my knowledge what can be done it's making a call via Web Gateway using %Net.HttpRequest.

I'm afraid that without going trough the Web Gateway it's not possible, but I'd love to be proven wrong.

@David.Satorres6134 , you asked:

We have reviewed the documentation but were unable to find a method or API that provides the correct compilation order for the cubes.

I gave the documentation links on how to provide the correct compilation order for classes.

In most cases the compiler does take care of dependencies and build/compile in correct order.
In my experience I have very, very rarely (maybe a couple of times) used DependsOn or CompileAfter Class keywords (I don't do cubes/DeepSee).

I'm not familiar with multiple cubes compilation, but evidently your implementation has some particular dependency that the compiler is unable to identify and take care of it.

Maybe  (just guessing here) you have some cross dependency that is "resolved" with multiple compilations?

I've seen that message too and.....I ignored it since everything works fine.

It would be nice to know without opening a WRC for something that, apart of that message, just works! 😁

If that directory is required for Web Gateway cache, then it looks like a bug in the GW installation script.

I don't have experience with SQL SP from IRIS but I believe the SQL syntax should be something like:

call ExternalDB.DB.StoredProcName(?)

I'm not sure named parameters are supported. I don't think they are.

@David.Satorres6134 , in the class EnsPortal.SuspendedMsg,  DeleteMessage() is an instance method and cannot be invoked directly.

Anyway, what it does is simply invoking:

Set tStatus = ##class(Ens.MessageHeader).%DeleteId(pHeaderId)

But, as explained in my previous post, this leave orphaned messages and should be avoided.

I suggest to add to your classes DependsOn or CompileAfter Class keywords.

I'm no sure it it makes any difference, but....what IRIS version are you using?

@Jeffrey Drumm , it's too late, he has already deleted the headers so the bodies are already orphaned.

@Kirsten Whatley , there is no query using the Ens.MessageHeader that can return orphaned message bodies info/reference. The very definition of orphaned messages is that have lost the link form Ens.MessageHeader.

Do you know the MessageBodyClassName of the messages you have deleted?
If it's a custom defined persistent class, can you provide some detail of the message(es) class(es)?
 

Whatever you use,  portal, code or SQL, I'd suggest NOT to delete the suspended messages. If you delete a message, only the message header will be deleted, leaving all the associated requests/responses orphaned.

I suggest discarding the messages using SQL.

Be careful doing so with a single update SQL statement for 2M messages, with more that 1000 records lock escalation will lock the entire Ens.MessageHeader table/class and your production will have big trouble. To avoid it use %NOLOCK.

Using Display mode:

Update %NOLOCK Ens.MessageHeader set Status ='Discarded' where Status = 'Suspended'

Using Logical or ODBC mode:

Update %NOLOCK Ens.MessageHeader set Status = 4 where Status = 5

Embedded SQL build the cached query ONCE while you compile

This is no longer true since some time/version, please check relevant documentation:

Embedded SQL is not compiled when the routine that contains it is compiled. Instead, compilation of Embedded SQL occurs upon the first execution of the SQL code (runtime). First execution defines an executable cached query. This parallels the compilation of Dynamic SQL, where the SQL code is not compiled until the SQL Prepare operation is executed.

As a result, some assumptions, even in the main post, are no longer accurate.

My suggestion is to read the article in this community from @Benjamin De Boe :

New in 2020.1: the Universal Query Cache

That's not the WebGateway port, it's the web server port, so you can change it in the web server configuration.

From the port you mentioned (57773) It seems you are using PWS (aka Private Web Server) that used to be installed with IRIS before version 2023.2 (if I recall it correctly).

Since you are using version 2024.3 my guess (I can be wrong) is that your system was upgraded from a previous version, so the PWS is still installed.

If so (you are using PWS), I suggest to install a proper "web server" (Apache or, if Windows, IIS) and use it instead of the deprecated, no longer installed, PWS.

It has been announced that future version (2025.??) PWS will be removed during IRIS install.

Well...it's still valid for old versions 😉

You may want to edit and add at the beginning that IRIS can use VSS with a link to documentation.

Yes, absolutely true, if you are not using an old version/product like Caché/Ensemble.

Windows VSS support was introduced few years ago, maybe with IRIS?

So, if your backup solution has VSS quiescence enabled, you can simply rely on it and you are good to go without any script/freeze/thaw. It's authomatic.

You can check messages.log file during backup, look for something like:

[Utility.Event] Backup.General.ExternalFreeze: Start a journal restore for this backup with journal file: e:\intersystems\iris\mgr\journal\20250210.004
[Utility.Event] Backup.General.ExternalFreeze: System suspended
[Generic.Event] VSS Writer: OnThaw
[Utility.Event] Backup.General.ExternalThaw: Resuming system
[Utility.Event] Backup.General.ExternalThaw: System resumed

Backup.Task is a system class located in %SYS, I'm not sure if creating a Backup.Task in another namespace (hopefully!!) address his issue.