System.IO

Kinetic ERP
,
21

Has anyone found a way to write to …EpicorData\Reports without using System.IO? I’m trying to work within the confines of the FileTransferService but so far have only been successful with writing to a user folder.

When I change the SpecialFolder from UserData to Report, I get an ‘UnauthorizedAccessException’ error. i.e. -

this.CallService<Ice.Contracts.FileTransferSvcContract>(hFileTransfer => {
hFileTransfer.UploadFile(Epicor.ServiceModel.Utilities.SpecialFolder.Report, fileName, fileBytes);

It’s going to be problematic for troubleshooting our shipping automation if the XML files created by my BAQ when a Pack is closed are spread among the user folders of all the different users that may mark a Pack closed. I need to find a solution that allows all these files to land in the same folder.

22

@danvoss I am just starting to evaluate alternatives for a similar capability we have that writes to \EpicorData on the Task Server. Have you found a reasonable replacement for System.IO?

23

I have not yet. For the moment, I’m ignoring the warnings and am continuing to use System.IO. Plan to talk to some of the Epicor folks at Insights to see if they have a suggestion.

24

For that folder, the answer is here:

2 Likes
25

You may want to seek out @Epic_Santiago

26

I’ll be at Insights. You can find me at the Tools booth (or whatever we’re calling it this year) most evenings when I’m not teaching Extended Education or Labs.

In the meantime, I’m happy to continue the conversation here.

I’ll start with a few notes…

  • The introduction of warnings should be in the release notes. If you can’t find them, let me know and I’ll hit up the docs team for clarification.
  • Using System.IO is not going away as a whole. Picking arbitrary paths, however is what we are limiting.
  • The current solution is to use FileTransfer as others have shown here.
  • We are looking at adding convenience methods to make using System.IO without arbitrary path access easier. This would happen no earlier than 2024.2.
1 Like
27

I thought Kinetic cloud hosting was moving to containers, wouldn’t that make the System.IO issue moot?

If not, one solution I would suggest would be to allow us to define datastores within a maintenance, and create a custom IO namespace with proxies to all the standard System.IO methods that take a datastore ID argument and a relative path. For on-premise it doesn’t limit what we can do, and for cloud you can just disable the datastore maintenance and make its tables inaccessible from BAQs, BPMs and Functions…

28

If a container is only allocated a certain amount of disk (20GB by default), I wonder if someone could accidentally fill up the virtual C: drive and that’s why they don’t want us writing to it? :thinking:

I would imagine that the EpicorData folder is mounted on some persistence storage service.

1 Like
29

2 posts were split to a new topic: Help with FileTransferSvc

30

Not to start a ####storm but they just added System.Reflection to the list.

I can’t say I’m happy at all. Feels like they’re slowly neutering the product.

I have quite a few advanced things that won’t work if they become errors.

5 Likes
31

If anyone is as unhappy with these changes as I am, please go vote:

Idea → Roll back Custom Code Restrictions that are no longer relevant with the move to AKS.

32

I can’t find any details about this in the release notes.

33

I see the conversation around System.IO is heating up again. We have some goodies coming out in 2024.2 that we’re not ready to announce yet. Stay tuned…

9 Likes
34

How about just some reassurance that everything we have isn’t about to break?

3 Likes
35

Would some xanax and a box of chocolates suffice? :laughing:

3 Likes
36

Not really, but we won’t care for a while.

Sounds good, when can I expect delivery?

37

Hey I thought he was going to send them to me

1 Like
38

39

Throw in a bottle of tequila :tumbler_glass:

40

Not tequila, but thanks anyway. I’m now singing…

2 Likes