09-05-2017 07:56 PM
We deployed portal 2016 for our client and we configure portal instance to run with https protocol. We set up the portal to use the external print service. The experiment shows that the PrintService still needs to be configured to run with http. However, when consuming the print service in portal, it shows the following error.
We also try consuming the print service with the portal running under normal http, or use hostname instead of the full qualified name for the print service but it still shows the same error message.
The Web site holds portal instances and print service do allow two bindings.
I suspect it is likely to be enviornmental issue but haven't figured out where it is.
Appreciate all ideas and insights
Solved! Go to Solution.
09-06-2017 08:51 PM
Here is some update on investigating the issue. For some reason, there is a missmatched message type between portal and print service. When setting up the print service in portal, the portal send message in "application/soap+xml" format while the print service expect "text/xml" format.
I include the portal log file here in case it's helpful.
I haven't found the cause why there is a missmatch. The portal and print service are out of the box.
Appreciate all suggestions and ideas on this issue.
09-08-2017 05:06 AM
It is possible there is mismatch here with HTTP and HTTPS. It should be investigated if the 'loadBalancingConfiguration' switch for printing will help this case. Despite the name it is not only specific to load balancing as it can be useful in SSL offloading cases and may be the configuration necessary here.
To trial please engage in the Portal instance web.config the ‘loadBalancingConfiguration’ for printing. Below is an example of it implemented.
Need to save the file and refresh all caches, .NET temp files and restart services to test properly.
Configuration for printing service:
* tileSize - positive number switches WMS layers at print time to "Tiled" mode with given tile size; default value is 2000; 0 switches WMS layers to "View" mode with buffer = 1;
* mapSizeLimit - maximum resolution of the generated image; default value is 5000;
* timeout - default value is 00:02;
* defaultService - (Local/FirstExternal) service type setted as default in printing window; default is FirstExternal;
* precisionGeographic - precision of coordinates in geographic CRS; default value is 7;
* precisionProjected - precision of coordinates in projected CRS; default value is 0;
* printingEngine - (internalInternetExplorer/phantomJS) browser engine used in printing process; default value is internalInternetExplorer;
* phantomJSProgramLocation - location of phantom program (used if printingEngine is phantomJS);
* userName - name of user for Basic Authentication (used if printingEngine is phantomJS and Windows Authentication is enabled);
* password - user password;
* enablePhantomVerboseLogger - (true/false) enable creation of additional log files for phantom engine; default value is false;
* loadBalancingConfiguration - (true/false) enable configuration for load balancing; default value is false;
* hideDpi - (true/false) hides DPI visibility in Template Options (OGC DPI is used); default value is false;
<printing tileSize="2000" mapSizeLimit="5000" timeout="00:02" defaultService="FirstExternal" precisionGeographic="7" precisionProjected="0" printingEngine="internalInternetExplorer" phantomJSProgramLocation="C:\Program Files\Hexagon\Geospatial Portal\Program\PhantomJS\phantomjs.exe" loadBalancingConfiguration=”true” />
09-10-2017 02:33 PM
I am testing the printing service on dev, so there is no load balancing implemented. However, I will try the configuration that you suggested.
09-13-2017 09:17 PM
From my online search, message type application/soap+xml is SOAP1.2 which wsHttpBinding uses and basicHttpBinding uses SOAP 1.1 (text/xml). The portal web.config has a section on basicHttpBinding for printing and print service also provide endpoint with basicHttpBinding, so technically there should be no missmatched in communicating message between these two.
We test the portal when it runs under HTTPS and HTTP but they still show the same error. This error is very confusing, and honestly I have no idea where I need to look.
Appreciate all suggestions and insights
09-13-2017 11:35 PM - edited 09-14-2017 07:23 AM
This happened to me after switching to ASP.NET Session State service instead of the original In Process mode. I don't know how to figure this out yet, I assume it might be either a limitation. Can you confirm that you use ASP.NET Session State service too?
09-14-2017 02:32 PM
Hi Jan, Stephen and team,
Thank you for looking into this issue. The ASP.NET Session state service is not running on the environment I tested. This is very bizarre. I will do more research on this.
09-17-2017 02:22 PM - edited 09-17-2017 02:24 PM
I finally resolved the issue. The problem is when print service gets consumed by a portal instance, in the process, it generates a verion file that have endpoint for PortalPrintService_v2.svc and not enough permission prevents it. The missed match I found it also happens when the print service well connects to the portal because the portal uses wsHttpBinding to connect print service basicHttpBinding (I already de-compiled the dll and check), this error message really derails my investigation.
01-09-2019 05:29 PM
I didn't make clear how I can solve the problem. Here is the detail
The reason why I observed that problem because the application pool used to run the external print service should have full control to the App_Data folder, some files are generated during the communication between portal local print and the external printing service, so the application pool must have the permission for that.
Technically, we shouldn't need to modify the permission for the application pool but for unknown reason, when we installed the webmap on the client environment, this error happened.