Here is my thoughts on this. Since you know what form the Web Service is submitting to and the data you are passing in the create operation you can open the form in the User tool (use the same login and password used in the Web Service header). Turn on the Filter logging in the User Tool ( Tools -> Options -> Logging). Put in the same data you passed with the Web Service and you would then have logs to trace.
BTW: You can get to the server log files from the user tool in a couple of ways if you know the location of the files. The easiest is with the Remedy Administrator you can create a form with an attachment pool (to hold the file) and using the PROCESS command of PERFORM-ACTION-ADD-ATTACHMENT in a filter have the server store the log file into an attachment. Fred -----Original Message----- From: Action Request System discussion list(ARSList) [mailto:[email protected]] On Behalf Of grenadaguy Sent: Friday, July 24, 2009 4:58 PM To: [email protected] Subject: Re: Trying to use BackChannel (AR Mid-Tier v7.0) Jarl, I started looking at backchannel before I was made aware of Web Services and haven't spent any time on it since. So far I have not been able to get Web Services to work with the constraints I am under so really researching it has been no more productive than trying to use backchannel. It seems that out of the box Web Services is basically crippled for a non-privileged user because it doesn't provide any diagnostics in the response to tell you what is wrong with a request. If I were trying to use Web Services with, say, Amazon, would I have to be calling Amazon technical support for them to turn on diagnostics and look through logs? Wouldn't I have a clearly documented interface with a way of determining the allowed values for each field, including whether a particular field could be left empty? I don't think I have that with the Remedy installation I have here, and I would be surprised if it was changed from out of the box. Once again I am appealing for suggestions on the way forward. -- With those two document you should get a good overview of the different methods of creating integration into AR System. So, then I find it strange that you spending a lot of time trying to integrate trough an undocumenteted interface(using the backchannel method) I would go for the wget and an xml integration(soap). Since you got an resonse from the SoapUI then your on the correct path. But like others pointed out, you need acess toi turn on logs and other mechanism to pin point where the error is. (I suspect the error to be that you do not send all necesary information to create an incident) -- Jarl 2009/7/23 grenadaguy <[email protected]>: > Jarl, I've read the relevant parts of: > > White Paper > September 27, 2006 > BMC ® Remedy® IT Service Management 7.0 Integrations > > and > > BMC® Remedy® Action Request System® 7.0 > Integrating with Plug-ins and Third-Party Products > > As well as browsing through a large number of others looking in vain for > any > details of BackChannel (the latter is sort of documented in the > performance > testing document). > > Is there any other document which would be relevant to what I'm trying to > achieve? > > And would further examination of the documentation help me without your > other pre-requsite being satisfied? > > > If you trying to create and integration into AR System be sure to have > access to a person who got admin privilegies. > > Reading the documentation is also a good start. > > -- > Jarl > > > > > 2009/7/23 grenadaguy <[email protected]>: >> It almost certainly would help if I had any administrative access to the >> server, or indeed any access other than with a basic brower and user >> privileges only to open and resolve incidents, however sadly this is not >> the >> case. >> >> It seems like the diagnostics provided by Web Services out of the box are >> just as cryptic as those with BackChannel? At least with BackChannel I >> was >> able to get an incident number separately from the request that actually >> failed. Also that's a clue that getting an INC# isn't any indication of >> successful incident creation. >> >> Any suggestions where to go from here appreciated, I'm just about ready >> to >> give up. The chances of altering the configuration of the server to >> improve >> the diagnostics are next to nil (politics and beaurocracy). >> >> >> Mark, >> >> You can turn on WebService's logs on the Mid-Tier level to see some >> more details about the Web Services interactions. However, if you are >> in fact getting an Incident number back, then I would start with >> watching Server side Filter logs first. After all in order for the >> number to exist the data had to hit the DB. So it sounds like it is >> all getting there. >> >> Maybe you have a permissions problem with the incident? ( Did you try >> to find that incident as an admin user? ) >> >> Maybe there is some workflow that is also deleting the record after it >> is created? >> >> Hope that helps. >> >> -- >> Carey Matthew Black >> BMC Remedy AR System Skilled Professional (RSP) >> ARS = Action Request System(Remedy) >> >> Love, then teach >> Solution = People + Process + Tools >> Fast, Accurate, Cheap.... Pick two. >> >> On Wed, Jul 22, 2009 at 4:09 PM, grenadaguy<[email protected]> >> wrote: >>> Thanks, I got the tip to use WebServices from another source as well >>> (coincidentally including a perl script written you your good self). >>> >>> I have set up a request in soapUI and am getting a response back with an >>> incident number (below), but no ticket is created and there is no error >>> to >>> say what the problem might be (not much better than BackChannel??) >>> >>> I'm attaching the request as well. >>> >>> <soapenv:Envelope >>> xmlns:soapenv="http://schemas.xmlsoap.org/soap/envelope/"; >>> xmlns:xsd="http://www.w3.org/2001/XMLSchema"; >>> xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance";> >>> <soapenv:Body> >>> <ns1:HelpDesk_Submit_ServiceResponse >>> xmlns="urn:HPD_IncidentInterface_Create_WS" >>> xmlns:ns1="urn:HPD_IncidentInterface_Create_WS"> >>> <ns1:Incident_Number>INC000000127815</ns1:Incident_Number> >>> </ns1:HelpDesk_Submit_ServiceResponse> >>> </soapenv:Body> >>> </soapenv:Envelope> >>
