New post
AllAccepted answers
Daniel Kutac · Jul 19, 2016

Well, whilst it is true that we have much better ways of handling JSON today, this article mentions is by pure coincidence, driven by the fact that I had that problem some 3 years ago and when searching for solution, I found write redirection code withing the class mentioned in the article.

BTW: there is a %Device class available, that wraps redirection code, so no need to write your own mac code anymore.

Daniel Kutac · Jun 27, 2016

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.

Daniel Kutac · Jun 21, 2016

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

Daniel Kutac · Jun 21, 2016

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.

Daniel Kutac · Jun 13, 2016

Thank you Markus for hint,

I have modified the code to read this way:

#dim vDoc as EnsLib.EDI.XML.Document=##class(EnsLib.EDI.XML.Document).ImportFromString("<Body><Topic>Temperature</Topic><Value>30</Value></Body>",.sc)
s vDoc.DocType="message:Body"
s vDoc.DocTypeCategory="message"
w !,vDoc.GetValueAt("/Body/Value")
w !,vDoc.GetValueAt("Value",,.sc)
if $$$ISERR(sc) d $System.Status.DisplayError(sc)

 

but it throws :

ERROR <Ens>ErrGeneral: Can't evaluate DOM path '/Body/$2:Value' because xsd_2:Topic in /Body/xsd_2:Value is not an element, instead this node is a 'unknown' node.

 

this drives me mad...

BTW: you're still using DOM way and not property path way of retrieving data.