OK. Lets just do this already !!

This example uses Properties and Settings to expose the Request and Response Types so they are viewable from the Management Portal:

This is achieved with the following code:

Class Test.Operation Extends Ens.BusinessOperation
{
Parameter ADAPTER = "EnsLib.HTTP.OutboundAdapter";
Property Adapter As EnsLib.HTTP.OutboundAdapter;
Parameter INVOCATION = "Queue";
Property RequestTypes As %String(MAXLEN = 4000) [ InitialExpression = {..GetRequestTypes()}, Transient ];
Property ResponseTypes As %String(MAXLEN = 4000) [ InitialExpression = {..GetResponseTypes()}, Transient ];
Parameter SETTINGS = "RequestTypes:Info,ResponseTypes:Info";

ClassMethod GetRequestTypes()
{
  set ret=""
  set messageTypes=..GetMessageList()
  quit:messageTypes="" ret
  for i=1:1:$LL(messageTypes) {
    set ret=ret_$C(13,10)_$LI(messageTypes,i)
  }
  quit ret
}

ClassMethod GetResponseTypes()
{
  set ret=""
  set messageTypes=..GetResponseClassList()
  quit:messageTypes="" ret
  for i=1:1:$LL(messageTypes) {
    set ret=ret_$C(13,10)_$LI(messageTypes,i)
  }
  quit ret
}

XData MessageMap
{
<MapItems>
  <MapItem MessageType="Ens.StringRequest"> 
    <Method>DoOne</Method>
  </MapItem>
  <MapItem MessageType="EnsLib.HL7.Message"> 
    <Method>DoTwo</Method>
  </MapItem>
</MapItems>
}

Method DoOne(request As Ens.StringRequest, response As Ens.StringResponse)
{
}

Method DoTwo(request As EnsLib.HL7.Message, response As EnsLib.HL7.Message)
{
}
}

How it works.

The Getter methods populate the Properties ( RequestTypes, ResponseTypes ) via InitialExpression

These Properties are exposed to the User Interface via the SETTINGS parameter

Note also I have set the MAXLEN of the properties over 2000K characters. This forces the Management Portal to render a TextArea instead of a single line Text input control.

The reuse pattern is to have this code in a class.

Then can add behavior via extends to inherit this behavior.

Class Test.NewOperation2 Extends (Ens.BusinessOperation, Test.Operation)
{
Parameter INVOCATION = "Queue";
}

IRIS is so flexible :)

w +$h

If someone else stumbles across question in the future:

Some encoding values supported are:

• Unicode
• Byte
• BigEndianUnicode
• UTF8
• UTF7
• UTF32
• Ascii
• BigEndianUTF32

Hi Tommy,

Something that might be a placeholder to this facility could be: https://openexchange.intersystems.com/package/UnitTest-RuleSet

The idea is a self-contained UnitTest class containing a Vanilla Starting HL7 message defined in a XData block.

Each test method constructs a clone of the starting HL7 message, makes required modifications, before sending to a target via a named Service.

I suppose it is simpler without the routing rule, check. Interested what Assertions are needed.

For example:

* Checking a MessageHeader was created for the same SessionId with a particular Target Name

* Checking a response was received from an end-point

From your question; Is there a particular reason to send over TCP to a Service? Is the message generator and sending being used for end-to-end / volumes / message types stressing?

Is this about message content variation (optional values) as well as the full message with a value in every field.

Hi Doug,

Have you considered creating a new Rule FunctionSet.

This would then appear in as a new available function in Rule Editor when compiled.

For example:

Class Test.Fun Extends Ens.Rule.FunctionSet
{
ClassMethod SegmentFieldContains(pDocument As EnsLib.HL7.Message, segmentName = "", fieldNumber = 0, value As %String = "")
{
  // validation
  quit:segmentName'?3AN 0
  quit:fieldNumber<1 0
  quit:value="" 0
  set isFound=0
  // get count of segments
  set segCount=pDocument.GetValueAt("*")
  // loop through all of the segments
  for i=1:1:segCount {
    set seg=pDocument.GetSegmentAt(i)
    continue:'$IsObject(seg)
    // skip wrong segment
    continue:seg.GetValueAt(0)'=segmentName
    // skip if field does not contain value
    continue:seg.GetValueAt(fieldNumber)'[value
    set isFound=1
    quit
  }
  quit isFound
}

}

