You are viewing limited content. For full access, please sign in.

Discussion

Discussion

[Bug LF10] [Fixed LF11] [Forms] [DocuSign] [PDF] An error occurred during the execution of the Save to Repository service task. [LFF5426-ErrorExecuteSTR]

Forms Snapshot Version 10 Capture Support Site
Updated February 27, 2022
posted on February 1, 2021 • Show version history

Notice: This has been fixed in Laserfiche 11. Please upgrade if you are experiencing issues.

TL;DR: (Updated)

PDFs generated by the latest version of the PDFKit.NET library (used by contract generation platforms like DocuSign) generate files that are incompatible with LF10's PDFViewNET library (e.g. the part that generates text/pages upon import). A workaround is posted a few posts below (turn off generate pages/text on import). Alternatively, upgrade to LF11 when it is released later this month. According to LF due to the complexity of updating the PDFViewNET library, a LF10 hotfix will not be produced for this issue.

Original Issue/Post Below

We have identified that some PDFs generated by a recent (December 2020) backend update by the cloud service DocuSign is causing the Laserfiche Forms "Save to Repository" function to fail with a non-descript "502 Unexpected Error".

As the error-causing files are viewable without any visible errors or issues in Adobe Acrobat (and Pro), we believe there is some kind of corruption at the XML level which Laserfiche's save to repository function is tripping up on.

We are unsure why these PDFs are causing the process to fail, however, manually opening and reprinting these files (via Print to PDF in Adobe Acrobat) and re-uploading them to the Forms process will allow it to save to the repository without failing. We've tried to pinpoint which version of PDFKit DocuSign are using to create the PDFs but we cannot seem to discern any logic as to why some document packages are corrupted while others are not.

 

The current work arounds are as follows: (see a later post for permanent workaround)

1) In DocuSign download the document "package". Open each PDF individually (e.g. the contract, the cover letter etc) and print it by using the Print to Adobe PDF option. Note, the corruption stops you from saving the PDF as other PDF formats e.g. PDF-A etc, hence needing to virtually print the documents. Once you have 'reprinted' each of the files, upload them to your forms process and retry the Save to Repository task. It should now work.

2) Alternatively, in DocuSign, if your package contains multiple documents, use the "Combine Documents" function to force DocuSign to regenerate all of the documents as a single combined document using "todays" build of their PDF generator (in case they update their SDK). We don't know why, but regenerating and combining seems to fix XML corruption. This isn't ideal because we then have to dissect the documents into individual files manually in Adobe Acrobat Pro as to attach the contract, cover letter, proposal etc to the various fields within the contract management process.

 

So what is being done about it?

We have reported this issue to Laserfiche Support and they were able to reproduce the error. They have advised the SDK used by Snapshot will be updated in Laserfiche 11 released later this month. Specifically their resolution for our support ticket was initially: "Known issue in bug 172178. Will be fixed in Laserfiche 11 with PDFViee4NET 6.1.2.11."

As this issue is affecting our users in production, and the problem is growing, we have requested a hotfix. If this issue crops up for you in any business critical capacity, be sure to reach out to Laserfiche support for assistance.

I am posting this to answers so that others are aware of this very frustrating issue and so that they can use the above workarounds in the meantime (saving themselves many hours of investigation).

 

Has anyone else encountered this issue with PDFs or DocuSign and the Save to Repository Task in Laserfiche Forms? Please share your story if you have.

 

To help with others searching for this error, a copy of the error from forms is below: 

Stack Trace:
Caught exception: Laserfiche.Forms.CommonUtils.Exceptions.LFFormsException
Message: An error occurred during the execution of the Save to Repository service task. [LFF5426-ErrorExecuteSTR]
at Laserfiche.Forms.Routing.SaveToLaserficheService.Execute(Int32 instanceId, IRoutingContext routingContext, RoutingInstanceStatus OriginalStatus)
at Laserfiche.Forms.Routing.ServiceTask.Execute(Int32 instanceId, IRoutingContext routingContext)

