Best Practice for mapping network drives

We have a BPM that needs to go out and get data from a network drive.

At the moment it is working simply by using the UNC path to the file in question. However, it seems like this depends on the credentials being properly supplied, which they currently have been via a remote desktop connection to the server. At some point I suspect that the credentials are going to be forgotten, either due to some timeout, or the desktop user logging out, or the server rebooting.

In E9 ABL we had a “DOS” command which called “NET USE” to supply the proper credentials. In C# I see that there are various ways which can be used to map a network drive, from shelling out to call Net Use to using libraries in .NET itself. What I don’t know is which of these will actually work in the E10 environment, or which ones are even recommended.

How should I make sure a network drive is mapped in my BPM before I try to access it?

This was a losing battle for a hosted client. It may be easier to have a script copy the file locally.

I definitely would put that locally, Client Side.

Having a Server attempt to read a clients file is recipe for disaster. If you are reading data from a shared UNC Path, well as long as the IIS App Pool User has access to that Path it should be no problem. Just get your permissions straightened out. Its best if you run IIS (App Server) as a Service Account. Not sure why you need to map a drive. File.IO can read \yourserver\path\file.txt fine

3 Likes

Or just have the process creating the file upload it to a UD table and then have your BPM process it from there.

Ah, that’s the rub… we have code in our production process that has no knowledge of Epicor. It puts the data in a CSV file, and at some point somebody realized that code was needed in Epicor and wrote a BPM in ABL to go out and get it.

And what would stop you from writing a program that pushes that file into Epicor from there?

Other advantages with the file in a UD Table

  • Stays with backups
  • Can have a status filed that indicates it has been processed and when
  • Easier reprocessing of errant records
1 Like

Time, mostly. Nobody has touched the code in a long time, so we would need to identify where it is (it’s possible there may be multiple pieces for different product lines), and then somebody would have to go in and write new code that talks to Epicor.