As I mentioned to Bob in ISC Discord chat, I'm in the midst of writing a tech article on podman w/ SAM - there are a few tricks to know even beyond the container download issue you may have. Sorry for the delay on the article - switched companies in the last week or two and my ISC Developer Community account is in transition!

For that download issue, if you can grab the containers its after on another machine and upload to /tmp or wherever, podman lets you specify a local folder to source them from - podman import is the command to look at - so podman has a copy and when compose is ran, as long as the tags match it'll pull em right in!

Edit: doc reference for podman-import:

Believe you are looking for System Configuration->Security->Applications->Web Applications, then click on the link for the webapp that looks like: /csp/healthshare/devclin and adjust the Session Timeout setting.

Default is 900 seconds I believe but we often increase ours to 1800 (30 minutes).

However, not sure this will address it for you as I'm working with a rather Production as well and my result still comes back within a few seconds. You mentioned an HTTP 500 which is a generic error - I would have expected a 408 (Request Timeout) or 504 (Gateway Timeout) if it were truly a session timeout issue.

Wonder if you can see any error in the Application Error log.

What version are you running where $EXTRACT is not available? Not sure I’ve heard of such a situation.  

edit: noted you referenced ..ReplaceStr which is an Interoperability function. There are semi-equivalents of $EXTRACT and $FIND in there as well - $EXTRACT is ..SubString. But note if you use the solution I or David presented, don’t use .. in front of $EXTRACT, $FIND or $PIECE as these aren't interoperability functions but pure ObjectScript functions. 

my suggestion, that I know works as we do something similar, is as follows:


Have to re-add the opening paren since we’re using that as our splitter, but some find it easier than chaining multiple functions together. David’s solution is certainly valid too.

Not to dog pile on as the links provided above provide the information but I want to highlight this one in particular, as it was a big 'gotcha' for us and even a long time InterSystems consulting partner I was working with at the time.

You can do everything else right, but if you setup your URL prefix in IIS for dev to be, say, /dev, so URLs would be, but your instance name is IRIS or ANYTHING other than 'dev', you will fail and not understand why.

The link I shared is just a sub-section of the same link Alexander shared but it addresses this gotcha. You must use that command in terminal to set the prefix on the instance associated with the URL prefix you created for it to recognize it appropriately. Without it, the only 'prefix' that will work by default is the name of the instance itself.

Hint, you can specify multiple prefixes (if desired) in comma-delimited format. It mentions that as well but a reason I bring it up is it helps tremendously cut down on the number of separate IIS configs to maintain in mirroring situations because I can setup the main prefix for the VIPA (Virtual IP Address) but also add prefixes for the individual server identifiers so if necessary, we can directly go to the individual servers of the mirror, even if they're not the current primary, for maintenance tasks (upgrade prep, security/task syncs, etc).  In this way, it totally negates any need for the private web server to remain running on your instances (big security win) and keeps the amount of maintenance relatively low on the IIS (or other web servers) side as well.

Nice! This post is definitely a good example of a plethora of ways to solve the same challenge. :-)

We have scripts similar to yours above that use SQL on Ens_Config.Item to iterate through for auditing component settings on a daily basis to ensure our engineers don't do anything too crazy (on purpose or not!) and it has worked well for us for several years now so confident in saying it should be a decent approach for you as well!

Best of luck!

That’s fair - another consideration then is something we also use - globals as “global parameters”. 

I.e. create a global like ^MyPkg(“DowntimeActive”) = <future $H value here> and then use a simple boolean check to see if current $H is less than the globals $H. Thus it automatically expires for us.  

We’ve evolved a bit beyond this now but for the source control reasons, it may be a simple solution. 

Hey @Jimmy Christian - Read through your responses to others to understand a bit more of what you're after. Short of creating a custom process class, there's no way to expose a setting on the Router in the Management Portal Production UX.

That said, if I understand what you are ultimately trying to achieve, might I suggest a simple Lookup Table named something like 'RouterDowntimeSettings' and then in that table, simply have some entries defined like:

Key Value
MyPkg.Rules.ClassName 1

Then inside your rules where you want to use this, you simply use the built-in Lookup function on that table and pass in the class name that you specified as the key. Might look something like this:


<rule name="Discard" disabled="false">
<when condition="Lookup('RouterDowntimeSettings','MyPkg.Rules.ClassName')=1">

Since Lookup returns empty string if the key is not found, this would only return true if a key was explicitly specified in the table, thus making it easy to implement as needed without causing unexpected errors or functionality.

Just an alternate approach that may work for you and reduce the amount of effort (no custom class creation that would need to be maintained). 

Edit: Fixed the boolean, didn't see your original was using returns.