You also can manage it if you deploy your solution as an IPM package.

Here is an example of IPM manifest to deploy code without source:

<?xml version="1.0" encoding="UTF-8"?>
<Export generator="Cache" version="25">
<Document name="demo.ZPM">
<Module>
  <Name>demo</Name>
  <Version>1.0.0</Version>
  <Description>DEMO.</Description>
  <Keywords>demo</Keywords>
  <SourcesRoot>src</SourcesRoot>
  <Resource Name="Sample.Demo.PKG" Deploy="true"/>
</Module>
</Document>
</Export>

Here are the release notes on introducing the feature.

Regarding CSP - I agree with @Alex Woodhead, you better convert your CSP to CLS classes derived from %CSP with %OnPage() where you have all your HTML, and thus you can deploy without code.

And you can refer to this CSP classes similar as you refer to CSP pages. 

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.

The links to InterSystems IRIS community Editions are updated.

The application should work either on IRIS Community Edition or IRIS for Health Community Edition. Both could be downloaded as host (Mac, Windows) versions from Evaluation site, or can be used in a form of containers pulled from InterSystems Container Registry or Community Containers: intersystemsdc/iris-community:latest or intersystemsdc/irishealth-community:latest . 

Thanks for reporting!

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
}