Web Appbuilder (Developer Edition) version release

CodyBarrett1

An issue we run into all of the time with WAB Developer Edition is the constant mismatching of versions from the hosted AGOL Web Appbuilder and the Developer Edition. Esri, when you release a new version of hosted AGOL Web AppBuilder, please also release the updated version of Developer Edition concurrently. We host backup applications onsite just in case AGOL can't handle the load.

MichaelRobb · ‎01-10-2017

I am voting down. Reasons:

This is not really an issue, it is a known architecture release cycle pattern.

Clarifying 3 questions about Web AppBuilder for ArcGIS | ArcGIS Blog

Why would a company structure their organizations Fail-over (DR) in the above mentioned manner? Worse yet, request ESRI to change their cycle to accommodate, "AGOL not handling the load".

Why wouldn't AGOL be able to handle the load? They use one of the largest cloud networks on the planet - Amazon, surely a larger setup than the mentioned 'onsite' where the D.R. resides. Thus, if Amazon fails to handle, quite confident the on-premise setup would cripple in seconds.

Perhaps clarification on this would be helpful

CodyBarrett1 · ‎01-11-2017

Hi Michael-

I do appreciate your response and I apologize for not clarifying more clearly. This is a known issue with Esri. We've broken AGOL three times in the last year and Esri is fully aware and understand it's an issue on their end. We have been working behind the scenes with high-level Esri employees trying to find a solution. Our interim solution was to replicate our high-availability applications from AGOL and create them using Web AppBuilder Developer Edition. This method was agreed upon by both organizations as a workaround. Obviously the issue we're having is keeping both the hosted AGOL Web AppBuilder and Web AppBuilder Developer Edition on the same version due to Esri staggering their version releases.

MichaelRobb · ‎01-11-2017

Cory,

Thanks for the response.

'breaking' is not what was originally posted. The original post describes mismatched versions. The organizations I am involved with also have many detailed complex issues with ESRI AGOL, even FME lately in December with esriFieldType changes made through the AGOL Transformer. Also we have dozens of Bugs with WABde and run both versions 2.1 and 2.2 (2.1 due to some items failing in 2.2 that was fixed in 2.1 (e.g. URL Query) and Portal. I guess I am not understanding how bugs in any environment equates to the idea that ESRI should change their known release cycle as per the original post. Further, if I understand you correctly, even if they were matched cycle versions, that they met this requirement, if AGOL was broken, then so would WABde anyways. Perhaps clarity on the 'issues' itself would be helpful, however, either it will be directly about AGOL and its contents in which case matching releases would not solve anything as merely both environments would be in a buggy state. This would also apply to PORTAL (on-premise) and Portals functions (e.g. Web App builder / Story etc) If it is regarding the constraints or even the cloud architecture, that would have nothing to do with WAB or AGOL versions but rather the architectural decisions made by your organization to go cloud vs on-premise. The decision to use cloud should have included the well known idea that ESRI would handle releases and upgrades, that also means you would be constrained to their NUMBUS/BUG FIX time cycle and existing known issues.

Alternately, the option to have on-premise would mean you could mitigate and put workarounds in place as bugs arise minimizing business operation (but requires in house resources (E.g. GIS Developer), but maintenance and upgrades would then be up to the business. I believe this is what your second response is suggesting. The huge benefit to in-premise, and how i set it up is a 3 tier deployment process. Production / (pre prod) Acceptance / DEV. Environment upgrades expose the issues coming downstream without any business impact or the need to make a panic phone call to ESRI. Again, this should have been discussed during architectural decisions to go cloud vs on-premise.

For myself there are certain larger clients I highly suggest NOT and do not implement the use of AGOL due to many constraints on the client requests. (e.g. client wants complex label expressions - not supported by AGOL / Security models etc). As well as the noted, you are confined to bugs with ESRI, then to open tickets, wait... hope they fix asap without impacting your business.

Due to no clear rebuttal, i will keep my thumb down in place.

MarkMcCart · ‎01-11-2017

This would solve a lot of issues we're having!