Before answering the specific questions, i will explain what business rules are for. (Routing rules are another story). Rules were invented to allow people who were not programmers to change code dynamically on a running system. That put a lot of constraints around them. It is the responsibility of the developer of the BP that invokes a rule to make sure the analyst who dynamically changes the rules can't do any damage, no matter how stupid or how malevolent they are.

If you are a programmer and your code is going through normal dev/test/promote cycles then you should probably just write a method of a utility class to do the work.  You can't do anything in a rule that isn't easier to do in code if you are a programmer. I will repeat that routing rules are another story.

to answer your points

1. You would have to post your code for a real answer but a few guesses.

  a) you can put values into context properties with an assign  elements

  b) the value that you <return> goes in the Result Location specified in the rule activity of the BP. 

  c) make sure you <return> when you have finished and don't continue through following <when> elements.

2. yes. you just use mulitple <assign> elments

3. a) lookup tables are designed for the case where you want to translate a lot of values. For example if you have thousands of product codes and their descriptions, that might be fixed of maintained on a regular basis, then lookup tables are the way to go.

3 b) Data transformations are for when you have two structures that are similar but not quite the same. For example an invoice might be represented slightly differently in two applications  but they are close and you want to move fields around between the two formats. A second example would be to change the values in a data structure, perhaps by using lookup tables to translate from the codes used by the sending application to the codes used by the receiving application.

It is hard to say, but i think the error is 'Invalid Name' and the reference to locks is just in the text of the long line of code where the error occurs. 

the name it says is invalid appears in the text but it doesn't look like valid COS to me so i can't see how it would compile. i would look at the cached query %sqlcq.DHCdAPP.892.INT and see what code it contains.

I think the class name and the production name need to match so in Studio you use Tools->CopyClass to get a class with the meaningful name. And then edit the Production Name in the XData.

Class MyPackage.MyMeaningfulName Extends Ens.Production
{

XData ProductionDefinition
{
<Production Name="MyPackage.MyMeaningfulName" LogGeneralTraceEvents="false">
  <Description></Description>

I think the only property that can be used to create the filename is Source which contains the original file name. That is included by specifying %f in the output file.

You *could* steal that and put the value of MSH-4 in HL7.Source in some DTL in the routing engine.

Hijacking fields is never elegant and it can always bite you later when someone tries to use it for its original purpose, but ...

There was a nationwide project in the UK a number of years ago and i believe there have been several more but i don't know the details.

Having said that, it is a very wide ranging standard so there is no guarantee that the pieces you want are covered by that project.

Also, when i last looked at this several years ago, it was widely agreed that the standard was dead, having slowly collapsed under its own weight (although some elements live on in other standards).

I don't know if ebXML has been revived in recent years, but I doubt it. Why are you interested in it?

I think that validating data types across the board in Ensemble is only useful in a few specialist situations, such as building an HL7 clearing house. It is expensive and often gets in the way of what you really want to achieve.

What downstream applications will successfully handle in messages is often very different to the published standard and most people will focus on validating particular fields that are important to their environment rather than adherence to the standard.

In the case of TN the early HL7 schemas defined it as a string, but added no structure or length restrictions so it added no value other than documenting for applications that this field was expected to be a phone number. It seems to have gone from HL7 2.5 and later.

Dave

Yes, credentials are defined in each namespace. It would be possible to map the relevant globals to a single shared database but that would add a piece of complexity that is more likely to hurt than help.

My **guesses** are that either your email server is not set up securely in your test environment and is accepting input anyway, or that you have some OS level authentication going on, or most likely you have configured an SSL configuration to use to connect to the email server and the username/password or certificate are part of that.

there is a thread about class queries that gives a full explanation but in this specific case you could do ...

 

   set statement=##class(%SQL.Statement).%New()
    set status=statement.%PrepareClassQuery("%SYS.GlobalQuery","Size")
   set resultset=statement.%Execute("c:\intersystems\ens20163a\mgr\ensemble","","*")
    while resultset.%Next() {
        write !, resultset.%Get("Name"),", "                                       
        write resultset.%Get("Allocated MB"),", "    
        write resultset.%Get("Used MB")
     }

In Ensemble or HealthShare there is a class for the HL7 segments but it is not a persistent class so it is not exposed to SQL. The segments are stored in raw globals for speed and the virtual document paths are  parsed at run time for efficiency. 

You can use the message browser to look for messages where a particular segment/field value has a given value. But if you look at the generated SQL it doesn't seem to make sense. That is because the SQL query is used in a cursor and the access to segment values is done in COS inside the cursor iteration.

If you can be more specific about what you are trying to do i might be able to give you some pointers about how to get where you want to go.

you have to be on 2015.1 to have a pure DTL transform of an X12 interchange.

On 2014.1 you will have to use object script to loop over the child documents of the interchange to get the groups and then loop over the child documents of the groups to get the  actual documents. I can't find an example right now, but hopefully another reader can point you to one.