Question
· Feb 8, 2018

File Passthrough when using a Router getting ERROR #5005

Hello

I am writing a simple routing interface that picks up files from a share using File.InboundAdapter.

I am then using PassthroughService and passing it to a router.

The Router is using Ens.StreamContainer to then get the filename.  I have then used contains to pick out part of the filename.

and then pass it to another simple passthrough operation to another share.

 

If I do a direct link without using the router it works fine and I get no errors, once I direct the messages through the router I am getting ERROR #5005  Cannot open file, it does however write a file to the share but the file is a corrupt pdf I cannot open.

Is there something I have missed or a reason I can't do this? 

Thanks

Lorraine

Discussion (10)3
Log in or sign up to continue

I am receiving the error on the Operation.

I literally just want to sort by filename so for example I will get files with different ward names in so I want to route them relating to this.

If I remove the router so its a direct service to operation for all files it works.  its only when I add in this router that I get the error on the operation.

 

Thanks

Lorraine

Hi Lorraine,

A few questions to help us get a clearer picture:

  • Which component is generating the 5005 error? Is it the router or the business operation?
  • Can you post a screenshot or the source code for your routing rule?
  • Is your router calling a transformation or just passing the file through unchanged?
  • What happens if you remove all logic from your router and just change it to do a simple "send" with no transformation?

-Marc

Hi Lorraine.

I think the issue is that the Constraint is not set for the condition to be able to reference the filename. I see that you have added a comment to another post which explains how to do this, but it stops short in explaining fully. Fortunately, Joshua Goldman then links to another post where he goes in to more detail.

I'll copy and paste it here, and include the link.

https://community.intersystems.com/post/how-route-file-based-file-type

  1.  Define a business rule. Make it a General Message Routing Rule and have the assist class be EnsLib.MsgRouter.RuleAssist.
  2. Add a rule to the rule set and double-click Constraint. Specify the rule class Persistent > ENS > StreamContainer
    That's the message class used by the pass-through file service/operation. You can also specify the business service as the source.
  3. Double-click  condition, and in the expression editor specify Document.Type or Document.OriginalFilename, add an operation, and a  value.
  4. Send it to the correct operation.
  5. Define a router business process and specify the rule you just created.
  6. Connect the pass-through file service to the router.

For future readers; I ran into this problem as well, and even setting up my rule carefully exactly as indicated, and with the constraint: msgClass=Ens.StreamContainer, it did not work.  I continued to get Error#5005 Cannot open file.

I found that it was the Operation that was not able to open the file in the Service's File Path.  

I ensured the file service sent the file synchronously to the routing rule by keeping the Archive and Work paths blank.

The final step necessary was to set the Force Sync Send on the RouteRXPFile RULE, to force the rule to send synchronously as well.  That allowed the Operation time to read the file before it was deleted, and send the file on to some other service on a different server / path.

I ran into this problem as well, and I vaguely recalled that the passthrough file service has issues with multiple targets. So I went to the documentation and tried to find any reference to the need to ensure the operations were called synchronously and (initially) couldn't. So I went ahead and configured the services with Work and Archive directories and waited for something bad to happen.

And of course, something bad did happen.

I later found the file adapter documentation that provides a clear description of how the Work and Archive directories impact synchronous delivery. It seems to indicate that the Work directory is more likely to break sync than the Archive directory, and that you can have an Archive directory configured while still supporting sync as long as the Work directory is not configured.