So, assuming you've defined the context variables on the Context tab of the BPL, they're visible/accessible as objects with DTL called from the BPL, just like variables you define within the DTL. You can treat them just like any other variable of the defined Type:

Given the example from the screenshot, you can reference cvisCurrMessage as context.cvisCurrMessage within the DTL and use any methods or properties associated with its class. context.cvisCurrMessage.GetValueAt("MSH:10"), for example, returns the value of the MSH:10 field of the HL7 message referenced by context.cvisCurrMessage.

The one thing you have to be very careful about is synchronous vs. asynchronous calls to operations. You can't be guaranteed that the response object will be populated in a timely fashion when invoking the operation asynchronously, and sometimes even synchronously if you're using the BPL <call> object. You'll want to invoke the operation via the process.SendRequestSync() method in a <code> object to keep things sequenced properly.

Does that help? (if yes, please mark this response as your answer :D)

Hi Scott,

What metadata are you referring to? Document properties such as Title, Author, Subject, Keywords, etc. or are you looking to actually extract patient data from formatted page elements?

It doesn't look like HealthShare has any built-in PDF parsing features, but there may be something developed by the community (if there is, I'm not aware of it, though). If it's the properties I mentioned above, though, they're normally stored near the end of the file and it's conceivable that you could scrape them out with COS. To do it right, though, I think you'd want to call an external utility to fetch it. The pdfinfo utility in xpdf does that pretty efficiently:

jdrumm@oobuntoo:/mnt/hgfs/DDownloads/Intersystems$ pdfinfo Sample.pdf 
Title:          Sample
Subject:        Just another pdf
Keywords:       test metadata cache fetching
Author:         Jeff Drumm
Creator:        PDFCreator Version 1.7.3
Producer:       GPL Ghostscript 9.10
CreationDate:   Wed Aug  2 07:32:38 2017

If you're looking to get data stored as formatted page elements, though, that's an entirely different challenge.

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?

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.

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:

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 ...

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.

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.

The XML document checks out syntax-wise, and the CDATA blocks containing the individual deployment objects check out as well. I think you've encountered a bug ... might be time to get the WRC involved.

If LDAP/AD isn't an option, you should look at the class documentation for Security.Users and Security.Roles in the %SYS namespace. They both have import and export methods that should get  you well on  your way.

You can limit the user export to specific roles, allowing you to synchronize non-administrative users without impacting the administrative ones. Assuming you've created a role named %Users that contains only those accounts that need to be updated across all servers:

%SYS > Set sc = ##class(Security.Users).Export("C:\InterSystems\UserExport.xml",.outcnt,"*","%Users")

This would create the file C:\InterSystems\UserExport.xml, containing the users in role %Users, with a count of the number exported in the variable outcnt. The variable sc is of type %Status and should be 1 if everything went ok.

Those users can then be imported on other hosts using the corresponding import method:

%SYS > Set sc = ##class(Security.Users).Import("C:\PathToImport\UserExport.xml",.incnt)

The number of users imported will be found in variable incnt. Again, sc should be 1 if the method completed successfully.

You could create a custom operation based on EnsLib.HL7.Operation.FileOperation, modifying (or replacing) the value of pFilename used in the outputDocument() method. You can get the specific field value you want to include in the filename with pDcocument.GetValueAt("<some_field_identifier>").

In your specific case, it could be as simple as inserting the following as the first line of the outputDocument() method:

    Set pFilename = pDocument.GetValueAt("MSH:4")_pFilename

Of course, you might want to take the precaution of making sure MSH:4 is actually populated before updating pFilename, and have it do something useful if it's not :)

Steve, when I worked with the WRC to configure this (back in 2015), I got significant pushback on attempting to use the "private" server. I'm not sure what will happen with an in-place upgrade, either.

That may have changed since then. Regardless, installing the CSP gateway on an external, standalone web server is a solution supported by ISC, so please take that into consideration as you plan your implementation of SSL.

Brendan,

Are you fixing the documentation to remove the reference to scp, or fixing %Net.SSH.Session to support it? From the way your answer is worded, I'm suspecting the former ...

sftp and scp are individually configurable services in ssh, and in my experience you can't be guaranteed that one or the other is available at a given customer site. If scp currently isn't supported, it would be useful to have. Getting sysadmins to turn on services that are purposely disabled can be  ... challenging :)

My guess is that  your transformation is attempting to set a field value in the request (source) message, or you're using  the SetValueAt() method against it somewhere. You can't modify the request, but you can clone it (%ConstructClone() method)  and modify the clone.