Yes, thank you Robert. I'm wondering why the class of the request message (which is the same as incoming message) and response message (which is outgoing) are not the properties of the class of operation. As every time when we do a Router it connects one operation or service with another and should be suggested automatically to a transformation UI. 

@Kurro Lopez !

I overlooked your package and introduced my own "one-class" package to handle this.

So the Setup.Init() method is not a loop anymore :)

ClassMethod Init(TgToken As %String, GPTKey As %String) As %Status
{
    set st=$$$OK
    set production="shvarov.telegramgpt.i14y.TgGptProduction"

    for item="Telegram.InboundService","Telegram.OutboundOperation" {
        set st=##class(shvarov.i14y.Settings).SetValue(production,item,"Token",TgToken)
        quit:$$$ISERR(st)
    }
    set item="St.OpenAi.BO.Api.Connect"
    set st=##class(shvarov.i14y.Settings).SetValue(production,item,"ApiKey",GPTKey)
    return st
}

Nothing happens until you intentionally load classes from a new branch and other resources into an IRIS namespace.

But I highly recommend you to rebuild iris docker image and reload classes from a new branch when switching branches otherwise you could have a mix of two (or even more) branches in IRIS that can lead to unexpected behaviour.

Great article, @Muhammad Waseem !

I'd add a docker command to start terminal.

First this one launches IRIS and creates a fresh namespace alone with the user 'demo' and password 'demo':

docker run --rm --name iris-demo -d -p 9091:1972 -p 9092:52773 -e IRIS_PASSWORD=demo -e IRIS_USERNAME=demo -e IRIS_NAMESPACE=DEV intersystemsdc/iris-community

Then to launch a terminal in PROD namespace:

docker exec -it iris-demo iris session iris -U DEV

DEV>