Disabling Base Processing Method - DocStarDeleteFile

ECM
1

Hi all,

We’re having a strange issue with ECM/DocStar in a multi-company setup. I was wondering if anyone has seen something similar and if the workaround we’re using is an acceptable way of fixing it. Changes below were done in the test environment but we’re looking to implement in production if we can’t get to the root cause.

We have two companies on E10 (on prem) and both have identical DocStar settings.

For one of the companies, when we delete an E10 attachment, it does not delete the related record in DocStar. As I understand it, this is how DocStar is supposed to function. However, in the second company, when we delete an E10 attachment it also deletes the record in DocStar.

One of the proposed solutions in another ticket was to recycle the server app pool, but our systems admin has this set up on a daily schedule and the issue has persisted.

When looking at the trace log for both companies when deleting attachments from E10, it looks like the only difference is that one of the companies is calling the DocStarDeleteFile method and the other is not. We didn’t see any BPMs or customizations that could be causing this.

As a workaround, I modified the base processing of the DocStarDeleteFile method to do nothing (i.e. only the “Start” tile in BPM Workflow Designer) and it works as intended: the file is deleted from E10 but kept in DocStar. I ran trace logs before and after enabling the base processing directive and it appears that the only difference is the runtime of the DocStarDeleteFile method.

I’ve read that changing base processing methods is strongly discouraged, but is there any risk to disabling this method? Also, has anyone else seen this issue or know why it’s happening in the first place? We’re pretty stumped on the root cause at this point.

Thanks!

2

True story, this is the core (primary) logic for the call, which is 99.9% needed.

Looking at decomp, it says it does this
: /// Check if docStar file with the same name already exists in the XFileRef attachment table for this Epicor table record

1 Like
3

For the decomp, were you looking at the DocStarFileExistsForTableRow method or DocStarDeleteFile?

On my end I’m seeing your description under the DocStarFileExistsForTableRow method. But for DocStarDeleteFile, all I’m seeing is “Delete file to Recycle Bin”.

I’m ok with disabling the core logic for the DocStarDeleteFile method as long as it only prevents files from being deleted in DocStar and doesn’t affect anything else in E10. We’re good with users deleting files from E10, we just want to prevent that delete action from affecting DocStar.

Do you know if DocStarDeleteFile affects any other BOs, or is it supposed to only affect the deletion of the file in DocStar?

4

You are absolutely correct, I misread that.

Ultimately it calls:

public void SoftDelete(Guid documentId)
		{
			string url = WebHelper.GetServerUrl(this._sci, "Document", "SoftDelete", false);
			string json = JsonConvert.SerializeObject(new Guid[] { documentId });
			((JObject)JsonConvert.DeserializeObject(WebHelper.ExecutePost(url, json, this._sci.Token, false))).CheckException();
		}

DocStarHelper.DeleteFile>DocStarHelper.SoftDelete

I see no other logic.

2 Likes
5

Thanks for the quick response!

With that said, would you say it’s fairly low risk to disable base processing for this method in production (without assuming culpability for any unforeseen issues)?

6

Key condition there haha. I guess since I am longer an official consultant, I can say it seems pretty low risk based on the code…HOWEVER

caveat - what happens if the code changes in future updates? I still think its manageable risk since if they are keeping separation of concerns, a method called DocStarDelete would literally only do that,

1 Like
7

Sounds good, I agree that future code changes are a manageable risk here.

Thank you for the feedback and help with this!