the error message seems to say that HL7 is not a property of context.

you would need to give a lot more detail about  CustomEDI.SQLSIUInRequest and its ImportFromString method for anyone to tell you what is going wrong. What data type does the ImportFromString return, and have you tested it in isolation?

I think the 'normal' way to do this, would be to leave the HL7 message as an object. You could use a business process that extracts only the fields that are needed to retrieve the patient ID and send that to the SQL database. But i suspect you already have external logic that processes a whole serialized HL7 message.

The meaning is documented 

http://docs.intersystems.com/latest/csp/docbook/DocBook.UI.Page.cls?KEY=...

including information about when the alerts are sent and how often the sensors are sampled.

Changing he values is documented:

http://docs.intersystems.com/latest/csp/docbook/DocBook.UI.Page.cls?KEY=...

you have to navigate the options in 

do ^%SYSMONMGR

to edit the sensors. You have to then provide CPUusage (case sensitive) as the sensor you want to edit.

John

the only place i can think of it being used in the pull down menu for selecting a target in a send. It only offers you configuration items that exist in the production you choose. If you haven't specified a production it lists everything it can find and gives you a big red warning.

There is nothing to stop you typing in a target that isn't on the list

dave

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.

go to system configuration -> memory and start up and there is pull down menu at the bottom of the page to set the system mode.

It isn't as large as some people would like, but it shows red or green for live and dev.

if you find the local documentation hard to search for this kind of simple question don't forget the documentation is on line and google accessible. Entering 

site:docs.intersystems.com version

into google so you only search the intersystems documentation gives you a good set of hits.

For the second question - if you are on a test/development system and you are happy to remove all information about the status and queued messages you can use:

do ##class(Ens.Director).CleanProduction()

but it will destroy information so it must never be used on a real system.

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 don't think your code is wrong per se, but you are using a variable tSC that is used elsewhere as a status value.

If you skip the assignment to tSC and put it straight into Target.text you will probably be ok.

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

strictly speaking Ensemble is a separate product. DeepSee is the BI technology that is included in both Cache and Ensemble. Some functionality of DeepSee needs extra license options.

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")
     }

Laura

your sample file is a an interchange (look for the ISA and IEA segments) that include one group (see the GS and GE segments) that in turn contains one 835 message (look for the ST and SE segments).

An interchange can contain multiple groups which typically contain many individual transactions.

You should just copy the ST and SE segments and all in between and use that to test your 835 transformation.

You can then create transformations on the interchange and the group and loop through all the individual transactions calling your DTL as subtransformations. I think this is documented but it has got easier in the last few years so hopefully you are on a modern release.

Alternatively, because people want the same simple changes to the interchange and group segments for all X12 transactions people often just write than bit in object script.

Ask again if you don't find the documetnation

dave

With 2015.1 and later you have the option to increase the rule logging. This will tell you exactly what is going on when executing a routing rule. 

There is a setting in the Development & Debugging section of the configuration settings of a routing engine. That is described as ...

This set of flags controls the logging performed by the rule engine whenever a routing rule is executed. The following flags are available:

• 'e' - log errors only. All errors will be logged irrespective of other flags, so setting the value to 'e' or leaving the value empty will only log errors.
• 'r' - log return values. This is the default value for the setting, and is also automatic whenever the 'd' or 'c' flags are specified.
• 'd' - log user-defined debug actions in the rule. This will also include 'r'.
• 'c' - log details of the conditions that are evaluated in the rule. This will also include 'r'.
• 'a' - log all available information. This is equivalent to 'rcd'.

Dave

As Liz says this feature has been in Ensemble for about ten years. One very obvious use case in development is to have a file based BO as a duplicate of a TCP BO so you can cut out all the complexity of testing with a real target system.

To add a duplicate you just add another config item to your production with the same name.

Whichever one is selected from the pull down will start up with the production.

To remove a duplicate you select the one you want to delete from the pull down and delete the config item from the production. The other one will be left behind. Or you could edit the XML to remove it.