Pass path from EnsLib.HL7.Service.FTPService to EnsLib.HL7.MsgRouter.RoutingEngine?

Primary tabs

Ensemble, HL7, FTP

I have a service named FTP_In that is of class EnsLib.HL7.Service.FTPService.   It picks up files from multiple subfolders and sends them to an EnsLib.HL7.MsgRouter.RoutingEngine.   What I want to do is somehow capture the subfolder as a variable for use in the routing rules.  Is this possible?

Let's say I have the following files and directory structure on my FTP Server

/incoming/green/apple.dat
/incoming/yellow/banana.dat

I want the Routing Rule to be able to send anything that came from the /green/ folder to one operation and from /yellow/ to another.

Replies

Hi Scott,

On initial investigation at least, it certainly seems like the property 'Source' on the message header, returns only the root folder path ie, "/incoming",  not the subdirectoryr path when you have used the Subdirectory Levels settings of the FTP adapter.

One option perhaps would be to see if there is some other information in the HL7 Message data (Source system ?  Source Facility ?) that could provide enough information for your business rule.

Another option would be to have multiple FTP_In business services, one for each sub-folder, although I realise this is inpracticle if the subfolder names aren't fixed, or, there could be many of them. 

Perhaps others in the community have a better approach (including subclasssing the product's Adapters perhaps) to exposing this detail.

Steve

I think using message header information is the obvious solution, but my reasons for doing this were slightly more complicated.  No need to elaborate though as I think I'll end up writing a custom function.

Thanks for the input.

User Dmitry Maslennikov has stated on this StackOverflow question that it does include the full path but when I looked in the viewer it was visually truncated.  I hadn't been able to verify in code yet.

I'll see if I can validate and if it's not there then use part of the message header.

Thanks Scott,

Our EnsLib.HL7.Service.FTPService uses the FilePath setting in the Source information which does not account for the sub directory searching option:

OnProcessInput() line:

Set tIOStream.Name=pFTPStream.Attributes("Filename")_$C(13,10)_"via FTP "_..Adapter.FTPServer_":"_..Adapter.FTPPort_" path '"_..Adapter.FilePath_"'"
 

But the adapter is passing the actual path where the file was retrieved from in pFTPStream.Attributes("FTPDir") . I will make the change in EnsLib.HL7.Service.FTPService to use  pFTPStream.Attributes("FTPDir") instead of ..Adapter.FilePath but I am afraid I cannot advise on which release this will be in.

To verify from terminal using  write  ##class(EnsLib.HL7.Message).%OpenId(<id>).Source

returns before the code change:

somefile.hl7
via FTP 192.168.224.100:2121 path '/hl7'

to

somefile.hl7
via FTP 192.168.224.100:2121 path '/hl7/1/yellow/'

Would this be sufficient for your needs or since you state the reasons are more complicated  a more elegant solution in the Ensemble service is needed.

Kind regards

James

 

If you think this is a valid request worth implementing I would think a dedicated property like .SourcePath that contains "/hl7/1/yellow" would be best to avoid as much string manipulation as possible.

I'd like to hear other opinions though.

And just to elaborate a little, what I was trying to do involved a lookup table.  Let's say I had an FTP adapter that picked up files from /ftpdir/ and 1 subfolder deep.  If I had

/ftpdir/green/
/ftpdir/red/

I could then have entries in the lookup table for "green" and "red" and (relatively) easily create a rule to do stuff based on the folder.  What I'm trying to do now is be able to block things.  So I have a lookup table named "BlockCustomer".  I could create the key value pair "green:1" and then use $PIECE on the proposed .SourcePath property to determine if it should be blocked.  

Although now that I think about it, I guess this could be done with the message header.  However if I have multiple facilities for a single customer the given field in the header may differ.  I'm not sure.