Jump to content

ADD Processing Publishing and Resolving Errors Q&A


Krista Schmidt

Recommended Posts

  • Moderators

Q: When the Publish Errors button is clicked, what is happening? Which files are then published that were originally held back?

 

A: After the streaming discovery job is completed and the user has decided that no other exceptions can be resolved, they click on the Publish Errors button. Publish Errors will generate one final export job of all remaining error families which can be pushed to review. This would include the documents extracted from partially extracted containers, as well as document families which resulted in a Detect Container or Read Email Fields error.

 

Example:

  • A PST file is extracted that results in many emails, but contains a folder that was unable to be extracted. The PST would be identified as a node level error and all files extracted from the PST will be held back during initial processing. If a user is able to resolve the folder issue and re-queue the container successfully, then the results will be pushed to review automatically. If nothing is done to the container, when the user Publishes Errors, the successfully extracted documents and their families would be pushed to review.
  • An MSG file was discovered with two attachments but resulted in a ‘Read Email Fields’ exception and the whole family was held back. When the user Publishes Errors, the MSG and its family will be promoted to review.

Q: How can I resolve errors for containers or items which were not promoted to review?

 

A: Errors encountered during processing would generally be resolved outside of the ADD Processing engine. Once the issue has been resolved, the exception can be re-queued using the ‘Modify Streaming Discovery Job’ button to resubmit the file for potential additional extraction. Keep in mind, users will want to review and resolve the file at the discovery location, not necessarily the original source location. Review the error report to find the location of the file with the error.

 

Example:

  • A Password protected PST file is identified. If a password has been provided, a user could un-protect the PST file and re-queue the exception.
  • A PST file had issues extracting all content. The user could run a repair utility such as ScanPST on the PST. This may or may not repair the file and has the potential to change metadata for content, but it is utilized generally through approval from the end client. The container could then be re-queued.

Q: How can the eCapture QC application be used with my Streaming Discovery job?

 

A: Once a streaming discovery job has completed, it can be loaded in QC to review the results. Generally, it would be used to review exception flags. Users can then attempt to determine what might have caused the error and utilize the different reprocessing options such as forcing the document to use Stellent to process in order to attempt to get additional information from the file. If the documents were loaded directly to Eclipse, the results from a successfully reprocessed file in eCapture QC will automatically be updated in Eclipse, similar to the Enterprise Imaging function today. Successfully reprocessed files could result in additional metadata or text being loaded to Eclipse.

 

Q: When an item level exception document is sent to Eclipse using the Publish Errors option, what can we expect the document to look like in Eclipse?

 

A: Documents published to Eclipse will be flagged in the System QC Flags (Ipro Eclipse Template Field Name) field with ‘Streaming Discovery Errors Forced Through Export’. Documents in these families which did not have an issue will appear as normal. Documents which caused the family to be held back will also be flagged as an exception and will most likely only contain file system metadata depending on the error.

Link to comment
Share on other sites

  • Moderators

Q: When the Publish Errors button is clicked, what is happening? Which files are then published that were originally held back?

 

A: After the streaming discovery job is completed and the user has decided that no other exceptions can be resolved, they click on the Publish Errors button. Publish Errors will generate one final export job of all remaining error families which can be pushed to review. This would include the documents extracted from partially extracted containers, as well as document families which resulted in a Detect Container or Read Email Fields error.

 

Example:

  • A PST file is extracted that results in many emails, but contains a folder that was unable to be extracted. The PST would be identified as a node level error and all files extracted from the PST will be held back during initial processing. If a user is able to resolve the folder issue and re-queue the container successfully, then the results will be pushed to review automatically. If nothing is done to the container, when the user Publishes Errors, the successfully extracted documents and their families would be pushed to review.
  • An MSG file was discovered with two attachments but resulted in a ‘Read Email Fields’ exception and the whole family was held back. When the user Publishes Errors, the MSG and its family will be promoted to review.

Q: How can I resolve errors for containers or items which were not promoted to review?

 

A: Errors encountered during processing would generally be resolved outside of the ADD Processing engine. Once the issue has been resolved, the exception can be re-queued using the ‘Modify Streaming Discovery Job’ button to resubmit the file for potential additional extraction. Keep in mind, users will want to review and resolve the file at the discovery location, not necessarily the original source location. Review the error report to find the location of the file with the error.

 

Example:

  • A Password protected PST file is identified. If a password has been provided, a user could un-protect the PST file and re-queue the exception.
  • A PST file had issues extracting all content. The user could run a repair utility such as ScanPST on the PST. This may or may not repair the file and has the potential to change metadata for content, but it is utilized generally through approval from the end client. The container could then be re-queued.

Q: How can the eCapture QC application be used with my Streaming Discovery job?

 

A: Once a streaming discovery job has completed, it can be loaded in QC to review the results. Generally, it would be used to review exception flags. Users can then attempt to determine what might have caused the error and utilize the different reprocessing options such as forcing the document to use Stellent to process in order to attempt to get additional information from the file. If the documents were loaded directly to Eclipse, the results from a successfully reprocessed file in eCapture QC will automatically be updated in Eclipse, similar to the Enterprise Imaging function today. Successfully reprocessed files could result in additional metadata or text being loaded to Eclipse.

 

Q: When an item level exception document is sent to Eclipse using the Publish Errors option, what can we expect the document to look like in Eclipse?

 

A: Documents published to Eclipse will be flagged in the System QC Flags (Ipro Eclipse Template Field Name) field with ‘Streaming Discovery Errors Forced Through Export’. Documents in these families which did not have an issue will appear as normal. Documents which caused the family to be held back will also be flagged as an exception and will most likely only contain file system metadata depending on the error.

Link to comment
Share on other sites

Archived

This topic is now archived and is closed to further replies.

×
×
  • Create New...