When creating tempoprary files, say my Process logs in on a webpage and downloads a report as an Excel that later on is read into a DataTable for processing.
Today we have a fileshare where we have a folder that we use as a temporary folder, but that is rather unsafe since we sometimes download reports with sensitive information.
I figure it would be possible to store it somewhere on the orchestrator machine? Not many people have access to that machine.
Where do you store your temporary files?
If you don’t need the temporary file after reading it once, I would suggest to store it into Data/Temp folder of project and add logic to clean it up at the end state of the bot.
Hi @Oneleg
You can store in temp folder on the machine or the user-specific temp folder (e.g- Environment.GetEnvironmentVariable(“TEMP”)).
Check below for clean,
Happy Automation!
Dear @Oneleg
You can lock the folder on Windows11 to protect sensitive data.
So that any other user not able to open the folder.
Just remember that, robot should have required privilege to read the folder content.
Here is a video, which guides on locking folder.
Storing the files in a folder within the project is not a good idea. Depending upon where packages are stored on robot servers, multiple jobs could end up using the same folder.
We just use a network folder specific to each automation. Why is it unsafe? Aren’t you controlling who has access to your production automation folders? Aren’t you deleting the files when the job is done with them?
We have a filelocation today but it is a share used by multipple people in multiple roles, and security says we have to store our files somewhere else.
So I figure a folder on the orchestratormachine would be good. Each automationprocess needs to have their own temp-folder.
Is there a reason why it isn’t good to have temporary folders there?
You could create a share on the Orchestrator server, but that seems like extra work when you already have specific servers set up for network folder purposes. Can’t you just create a folder in the same place as your existing share and then lock it down so only certain people have access?
That is what we have today and our securitydepartment says we have to move the folder somewhere safer.
Lots and lots of people have access to the share it is located on today even if “our” folder is locked down it isn’t enough.
We are only four people who have access to the orchestratorserver.
Is there any drawbacks of have our temporary folder on that machine?
Hi @Oneleg
Use an Assign activity:
tempFolderPath = Path.Combine(Path.GetTempPath(), “UiPathTemp”, Guid.NewGuid().ToString())
Then use Create Directory to create it:
Path: tempFolderPath
When using “Save Attachment” or downloading via browser, set the destination path to:
Path.Combine(tempFolderPath, “report.xlsx”)
Use Excel Application Scope or Use Excel File activity:
File path: Path.Combine(tempFolderPath, “report.xlsx”
Use a Try-Catch-Finally:
In Finally, add a Delete Folder activity:
Path: tempFolderPath
Or use an Invoke Method:
Target Type: System.IO.Directory
Method Name: Delete
Parameters:
tempFolderPath (String)
True (Boolean - recursive)
You can try this method too if any error let me know
Nice pattern but we canb have one Performer which sole purpose is downloading reports to a temporary folder and another Performer which sole purpose is uploading reports to the customer they belong to. So I have to have a temporary folder that exists all the time.
Are there any drawbacks having this folder on the orchestrator machine?
Yes. Additional load on the Orchestrator server for things it wasn’t intended to do. Additional administrative overhead to manage the Orchestrator server as a network folder server. You already have infrastructure for network folders. Use that.
The temporary folder doesn’t have to exist all the time. Create it at the beginning of your process, use it to store files during your process, delete it (and the files) at the end of your process.
It should be. Your security team’s position makes no sense.
This topic was automatically closed 3 days after the last reply. New replies are no longer allowed.