We use Epicor IDC for scan/capture and documents are exported to a folder.
The ECM Client imports the documents and they are deleted from the folder upon completion.
Our ECM application server had a failure and the ECM System log shows “Completion failed”. This was not noticed for several hours when users told us their documents were missing.
Can we set up a notification somewhere for when these failures occur?
I am not aware of any way to get alerted automatically if the import fails.
If you are talking about the ECM Client’s Log Viewer tab, the Client and Automation tabs are actually logged to the local Windows Event Log - it might be possible to trigger something at the Windows level, perhaps using some sort of third party tool to monitor the event logs.
I’ve not tried it, but you can also associate a script to an event entry being logged inside the Windows Event Viewer. So your event might be the EclipseAutomationService() event and you could hook a PowerShell script to that wills end you an email.
We had a similar issue. This is definitely one of the numerous Potential Points of Failure in our typical IDC to ECM flow. Ultimately, my Windows server administrator just set up some sort of e-mail alert on the Windows side (not via any Epicor app or functionality) when a file older than 30 minutes exists in the Windows server folder where IDC places document files . . . in our case, 1 PDF and 1 XML file per IDC document, for transfer to ECM.
In a recent issue, we had a real-time anti-virus (AV) scanner on that Windows server that was slowing the transfer of PDFs (but not the corresponding XML files). The EclipseAutomationService tries to rename the PDF and XML files at the start of transferring to ECM; I believe it changes the extension of the PDF and XML files to .lock or .locked. For some reason, this real-time AV app was allowing the EclipseAutomationService to change the file extension on the XML quickly, but it was delaying the file extension change on the PDF. The result: The EclipseAutomationService transferred the XML file, but not the PDF. Thus, the document never got transferred to ECM. And there’s no sane notification (i.e. an e-mail notification) that the transferred failed. Maybe the issue (XML received without matching PDF) is buried in the logs of the EclipseAutomationService, but that’s not useful to DETECT a problem.
Therefore, we had to rely on the IDC user notifying IT that a document never made it into ECM. Not ideal for enterprise automation.
In my opinion, other Potential Points of Failure in a typical IDC-to-ECM process:
If the IDC E-mail Client app attempts to create an IDC Batch with an unusually long Batch Name, the app simply drops the e-mail and does not batch any of the PDF attachments. We see this, because our Batch Name syntax uses the Subject, as well as the Sender, of the e-mail. Some of the e-mails have a Subject longer than 250 or 260 characters (including spaces). IDC does not alert anyone that it dropped (skipped) such an e-mail. The e-mail is not moved to any Inbox.Errors folder when this issue occurs. But the error is logged deep within an IDC e-mail client log on the server.
If the IDC E-mail Client app attempts to create an IDC Batch with an unacceptable Special Character, the app simply drops the e-mail and does not batch any of the PDF attachments. Same lack of notification was with the Batch Names that are too long. The e-mail is not moved to any Inbox.Errors folder when this issue occurs. In one example, we had a recurring issue where the e-mail had a dash with unacceptable encoding. If you looked at the e-mail, you’d never suspect that it was an unacceptable Special Character. An expert from ancora actually got involved. I apologize, but I didn’t document the exact problematic dash character nor its encoding.
If the IDC E-mail Client attempts to create an IDC Batch with a corrupt PDF file, the app simply drops the PDF and does not alert anyone. A few months ago, a customer repeatedly sent e-mails where a PDF attachment was corrupt. If a person tried to open that corrupt PDF attachment, Adobe Acrobat would pop up an error that the file was corrupt. The problem for us: That customer would typically send e-mails with multiple PDFs, i.e. 5 PDF attachments, and only 1 might be corrupt. So the IDC batch would get created, but only with the 4 good PDFs. No e-mail alert or sane, user-friendly notification that this batch was missing a PDF, because it was corrupt.
Thanks for the replies.
I will check the server side.
Good stuff @JerseyEric - Thanks for the write-up. I’ll forward this off to the guys at Ancora that I’ve had contact with so they have it to consider for future updates.