topic Enabling a Custom Geoprocessing Widget in WAB Fails in ArcGIS Web AppBuilder Questions

Enabling a Custom Geoprocessing Widget in WAB Fails

MichaelCollins6 — Thu, 05 Sep 2019 16:59:55 GMT

Hi all:

I am getting the following error when attempting to publish a widget to WAB in our Enterprise Portal. The file is definitely there so I am hoping this is a simple issue, but am utterly stuck. This was replicated using the stock geoprocessing widget as well by publishing that to the same server.

GET https://maps.gpinet.com/Test/widgets/Geoprocessing/nls/strings net::ERR_ABORTED 404 (Not Found)

init.js:37 Error: scriptError at c (init.js:11) at HTMLScriptElement.<anonymous> (init.js:35)

init.js:37 src: dojoLoader

init.js:37 info:

(2) ["https://maps.gpinet.com/Test/widgets/Geoprocessing/nls/strings", Event]
1. 0: "https://maps.gpinet.com/Test/widgets/Geoprocessing/nls/strings"
2. 1: Event {isTrusted: true, type: "error", target: script, currentTarget: null, eventPhase: 0, …}
3. length: 2
4. __proto__: Array(0)

Re: Enabling a Custom Geoprocessing Widget in WAB Fails

DavidWilton — Wed, 20 Nov 2019 03:46:27 GMT

The problem here is that when you publish a widget into Portal its hosted outside the WAB and you run into issues with paths. Widgets/MyWidget will no longer work. I'm not 100% sure on i18n, it always seems to work differently with paths to other dojo require items. Anyway I ran into the same issue with the AddData widget so here is what I think. With the geoprocessing widget I see:

RecordSetEditorChooser.js: 26

'dojo/i18n!../nls/strings',

Here there is a path and it is failing to find it, the error message is misleading I think its actually looking for it in the WAB. There should be a way to make it work as a relative path but I'm not sure what it is. I ended up just requiring the js file relatively (so no i18n):

'./nls/strings',

then using the .root property:

RecordSetEditorChooser.js: 38

lang.mixin(this.nls, gpNls.root);

This means your localisation won't work, but at least the widget may work...

With the add data widget there were lots of data-dojo-type within the templates. Remember "widgets" no longer works as a path, this is looking in the widgets folder of the WAB, not local to your widget. To fix this I ended up removing the data-dojo-type and creating the widgets within widget.js. Hoepfully you won't have to do this and it will be the simple one line fix above (because this is a nightmare)

data-dojo-type="widgets/AddData/search/ScopeOptions"

The main point is that you have to get into the mindset that everything must work relatively if you are going to host the widget for portal

Re: Enabling a Custom Geoprocessing Widget in WAB Fails

ØysteinKristoffersen — Wed, 20 Nov 2019 12:19:06 GMT

Hi, I have the exact same issue with the AddData widget. Could you possibly share your code if you managed to get it working?

Re: Enabling a Custom Geoprocessing Widget in WAB Fails

DavidWilton — Wed, 20 Nov 2019 22:58:27 GMT

Completely hacked together, but it it should work at least

Dropbox - AddDataPortal.zip - Simplify your life

Re: Enabling a Custom Geoprocessing Widget in WAB Fails

ØysteinKristoffersen — Thu, 21 Nov 2019 11:55:56 GMT

Thank you very much! I am unfortunatley not able to download the zip-file from that link. Could you try share the file again? Otherwise you could send it to my email perhaps

Re: Enabling a Custom Geoprocessing Widget in WAB Fails

DavidWilton — Thu, 21 Nov 2019 23:58:01 GMT

Sorry try again. If this doesn't work drop me a PM on linked in (I don't think you can PM on geonet?

Dropbox - AddDataPortal.zip - Simplify your life

https://www.linkedin.com/in/davidjwilton/

Re: Enabling a Custom Geoprocessing Widget in WAB Fails

ØysteinKristoffersen — Tue, 26 Nov 2019 06:50:05 GMT

I managed to download now! Thank you for helping out!

Re: Enabling a Custom Geoprocessing Widget in WAB Fails

DavidWilton — Tue, 03 Dec 2019 02:36:15 GMT

Øystein, I realised there was an issue with the NLS if you were using the "add from file" option. updated here

Dropbox - AddDataPortal.zip - Simplify your life

Re: Enabling a Custom Geoprocessing Widget in WAB Fails

Vara_PrasadM_S — Tue, 19 Dec 2023 17:45:58 GMT

Thank you very much!

It helped me a lot.

Re: Enabling a Custom Geoprocessing Widget in WAB Fails

WenhaoWu — Sun, 28 Jan 2024 01:52:48 GMT

Hi @DavidWilton thank you so much for sharing your widget code. I have the exactly the same issue and have been stuck with this for days...

Could you clarify what you did to get it to work was ONLY replacing the original "dojo/i18n!../nls/strings" to ".nls/strings" and creating local nls folders with those translation files?

Do I also need to make these two changes? If necessary, where do I look for these two places to change?

- the RecordSetEditorChooser.js: 38 change "lang.mixin(this.nls, gpNls.root)"

