Cutting support for the WUT was simply not the right move. Look at a company like Cherwell that supports a fat client. They freely admit that there are some features such as dashboards and stuff that are only available to the web client. However, there are some functions that are just simply easier to do within a fat client than trying to funnel your user base into a web client. Not to mention that the web client was awful and the software was not truly written to be fully consumed via the web client only... Even with v9, there are some functions that are just clunky via the web and would be much easier using a fat client. Not sure why companies in general take a stubborn stance on things sometimes. On a lighter note, happy holidays people!
Sent from my iPhone > On Dec 26, 2015, at 9:33 AM, Rick Cook <remedyr...@gmail.com> wrote: > > ** > I find it quite useful when doing large data import tasks with modify all > functions and all. Why run all that traffic through the Mid-tier layer for > an administrative function? > > Rick > >> On Dec 26, 2015 5:02 AM, "JD Hood" <hood...@gmail.com> wrote: >> ** >> Hi Doug, >> >> Perhaps BMC should investigate *why* folks are still clinging to the User >> Tool. >> >> What functionality does it provide that is missing in the web client? >> Identify it and where technically possible, add that functionality to the >> web client. Then the *need* (if not desire) for the User Tool will likely >> dissipate. >> >> For me, the main issue with the web client is ad-hoc reporting. To export a >> standard Remedy .arx file for most any ITSM form (or other form with a >> gazillion fields) is not feasible. That "arsystem" arx export functionality >> *desperately* needs an "add all fields" button to make it easier (humanly >> possible?) to move record(s) out of a given system for purposes of testing, >> development, personal backup, etc. >> >> But that's just my pet "missing User Tool feature" in the post version 8x >> world. I know others have voiced different "missing User Tool features" >> around these parts. BMC might want to look into it. >> >> Now, I haven't had an opportunity yet to see what v9x Mid Tier brings in >> this regard, so if BMC has now accounted for my pet issue, then as far as I >> am concerned... um... nevermind. :-) >> >> Thanks! >> -JDHood >> >> >>> On Fri, Dec 25, 2015 at 9:32 PM, Mueller, Doug <doug_muel...@bmc.com> wrote: >>> Everyone, >>> >>> Just to be clear here and reinforce some things that have been mentioned. >>> >>> One commitment we have is compatibility with our API/interfaces. We want >>> to be sure that if you have written a program to the system on any version >>> of the server, that it will continue to work on future versions of the >>> server. >>> >>> In this case, there was an api function -- Export specifically -- that had >>> a problem with an export format in that it put a name in that format that >>> was not able to be properly processed by an existing API program that used >>> that operation. This issue was corrected. >>> >>> Now, the fact that in this case the API program was the Windows User Tool >>> is not the major issue. It is an API program that stopped working because >>> of an issue with the API producing data in a compatible way so that the >>> existing functionality of a tool would continue to work. So, the server >>> was corrected to maintain the compatibility of the API. >>> >>> You will find that we have always been committed to this compatibility. >>> Occasionally, there is a miss somewhere -- as in this case -- and that miss >>> is corrected. >>> >>> This commitment is important for anyone who wants to produce an integration >>> or interaction with the system. It means that as the server is upgraded, >>> there is no requirement to change the integrations/executables as they >>> should continue to work. Generally, this is true. It allows you to mix >>> and match versions of executables, mid-tier, applications, and server. >>> >>> NOTE: There is no magic here. The older executable does not suddenly >>> inherit new functionality. And, when you upgrade to using a new API, the >>> program may need to be updated to react to changes in the API/interface. >>> But, while continuing to use the older API for that program (even if other >>> programs are using the newer API), you can continue without having to >>> rebuilt right away. >>> >>> If you ever see an API incompatibility causing issues across versions, >>> please let us know right away. >>> >>> Doug Mueller >>> >>> -----Original Message----- >>> From: Action Request System discussion list(ARSList) >>> [mailto:arslist@ARSLIST.ORG] On Behalf Of Misi Mladoniczky >>> Sent: Saturday, December 19, 2015 12:55 AM >>> To: arslist@ARSLIST.ORG >>> Subject: Re: Something to be aware of - the User Tool cannot work with >>> overlaid forms on a 9.0 server - FIXED >>> >>> Hi, >>> >>> I think it is great news. >>> >>> Note that they fixed the AR Server rather than the User Tool. >>> >>> This was clearly a bug on the server side, as the server did not comply to >>> the way the older API worked. The client sends it's API-version along with >>> the call to the server, and the server is supposed to talk back to the >>> client with that same version of the API. >>> >>> I see very few who use ARUser.exe as main access to the AR Server nowadays, >>> but to look at and add/change core/foundation data it is very useful. >>> >>> Best Regards - Misi, RRR AB, http://www.rrr.se (ARSList MVP 2011) >>> >>> Ask the Remedy Licensing Experts (Best R.O.I. Award at WWRUG10/11/12/13): >>> * RRR|License - Not enough Remedy licenses? Save money by optimizing. >>> * RRR|Log - Performance issues or elusive bugs? Analyze your Remedy logs. >>> Find these products, and many free tools and utilities, at http://rrr.se. >>> >>> > I was thinking the same thing. This is a dangerous precedent. Just as >>> > people are finally accepting WUT is dead it gets some new life (not >>> > that I am going to complain). >>> > >>> > Although thinking about it a little more... there are a number of >>> > tools that BMC doesn't officially support but do maintain. Looks like >>> > WUT might fall into this class now? >>> > >>> > On Fri, Dec 18, 2015, 12:48 AM Thomas Miskiewicz <tmisk...@gmail.com> >>> > wrote: >>> > >>> >> ** >>> >> Thanks for the update Mark. I thought the User Tool is dead. >>> >> >>> >> On 18 Dec 2015, at 09:45, Walters, Mark <mark_walt...@bmc.com >>> >> <mark_walt...@bmc.com>> wrote: >>> >> >>> >> ** >>> >> >>> >> *UPDATE – this was fixed in the 9.0 SP1 server – the User Tool can >>> >> use overlaid forms again.* >>> >> >>> >> Knowledge Base article KA427109 >>> >> <https://kb.bmc.com/infocenter/index?page=content&id=S:KA427109> >>> >> >>> >> Some changes in the server in version 9.0 mean that the User Tool is >>> >> unable to work with overlaid forms. Searches, creates and modifies >>> >> result in a 303 Form does not exist on server error as the client >>> >> references the form name with the __o extension which the server does >>> >> not recognise. >>> >> >>> >> Mark >>> >> >>> >> *Knowledge Article ID:* >>> >> >>> >> KA427109 >>> >> *Version:* >>> >> >>> >> 0.1 >>> >> *Available To:* >>> >> >>> >> External >>> >> *Status:* >>> >> >>> >> Unpublished >>> >> *Updated:* >>> >> >>> >> 06/15/2015 >>> >> >>> >> >>> >> >>> >> *Problem* >>> >> >>> >> The Remedy User Tool client is unable to create records or perform >>> >> searches when using overlaid forms from an ARS 9.0 server. The form >>> >> can be opened but any other operations result in an ARERR 303 Form >>> >> does not exist on server error. >>> >> >>> >> *Solution* >>> >> >>> >> This is due to changes in the way overlays are stored in the 9.0 >>> >> metadata. The __o extension is no longer used but the .arf form >>> >> definition which is exported by the server, and used by the User >>> >> Tool, still includes it. The client tries to use the form name from >>> >> the .arf file when sending API calls to the server but the server >>> >> does not recognise the name and returns the 303 error. >>> >> >>> >> A defect has been created to track this (SW00490959) but, as the User >>> >> Tool is no longer supported, it is not clear whether this will be >>> >> addressed. >>> >> >>> >> >>> >> ------------------------------ >>> >> *Mark Walters* >>> >> Lead Technical Support Analyst >>> >> *Direct* >>> >> >>> >> +44 (0)118 921 8379 >>> >> >>> >> >>> >> >>> >> E2 >>> >> Eskdale Road >>> >> Winnersh, RG41 5TS >>> >> UK >>> >> <image001.jpg> <http://www.bmc.com/> >>> >> >>> >> >>> >> >>> >> BMC Software Limited Registered Office: Building E2, Eskdale Road, >>> >> Winnersh, Wokingham, Berkshire, United Kingdom, RG41 5TS Registered >>> >> in England No. 1927903 The content of this email is confidential. If >>> >> you are not the addressee, you may not distribute, copy or disclose any >>> >> part of it. >>> >> If you receive this message in error, please delete this from your >>> >> system and notify the sender immediately. _ARSlist: "Where the >>> >> Answers Are" and have been for 20 years_ >>> >> >>> >> _ARSlist: "Where the Answers Are" and have been for 20 years_ >>> > >>> > ______________________________________________________________________ >>> > _________ UNSUBSCRIBE or access ARSlist Archives at www.arslist.org >>> > "Where the Answers Are, and have been for 20 years" >>> > >>> >>> _______________________________________________________________________________ >>> UNSUBSCRIBE or access ARSlist Archives at www.arslist.org "Where the >>> Answers Are, and have been for 20 years" >>> >>> _______________________________________________________________________________ >>> UNSUBSCRIBE or access ARSlist Archives at www.arslist.org >>> "Where the Answers Are, and have been for 20 years" >> >> _ARSlist: "Where the Answers Are" and have been for 20 years_ > _ARSlist: "Where the Answers Are" and have been for 20 years_ _______________________________________________________________________________ UNSUBSCRIBE or access ARSlist Archives at www.arslist.org "Where the Answers Are, and have been for 20 years"
