Hi Evgeny,

If the operation class is using the mechanism in Ens.BusinessOperation to route incoming requests to the OnMessage() method, you can use the XData content to get a list of supported request (just as the Portal testing dialog does). If the operation class implements it’s own custom OnMessage(), there is no simple way to tell what request classes are supported. The XData is described in the documentation.

For responses, there is a RESPONSECLASSNAME parameter defined in classes extending Ens.Request. I believe this used by the BPL editor. This is somewhat limited however, since the operation can as well respond with any %RegisteredObject object and accept any kind of request (via OnMessage), e.g. any class extending %RegisteredObject if it is marked as "in process".

Anyways, as Robert C. points out, documenting what the operation intent is and it's interface, especially if they are not trivial, helps a lot and IMHO is best practice.

For simple headers (and footers), you can use the 'batch class' feature of the record map file batch service (EnsLib.RecordMap.Service.BatchFileService) and operation (EnsLib.RecordMap.Operation.BatchFileOperation), and a class such as EnsLib.RecordMap.SimpleBatch to specify a header string.

The record map file operation append records to the output file. The initial value of the 'Filename' setting is '%Q', hence you get one file per timestamp.

If you set "Filename" to '%f', the output file name will be the same as the input file name and records from one input file will be appended to an output file with the same name.

You can call the Tranform(source,target) class method implemented by classes that extend Ens.DataTransform :

• directly in objectscript code
• through code generated for a BPL or router process ('send' action optionally uses a list of transformation classes that gets applied in sequence to the message before it is sent to target(s)). 
• through code generated by a DTL ('subtransform')

If you need to process the entire file and no line filtering, I would go for using pass through file service (EnsLib.File.PassthroughService) to send an instance of stream container (Ens.StreamContainer) to either a message router (EnsLib.MsgRouter.RoutingEngine) or custom (BPL or code) process, and use a transform (class extending Ens.DataTransform) to transform the source stream container into a target stream container and send it to the file pass through operation (EnsLib.File.PassthroughOperation) for output.

I would use a custom process over message router if transform needs data source(s) (e.g. response from another process or operation) other than the input file. The transform can pick a suitable target stream class (Extending %Stream.Object) to hold in the Ens.StreamContainer depending on where you want to store the data (database vs file system,…)

HTH

Merry Christmas everyone !

My first time with AoC was a lot of fun, thank you for running this Objectscript ladder.

Congratulations to all participants.

My repository: https://github.com/theanor/idc-aoc-2022-theanor

And quality scanner status : https://community.objectscriptquality.com/dashboard?id=intersystems_iris_community%2Fidc-aoc-2022-theanor

To get an IRIS session integrated in VSCode terminal, you can add it to settings.json :

  "terminal.integrated.profiles.windows": {
        "IRIS Terminal": {
            "path": [
                "C:\\InterSystems\\IRISHealth\\bin\\irissession.exe"
            ],
            "args": ["<instance name>"],
            "icon": "terminal-cmd"
        }
    }

However, this terminal window will lack the niceties of the ISC Terminal application, such as command history.

Hi Ben,

You can use EnsLib.HL7.Schema ResolveSchemaTypeToDocType() class method to resolve DocType dynamically.

For example, if message is an OREF to an instance of EnsLib.HL7.Message :

s message.DocType = ##class(EnsLib.HL7.Schema).ResolveSchemaTypeToDocType("2.5",message.Name)