I very rarely show system messages to the end user. What makes sense from a technical perspective very rarely makes sense to an end user.
SOAP Services are automated and it makes sense for Remedy to send errors the way it does. Generally, in whatever application I'm putting together I will have a generic error handler. Within that error handler there is logic that does 4 things: 1) translates expected error messages to something the user will understand. 2) formats error messages in a manner that works with my end user interface 3) logs the error 4) attempts error recovery and failing that presents the error to an end user. You'll get errors form the SOAP library you are using (things like XML invalid, destination server unavailable), from Remedy (database timeout, password invalid, plugin server not available), and from the application (must select item from menu, people record not found). Every interface is going to have to deal with those errors as cleanly as possible. For out of service, there are a few things you can do. 1) You can flag your app to use an alternative server, and barring availability: a) store requests and forward them when availability has returned b) alert your end users with a banner that says some functionality is not currently available c) alert end users interactively when they run into problems d) bring your application into a not-available state 2) You can alert appropriate staff. a) by creating an incident b) by sending an SMS Message c) by sending an email d) by adding a log entry Also for out of service, there are usually expected down times for maintenance, upgrades, and whatnot. Pro-actively addressing that is obviously a good idea. Sometimes it's on a schedule, sometimes you can get the information from a monitoring system, sometimes you can get it directly from Remedy. Have a look at: http://php.net/manual/en/language.exceptions.php Using try/catch will allow you to intercept the SOAP errors before they get to your end user. You'll have something like: try { doTheSOAPThing($data); } catch ($e) { raiseThePitchForks($e); echo humanFriendly($e->getMessage()); } There are php.ini settings that will hide error messages from end users. Typically, I will show error messages in development and hide them in production. That prevents unexpected library errors from reporting too much about your environment. http://www.php.net/manual/en/errorfunc.configuration.php#ini.display-errors A lot of library based errors will hand over information that you don't necessarily want made public. Like the name of your database server or user, installation paths, addresses of internal servers, etc. On Tue, Mar 5, 2013 at 8:49 AM, L G Robinson <n...@ncsu.edu> wrote: > ** > Hi Fred, > > Thanks for your reply. In testing with my dev server, I find the following: > > SoapUI says: > > <soapenv:Fault> > <faultcode>soapenv:Server.userException</faultcode> > <faultstring>ARERR [90] Cannot establish a network connection to > the AR System server : Connection refused my_ars_server:33000</faultstring> > <detail> > <ns1:hostname xmlns:ns1="http://xml.apache.org/axis/";> > my_ars_server.ncsu.edu</ns1:hostname> > </detail> > </soapenv:Fault> > > In the #status# header I see: HTTP/1.1 500 Internal Server Error > > > A PHP program calling a web services says: > > An error occurred while getting the call: SOAP Error: ARERR [90] Cannot > establish a network connection to the AR System server : Connection refused > my_ars_server:33000[locutus:~/MyRemedyPHP_API] > > So I guess this is ok in the sense that the PHP recognizes this as a > failure. I was just curious if anyone was doing anything different to > provide anything more informative. > > Thanks. > Larry > > > On Mon, Mar 4, 2013 at 2:33 PM, Grooms, Frederick W < > frederick.w.gro...@xo.com> wrote: > >> ** >> >> If the ARS Application is down doesn’t the Web Service call result in a >> SOAP Fault with an Unable to connect to server error?**** >> >> ** ** >> >> Fred**** >> >> ** ** >> >> *From:* Action Request System discussion list(ARSList) [mailto: >> arslist@ARSLIST.ORG] *On Behalf Of *L G Robinson >> *Sent:* Monday, March 04, 2013 1:28 PM >> *To:* arslist@ARSLIST.ORG >> *Subject:* Best way to "out of service" a Mid-tier server**** >> >> ** ** >> >> ** **** >> >> Hi Folks,**** >> >> ** ** >> >> Recently, my DBAs migrated my Remedy Oracle DB to new hardware. This >> activity necessitated an extended outage for my users. Typically, when my >> system will be unavailable for an extended period, I install temporary >> replacements for some HTML and JSP pages so that I can display information >> about the outage and point to status pages, etc.**** >> >> ** ** >> >> For my Mid-tier users, I usually replace the index.html file in the >> Tomcat "webapps/ROOT/" directory and I also replace the >> "webapps/arsys/shared/login.jsp" page with a redirect to an information >> page. This all works well.**** >> >> ** ** >> >> My question is about the Mid-tier servers that we have designated as part >> of a pool of servers dedicated to responding to web service requests. Since >> there may or may not be a person sitting in front of a browser for these >> servers, I'm looking for suggestions on the best wat to "out-of-service" >> the web service Tomcat servers. The web services might be called by a PHP >> web page or they might be called by an automated process using a Perl or >> PHP script. I want to fail in such a way that the user (person or script) >> knows that it failed and also provide useful information about why it >> failed. Any suggestions?**** >> >> ** ** >> >> ARS: 7.6.04 SP3 201201302357**** >> >> Oracle: 11.2.0.3.0 - 64bit**** >> >> Mid-Tier: 7.6.04_SP3_201208101612_Hotfix**** >> >> Tomcat: 6.0.35**** >> >> JAVA: 1.7.0_05**** >> >> ** ** >> >> Thanks.**** >> >> Larry**** >> >> ** ** >> >> Larry Robinson**** >> >> Remedy Developer / Administrator**** >> >> North Carolina State University**** >> >> Raleigh, NC USA >> > _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"
