EnsLib.EDI.XML.Document from Caché %Registered Class?

Question

Question

Jeffrey Drumm · Jan 8, 2018

I've inherited a business service that takes a large XML document with repeating elements, extracts them via %XML.Reader and chunks them into separate persistent objects for delivery to a EnsLib.MsgRouter.RoutingEngine-based routing rule. Unfortunately, the lack of GetValueAt() for the message's class leaves me without much in the way of complex decision-making options.

I've hacked together a rather inefficient mechanism for getting at what I need by using %XML.Adaptor's XMLExportToString() and EnsLib.EDI.XML.Document's ImportFromString() method to extract things like child node counts and such. This seems incredibly wasteful.

Is there a more streamlined way to "clone" a simple XML-Enabled %Persistent object as one of type EnsLib.EDI.XML.Document?

Thanks ...

Discussion (3)1

Log in or sign up to continue

Marc Mundt · Jan 11, 2018

It sounds like you might be able to avoid the problem of converting to XML and creating an EnsLib.EDI.XML.Document if you were able to access fields in your persistent message class from your routing rule logic?

If your persistent message class has discrete properties, you can still refer to these directly in a routing rule condition even without the VDoc style GetValueAt().

If your message object has references to repeating child objects and you need to get to a deeper level such as checking a property of the Nth child object you can do this by creating a custom function and passing it the Document object as a parameter.

0 0

score 0 · Answer 1 · 2018-01-11T14:20:47-05:00

Thanks, Marc, that's what I'm doing now, including the creation of some custom functions to get at things like child node counts that aren't normally accessible via EnsLib.MsgRouter.RoutingEngine. An efficient mechanism for conversion of a Cache object to class EnsLib.EDI.XML.Document would have given me access to all of that VDoc's methods with minimal coding, though.

score 0 · Answer 2 · 2018-01-12T09:36:32-05:00

Hi.

I'm not sure what your "persistent objects" contain, but if the repeating data is in the form of strings or streams then perhaps you could put them into a XPATH document object ( %XML.XPATH.Document) and use the evaluator in that? I support a system that has a message with a transient property to hold the document created, so it's only done once (per processing), and a method that builds that property if needed and then calls the EvaluateExpression method in that property for an expression supplied as a parameter. This is used in transformations to extract data to post into HL7 v2 messages, so the same calls should work in rules as well.

Of course the XPATH expressions may be no easier to define than your exporting and importing methods. I certainly struggled with them and in the end had to build lots of special inputs that added the huge long list of nested items that usually went at the front of each expression, resulting in calls like source.Pull("Baby","ep2:id/@extension") where "Baby" added a prefix of over 160 characters to find the baby section of the Mother's full document before tunneling down to the hospital number. If you already have a sub-section of the full document then you may not need as much.

Mike