I like your idea of introducing it in a "New Transform" Wizard

Ah, thanks Alex! I should have been enabling the Testing option for Production first.

Yes, this shows a set of available requests but doesn't expose response types though.

IMO request and response message classes are like Interfaces of a service or a production so it should be very obvious which they are.

Hi Alex! This is a good one about Test Action!

However it doesn't work for me - maybe it is a UI glitch:

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
}

Thank you, @Kurro Lopez ! I'll take a look!

The bonus set is updated. Two bonuses added:

• 4 points for the community opportunity implementation.
• 1 point for the columnar index usage.

Thank you, @Guillaume Rongier! I like it!

But sometimes we can just have a production with "standard" services and operations, so there is no option to override OnInit().

How can I use it as a parameter to IPM installation? 

The only caveat that this approach works only for the "pre-initialised" settings - those that are presented in the production class xdata block. So, if you plan to make changes programmatically, init these settings with any placeholders and this method will be able to change it programmatically later.

Looking forward!

For now it ended in the following way:

USER>d ##class(shvarov.telegramgpt.Setup).Init($system.Util.GetEnviron("TG_BOT_TOKEN"),$system.Util.GetEnviron("OPENAPI_KEY"))

This is how we can setup production after docker build and start in the following project. Thank you, @Guillaume Rongier 

Thanks @Alexander.Woodhead!

Already implemented in this manner. Now the module can be installed as is:

USER>zpm "install telegram-gpt -D TgToken=your_telegram_token -D GPTKey=your_ChatGPT_key" 

Thank you, @Sergey Mikhailenko !

This is exactly the thing I was looking for.

Implemented in a new version of ChatGPT Telegram bot

In a new version can also be installed as:

USER>zpm "install telegram-gpt -D TgToken=your_telegram_token -D GPTKey=your_ChatGPT_key"

so you can pass the Telegram Token and ChatGPT API keys as production parameters.