Hello,
I am migrating to Experience Builder Dev. Edition 1.18 on a new server, coming from WAB Dev. Edition. My custom models and widgets are getting completely rebuilt from scratch after the migration over after no longer being compatible. I finally have a reconfigured highlight parcel tool, seems simple enough... interactive selection, appends to an empty memory dataset and add output to the map. The output is a specifically selected parcel by the end user that's boundaries are highlighted with different symbology.
This model runs perfectly fine, adds output to map in Pro 3.5. I shared this model as a geoprocessing tool to my Portal account and then added that to an analysis widget inside of Experience Builder 1.18 on my new web app. (the layer project this was published from is also present in the apps web map)
When I run this as a widget in Experience Builder it runs successfully as it should, it even creates the output in the layer list and when I open the output table to parcel I selected was properly appended to the table. HOWEVER.... the output never renders and its symbology never shows up? It even zooms to the correct parcel. Yet no symbols ever render.
I cannot figure out what is wrong
I am struggling with this as well (Enterprise 11.3). My geoprocessing output is visible but there doesn't seem to be anywhere in experience builder to configure the symbology of the outputs like what exists in WAB. Setting the symbology in the model works when run in ArcGIS Pro but has no effect in the published tool. Maybe I'm missing something in the publishing process?
Hi Jeff!
I ended up solving my own problem, which seems like it was likely an overly complicated model that could be simplified. So I by swapped the "append" with a "copy features" and then I had it copy the highlighted features to a temporary memory layer. Once I made that change, the geoprocessing tool issue was resolved. (the append tool in my model seems to give me issues?)
I did however notice that the symbology is different than WAB - but it is still there. But I was able to set a default symbol in the widget settings still. (see photo) But I do not see the same option for you... I wonder if your issue is a setting when you published your geoprocessing tool from ArcPro. (my model outputs are set as "parameters" and "add to display")
Another way I successfully applied symbology by default was by running a model first in ArcPro. Then setting the symbology in the project, and exporting as a layer file(.lyrx). Then I went into my model parameter and set the template property to the .lryx file I saved and published as a service.
Molly
Thanks for the reply and encouragement! I'm pretty sure version 11.3 doesn't allow for setting symbology of geoprocessing outputs through the Analysis widget like what you see in 11.5.
See here.
We have not yet support config symbology rendering in Analysis widget in Experience Builder.
But if you publish custom gp service by applying the symbology to the output it should work. See https://www.esri.com/arcgis-blog/products/arcgis-pro/sharing-collaboration/how-to-control-the-output...
Thanks for the reply. I tried following the two suggestions in that article with no success. I've given up. The orange symbology will have to do until we upgrade to 12.1.
Just for your notes, I did notice that if I browse to the custom geoprocessing tool in my items and select "Open in map viewer", and run it there, it will render the symbology correctly. However, when I add the tool through the analysis widget in experience builder, the symbology is always the default orange.
Good feedback. Thanks for letting us know. We will take a further look.
@JeffLegato1 do you do anything about the symbology in the gp service? or everything is default?
There isn't anything I can do really in configuring the symbology in the gp service other than pointing the outputs to a .lyrx in the tool properties in Pro v3.3.1. We are Enterprise 11.3 and, as I understand it, all of these issues will go away once we upgrade to 12.x. We have to deal with our old v16 SQL server first though. No easy task as our SQL server is also hosting other legacy applications. Thanks @Wei_Ying for taking a peek at this.