I have never been into building electric circuits, but this Arduion toy really got me. Purchased one and now starting experimenting. Next phase - with Cache. Nice topic.

You can store both structured and unstructured data in Cache. Thus you can retrieve this data. For structured data you can use regular SQL, XML or Object approach and others (JSON etc...). For unstructured data we have iKnow technology that allows to search such data. Please visit our documentation pages andf filter product to Cache.


No prodlog opened yet, Timur. But it might be worthy asking at least to put the information about performance of the method into the class reference and documentation of file outbound adapter. I'll do that.


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.

I tried several variants, and it seems to me that "dummy numbers" were result of some data corruption in customer database as I could not reproduce it.

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.

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.



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.


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.


got it. I was missing xmlns declaration.


#dim vDoc as EnsLib.EDI.XML.Document=##class(EnsLib.EDI.XML.Document).ImportFromString("<Body xmlns=""""><Topic>Temperature</Topic><Value>30</Value></Body>",.sc)

works as expected.