Love it! Thanks a lot, @Alex Woodhead !

This is exactly what I need!

Thanks a lot, @Alex Woodhead !

@Philipp Bonin , maybe you could consider that in your wonderful ObjectScript to Embedded Python translator?
 

Yes, indeed!

I had an issue with VSCode that didn't compile code. But VSCode window reload solved the problem and I saw the function in the list! Perfect!

Thank you, @Alex Woodhead !

Thanks Ed!

It is more that I convert ObjectScript to Python and it get stuck on Job command. Thought of something universal for such cases.

Thank you @James MacKeith ! This is interesting, never touched our WorkQueue Manager before.

Haha, this is good, @Alex Woodhead ! Thank you!

Neat!

@Alex Woodhead , noticed you derived the class from Ens.Rule.FunctionSet

What benefits does it give?

I was hoping to see the compiled function in the available functions list here:

But it doesn't.

This was related to OwnObjectScriptExtension. It has a nice feature of converting ObjectScript to Python. It converts quite nice but gets stuck with such special variables. 

Thanks, Robert!

Anyway I think every operation should expose these classes: request class and response class. They are like interfaces of a given service or operation.

And once I start building a transformation where it is known where the router gets the message(response) from and where it directs it the data transformation builder could show these message classes on the source and target parts of the transformation. This will safe a significant amount of developers' time.

If we think how this could be implemented, what about extending Operations with MessageClasses class, that will add two properties RequestClass and ResponseClass, that could be overridden with a proper class types by Operation developer?

This is crucial if we have a lot of 3rd party Operation and Services builders.

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!

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.