Resources property is not evaluated. You can see that in %Installer.Role class, %OnGenerateCode method.

/// Generate code for this document.
Method %OnGenerateCode(pTargetClass As %Dictionary.CompiledClass, pCode As %Stream.TmpCharacter, pDocument As %Installer.Manifest) As %Status [ Internal ]
{
Do pCode.WriteLine(..%Indent()_"Do tInstaller.CreateRole($$$EVAL("_..Target_"),$$$EVAL("_..Description_"),"""_..Resources_""","""_..RolesGranted_""")")
Quit $$$OK
}

You can get around that with this hacky solution:

 <Role
Name="${PMGNAMESPACE}"
Description="Works User Role for ${PMGNAMESPACE} Namespace"
Resources='"_tInstaller.Evaluate("${PMGDbResource}:RW,PMG:RWU")_"' RolesGranted="" />

Which would be compiled into the following code:

 Do tInstaller.CreateRole(tInstaller.Evaluate("${PMGNAMESPACE}"),tInstaller.Evaluate("Works User Role for ${PMGNAMESPACE} Namespace"),""_tInstaller.Evaluate("${PMGDbResource}:RW,PMG:RWU")_"","")

I guess if you need to do that once, it's okay. But if it's a regular occurrence writing a method and calling it from installer might be a better solution.

Here's an article on %Installer usage.

Not sure about delegated authentication (is it only delegated? Or with password? Details may vary depending on your exact setup), but for password authenticated web application SSO is possible by following these steps (originally written for CSP+REST web apps, but the idea is the same):

  1. All brokers effectively have Parameter UseSession = 1;
  2. REST web application and client web application allow only authenticated (i.e. password) access.
  3. REST web application and client web application have reasonable Session timeout (i.e. 900, 3600).
  4. REST web application and client web application have the same GroupById value.
  5. REST web application and client web application have the same cookie path.

If all these conditions are met, user would only consume one license slot per session and perform only one login and audit database would store only one login event per session.

Compare what user entered to the specific value. If they mismatch  - ask again. Also there are several utility methods in %Prompt class for number/yes-no/etc input:

  • GetNumber
  • GetString
  • GetYesNo
  • GetArray - Prompt for a number or entry in a displayed menu. Returns the selected item.
  • GetMenu - Prompt for a number in a displayed menu.
  • GetMore - Prompt for More or Quit.

For example:

do ##class(%Prompt).GetYesNo("Enter Yes or No:", .result)

User can input only Yes (Y) or No (N). result variable would hold 1 or 0.

You can also check %Prompt code and write something based on that.

Turns out Java Gateway can instantiate objects and call their methods.  Here's a rewrite of the above code, but all connecting is done in constructor:

package com.isc.rabbitmq;

import com.rabbitmq.client.*;

public class Wrapper {
    private final Channel _channel;

    private final String _queueName;

    public Wrapper(String hostName, String queueName)  throws Exception {
        ConnectionFactory factory = new ConnectionFactory();
        factory.setHost(hostName);
        Connection connection = factory.newConnection();
        _channel = connection.createChannel();
        _channel.queueDeclare(queueName, false, false, false, null);
        _queueName = queueName;
    }

    public void sendMsg(byte[] msg) throws Exception {
        _channel.basicPublish("", _queueName, null, msg);
    }

    public int readMsg(byte[] msg) throws Exception {
        boolean autoAck = true;
        GetResponse response = _channel.basicGet(_queueName, autoAck);
        int len = 0;
        if (response == null) {
            // No message retrieved.
        } else {
            AMQP.BasicProperties props = response.getProps();
            len = response.getBody().length;
            System.arraycopy(response.getBody(),0,msg,0,len);
        }
        return len;
    }

}