Question

(413) Request Entity Too Large.

Workflow Forms

Updated December 3, 2024

asked on August 20, 2024

Hello,

I have a Process which re-uses tasks and workflows, essentially until the user is finished entering in all the data, and approvals.

User enters in data > Workflow saves data to DB and Clears page > User enters more data.
This goes on until the User is finished, then goes off to approvals.

I have recently started hitting this error:

Stack Trace:
Caught exception: Laserfiche.Forms.CommonUtils.Exceptions.LFFormsException
Message: An unexpected error has occurred. [LFF502-UnexpectedError]

Inner exception: System.Net.WebException
Message: The remote server returned an error: (413) Request Entity Too Large.
at System.Net.HttpWebRequest.GetResponse()
at Laserfiche.Forms.Routing.WrapHttpWebRequest.GetResponse()
at Laserfiche.Forms.Routing.LFWorkflowService.Execute(Int32 instanceId, IRoutingContext routingContext, RoutingInstanceStatus OriginalStatus)
at Laserfiche.Forms.Routing.ServiceTask.Execute(Int32 instanceId, IRoutingContext routingContext)

At this point, the Affected Form seemingly cannot run any more workflows.

I found this post:
https://answers.laserfiche.com/questions/174587/413-Request-Entity-Too-Large--Workflow-Web-Service-API

And was able to increase the Max Size as described.

Web\Laserfiche.Workflow.Web\Web.Config

Default MaxReceivedMessageSize was:

10485760

Doubled it to:

20971520

Same here:

Laserfiche.Workflow.Service.exe.config

Default was 1024000000.

Doubled to 2048000000.

I have restarted services, and Recycled Workflow Web Services App Pool.

This resolved the issue for a bit longer, but the issue just returned several tries later (Same instance).

Are there any limitations to sending the user back to the same user task in the Process?

Is there any way to see what could be causing this issue specifically?
I am not sure why the data would be larger each time, it is just updating SQL tables via workflow, then clearing the form.

I greatly appreciate any guidance.

Thank You!

0 0

Replies

replied on August 20, 2024

The snippets of XML in your initial message do not match the ones in the post you linked, so i think you're still running with default settings.

That said, even with the size increases, there is no way to have a "forever" form that can be wiped and submitted over and over in the same instance. Information on previous submission is part of the data passed to Workflow, so the size of the messages can get unwieldy pretty fast.

1 0

replied on August 21, 2024 • Show version history

Hi Miruna,

Yes, the Web.Config, and Laserfiche.Workflow.Service.exe.config, I couldnt find the exact locations.

The snippets were the closest i found.

I see, that will change my approach then. I was trying to use a theoretically infinite form.

I suppose I could split them into separate forms. One for Upload, and one for Approval.

Could you let me know where the restriction lies on each instance?
Is it the amount of Assigned User Tasks, Amount of Workflows ran, or just everything in the Action History (User Tasks, Workflows, etc)?

Thank You again for the info.

0 0

replied on August 21, 2024

All of the above, really. When Forms calls a workflow, it hands over the form's current data along with all the history of the process so far, how many user tasks it had, who were the submitters in each, when those submission times and decision actions and so on.

You are starting a new instance of Workflow when you call it in a service task, but your Forms instance carries its entire history around because it never ends.

It's hard to say if breaking things up in 2 forms would be enough without understanding what you're trying to achieve. What is the use case you are trying to implement? Why do you need one form that gets wiped out and re-filled over and over?

0 0

replied on August 22, 2024

Hi Miruna,

Essentially we have a Process, Newly Developed in Laserfiche to process Expense Claims. The process is nearly complete, and works great. We only saw the restriction during our Testing.

The first part of the Process simply allows the user to fillout a form (Several Pages) with criteria. Workflow uses this criteria to calculate the expenses, eligibility, and a few other factors, and right now we just have the form clearing the data and allowing the user to enter in criteria for the next day for example.

This goes on until all the user is finished.

User enters criteria > Workflow manipulates and compares data with External tables and api > Workflow saves newly formatted data to a SQL Table.

----------Here is my guess where I can split the forms-------------

Next, we have a Summary page to present the totals (From SQL) of all the entered expenses.

This routes through an approval path, and currently allows it to be sent back if there are issues.

Approval path is about 6-7 people.

Since the beginning of the process is simply intaking criteria, my only idea would be to isolate this to its own form. I suppose this could simply be a new instance each time as well.

Since the latter half of the process is approvals, i figure I can isolate this as well, but it would have to be one instance to track all the approvals together.

I appreciate your feedback. The current form with everything included in one instance is complete and working, we just weren't aware of the limit! We do not mind splitting it if that would avoid the limitation.

Thank You!

0 0

replied on August 20, 2024

Hi All,

I have also attempted this on a very simple dummy form.

I have a number on the form, then a workflow increments the number by 1. Re-assigns it to the previous User Task.

I got up to 111 before receiving the error.

If anyone is aware of this limit and can point me in the direction on any further information, that would be Greatly Appreciated!

0 0

replied on December 3, 2024

Also running into this issue. Going to implement an increase but interested in feedback of long running instances. May need to discuss details.

0 0

replied on December 3, 2024

Hi Lexie,

Unfortunately I couldn't find a way past this.

We have a form that allows data entry and an approval process.
We setup the data entry part to just go back to the same page for the next data entry, which resulted in the action history being incredibly large. We reached the limit there.

Ultimately we set it all up where the data entry is its own form, and the approval process is its own as well.

Since the data entry is all writing to SQL for us, it worked out well having the approval portion reference SQL.

Good Luck

0 0

You are not allowed to follow up in this post.

Question

Question

(413) Request Entity Too Large.

Replies

Sign in to reply to this post.