Hi Andrew,

Thanks for posting this. I am in the process of coding a similar automated statistics email, so I am reading your code with interest and may well use some of it. My only comment is that since this is for monitoring Ensemble, I actually decided to use Ensemble to implement it. So I have a message class with properties like "Subject" etc. and this is sent to an Operation that uses the Ensemble email adapter to send it. There is also a Service that runs once a day to pull the required information and builds the email message.

Mike

A lot of the code we have to deal with is like the "One Line" method, but then some of it was written back in the days when there was very little space in the partition for the program, and the source code was interpreted directly, so it had to be kept small. What is different is that while the code to handle the traverse is all kept on one line, which I think makes the scanning method clear, other code for pulling and writing stuff is usually on lower "dotted" lines, like this:

S Sub1=""FS Sub1=$O(^Trans(Sub1)) Q:Sub1=""  D
.W !,"Sub1: ",Sub1
.S Sub2=""F  S Sub2=$O(^Trans(Sub1,Sub2)) Q:Sub2=""  D
.. ; etc

And yes, it uses the short version of commands (as you did for the Quit, I notice). I'm not saying this is the best style to use, obviously, as things have moved on, but we do still tend to use it when amending the old code.

I think it is useful to be aware of all these variations, as you may come across old code using them. Also, sometimes the array structure can be better or faster than objects and SQL, whether in a global arrays, or in temporary local arrays. Its a very neat and flexible storage system.

Mike

Many guides to "good programming" (in any language) would advise that the return from a function/method should be used for "real" data only, and any "exception" situations should be flagged as an error. While I'm not convinced this is always the best way, I can see the advantages. Code with repeated tests of returned status values can be messy and hard to read, and if the only thing it can do when the status is a fail is to quit out again with a status of "failed", then there is not a lot to be gained.

Mike

I'm just thinking that maybe we need more information as to why this is needed before recommending anything. If the network connection is good enough for mirroring, then why not just map the classes to a central repository? Perhaps all that is needed are security settings to prevent updates from the "slave" systems. Perhaps there is no network connection, in which case mirroring or shadowing is not possible, and what is needed is a good way to automate export/import to OS files.

Mike

I have used the  %XML.Writer class to create a document, but only for a fairly simple one that was destined for a SOAP outbound call. The SDA is tricky, so I would imagine using HealthShare (Ensemble) would be much easier. (I have used Ensemble classes like EnsLib.EDI.XML.Document that can be added to a message, etc. and used as the target for transformations once you have an appropriate document definition loaded in. Reduces the coding required, though not entirely as repeating groups are an issue.)

Mike

I won't embarrass myself by listing the MUMPS code from 1991 that does this on our application, but I will comment that you need to work out how many birthdays have gone by so it must compare month and day values once the basic year subtraction has been done. It gets quite complicated. (Might also like to look at whether you need more than just a "years old", and also need months or days for very low values.)

Mike

Hi.

I'm not sure what your "persistent objects" contain, but if the repeating data is in the form of strings or streams then perhaps you could put them into a XPATH document object ( %XML.XPATH.Document) and use the evaluator in that? I support a system that has a message with a transient property to hold the document created, so it's only done once (per processing), and a method that builds that property if needed and then calls the  EvaluateExpression method in that property for an expression supplied as a parameter. This is used in transformations to extract data to post into HL7 v2 messages, so the same calls should work in rules as well.

Of course the XPATH expressions may be no easier to define than your exporting and importing methods. I certainly struggled with them and in the end had to build lots of special inputs that added the huge long list of nested items that usually went at the front of each expression, resulting in calls like source.Pull("Baby","ep2:id/@extension") where "Baby" added a prefix of over 160 characters to find the baby section of the Mother's full document before tunneling down to the hospital number. If you already have a sub-section of the full document then you may not need as much.

Mike

Anyone know why we ended up with this strange behaviour? Why doesn't COS store 2 and "2" in the same way in lists? The rest of the programming environment is based around them being the same - (2="2") - as everything is a string until used otherwise. It may use "an optimized binary representation", but surely that's not really an excuse. Just curious.

Hi,

I won't claim this is an answer, because it's not quite the same and people may object to the structure, but here is one solution that is used quite a lot in code I look after. Basically, a subroutine is called and then tests are done and a Quit is used to drop out when a match is found. Often used for validation, something like this that returns a result in the zER variable:

V1 ; Validate ORGC
   S ORG=zORG D WC2^hZUTV I zER'="" Q
   I IPACC<9,'$D(^hIW(WAID)) S zER="No details set up for ward" Q
   D WARDON^hILO1 I LOCK S zER="Ward in use" Q

VQ2 Q

Apologies for the old-fashioned code! However, you can see each test can be quite complex and using lots of variables, but it is easy to understand as long as you expect the structure to work that way.

This is very similar to the "clean code" solution of making the whole thing into a function that returns a value:

ClassMethod Main(val1 As %String, val2 As %String) {  write ..MyOutput(val1,val2) }ClassMethod MyOutput(val1 As %String, val2 As %String) As %String {  if val1 = 1 return "case 1"  if val1 = 2, val2="*" return "case 2"  return "default match" }

Of course there are probably as many answers as there are Cache programmers!  :-)

Hi. The "clean code" people would recommend just one parameter max, and better would be none! But I think that's going a bit far, and agree that 3, or maybe 4, maximum should be aimed for to keep things easy to understand when reading, though there may be exceptions.

The array passing is a good idea to reduce the number for normal routines, but I think the ideal for classes is using objects. If you are truly embracing objects, and self-documenting code, then new classes are usually needed and what used to be parameters become the setting of properties, like this:

S table=##class(CMT.UI.Table).%New()
S table.TopLine=10,table.BottomLine=21
S table.HeaderFormat="Underline"
D table.DefineQuery("CMT.UI.PatchSite:MyList")
D table.AddColumn(3,,"BOLD")
...etc.

D table.Display()

It works well in some cases, but I have to admit that there is a tendency for the number of classes to get a bit silly if you take it to the extreme. Sometimes simple code is best.  :-)     / Mike

This may be slightly dodgy as it depends on assuming how the DTL will be compile, but I have used them to implement a loop around a set of standard DTL actions.

For one the source message had a stream with a document in it, and it needed to be chopped up into chunks, each one being put in a field in an HL7 v2 OBX segment. So an initial CODE action opens the loop with something like "Do {", gets the next chunk and quits if none. Then there are some normal ASSIGN actions setting up the new segment - easy to put in and appear in the DTL display. And finally there is a second CODE action to end the loop with "}".

It works, but only as long as InterSystems keep the compiled code for the assigns nice and simple.

A similar use was when dealing with xml documents. Again I needed a loop that enclosed normal ASSIGN actions, but this time for things like stepping backwards and deleting unwanted elements, or creating them from an array.

Also, I used a CODE action to work out if a DTL was running inside a business process, or just in the Studio for testing, so that some expected properties could be created to allow the test to run. Just for debugging.

Regards,

Mike

Hi Jenny,

The FOREACH has to iterate over something, but there is only one input field, so I don't think there is any other way than a CODE action in a DTL (at least on v2012). I could have done the whole loop in the one CODE, or called an outside function, but I preferred to use the GUI to set up the ASSIGN actions for me, to provide the extra validation and visual links in the DT Builder. I have used DTL whenever possible in other areas like in BPL to extract data from messages into temporary variables. Maybe not always the quickest or easiest way, but I think it makes the system more transparent.

For the loop the DT is actually called from a routing rule. The source is a simple message class with a few fields, and the target an HL7 v2 MDM_T02 message. I suppose if a full BP was involved then the loop could have been implemented in BPL in some way, but I think that would get complicated. Perhaps DTL needs a more general WHILE/UNTIL loop action added?

if you open the class in Studio, and view the "Inspector" pane, then pick "Property" from the first drop down and your property in the other (or double click it), then it shows a very long list of possible things you can add. It may even show all of them, I don't know. You can then click on the values to enter them, sometimes getting drop down lists of possible values.

I've often used the inspector as a way of finding out what might be available, and then searching any keywords in the Caché documentation to confirm how to use it.

Regards,

Mike

I may have misunderstood your requirement, but  you may not need a Business Rule at all. To pull data from the request into the context  I've actually used Transforms.

To get this to work, I created a new class that Extends (%SerialObject, %XML.Adaptor), and defined in it the properties that I need to store. I could then define a Transformation from the incoming message type to this new one, pulling everything I needed. In the BPL  I then added a property called "TempStore" of that type to the Context object in my BLP. To pull the data I added a Transform Activity with a Source of "request" and a Target of "context.TempStore" using the Transform.

Later Activity boxes could then use the fields with references like "context.TempStore.priorMRN" to do tests, etc. I've also used the same trick to update outgoing messages with data from the context (using Create = existing in the Transform).

I hope this is useful.

Regards,

Mike