Great spot @Timothy Leavitt 
Extra syntax sugar, can project as method expression to make more transparently embedded.

 ClassMethod makeComplement(d As %String) As %String [CodeMode = expression]
{
 $tr(d,"ATGC","TACG")
}

Also I believe Java lacks convenience of compile time ObjectScript macros:

#define DNAComplement(%dna) $tr(%dna,"ATGC","TACG")

Write $$$DNAComplement("ATC")

Sharing for readers, an alternative code approach, to generate a pad-string without Translate and Justify, uses another application of the Piece function.

set $Piece(replace,",",81)=""

This is sets a comma delimited string, at piece 81, to an empty string.

Which effectively results in a string of 80 commas.

So:

 Parameter WhiteSpace = {$C(9,10,13,32,160)}; 

ClassMethod Short(t) As %Integer
{
  s $P(replace,",",$L(..#WhiteSpace)+1)=""
  s t=$zstrip($TR(t,..#WhiteSpace,replace),"<=>",",")
  q:'$L($TR(t,",")) 0
  s l=$L(t,","),m=$L($P(t,","))
  f i=1:1:l {s n=$L($P(t,",",i)) s:((n>0)&&(n<m)) m=n}
  q m
}

Regarding input. I don't trust calling code to never provide an empty string :)

Example updated as feedback.

"uit"

Thanks for recommendations. Taking these changes onboard think I would then make the whitespace characters configurable.

Then others can just override this behaviour in a subclass or maintain the original a bit easier.

Parameters are a great ObjectScript syntactic sugar :)

Parameter WhiteSpace = {$C(9,10,13,32,160)};

ClassMethod Short(t) As %Integer
{
  s t=$zstrip($TR(t,..#WhiteSpace,",,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,"),"<=>",",")
  q:'$L($TR(t,",")) 0
  s l=$L(t,","),m=$L($P(t,","))
  f i=1:1:l {s n=$L($P(t,",",i)) s:((n>0)&&(n<m)) m=n}
  q m
}

Hi Jimmy,

Yes this is using the router context to test if a message has some invalid characters.

As an example I simply used the content "BAD" in the message to demonstrate.

If you want to identify specific characters by numeric code-point an additional FunctionSet method could be employed. For example:

 /// RuleSet function to evaluate whether a given raw input string contains unwanted characters
/// Unwanted characters are supplied as a comma delimited string.
/// For example detect "9,32" would match any ASCII Tab and ASCII space characters
/// The $ASCII function can be used to identify the numeric code point of a character, to be supplied in the detect parameter.
ClassMethod ContainsChars(rawData As %String = "", detect As %String = "") As %Boolean
{
    quit:$Length(rawData)<1 0
    quit:$Length(detect)<1 0
    set found=0
    set len=$Length(detect,",")
    for item=1:1:len {
        set charNum=$Piece(detect,",",item)
        continue:charNum'?1.N
        set char=$Char(charNum)
        if rawData[char {
            $$$TRACE("Found Character "_charNum_" in rawData")
            set found=1
            quit
        }
    }
    quit found
}

Usage example:

Cheers,

Alex

This is sucessful if no longer showing class not found error.

It found the class and ran the method sucessfully.

Set rowId=1

If ##class(EnsLib.HL7.Message).%ExistsId(rowId)=0 or 1 then

    The class EnsLib.HL7.Message has been mapped to the current namespace.

It is giving 0 because there has been no HL7 messages created yet (with rowId 1) or message rowId 1 has been purged from namespace.

A better non-error prone way to programatically test whether the class is available to the namespace could use:

write ##class(%Dictionary.CompiledClass).%ExistsId("EnsLib.HL7.Message")

Hi Michael,

Anastasia mentioned rerun is at: https://youtu.be/DBGvt0jd4yI

Hi Scott,

Many thanks for reporting this. Yes this is unintuitive.

I have updated the implementation so:

1. Method GenerateTestCases now has additional parameter autocompile which is default yes.

2. Method AddTestFromMessageBody now has additonal parameter recompile default no.

Now when you generate new TestCases by default they will be auto-compiled and ready to accept attaching new HL7 messages for testing.

For clarity the message id "1218515" will be an EnsLib.HL7.Message RowId. This is the same ID seen in System Management Portal Integration Messages view as MessageBodyId.

To have added messages immediately ready (compiled) for next test run can use:

set recompile=1

set tSC=##class(UnitTest.Test.DTL.TestTrans.TransformSource2).AddTestFromMessageBody("EnsLib.HL7.Message",1218515,1,.sourceXdataName,.targetXdataName,recompile)

The class "UnitTest.Test.DTL.TestTrans.TransformSource2" was generated from an an HL7 DTL class "UnitTest.DTL.TestTrans.TransformSource2" in my test environment.

I have also added reference test class: UnitTest.DTL.TestTrans.TransformSource2.xml to github,

# Example Generate from reference class:
Do ##class(UnitTest.DTL.HL7TestCase).GenerateTestCases("UnitTest.DTL.TestTrans.TransformSource2", "UnitTest.DTL.Test2.TestTrans.", 0 , , 0,1, 1, .pStatus)

Skipping class UnitTest.DTL.TestTrans.seg.MSH not matched
Skipping class UnitTest.DTL.TestTrans.seg.PID not matched
Created TestCase: UnitTest.DTL.Test2.TestTrans.TransformSource2
Compilation started on 08/18/2022 19:56:23 with qualifiers 'ckf'
Compiling class UnitTest.DTL.Test2.TestTrans.TransformSource2
Compiling routine UnitTest.DTL.Test2.TestTrans.TransformSource2.1
Compilation finished successfully in 0.031s.

# Add a new test message pair from an existing HL7 message with rowid 189
set tSC=##class(UnitTest.DTL.Test2.TestTrans.TransformSource2).AddTestFromMessageBody("EnsLib.HL7.Message",189,1,.sourceXdataName,.targetXdataName,1)

# Run UnitTest
do ##class(UnitTest.DTL.Test2.TestTrans.TransformSource2).Debug()

# There will be one intentional error as the original template for manually adding messages is still present. But it does demonstrate attempting to process both pairs of message blocks.
# Perhaps this placeholder template should be suppressable when generating new TestCases if always programatically adding them.

 XData TESTMessageSource
{
<test><![CDATA[
<!-- Your Source HL7 Message or Segment content goes here -->
]]></test>
} XData TESTMessageTarget
{
<test><![CDATA[
<!-- Your Expected output for HL7 Message or Segment content goes here -->
]]></test>
}

Thank you for trying out the utility.

Hi Scott,

Have released a new community utility  for comparing the routing of a set of HL7 messages between systems or version of productions.

https://openexchange.intersystems.com/package/BulkProfile-HL7RoutingRul…

Tested on IRIS for Health versions RedHat 2018.1.2 and RedHat 2022.1.

Kind regards,

Alex

Great questions to consider.

1. The single message.
  The princplie with the example is a single base message for maximum reuse.
  However you define many Methods with the prefix "Test" and these automatically get run by the UnitTest runner.
  Within each method you can send one or more variations of the base test message.
  For example: Consider RoutingRules with different behaviour for Age and Gender.
  Within the same TestMethod you can implemented small updates to the base message to ensure full coverage of your routing rule logic.
  ie: TestAgeGender Method, could send adjusted messages for various age ranges and genders.
2a. Yes the automatic correlation of one base message in BeforeAllTests was done as a convenience.
  It is trivial to add a helper method to pull messages for different XData sources as needed. I will add this. Good suggestion.
 b. Yes. I could also implement a much simpler utility that simply reads HL7 files from a directory and outputs a CSV report of:
   * Source filename
   * Routing Result: Which rule number was applied
   * Routing Return Value: Where it was sent, What transform was employed
   This doesn't need the UnitTest runner and the corresponding web report to be generated.
   Expect you could run the "Test Reporting" class on both the pre-migration and the post migration platform and compare the output report.
3. Yes I have experience with UnitTests for DTLs.
   The particular challenge for these I find are with generated fields like some Dates, and Episode Number.
   ie: You want to compare most things you transform about a message, but wish to exclude certain fields for UnitTest validation as they always have a different / unique value.
   A non-intellegent comparison tool will just say the output files are always different.
   For this I have some other code that analyses all DTLs in a namespace and generates corresponding UnitTest classes with targeted "Compare" methods, generated by parsing the DTL XML.
   This allows you to easily go in after generation and comment out a few specific HL7 fields you wish to exclude from comparison between the expected and the actual HL7 transform result.
   The reuse here is in adding new XData message pairs, for source and expected transformed message, to Tests to the class definition.
   The unit Test automatically picks up the new messages to transforma and validate. So you could actually employ an analyst role instead of developer, to enhance DTL UnitTests for edge cases.  

The main value with UnitTests is for continious integration and / or avoiding future changes breaking code behaviour in unexpected ways.
It also allows you to validate parts of a production in isolation.
It automates regression tests of code.
It can save time with rework. For example I had a routing rule for routing and filtering messages based on their Snomed classifications. The rules were quite complex and would take hours to manually test.
However with one Routing Rule UnitTest I could add an enhancement and retest in minutes with the confidence that previous behaviour was preserved.
There is a judgement on which approach brings the most immediate value, but in the longer term incrementally adding UnitTests can enforce more robust and controlled transformation and routing behaviors.