Hi Mark,

Some thoughts on this:

Anticipate the online backup (CBK) may tie-in with operating system and Cache version to run the restore

It may be better to have "at rest" CACHE.DAT files:

They can be:

• Renamed to IRIS.DAT
• Mounted and "upgraded"
• Endian converted if needed

Having md5 checksum of CBK / DAT files can help identify transfer issues to / from offline media.

An integrity check can also be a useful confirmation tool to trace back if the original backup had issue.

Having undeployed SQL table definitions maybe useful future proofing.

For older versions of Cache install media contact the wrc.intersystems.com

Anticipate IRIS will be here after another 45 years, so will easily meet the 10 year requirement.

Hi Robbie,

I had created a OpenExchange PythonHelper : https://openexchange.intersystems.com/package/PyHelper

// Create an IRIS List turn into a Python List
set pyList=##class(alwo.PyHelper).toPyListOrString($LB(1,2,3,4,5,6))
// Write to terminal to check content
zw pyList
pyList=3@%SYS.Python  ; [1, 2, 3, 4, 5, 6]  ; <OREF>
// Convert the Python List to a IRIS List
set myIRISList=##class(alwo.PyHelper).ListFrompyList(.pyList)
// Output to terminal to confirm
zw myIRISList
myIRISList=$lb(1,2,3,4,5,6)

Any feedback welcome.

Hi Evgeny,

Not saying this is best way but this indirection can be achieved with python eval. For example:

$Classmethod equivalent

classname="%SYSTEM.SYS"
methodname="ProcessID"
eval(f"iris.cls(\"{classname}\").{methodname}()")

$Property equivalent

Instantiating a Python exception and then iterate over properties printing out:

myerror=iris.cls("%Exception.PythonException")._New("MyOops",123,"def+123^XYZ","SomeData")

for propertyname in ["Name","Code","Data","Location"]:
    propvalue=eval(f"myerror.{propertyname}")

    print(f"Property Name {propertyname} has value {propvalue}\n")

output was:

Property Name Name has value MyOops
 
Property Name Code has value 123
 
Property Name Data has value SomeData
 
Property Name Location has value def+123^XYZ

$Extract ($E) and $Translate ($TR) can provide a string manipulation

> set inDate="1997-08-09 10:38:39.700000000"
> set outDate=$TR($E(inDate,1,19)," ","T")_"Z"
> write !,outDate
1997-08-09T10:38:39Z

So steps are:

• Grab the first 19 characters
• Convert space " " to "T"
• Append a "Z" to the end

Ignore if already the case, but would also recommend familiarity with $Piece, $Select and "[" (Contains operator) . $Find can also be efficient in string searches.

Thanks @Evgeny Shvarov , this is the optimal approach. As on reading the documentation it suggests you can target different IRIS builds (with the help of docker code compiling hosts) and the IPM repository can host the same module version for different $ZVersion IRIS targets transparently.

Is there intention to support code signing, and with pre-install validation, to ensure code cannot be modified at rest, between being uploaded to a repo and then downloaded to a third-party instance?

Wondering practically about an IRIS upgrade process. Should the IPM client have ability to:

• List installed modules that have a previous IPM bytecode install
• 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)
• Provide a batch upgrade option, to upgrade installed modules to the SAME module version but with the newer version of IRIS $ZVersion Byte code

Restating advice from above.

A mapping rule is required per database with data.

For example.

------------ Mapping one -----------------

Global Database Location = 201606_HIPAA

Global Name: HISTORY

Global Subscripts to be Mapped: (201606)

------------ Mapping Two -----------------

Global Database Location = 201607_HIPAA

Global Name: HISTORY

Global Subscripts to be Mapped: (201607)

-------------------------------------

Can see Global "History" is stated in question.

Suggest review is needed to double-check where indexes and rowID counters are stored.