I'm having an issue with my Portal's print service (using the built in Print button in the web map). If a map contains a referenced feature service, the only way the print service will work is if the feature service is shared publicly. If the feature service has organization or owner level permissions, the print service will fail. I receive the following message when using the print service: "An error occurred while creating the printed map." If I check the server logs, I receive the following error for the Utilities/PrintingTools.GPServer service: Error executing tool. Export Web Map Task : Failed to create layer from service at . Note that the feature service URL it provides in the URL is valid. I can copy and paste it in a browser and it takes me straight to the rest endpoint. The only way it works is if the feature service is shared publicly. Otherwise, it fails. Here is what I have tried with no success: * Share the PrintingTools service with the public. * Make the referenced feature service (when not shared publicly) and PrintingTools service the same owner in Portal. * Share the feature service and PrintingTools service with the same group in Portal. None of that works and the only way it works is if the feature service is shared publicly. We're using ArcGIS Enterprise 11.2. I'm assuming this is not expected behavior, right? If not, does anyone have any issues on what the issue could be? Thank you! UPDATE: I've made progress in determining the root cause of this issue. The PrintingTools service doesn't seem to like AD accounts. If I am logged in under a built-in Portal account and use the print service with a feature service not shared publicly, it works fine. However, if I am logged in under an AD account and attempt to use the print service with the same feature service (not shared publicly), it fails. Second UPDATE: I initially thought it was an AD vs. built-in account issue. But I've ruled that out and realized that it's just a browser issue. Opening the map in an incognito tab or using another browser works..... I don't think it's ideal for users to have to completely clear their cookies and cache every time they want to use the print service (because this is happening to multiple people), but at least it's not completely broken.

nav[aria-label="Primary Navigation"] { padding: 0; & ul { list-style: none; width: 100%; display: flex; flex-direction: row; justify-content: start; align-items: start; gap: 30px; padding: 0; & li { margin: 0; } & ul li { list-style: none; } } }

Portal Print Service Doesn't Work Unless Feature Service is Shared Publicly (Export Web Map Task error)

ryanuthoff

I'm having an issue with my Portal's print service (using the built in Print button in the web map). If a map contains a referenced feature service, the only way the print service will work is if the feature service is shared publicly. If the feature service has organization or owner level permissions, the print service will fail. I receive the following message when using the print service: "An error occurred while creating the printed map."

If I check the server logs, I receive the following error for the Utilities/PrintingTools.GPServer service:

Error executing tool. Export Web Map Task : Failed to create layer from service at <feature service URL>.

Note that the feature service URL it provides in the URL is valid. I can copy and paste it in a browser and it takes me straight to the rest endpoint. The only way it works is if the feature service is shared publicly. Otherwise, it fails.

Here is what I have tried with no success:

Share the PrintingTools service with the public.
Make the referenced feature service (when not shared publicly) and PrintingTools service the same owner in Portal.
Share the feature service and PrintingTools service with the same group in Portal.

None of that works and the only way it works is if the feature service is shared publicly.

We're using ArcGIS Enterprise 11.2.

I'm assuming this is not expected behavior, right? If not, does anyone have any issues on what the issue could be? Thank you!

UPDATE: I've made progress in determining the root cause of this issue. The PrintingTools service doesn't seem to like AD accounts. If I am logged in under a built-in Portal account and use the print service with a feature service not shared publicly, it works fine. However, if I am logged in under an AD account and attempt to use the print service with the same feature service (not shared publicly), it fails.

Second UPDATE: I initially thought it was an AD vs. built-in account issue. But I've ruled that out and realized that it's just a browser issue. Opening the map in an incognito tab or using another browser works..... I don't think it's ideal for users to have to completely clear their cookies and cache every time they want to use the print service (because this is happening to multiple people), but at least it's not completely broken.

Najděte více příspěvků označených jako

Accepted answers

All comments

JonM32

@RyanUthoff Did you ever find out a solution to this issue?

