Latest Contributions by NicolasGIS

Hello @RajkumarPadmanabhan, Thanks for sharing these links. I would love switching from SAML to OIDC by I can't because of the following issue: https://community.esri.com/t5/arcgis-online-questions/agol-oidc-username-not-consistant-with-saml/m-p/1560118#M62451 Is it something you are aware of ? Thanks for listening ... View more

Completely agree with you ! Currently this limitation makes the integration of a small map component in a big application where the user is already logged not ideal with the only supported code flow. Specially with the new support of OIDC, if the backend application have already an IDToken for the user,  it would be nice to be able to get an ArcGIS Token by prodiving this IDToken (urn:ietf:params:oauth:token-type:id_token): https://curity.io/resources/learn/token-exchange-flow/ ... View more

Hi ! Same use case here. So far we are redirecting the user a second time to get an ArcGIS token. No need to enter credentials a second time thanks to SSO but still there an additional redirection at startup which is not ideal. Did you find a solution? I guess it would require to somehow automating the OIDC login of ArcGIS enterprise via REST call. Thanks ... View more

Hello @BanchanaPandey, Facing the same issue out of the blue after importing webgisdr site. Do you remember what was the trick with this "site key" by any chance ? Thanks ... View more

@TimHaverlandNOAA, this is a non-documented parameter so it won't be in ArcGIS API for Python. You should use tool like Postman or so, in order to make manually the POST to "importSite" with the additional parameter "mode:dr" in order to make it work. ... View more

Thanks @JonathanQuinn ! This is exactly what I was looking for. It is super useful ! Last night, while testing the new objectStore, the restore of the latter took 14 hours (cf. https://community.esri.com/t5/high-availability-and-disaster-recovery-questions/can-t-backup-arcgis-enterprise-11-4-webgisdr-since/m-p/1567875) but failed with another weird issue for ArcGIS Server (something like "ArcSOC PID XYZ not ready" or something like that). I restarted ArcGIS Server service, and run the import site operation for ArcGIS Server with "mode:dr" and Portal for ArcGIS  and it worked like charm ! I spared yet another 15 hours of my time ! I don't understand why you don't document it. Super powerful. Thanks again for sharing.     ... View more

Hello, Apologize for my late reply but tests are taking ages.... I will summarize my testings but here is my conclusion: everything seems to be working properly but it is just super long and slow. I found out that "Windows Defender" was slowing the backup down. I added exclusions to: - arcgis datastore backup folder - webgisdr temp and backup folder and after that, I was able to make a webgisdr backup... but performances are really poor compared to tileCache. Here is a quick overview: Scenario 1: ------------------- - 1 base deployment - Portal for ArcGIS, ArcGIS for Server, ArcGIS datastores (relational, tileCache, objectStore) - Windows 2022 16 CPU - 60 GB RAM deployment - Disk: 160 GB. - Attached local D drive "io3" 300MB/S and a rate of 5 IO operation per gigabyte with a guaranteed minimum of 500 IO operations and a maximum of 2000 IO operations (both, read and write)   Scenario 2 (objectStore on a dedicated VM): ------------------- - 1 base deployment - Portal for ArcGIS, ArcGIS for Server, ArcGIS datastores (relational, tileCache) - Windows 2022 16 CPU - 60 GB RAM deployment - Disk: 160 GB. - 1 datastore deployment - ArcGIS datastores  (objectStore) - Windows 2022 16 CPU - 60 GB RAM deployment - Disk: 160 GB. - Attached local D drive "io3" 300MB/S and a rate of 5 IO operation per gigabyte with a guaranteed minimum of 500 IO operations and a maximum of 2000 IO operations (both, read and write) As you can see it now takes: - 12h30 in a base deployment when webgisdr temp and backup folder can be local - 16h in a scenario with a shared webgisdr temp and backup folder (we can ignore the deletion but thought it is interesting to note that it is now taking ages as well) I am bit scared now because this ArcGIS Enterprise deployment is small. TileCache is only 27 Go. Our professional WebGIS has currently a tileCache of 110 Go and I am not sure it will fit in 24 hours. I am about to start the test. It seems to me that with the objectStore, we are retrograding back in time of BUG-000139154 BUG-000139154: https://support.esri.com/en-us/bug/tile-cache-datastore-backup-takes-too-long-and-the-data-bug-000139154 The bad piece of new is that there is only room for 1 version to fix it (11.5) !   Note that a webgisdr backup of the same site on tileCache takes only 30 minutes !   And finally to answer your question @Gaius_Kuttappan : - There is a size reduction after migration (from 27.8 Go -> 21. 4GB)  and all migrated scene layers are loading correctly - Yes, datastore are validating properly - Describedatastore: READWRITE - nothing special - Yes, full permissions correctly set. - Nothing abnormal in webgisdr logs as everything is working as expected.   Any thought @JonathanQuinn ?   Thanks ! ... View more

On our side, in the end we kept having this SMB error that we thought would be solved by removing the incorrect registered data store. We found out using "process monitor" that the SMB error was coming from ArcSoc process when starting a new soc instance. We searched everywhere for this path on ArcGIS Manager and Admin interface: could not find any mention of it. Then we checked the ArcGIS Project used for publishing and found out that this path was referenced as broken in the "Folders" list section as on the image below. We republished each service. SMB errors went away. No issue since then (10 days). To be followed. Broken path in ArcGIS Pro folders project Conclusions: - I did not think that these paths matter in the ArcGIS Pro project for publishing - The issue is still unclear to me: SMB error could occur without having necessarily a crash. - Maybe because almost all our services (50) were published with this broken path, if several of these broken services start spinning up ArcSOC processes, it could lead to it ?! ... View more

Thanks for your feedback @AndyGup . It is visible on your core samples from "js-api-resources" repository: https://github.com/Esri/jsapi-resources/tree/main/core-samples/jsapi-custom-workers Run 'npm install', 'npm run build' and serve the build. You end up with the phenomena described: many requests to individuals workers' dependencies modules. Don't need to click on "Run spatial Join" to run the custom worker. Basically, as soon as you make use of custom workers with core, you end up with the phenomena described that is to say loading all the depencies of ESRI Maps SDK workers individually (mainly FeaturePipelineWorker dependencies for simple webmap). If you compare with a CDN version of the app:   require(["esri/Map", "esri/views/MapView", "esri/layers/FeatureLayer", "esri/widgets/Legend"], (ArcGISMap, MapView, FeatureLayer, Legend) =>{ const cityLayer = new FeatureLayer({ portalItem: { id: "e39d04981238498792eb33ea26ba1c09" } }); const frsLayer = new FeatureLayer({ portalItem: { id: "cdff193a3e3743a5bc770e2743f215b3" } }); const map = new ArcGISMap({ basemap: "dark-gray-vector", layers: [cityLayer, frsLayer] }); const view = new MapView({ container: "viewDiv", map, center: [-117.98, 33.96], zoom: 12 }); const legend = new Legend({ view }); view.ui.add(legend, "top-right"); })     all the worker code is bundled in 'https://js.arcgis.com/4.31/esri/views/2d/layers/features/FeaturePipelineWorker.js'  and there much much less requests:   ... View more