- data-dojo-type="widgets/AddData/search/ScopeOptions"

Many thanks!

Wen

Re: Enabling a Custom Geoprocessing Widget in WAB Fails

WenhaoWu — Sun, 28 Jan 2024 01:55:44 GMT

I reread your post and realized that the "RecordSetEditorChooser.js" was referring to the Geoprocessing widget, so that's why I couldn't find it in the AddData widget....

and the data-dojo-type="widgets/AddData/search/ScopeOptions" is something hopefully we don't need to modify, right?

Thank you!

Re: Enabling a Custom Geoprocessing Widget in WAB Fails

WenhaoWu — Sun, 28 Jan 2024 01:58:58 GMT

Also sir @DavidWilton , when you get a chance, could I possibly get your input on my process of developing and deploying a custom widget? That'd be super helpful, and many many thanks!

My process is this:

- downloaded from the ArcGIS Web App Builder SDK: https://developers.arcgis.com/web-appbuilder/guide/getstarted.htm

- went into the /server side folder and found the AddData widget folder where I need to make some changes to add a simple business logic for my use case

- tested the widget locally within the downloaded SDK/Dev Edition and it worked well

- packaged this modified AddData widget and uploaded and hosted on a Google GCP server with a Manifest JSON

- Add this widget as an App Extension using this Manifest JSON pointing to my custom AddData widget

- imported this custom widget to an existing Web map app I have on my ArcGIS Portal

- encountered the same error "ScriptError: ..../dojo/i18n!../nls/strings" (but hopefully adding local relative nls folders can work?)

Some additional tests I have done:

- I also checked my local server side widget folder, I found there are 15 Javascript files that contains this path "dojo/i18n!../nls/strings" in their define[] statement, as you had described above. I tried to replace this line with a direct URL link pointing to the strings.js file hosted on my GCP, but neither worked for my local environment or on the Portal. Another WAB out-of-box widget that contains this"dojo/i18n!../nls/strings" is the Edit widget. I even packaged this default Edit widget and tried importing it as a custom widget to my portal apps, but it gave me the same Script Error.....

Thank you!

Wen

Re: Enabling a Custom Geoprocessing Widget in WAB Fails

VLRoyrenn — Tue, 07 May 2024 21:21:51 GMT

No, it looks like an issue with the string being incorrectly built when the Dojo i18n loader is used, it's not a path resolution difference between the Enterprise portal and the developer's edition.

The ressource "dojo/i18n!../nls/strings" is supposed to resolve into something like "arcgis.example.com/widgets/AddDataStock/nls/strings.js" and the localized file "arcgis.example.com/widgets/AddDataStock/nls/fr/strings.js", with the resulting module being cached as "arcgis.example.com/widgets/AddDataStock/nls/strings.js/fr-fr". When added to n enterprise portal, however, it instead resolves into "arcgis.example.com/widgets/AddDataStock/nls/strings" when loaded by the dojo/i18n loader from a dojo module, like what the AddData and Edit widgets do. This misses the ".../strings.js/fr-fr" module already in cache and tries loading a file that does not exist. When using WAB dev edition, you'll notice no nls file gets loaded when opening either widgets, since they are loaded as the app launches.

The suggested workaround of just requiring "../nls/strings" with no i18n has the issue of completely disabling translations for all parts of the widget that loaded the strings this way, defaulting to english.

I can't say where the extra .js is normally supposed to come from (it's not the legacy loader checks, they don't run in the Dev edition anymore than in my enterprise portal). This is proving very unpleasent to debug, ans I certainly won't miss Dojo once we move to Experience Builder.

Re: Enabling a Custom Geoprocessing Widget in WAB Fails

VLRoyrenn — Wed, 08 May 2024 20:04:57 GMT

So it really looks like an interaction between the "dojo/i18n!" loader, Dojo's relative path resolution, the stock/custom widget path split in the Enterprise Portal, and possibly the _WidgetsInTemplateMixin.

Debugging imports inside minified AMD code bundles has proven frustrating enough that I'm not going to try figuring out the precise cause of the issue. I've instead completely removed all relative imports from the problematic widgets and replaced them with the likes of "dojo/i18n!widgets-custom/AddDataCustom/nls/strings" and data-dojo-type="widgets-custom/AddDataCustom/search/ResultsPane", which seems to have solved it.

I have to declare my own widgets-custom package in ArcGIS/Portal/apps/webappviewer/init.js in order to have a root location for the custom widget location in the Enterprise Portal, in my case arcgis.example.com/widgets/, so that it can be correctly resolved.

dojoConfig.packages = [{ name: "widgets", location: window.path + "widgets" }, { name: "widgets-custom", location: "//" + window.location.host + "/" + "widgets" }, { // Keep everything else the same }];

Note that dojoConfig.packages is declared in two separate locations in that file, you might need to change both.

WAB Dev edition can make a similar modification in `client/stemapp/init.js` and `server/apps/<n>/init.js` by just pointing to the same location as the widgets package, so the references are also valid there.

@WenhaoWu: That might solve your problem, in case you haven't found a workaround yet.