Inner exception: System.NullReferenceException
Message: Object reference not set to an instance of an object.
at Laserfiche.PdfServices.PdfExtractor.LoadFile(Stream pdfStream)
at Laserfiche.PdfServices.PdfExtractor.ImportPDFPagesFromStream(Stream pdfStream, DocumentInfo doc)
at Laserfiche.PdfServices.PdfExtractor.ImportPDFStream(Stream pdfStream, DocumentInfo doc, DateTime dtLastModified)
at Laserfiche.Forms.CommonUtils.LFHelper.TryImportAttachment(Session sess, cf_bp_attachment_data attachment, FolderInfo parentFolder, String volume, String attachmentName, String ext)
at FormsModel.RoutingModels.Services.SaveFormToLaserficheStrategy.SaveAttachmentToLaserfiche(Session session, XmlDocument datasetXml, STLConfigurationObj conf, DocumentInfo rootddoc, String timeZone, String rootFolderPath)
at FormsModel.RoutingModels.Services.SaveFormToLaserficheStrategy.SaveToLaserfiche(Session session, XmlDocument datasetXml, List`1 STLConfigList, SaveToLaserficheParameters saveToLaserficheParameters)
at FormsModel.RoutingModels.Services.SaveToLaserficheHelper.OpenSessionAndSave(IEntityContext _AppContext, Int32 STLRepositoryId, List`1 STLConfigList, XmlDocument datasetXml, ISaveToLaserficheStrategy saveToLaserficheStrategy, String timeZone)
at FormsModel.RoutingModels.Services.SaveToLaserficheHelper.SaveToLaserfiche(IEntityContext _AppContext, Int32 STLRepositoryId, List`1 STLConfigList, XmlDocument datasetXml, ISaveToLaserficheStrategy saveToLaserficheStrategy, String timeZone)
at Laserfiche.Forms.Routing.SaveToLaserficheService.Execute(Int32 instanceId, IRoutingContext routingContext, RoutingInstanceStatus OriginalStatus)

1 0
replied on February 9, 2021

So this is not related to saving the form as a PDF. Only an attachment uploaded to the form. In this case, how do I prevent the archive from trying to save the attachment, so that I can save the form?

The workaround to manually download the attachment is no good if the form is still not saving.

0 0
View 1 previous reply
replied on February 9, 2021

Hi Chad,

If I understand you correctly, you should not get this error when simply saving a submission as a PDF using the Save to Repository Activity.

This bug is caused by malformed PDF attachments breaking the Import process during a Save to Repository action where there is a PDF attachment present.

The only work around for a production environment experiencing this issue because of malformed PDF attachments is to disable Generate Text and Generate Pages for the user account nominated by the Save to Repository Profile. Instructions to do that are in the solution above.

This solution might help if you've come across another webservice (like DocuSign) who may have recently updated their PDF rendering libraries and are now generating incompatible PDFs (do share if this is the case!).

0 0
replied on February 9, 2021

I think the problem here is that the submission will not archive, because the archive activity includes both a submission AND an upload. I was trying to remove the upload so that the submission could be saved at the very least and we could import the upload seperately.

Is this caused by modifying forms to automatically convert PDF uploads to TIFF images? That is not even an official configuration, it is a secret configuration.

 

0 0
replied on February 9, 2021

Oh yes, this was an easy fix. It was only when trying to use a modified forms account to convert uploaded PDFs to TIFF. Sometimes the conversion fails, but when this happens it also does not carry out any other configurations in the save to repository task.

Your recommended workaround fixed the problem. Simply have 2 service accounts, one that converts to TIFF and one that does not. For the processes which have problems converting, switch back to standard configuration.

1 0
replied on February 9, 2021

Hey @████████ glad a variation of the workaround worked for you. I must say I'm still a little confused about your issue. I hope it isn't a wider issue.

I have written another post regarding some improvements that could be made to how submissions and attachments are saved to the repository. Feel free to go add your thoughts and +1 here: https://answers.laserfiche.com/questions/181862/Feature-Request-Save-to-Repository-and-File-Management-Enhancements-Forms#repliestomain

0 0
replied on February 8, 2021 • Show version history

No Hotfix from Laserfiche
Solution: Upgrade to Laserfiche 11 (Now Available)

Hi team,

Hope you all had a good weekend.

Laserfiche Support have come back to us to advise that due to the complex nature of this specific issue a hotfix will not be possible at this time. According to Laserfiche, this issue is resolved in LF11, and their recommended solution is to upgrade when it is released later this month. There is no way for me to verify this for ourselves or our customers because the release of LF11 is still a few weeks away. This does not help customers who cannot/will not upgrade to LF11, meaning the only real way to solve this issue currently (and for legacy customers) is to use the workaround I posted earlier.

Unfortunately as more companies/platforms/web services who are using PDFKit.NET upgrade their rendering libraries, we may see this become a more widespread issue. So if you have a customer experiencing issues importing PDFs with [Generate Pages] or [Generate Text] turned on, please be sure to chime in on this thread and reach out to Laserfiche to keep them in the loop on the demand for a hotfix.

cc: @████████

 

Here is what the errors caused by this bug look like:

Error messages on import into the Laserfiche Repository (or Web Access):

Import Error
There was an error importing 'Document.pdf':
Object reference not set to an instance of an object.

Error message on save to repository activity from Laserfiche Forms:

An error occurred during the execution of the Save to Repository service task.
[LFF5426-ErrorExecuteSTR] Details:
URL:
Error: ErrorExecuteSTR
Date: 13/01/2021 10:58:29 AM (New Zealand Standard Time) HTTP
Status Code: 500

0 0
replied on February 9, 2021

Just as an FYI to this, We were told via support case 214658 that a hotfix is set for mid to late March. 

We also asked for a hotfix because upgrading to version 11 is not just something that can be done over night for a lot of customers.

Secondarily, we also have a customer who is using LF cloud that has this issue. We aren't able to get any kind of timeline on when it may be resolved there. If anyone has any information with regard to this issue and the cloud, please update this post. :)

3 0
replied on February 2, 2021 • Show version history

Workaround for the Import Issue

Just an update on this, with a workaround if your organisation or customers currently rely on DocuSign for e-signature. 

DocuSign will not be rolling back the update to PDFKit.NET that they implemented in December. Therefore, if you are trying to import DocuSign documents into Laserfiche Web Access / Windows Client OR via the Laserfiche Forms "Save to Repository" activity you'll need to use this work around.

So, for Web Access and/or the Windows Client (e.g. Drag and Drop) - simply deselect "Generate text" and "Generate pages" after dragging and dropping into the repository on import.

You can find these settings here:

The default options on this screen can be accessed via your User Profile which you can find here:

Specifically of interest will be the "New Documents" tab which displays your Import Defaults:

You want to set your default settings here to make your own life easier.

Failure to do so in Web Access / Windows Client will result in this error when importing malformed DocuSign PDFs:

So that's great.. but Laserfiche Forms doesn't give you an option to deselect or override the "Generate Pages" or "Generate Text" on import via the "Save to Repository" activity. Turns out that is because it actually respects the settings of the user profile used to save files using the "Save to Repository" activity.

So, in theory, if you configured your user profile default options to NOT generate pages or text per the above instructions, and then you were to use your own user credentials (not advised) as a profile for the "Save to Repository" activity in Laserfiche Forms the system will respect your wishes and save the PDF directly without triggering the error. So we're getting somewhere!

However, it is not advisable to use your own credentials to store files into the repository so you are best to create a new repository user with the sole purpose of importing documents from Laserfiche Forms where the settings to Generate Pages/Text are "OFF" by default.

Below, I'll show you how to do that:

Generate a strong password, and keep a record of it in your preferred Password Management solution. For this service user, be sure to ignore the maximum password age and to prevent the user from changing their password. 

It is best practice to only provide the user with the privileges they need, in this case their sole purpose is the importing of documents to the repository.

Now, if your environment is like ours chances are you've got authentication connected to Active Directory which means you may not be able to login as the user and access their options to set the defaults without a whole lot of fuss.

Luckily, Laserfiche allows you to manually set preferences at the user profile level. So, using the attributes outlined above, configure our "Filing Clerks" user attributes using the "Attributes" tab. This will set the defaults to ensure your PDFs do not have their text or pages processed when they're passed into the repository by the "Save to Repository" activity in Laserfiche Forms.

 

The last step is to update your Save to Repository Activity in your various business processes.

Pro-tip: Rather than creating a "new" profile with the updated credentials, simply "edit" the existing one, and update it with the new credentials. This will save you from having to go through and update every "Save to Repository" node in your business process.

We deal with a high volume of contracts (hence the importance of finding a workable solution as soon as possible) and I hope that if you're in the same position that this will some how help you too.

0 0
replied on February 2, 2021

Just to add to this, we have had similar issues with a lot of customers that use docusign. We opened a case with docusign to see if something could be done on their end. Docusign went to version 1.5 of Adobe in December 2020. The problem fits exactly with that move. 

 

We have tested docs from the 1.4 iteration before the transition to 1.5 and there is no problem. It seems that this problem was/is caused by that move and so this issue is likely either more widespread than just docusign or it will be shortly.

 

I have asked Laserfiche for a hotfix for version 10.4.3 because it's very critical to some users and they are asking me to provide a list of customers that are affected by this. You may also want to reach out and let them know who may be affected on your side as well. The more systems that are affected, the better the chance that a hotfix will be released.

2 0
replied on February 2, 2021 • Show version history

Thanks for adding your story @████████. Your confirmation of this issue is good to hear. We'll be lodging a support ticket with our enterprise account manager at DocuSign. Did you have a case number we can also reference in our report to ensure DocuSign don't try to downplay this issue?

According to Laserfiche support they'll be updating to the January 4th release of the PDFView4NET library that is used to render PDFs in LF11. This morning they acknowledged the importance of this growing issue and confirmed to us that they'll look at trying to build a hotfix.

I'm trying to decipher from the PDFView4NET change logs the source of the issue..
 

Release Notes: January 4, 2021 - PDFView4NET 6.1.2 release

PDFView4NET 6.1.2 Windows Forms and WPF editions have been released. For the complete list of features click here. The following features are supported in this version (+ new features/enhancements, — bug fixes):
PDF Rendering:
— Text is not rendered when embedded Arial font is damaged - fixed
— Documents that include Type4 functions cannot be rendered - fixed
— Some CFF fonts are not rendered correctly - fixed
— JPEG2000 images with DeviceN colorspace are not displayed correctly - fixed
— JPEG images with incorrect height in image data are not displayed correctly - fixed
— WPF - Some paths are not scaled correctly - fixed
— WPF - Shared images are decoded for each display instance - fixed

At this point, your guess is as good as mine. I imagine it is to do with the Type4 functions which fail to render. The rest seem to be cosmetic issues. There are even more 'show stoppers' in the latest Feb release that only came out a few days ago.

Really proud of Laserfiche for responding as quickly as they have. DocuSign have been less than ideal to work with to be honest.

0 0
You are not allowed to follow up in this post.

Sign in to reply to this post.

Details
Related Posts
Loading ...