New post
AllAccepted answers
Jeffrey Drumm · Jul 27, 2017

The problem is that your syntax doesn't really describe  a property; it's shorthand that works in the routing rule and DTL editors.

Try, instead, set context.X = request.GetValueAt("MSH:9.2").

EDIT: Looking at the log you included, it appears as though you are using the correct syntax at some point. Is context.X defined as a %String in the BPL context variable definitions?

Jeffrey Drumm · Jul 17, 2017

It's not a character set problem, it's a malformed HL7 problem. If the vendor sending the message needs to include a carriage return character in the middle of a segment, they should be escaping it. 

If the vendor won't fix it, you're probably looking at overriding the inbound service's OnProcessInput() method to strip out \0x0D\0x0A sequences and replace them with something else. If they're in there for textual formatting purposes, you'll need to know what the target system expects for a line-break character sequence.

Jeffrey Drumm · Jul 17, 2017

Are you sure you're looking at the right task? I/O logs would normally be purged using Ens.Util.Tasks.Purge, which is also used to purge messages, alerts, and other production logging. Here's a task I created specifically for demonstration purposes. You won't find this in your scheduled task list by default. You may have another, similar task that someone may have set up in your environment, though:

 

Jeffrey Drumm · Jul 15, 2017

If you're working with messages coming in from an HL7 service, the doctype will likely already be set. I only set it in my example because I used the ImportFromFile() method, which does not automatically select a schema and DocType category.

The DocType essentially defines the message object's rules use for parsing the message, so without one, you won't really be able to do much with them.

You could do some basic parsing/counting with $PIECE and some loop constructs against the raw message, but that doesn't sound like a lot of fun ...

Jeffrey Drumm · Jul 14, 2017

It appears as though an expression won't work in the target field. Interestingly, though, this actually compiles for me on 2017.1:

It errors when the rule executes:

I've done dynamic routing in a BPL code bock using ObjectScript, though, and you could certainly write your own BP in Studio for it ... see the methods SendRequestSync()/SendRequestAsync() in Ens.Host, of which Ens.BusinessService/BusinessOperation/BusinessProcess are subclasses.

Jeffrey Drumm · Jul 3, 2017

Yes, and InterSystems provides quite a few examples for developing Business Services. A Service generally extends an existing class, since there's a lot of operational stuff that is common between services. A Service also has a Parameter that defines the Adapter class it uses, which provides the methods to communicate with other processes/applications/servers. You can browse the EnsLib package for something that comes close to fitting your needs, then create a new class that either extends it or replaces its functionality with something different.

Look at the COS (Caché ObjectScript) source for, say, EnsLib.HL7.Service.TCPService to get an idea of how it hangs together. And if you need a custom Adapter to support something that isn't built-in, you can look at the code for those as well (for example, EnsLib.HL7.Adapter.TCPInboundAdapter). This is obviously all done through Studio, and guides for developing using the pre-built adapters are included in the Caché/Ensemble documentation.

Now, if you're talking about an API for some development platform other than COS, that's a different beast.

Jeffrey Drumm · Jun 30, 2017

Are you looking for the Destination file path? That's a Property of the Adapter class. If you need to reference it from within one of the methods you've overridden or have created as a callback, you can  reference it as ..Adapter.FilePath.

If it's the Source file path you're looking for, the only place you'll find that is in pRequest.Source, and that will include not only the path but the filename as well.