I have the same problem using 11.3 enterprise. Printing works in Chrome but in Edge, it fails most of the time (unless I switch to incognito mode).

SillPaul

I was able to resolve this issue by changing the sharing level on our Data Stores.

The data stores were shared with the creator (user) and a group that I'm a member of.

However, the "Error executing tool. Export Web Map Task : Failed to create layer from service at <feature service URL>" persisted until the Data Stores were shared with our Enterprise.

SillPaul

Did you get any resolution to this? We are experiencing the same issue, on the similar platform (11.3, Windows).

Juan_Toro-Killion

I'm having an almost identical problem. I've also been working backwards by testing various things, like the original poster, to figure out what's going on. I've found out that if I don't try to print hosted feature services, the print service works fine. It's only when 1 or more hosted feature services are turned on in the map (WAB, EB, or Map Viewer) does the print task fail. I'm running 11.3 on Windows. Any comment on why there is no need for me or my users to clear cache when printing referenced/server feature services, but it's almost required when printing hosted (majority of our use cases)?

TimoT

Hi @RyanUthoff

This issue is likely related to a known limitation: BUG-000135413.

Using DevTools, you'll see that the token isn't passed in the request payload when the issue occurs. Off the top of my head, potential workarounds include:

Continue to clear cache and cookies or use incognito mode
Switching the default print service to another federated server's print service where users are less likely to trigger the known limitation
Embed credentials into a custom print service. This could potentially pose a security risk.

ryanuthoff

They have to clear it periodically. It's not literally every time, but also frequently enough to where it's pretty annoying. Also, it appears that the user has to clear both the cookies and cache. We tried only clearing the cache, and that doesn't fix it. It needs to be both cache and cookies.

I went on a wild ride trying to figure out this issue. When I was troubleshooting, I did try clearing the cache and it didn't work, so I initially ruled that out. And then opening an incognito tab and it working with a built-in account made me think that was the issue. But in reality, the incognito tab worked because it reset both the cookies and cache. I was caught off guard because there were ArcGIS Server logs saying it couldn't create the layer, so I thought those were permissions related issues. I never would have expected it to be cache related.

RClaveroM

Hi @RyanUthoff, seeing now your 2nd update, do they have to continuously clear the browser cache to use the print service without issues (every user's session?) or just once, and then it remains to work well?

I have had in the past that when changing the print service type within the Web AppBuilder print widget end-users were then getting the "Error executing tool. Export Web Map Task..." and clearing the cache solved the issue (as a complete final solution, I mean). I also see that clearing the browser cache is listed as a workaround in this Support article.

BillFox

I'm not sure if those are exactly like what you are troubleshooting but hope they help or spark some others memory to help you

BillFox

note 3: https://community.esri.com/t5/arcgis-enterprise-portal-questions/have-you-printed-arcgis-com-marketplace-premium/td-p/290414

BillFox

note 2: https://community.esri.com/t5/arcgis-online-questions/printing-limited-usage-layers-with-our-own-print/td-p/418534

BillFox

note 1: https://community.esri.com/t5/arcgis-web-appbuilder-questions/export-web-map-task-failed-to-create-layer-from/td-p/1123814

ryanuthoff

Technically, we could do that. But I feel like that's a pretty excessive workaround (paying for additional ArcGIS server licensing as well as the costs of running the server itself) just to run a printing service that should be working on the federated server in the first place.

I don't know what the root cause of the actual issue is. I'm not sure if it's on the browser side or the server side, but clearing out the cookies and cache seems to temporarily fix it. But regardless, I feel like the root cause of the issue should be fixed as opposed to deploying additional servers just to get around this printing service issue.

BillFox

do you have the option to stand up a separate (stand-alone) (not federated) ArcGIS Server machine to handle just printing chores?

Připojte se k diskusi

Přihlášení členové mohou přispívat, sledovat aktualizace a další. Jste tu noví? Zaregistrujte si bezplatný účet.

Rychlé odkazy

Community Help
Find useful guides, FAQs, and documents to help you navigate and make the most of Esri Community.