All
Accepted answers
Jeffrey Drumm · Jul 21, 2017 go to post

Evgeny, I received a registration confirmation on Wednesday; do I need to re-register?

Jeffrey Drumm · Jul 17, 2017 go to post

There aren't any "userland" settings in the HL7 service configuration that will allow a carriage return to be treated as both a segment delimiter and, well, not a segment delimiter. They're mutually exclusive.

This situation is one of the reasons why InterSystems supports custom services ...

Jeffrey Drumm · Jul 17, 2017 go to post

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 go to post

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 go to post

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 go to post

A bit counter-intuitive, but GetValueAt() works for this, using the same segment path identifiers that you use in DTL:

HICG > set msg=##class(EnsLib.HL7.Message).ImportFromFile("C:\interface\ensemble\LabResult.hl7")

HICG > set msg.DocType = "2.3.1:ORU_R01"

HICG > w msg.GetValueAt("PIDgrpgrp(1).ORCgrp(1).OBXgrp(*)")

191

Jeffrey Drumm · Jul 14, 2017 go to post

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 go to post

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 go to post

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.

Jeffrey Drumm · Jun 29, 2017 go to post

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.

Jeffrey Drumm · Jun 29, 2017 go to post

Hmm. Interesting. I created the exact same rule as your original in my local testing environment and it worked as expected. I was not using the testing service, however. I'm running HS 2017.1 if it matters.

Jeffrey Drumm · Jun 29, 2017 go to post

Stuart, have you verified that the merge message parses correctly? Check the contents of the message in the message viewer and verify that the MRG segment isn't displayed in black text. If the segment doesn't parse against the schema and doctype specified in the inbound service, the HL7.{} field selectors referencing it won't work.

Jeffrey Drumm · Jun 28, 2017 go to post

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.

Jeffrey Drumm · Jun 28, 2017 go to post

Have you looked into centralized administration via LDAP/Active Directory? This might not be practical if the servers are not accessible through the same network infrastructure, but it could be a significant time saver in the long run.

Jeffrey Drumm · Jun 26, 2017 go to post

Yes, that's the link I posted in response to Evgeny's request. Looks like we just missed each other laugh

Jeffrey Drumm · Jun 26, 2017 go to post

Yes, that's the link I posted to Evgeny's response (which I appear to have posted just as you were writing your reply).

Jeffrey Drumm · Jun 23, 2017 go to post

Thank you, Joyce. Looking forward to seeing what's working!

FYI, updating to Oxygen seems to have fixed one issue I had intended to report (the debugger would drive my standalone Apache server's memory and CPU utilization through the roof).

Jeffrey Drumm · Jun 22, 2017 go to post

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 :)

Jeffrey Drumm · Jun 20, 2017 go to post

I've backed out all of the changes that I would have suspected might have an impact, and it's still working (and yes, I've restarted both Apache and Caché). The only thing I haven't yet backed out was the creation of a non-SSL site  on port 8881, but that's something I did early on and am fairly certain I tried an Atelier connection after. But I may be misremembering ...

Jeffrey Drumm · Jun 20, 2017 go to post

So, I got it working.

It took a long time, because I missed one very important detail: the trailing backslash on the URL is very, very important. I was testing in my browser with http://oobuntoo.local:8881/api/atelier, which isn't exactly what Bernd and Dmitry told me to do. Since that wasn't working, I wasn't bothering to test Atelier's ability to connect. So somewhere in my flailing around I managed to fix whatever was preventing it from working, and now I need to backtrack through that and figure out what it was.

So ... thanks everyone. I'll mark the right answer as correct as soon as I figure out which one it was!

Jeffrey Drumm · Jun 20, 2017 go to post

I've removed the CSPFileType directive and am getting the same result ... "Not Found."

EDIT: And, of course, restarted Apache :)

Jeffrey Drumm · Jun 20, 2017 go to post

I had only one entry in CSP.ini, for LOCAL. The server name was configured appropriately, and the '/' app path was routed to it. I don't have an explicit path to '/api' but there wasn't one in the "private" web server's CSP.ini either and that works fine for Atelier.