Skip to main content

Error Running Report after 3.14 upgrade

James Landwehr

After upgrading to Essentials 3.14, I am getting an error when trying to generate a mailing label report inside a workflow. The workflow runs fine until the activity that includes the Mailing Labels report, then it fails with "Workflow Error - Error running report" 

The report runs fine from the GCE Rest endpoint for a single parcel. I'm wondering if this is a bug within workflow? Nothing else has changed on our installation since the upgrade. The error starts on the attached fiddler archive on Line 94 I believe. Any help appreciated.

 

/customer/servlet/servlet.FileDownload?file=00P6000000e88Q8EAI (https://support.geocortex.com/Data/Sites/1/userfiles/773/fiddler_buffer_archive.zip) /Data/Sites/1/userfiles/773/fiddler_buffer_archive.zip

0

Comments

14 comments

Date Votes
  • Permanently deleted user

    Same thing here - just upgraded to 3.14 this morning and been troubleshooting reports ever since.  Same error:

    /customer/servlet/servlet.FileDownload?file=00P6000000e88SmEAI

    Forgot to add - I installed the 3.14 hotfix #1 as well.  I don't see anything in the REST application error logs and am stuck on what the problem could be. 

    0
  • Ryan Cooney

    Hi All,

    The Fiddler trace indicates that the workflow is running correctly on the server. The response to request #94 is properly formed and indicates that the viewer should run the layer report. The next request is also properly formed and is from the completion of the report activity (but without a result URL). So the problem appears to be in the implementation of the report activity handler in the Silverlight Viewer. The implementation of this activity assembles a new request to actually invoke the report endpoint. Since we don't see this request in Fiddler it proabably didn't happen. This sounds suspiciouly like a URL length issue where the URL is too long to perform a GET and POST is needed instead.  What viewer version  are you running? The referrer header in Fiddler suggest 1.3. Something very similar to this was fixed in 1.4.

    --Ryan

     

    0
  • James Landwehr

    We are using SLViewer v. 1.9. The referring URL is a legacy URL path referring to our current silverlight location (http://<servername>/SilverlightViewer_1_3)

    But yes, we are using the most current viewer v. 1.9

    0
  • Ryan Cooney

    Hi Jim,

    Thanks for the update. We have identified the cause now. The Esri Silverlight API changed at version 10.1 (which GVS 1.9 uses) such that the ESRI.ArcGIS.Client.Utils.Normalization.Normalize(Geometry g) method now throws an exception if the spatial reference of the geometry is null. Previously it would just ignore it.

    As a workaround you could switch your RunExternalCommand activity that calls the "AddMarkup" command to instead call the "AddTemporaryMarkupGeometry" command. This uses a different graphics layer from the regular markup and avoids the problematic "Normalize" call. This may not be ideal, but at least the report would run.

    --Ryan

    0
  • James Landwehr

    Ryan,

    That seemed to fix the issue. Thanks a lot for following up on it. Much appreciated.

    Jim

    0
  • Permanently deleted user

    Working here too - thanks Ryan!  Should we continue using the temporary markup geometry, or are you planning on changing the AddMarkup command in a future release? 

    0
  • Ryan Cooney

    Glad to hear it.

    We will change the AddMarkup comand for the next release to avoid this issue.

    --Ryan

    0
  • Permanently deleted user

    Thank you, I also had this issue. Switching to temporary markup worked for me too.

    0
  • Chris Dunlop

    Ryan, I've run across a similar situation since upgrading to GE 3.14, SV 1.9.  I get the Error Running Report error, but I'm not using any markups in the workflow.  I do have a Display Capture Geometry task that seems to cause the error.

     

    If I select an area of interest in the Display Capture Geometry, and I supply the geometry to the Report task, it works correctly.

    If I don't define an area of interest in the Display Capture Geometry, I leave the geometry field blank in the Report task, and it fails.

    The weird thing is, I have some similar workflows that use the exact same logic that work even if I don't define an area of interest.

     

    Any ideas how to get around this?

    Thanks,

    Chris

    0
  • John Nerge

    I had this same issue in a mailing labels workflow that uses Display Capture Geometry to select properties and includes an option to buffer features prior to generating the labels. I just bypassed the AddMarkup activity in my workflow. Everything is working fine now with the only downside being that the end user won't be able to see the markup representing the buffer they are using to select parcels.

    Instead of passing the geometry from the Display Capture Geometry to my report, I use the selected parcels to create a where clause using a ParallelForEach activity (learned how to do this from one of the mailing label samples in the code gallery). As such, the spatial selection is only being used to represent the selection on the map, and the report runs using an attribute selection. I set it up this way because I needed the option to bypass running a buffer, so I don't always have a geometry to pass to the report. Also, there are other optional settings in the tool to exclude city-owned and vacant properties, both of which generate supplemental information to be included in the where clause.

     

    Thanks to Ryan for mentioning that the AddMarkup command will be fixed in the next release. I've left it in my workflow but unattached from the flowchart so I can implement it again once it's been fixed.

    0
  • Chris Dunlop

    I got around my problem by adding another form after the capture geometry form (I have a series of forms with Previous and Next buttons).  No idea why this would make it work, but I'd noticed that I wasn't having the same problem in workflows where I had additional forms after the capture geometry one.

    Chris

    0
  • Carmen Durham

    I am having a similar issue where the report runs using a geometry drawn by user from "DisplayCaptureGeometry"  along with a "Where clause".

    Using no markups, only highlights.

    Except in my case, the report works wonderfully if the user has NOT added any markups from the Drawing Tools within SLV.

    If the user has added any drawings, the report will fail.  It is definitely within the report control. It definitely seems to have something to do with the graphic from the DisplayCaptureGeometry and the markup from drawing tools. I will look into John Nerge's suggestion.

    Same exact workflow except exports to a .xls vs. going to a .rpx works fine.

    GE3.14 and SLV 1.9

    Thanks,

    Carmen

    0
  • Permanently deleted user

    I also have the issue of the report failing if there is markup on the screen (not markup generated from the workflow, any markups)

    It will return workflow error - error running report.

    Cathy

    0
  • Permanently deleted user

    Hi Cathy,

    I've added your name as a stakeholder on this issue. It has been resolved in the next version of the Silverlight viewer (1.10).  While I don't have a fixed release date, you should receive an automated email when this version is available for download. You'll also see a post in the Announcements forum too.

    regards,

    Edmond

     

    0

Please sign in to leave a comment.

Didn't find what you were looking for?

New post