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: arslist@ARSLIST.ORG
> 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"

_______________________________________________________________________________
UNSUBSCRIBE or access ARSlist Archives at www.arslist.org
Platinum Sponsor: www.rmsportal.com ARSlist: "Where the Answers Are"

Reply via email to