I would even go so far as to advocate that the interface should be independent of the OOB stuff.
So while the OOB application my have a web service that could work with the current application. There simply is no contract/expectation that the WebService will not change during a patch to the application or an upgrade of ARS. By using a separate form/application you are insulated when the OOB stuff changes and you have a chance of adding additional workflow/corrections to the interface to map it to the "new OOB" application. (And if you are real lucky.. not have to change the "non-ARS" side of the integration at all.) However, to the specific concerns of "transaction control, retries, log or any other type of control." Transaction control.... well.... that is a bit hard to address unless your a bit more specific. It is the responsibility of the WS client to complete the WS call. (And retry, or error if needed.) But you likely are asking about more of a "transaction broker" that will accept the WS request and then turn around and be the real WS client and deal with all of the retry/error/reply stuff asynchronously. ( I believe those features go beyond the standard WS design and are not even targeted in the ARS WS universe for either publishing nor consuming.) You could write your own broker, but that seems silly to me. You could do a kind of "DSO" design where you have consuming requests entered into an ARS form that you have an external process poll and process. The processing may then update the parent in a determined way to complete the processing of the request. However for the publishing side... ARS WS are just not alterable. You could write your own WS and use ARS API behind them if you wanted to. (But that is likely more work than you want.) I think "Logs" should be possible, but you may need to look at API logs to see some of what you might find useful. ( And likely Plugin Server logs too.) HTH -- Carey Matthew Black Remedy Skilled Professional (RSP) ARS = Action Request System(Remedy) Love, then teach Solution = People + Process + Tools Fast, Accurate, Cheap.... Pick two. On Wed, May 28, 2008 at 11:09 AM, strauss <[EMAIL PROTECTED]> wrote: > We don't use web services at all so are not familiar with that > particular problem, but we found the same limitations that you did with > the HPD:IncidentInterface form when integrating Kinetic Request. We > learned that we have to set Kinetic to create HPD:WorkInfo entries > directly, and then used custom filters to make specific changes to the > Incident record without going through the HPD:IncidentInterface join > form. We implemented customer ability to update an incident, close an > incident, or reopen an incident in this way, adding a few custom fields > for action flags to the HPD:WorkInfo form. HPD:IncidentInterface is just > too cumbersome to work with, as you have seen, and the bizarre design of > it _promotes_ data corruption. > > If you are trying to push a consolidation of data out through web > services, my bet would be that you will need to create custom join > forms, similar to what you would build to support custom reporting, that > contain all of the data that you want to push out to the web service > interface. You then can build any custom workflow that you want against > the custom join form to control your output to the web services. > > Christopher Strauss, Ph.D. > Call Tracking Administration Manager > University of North Texas Computing & IT Center > http://itsm.unt.edu/ > >> -----Original Message----- >> From: Action Request System discussion list(ARSList) >> [mailto:[EMAIL PROTECTED] On Behalf Of renato.fichmann >> Sent: Wednesday, May 28, 2008 12:15 AM >> To: [email protected] >> Subject: Web Services XML Questions - Very Interesting Implementation >> >> Hi Guys, >> I have a ITSM7 / ARS 7 system and we'd like to heavily use the web >> services interface to connect our Remedy infrastructure to several >> different systems such as alarm systems, other ITSM solutions, CRM >> based application among others. >> >> We've faced several limitation in regarding Web services, BMC is >> giving us some options around 3rd part applications in between, which >> is not the best solution at the moment. The issues are: >> >> 1. When the consumer system updates only some fields, like incident >> status through the out of the box webservices interface and form, >> Remedy set the other fields as NULL. This documented limitation forces >> the interface to either populates all the fields in the incident form, >> even if they are only changing a single field, or find an alternative >> solution. >> >> 2. In the other direction when pushing content to a provider, the >> requirement is to send more than just the incident related fields, but >> also the CIs related and some additional related subforms. The out of >> the box solution doesn't care about transaction control, retries, log >> or any other type of control. >> >> Have you guys experimented any of these situations in your >> infrastructure? What about the high level solutions for these demands? >> >> Regards, _______________________________________________________________________________ UNSUBSCRIBE or access ARSlist Archives at www.arslist.org Platinum Sponsor: www.rmsportal.com ARSlist: "Where the Answers Are"
