Thanks, Robert. To be perfectly honest, this is my first time using the print widget. Can you point to where this specific behavior is documented? I didn't seem to come across that mentioned anywhere. I don't doubt that I'm seeing intended behavior, but it does seem like a sub-optimal (though arguably more generic) use of the API so I'm wondering if there are hooks for either intercepting the built JSON or otherwise configuring what get's sent to the server. In my case I may need to find a workaround or else effectively rebuild the print widget from scratch...
As William most JS API internals there is no specific documentation on this. For those of use that have used the API for years now we are just familiar with this. You can as some have alter the json before it is sent using esriRequest.
Hi, Robert. I'm sorry, would you mind elaborating on that last comment? I see esriRequest but it looks like an AJAX helper utility. Is there a way to intercept requests made by the framework with this? Or are you suggesting I just redefine "esri/request".
My feeling is that the features are going to have to make their way to the print service one way or another in order to be converted to an image. Whether this is done by your client sending whatever feature data it has currently or the service making separate requests to the feature service based on the oids passed in, the result is going to be more or less the same.
It's surprising to me that this is causing issues. Are the features that get passed in filtered by the extent of the view? How many features are we talking about here?
Hi Thomas, thanks for the response! It's a fair point about features needing to make their way to the print service either way. That said, coming from the client we're potentially talking about a lot to send over the wire. We also have much less control over network speeds, etc. I feel like you could support better (or just different) feature resolution with those geometries getting expanded on the server as opposed to just using what's on the client. But you're absolutely right, it's gotta happen somewhere.
It looks like I'm *mostly* seeing things being filtered by view extent with a bit of a buffer. This makes sense, depending on the dimensions of the export image vs the client side view you might need more or fewer features than reside within your view extent.
I copied the error from ArcServer logs below. The Web Map as JSON param is definitely present when the request leaves my browser. It could be getting truncated somewhere along the way - I'll need to do some digging there.
Error executing tool. Export Web Map Task : ERROR 000735: Web Map as JSON: Value is required The value is empty. The value is empty. ERROR 000735: Web Map as JSON: Value is required
FYI I'm seeing request payloads of about ~20MB. This thread (Export Web Map Task - JSON length limit?) led me to check my own server configs and indeed I'm at the default of 10MB as a cap for POST sizes. I checked the other components of my stack and as far as I can see this is the only place I could be hitting a size limit.
Hopefully that provides a short term fix but figuring out how to bring this down to a reasonable number could still be interesting.