Hi @Alexander.Woodhead!

  • List installed modules that have a previous IPM bytecode install

Having IPM client in place you can check the installed modules and its versions. The newly installed module will replace the old one.

  • List installed modules that would be affected by an IRIS upgrade. Is the newer source code even available in registered repos? (Postpone the IRIS upgrade)

I'm not sure I understand correctly what you are asking here. Anyway, one can setup their own IPM registry to supply its customers/clients with IPM modules. and this private IPM registry has the list of all the versions available and the stats of installations if this is set up. So any client that has access to this registry can install any desired version or just the latest if the version is omitted.

  • Provide a batch upgrade option, to upgrade installed modules to the SAME module version but with the newer version of IRIS $ZVersion Byte code

I'm not sure this functionality exists. It's better to have a newly published module version with the upgraded IRIS $zversion bytecode.

But if this functionality is in need please submit an issue.

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
}