Question
Murillo Braga · Jun 21, 2016

Business rule doubt

Hello guys,

I've built a simple rule , as follows:

Thing is, in rule 2, the operation succeeds, the message reachs BO HL7, but in rule 1 it does not go through. In rule 1, I have two different conditions, but they are linked by an OR and one of the conditions is simply IF 1=1.

Do you guys have any clue on why rule 1 does not reach BO HL7?

Thanks

10
2 0 17 642
Log in or sign up to continue

Actually if I add a rule with IF 1=1 OR IF 1=2, it goes through, but if I add a constraint on it, it won't work anymore

I'm grabbing a HL7 file from a folder. There is the message:

MSH|^~\&|7edit||7edit||20160613154817||ADT^A01|MSG-20160613-154817-0669|P|2.2
EVN|A01|20160613154837^20160613154844
PID|5544||987||Braga^Murillo
PV1|9877|C

Murillo,

I'd open the rule definition in Studio, use View Other untill you see generated MAC code. That would give you direct clue what is evaluated and when/why.

Dan

Hello Daniel,

Thanks for you help , but it doesn't help me much. As I said, if I place a very basic rule there with (if 1=1 OR 1=2), it works fine, but as soon as I just place a constraint on the rule (which source is a hl7 file being sent by my business service 'Service for input file'), it blocks the message from being forwarded.

Here is the rule:

<ruleSet name="Rule set name =)" effectiveBegin="" effectiveEnd="">
<rule name="" disabled="false">
<constraint name="source" value="Service for input file"></constraint>
<constraint name="docCategory" value="2.2"></constraint>
<constraint name="docName" value="ADT_A01"></constraint>
<when condition="(1=2)||(1=1)">
<send transform="" target="BO HL7"></send>
</when>
</rule>

Maybe modify the simplified rule you showed above, so it includes only the first of the 3 constraints. Then repeat with only the second. Then with only the third. Does this pinpoint only one constraint failing? Or do all three fail independently?

What Ensemble version are you using?

Hello mate,

Thanks for the response. Actually I'm using Healthshare, sorry for the wrong information. I'm quite new on that.

The idea about testing each of them individually does not work. It seems that any constraint that I add there, it blocks the operations below it. If I remove the constraint, it goes through well.

Again, as I've said in my first comment, the rule that I have which has no constraints, works pretty fine.

But the thing is I need to add this constraint in order to assess a few data from the HL7 ADT A01 message and that is the only way to do it, right?

Healthshare version: 2015.2 1HS. 7913.0

My point was that if you can see at the INT (I was originally pointing to MAC) level, what actual ObjectScript code the rule (XML) generates, it would be easier to understand what's going on. You need to call View Other once more, from XML view, to get to the INT level.

 

it would also help, if you put TRACE element and evaluate the two message  properties there to see what Ensemble thinks of them.

Sorry for the wrong information, mate. I'm quite new on this and I'm using Healthshare (v. 2015.2 1HS. 7913.0).

Can you tell me how to get to this INT level? Can you kindly provide a printscreen?

Thank you!

sure, supposed you have a class opened with the rule definition (the XML data you showed earlier) you just click a tiny icon with a little search glass in it. Or you can press Ctrl+Shift+V at the same time. This would bring the ObjectScript layer of the rule.

But my feeling is that condition is simply never called due to the constraint in the rule 1. the constraint is evaluated first before it let's you go and evaluate condition within rule.

You can also change level of tracing information produced by the rule, just makes sure that you production has "Log General Trace Events" turned on, then the Business process that uses the rule has "Log Trace Events: on and Rule logging set to "a" for collecting ALL details. This could also help in determining what is rule evaluating.

Dan

 

My team leader advised me to do one thing that did the trick: stop the production, save the business rule and then restart the production and resend the message again.

He said it sounds like it's something related to memory management done by the Ensemble, because for safety reasons/keep the messages flowing correctly, it keeps some previous compiled version in memory until a certain point and then brings new one as soon as it realizes that either it's the right time to do it or I've ordered it to do so. I might be saying bullshit, but as I've said, I'm just a begginer in this environment.

Thanks mates!

Or provided you can read and understand ObjectScript you could set up our Serenji debugger and then replay a message, stepping through the INT code.

My team leader advised me to do one thing that did the trick: stop the production, save the business rule and then restart the production and resend the message again.

He said it sounds like it's something related to memory management done by the Ensemble, because for safety reasons/keep the messages flowing correctly, it keeps some previous compiled version in memory until a certain point and then brings new one as soon as it realizes that either it's the right time to do it or I've ordered it to do so. I might be saying bullshit, but as I've said, I'm just a begginer in this environment.

Thanks mates!

Glad you sorted this out Murillo. However, one of great features of rules is that one can change them on the fly and as soon as they are compiled, the new version becomes active, without need to stop component/production. It would be difficult to find out now, why you needed to stop production. Perhaps Ensemble system developers can comments. On the other hand, it is true that you need (since 2010 or so) to stop/start production components (services, operations) when they are modified and compiled.

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

My team leader advised me to do one thing that did the trick: stop the production, save the business rule and then restart the production and resend the message again.

He said it sounds like it's something related to memory management done by the Ensemble, because for safety reasons/keep the messages flowing correctly, it keeps some previous compiled version in memory until a certain point and then brings new one as soon as it realizes that either it's the right time to do it or I've ordered it to do so. I might be saying bullshit, but as I've said, I'm just a begginer in this environment.

Thanks mates!

You mentioned that when you add a constraint, that's when the rule stops working.

Check to make sure the data in your message matches your constraints:

In the message body properties, DocTypeCategory should match the rule constraint's docCategory.  If they don't match, look at the settings for the business service sending messages to the router and make sure the "Message Schema Category" setting is set correctly.

Also make sure the message body's DocTypeName matches the rule constraint's docName.

Also make sure the message header's SourceConfigName matches the rule constraint's source.

As a side note, when the business service generates the HL7 message object, if the Message Schema Category setting is correct, the service will pull the document type out of MSH:messagetype and store it in DocTypeName for the constraints, so your condition checking MSH:messagetype should be unnecessary.   It's checking the same thing as the constraint.

My team leader advised me to do one thing that did the trick: stop the production, save the business rule and then restart the production and resend the message again.

He said it sounds like it's something related to memory management done by the Ensemble, because for safety reasons/keep the messages flowing correctly, it keeps some previous compiled version in memory until a certain point and then brings new one as soon as it realizes that either it's the right time to do it or I've ordered it to do so. I might be saying bullshit, but as I've said, I'm just a begginer in this environment.

Thanks mates!

I suspect the Message Schema Category setting specified in your Business Service is NOT specifying category 2.2. This setting overrides whatever version number is in MSH:12 (since the MSH value is notoriously unreliable). You may be specifying another version or a custom schema.  When the message hits your rule, the docCategory constraint value is compared to what the Business Service assigned, not MSH:12. 

Look at a message that failed in the Message Viewer Body tab, to see the MessageTypeCategory value (which is compared to docCategory) and Name value (which is compared to docName). One of them does not match, otherwise the message would be sent.

The WHEN conditional expression in Rule 1 does absolutely nothing. The pair of AND conditions duplicates the docName filter in the Constraint so also has no effect. And therefore adding  OR 1=1 further has no effect. So the Constraint has to be your problem.

If you added the same constraints to Rule 2, it would also break, since your problem is with the constraints.