CSP pages are at the beginning of a long compilation pipeline

CSP + CSR -> Cls + inc -> Mac -> Int -> Obj

So anticipate CSP can be similar case to handling classes but with the attention on the target package name configured for class generation.

For a webserver extension handler (for csp, cls) it can be configured to skip check for the existence of physical CSP file. In CSP application configuration the "check for recompilation" option can be disabled.

Alternatively CSP pages can be implemented directly as classes that extend %CSP.Page with web requests going to " [classname] .cls " instead.

Check out utility method :

Do $SYSTEM.OBJ.MakeClassDeployed(.classes, qspec, fulldeploy)

Another avenue for consideration are legacy utilities: %RIMF and %ROMF can load and export respectively, compiled obj byte code (pcode)

Hi Evgeny,

They should show up after being compiled.

May need to close the DTL completely and reopen to get the list to repopulate?

The benefits should be for easy reusability in Transforms and Business Rules

Starting the production, allows the "Test" action to be available.

Testing is enabled on production settings

Hi Evgeny,

Historic message type flows can be seen with:

SELECT %NOLOCK DISTINCT SourceConfigName,TargetConfigName,MessageBodyClassName
FROM Ens.MessageHeader
ORDER BY SourceConfigName,TargetConfigName,MessageBodyClassName

For a running production with Testing enabled, the Test Action launches a dialog with drop-down list of test message types handled by an operation.

See: Class EnsPortal.Dialog.TestingService with classmethod GetValidRequestTypeList

A pattern I have noticed implemented for processing generic XML Streams is for a property to be exposed in the business operation that configures a list of expected ClassNames ( supporting %XML.Adapter ) to correlate.

An interesting question for 3rd-party providers of interoperability components.

Maybe this is suggesting a "New Transform" Wizard could be aware of the production in focus.

In some implementations due to the visibility of notes in the management portal, these may be directed more at a "support role" than a "developer role" for which the organizations may be different. So some empathy with removing the dev teeth from descriptions where they might be confusing, outside an operational support context. Possibly would be beneficial to have different types of production visible notes.

.

If the question is regarding automated setup configuration of services:

A recent advancement if you are using Linux / Unix platform is to use cpf merge.
https://docs.intersystems.com/iris20231/csp/docbook/DocBook.UI.Page.cls?...
This can manage instance configuration file and CSP applications.

CSP Merge can be applied on the first startup of service in Docker provisioning.

Before that, and for Windows currently, have successfully implemented %INSTALLER classes to reconfigure vanilla servers for application migration and usage.
https://docs.intersystems.com/iris20231/csp/docbook/Doc.View.cls?KEY=GCI...

Security was mentioned as a challenge for LLM. Will mention LangChain does have a feature if useful:

https://python.langchain.com/en/latest/modules/chains/examples/constitut...

For info to also share about Class: Ens.Production has ClassMethod ApplySettings.

set pSettings(<itemName>,<target>,<settingName>)=<settingValue>
do ##class(Ens.Production).ApplySettings(<productionName>, .pSettings)

From terminal / csession do you get "1" returned when running:

write ##class(%SYS.TaskSuper).SuspendSet(1)

Failing that, if the server is not being used currently would stop and then start Ensemble Service in Emergency Mode and disable TaskScheduler / remove problem schedule. Then shut down Ensemble service from Emergency mode and start up Ensemble as normal.

Have created an article to demonstrate at: https://community.intersystems.com/post/dynamically-creating-hl7-message...

Thanks @Evgeny Shvarov for the challenge.

I was digging through the ZPM code this afternoon. What I discovered is the need to implement AbstractInstaller and include in your module resources.

Here is a class that implements loading System Default Settings via ZPM command (when configuration phase is included by a ZPM activity)

 Class alwo.ChangeProductionSetting Extends %ZPM.AbstractInstaller
{
 Parameter Version = 1.0;

Parameter MaintenanceVersion = 5;

 ClassMethod OnConfigureComponent(pNamespace As %String, pVerbose As %Boolean = 0, ByRef pVars) As %Status
{
set tSC=$$$OK
set tSettingName=""
set (tProductionName,tItemName,tHostClassName,tTarget)="*"
set tValue=""
set varName=""
for {
  set varName=$O(pVars("zpm",varName),1,varValue)
  quit:varName=""
  if $ZCVT(varName,"U")="PRODUCTIONNAME" {
    set tProductionName=varValue
  } elseif $ZCVT(varName,"U")="TARGET" {
    set tTarget=varValue
  } elseif $ZCVT(varName,"U")="SETTINGNAME" {
    set tSettingName=varValue
  } elseif $ZCVT(varName,"U")="ITEMNAME" {
    set tItemName=varValue
  } elseif $ZCVT(varName,"U")="VALUE" {
    set tValue=varValue
  } elseif $ZCVT(varName,"U")="HOSTCLASSNAME" {
    set tHostClassName=varValue
  }
}

set existingId=tProductionName_"||"_tItemName_"||"_tHostClassName_"||"_tSettingName 

if tSettingName'="" {
  if ##class(Ens.Config.DefaultSettings).%ExistsId(existingId) {
     set oDefaultSetting=##class(Ens.Config.DefaultSettings).%OpenId(existingId,1)
  } else {
    set oDefaultSetting=##class(Ens.Config.DefaultSettings).%New()
    set oDefaultSetting.ProductionName=tProductionName
    set oDefaultSetting.ItemName=tItemName
    set oDefaultSetting.HostClassName=tHostClassName
    set oDefaultSetting.SettingName=tSettingName
  }
  // Assumes use of whitespace in settingValue is as intended
  set oDefaultSetting.SettingValue=tValue
  set tSC=oDefaultSetting.%Save()
}
Quit tSC
}    
}

Next in my ZPM module definition I added the tag at same level as Resource tags:

<Resource Name="alwo.TestProduction.CLS"/>
<Resource .... />
<InstallerClass>alwo.ChangeProductionSetting</InstallerClass>

In the zpm install command I could use:

load -v \some\localfolder\AddSetting -DProductionName=alwo.TestProduction -DHostClassName="EnsLib.MsgRouter.RoutingEngineST" -DItemName=TestProcess -DTarget=Item -DSettingName=RetryInterval -DValue=25

If you change your mind about the setting or want to add a second setting you can use for example:

module-action alwo-changeproductionsetting configure -only -DProductionName=alwo.TestProduction -DHostClassName="EnsLib.MsgRouter.RoutingEngineST" -DItemName=TestProcess -DTarget=Item -DSettingName=RetryInterval -DValue=25

For the arguments the only mandatory ones are:

• -DSettingName
• -DValue

When the others are not specified they simply go in as wildcard "*" against the System Default Settings.

BTW: Need to delete the "settable" values from the Production XData configuration in distribution, so that the default is applied.

ie: If looking at Production Configuration in Management Portal and a production Item setting is displaying with the Black font label, it means this value is masking the System Default Setting.

If you don't want to pass so many D parameters then some of the values could be hardcoded for project as Parameters in the InstallerClass.

 Parameter DProductionName="A Production Name";

Parameter DTarget="Item";

Parameter DItemName="Telegram.BusinessOperation";

Parameter DSettingName="Token";

Then would would be closer to original requirement:

zpm "install telegram-gpt -D Token=sometoken"

Hope this helps.

Kind regards,

Alex

Some odd questions:

1) Is the license still valid

2) Is it possible to suspend the Task Schedule before changing the problem item.