Hi Christopher,
The closed status is controlled by the HPD:Help Desk workflow itself (and NOT the SYS:Status Transition Rules table for the creation of a Closed ticket). With Meta-Update, I build a ticket and all related records (like First Response Work Info) and so on, then go back over the ticket to close it. I work directly with the HPD:Help Desk and have only briefly experimented with HPD:IncidentInterface_Create and found it's easier to do what needs doing on the form directly. Cheers Ben Chernys Senior Software Architect Description: logoSthInc-sm Canada / Deutschland Mobile: +49 171 380 2329 GMT + 1 + [ DST ] Email: Ben.Chernys_AT_softwaretoolhouse.com Web: <http://www.softwaretoolhouse.com/> www.softwaretoolhouse.com Check out Software Tool House's free Diary Editor and out Freebies Section for an ITSM 7.6.04 Forms and Fields spreadsheet. Meta-Update, our premium ARS Data tool, lets you automate your imports, migrations, in no time at all, without programming, without staging forms, without merge workflow. <http://www.softwaretoolhouse.com/> http://www.softwaretoolhouse.com/ From: Action Request System discussion list(ARSList) [mailto:[email protected]] On Behalf Of strauss Sent: June-21-12 23:37 To: [email protected] Subject: Re: IncidentInterface_Create ** Well, the integration of Kinetic Request 4.0.3.3 to Incident 7.0.02.009 via HPD:IncidentInterface_Create was still worked after upgrading to KR 5.0.3 and Incident 7.6.04.01 where HPD:IncidentInterface_Create and HPD:Help Desk are both Overlaid, so that is a good thing I think. The biggest hang-up was the glaring new error BMC introduced into the HPD:Template form, which upgraded improperly and stopped working at all. BTW, I seem to recall that we have never gotten Kinetic to create a new Incident record in a Closed status - I don't know if the limitation is in Kinetic or (more likely) in the OOTB interface between HPD:IncidentInterface_Create and HPD:Help Desk. On the other hand (like other developers), we found the HPD:IncidentInterface form for modifying existing records to be a dangerous tool, prone to data corruption and error. It was far more reliable (and safer) to create a new HPD:WorkLog record and in the process push updates directly to the associated HPD:Help Desk record. Christopher Strauss, Ph.D. Call Tracking Administration Manager University of North Texas Computing & IT Center http://itsm.unt.edu/ From: Action Request System discussion list(ARSList) [mailto:[email protected]] On Behalf Of John Sundberg Sent: Wednesday, June 06, 2012 2:04 PM To: [email protected] Subject: Re: IncidentInterface_Create ** Also, I have heard BMC say - that it is a "supported way" to push into Incident. (You can think of it loosely as an API) As in - BMC owns the responsibility from version to version - that it will work. So - if you are somebody like Kinetic - we should feel "somewhat safe" to push to incident_create and it will work from version to version. *** Side note: you may be pushing to one form (incident_create) - but it then creates records in a variety of different forms. So - yes you could do it - but you might have to do 5 pushes vs the one. -John On Wed, Jun 6, 2012 at 12:30 PM, Lyle Taylor <[email protected]> wrote: My understanding was that the primary purpose of the "interface" forms and web services was to provide a more stable integration point for custom integrations. It follows the normal interface vs. implementation paradigm. You publish an interface which establishes a contract between your system and others, and change that as little as possible. Then, you can make all the changes you want behind the scenes so long as it doesn't break the contract you have provided (the interface) with external systems. The idea then is that BMC can change the implementation details of that module without having to worry too much about breaking customer integrations if they use the provided interface. In general, my recommendation is to use defined interfaces when possible. That said, I've had numerous problems with that particular interface in ITSM 7.0. In particular there are issues around the Status Reason field. Supposedly they have been fixed somewhere along the line in 7.5 or 7.6, but I can't confirm that. There have been at least two issues with it. The first is that it's required to have a value for certain Status values, but was not included in the web service. The second issue is that something is broken in the Join form or something that causes it not to save the value correctly. It doesn't get completely ignored, but effectively gets ignored. It's aggravating - you'll see the value getting set at one point in the workflow logs, and then you see it unset again later. I remember going through the filter logs and a filter would checked twice to see if it would run. In one case, the Run If would pass, and it would run, the next time it would fail, and so it would not run. This was even though the value of the Status and Status Reason fields had not changed from one test to the next. I finally gave up on it. So, in our case, we use it, and have exposed the Status Reason field, but still have some issues around it. Other than that, it seems to work fine, though. As I said, in general, when an interface is provided I think it is best to use the interface unless you have really good reasons not to. If anything, if there is doubt, I would be looking for reasons NOT to use the interface rather than reasons TO use the interface. I'm not sure that sounds right - I wouldn't actively look for reasons not to use it - the point is, good justification should be in place if you are not going to use the interface. Justification is not required for using the defined interface. Not sure that sounded much better. Oh well... :-) Lyle -----Original Message----- From: Action Request System discussion list(ARSList) [mailto:[email protected]] On Behalf Of Longwing, LJ CTR MDA/IC Sent: Wednesday, June 06, 2012 10:24 AM To: [email protected] Subject: Re: IncidentInterface_Create So what you are saying is that I may be assuming competence where none exists? :) -----Original Message----- From: Action Request System discussion list(ARSList) [mailto:[email protected]] On Behalf Of ravi rai Sent: Wednesday, June 06, 2012 10:19 AM To: [email protected] Subject: Re: IncidentInterface_Create ** LJ i dont think it does all validation we have written lot of filter and filter guides to do validation which we needed > Date: Wed, 6 Jun 2012 10:12:56 -0600 > From: [email protected] > Subject: Re: IncidentInterface_Create > To: [email protected] > > Hey Ravi, > Yes, I'm familiar with the function of the form, but what I'm not aware of is WHY it's needed. Basic information that I have picked up over the years tells me that because of the fact that HD is VERY active link based, there are various business rules that are written and enforced when creating things through the GUI that aren't enforced when creating them through a push to the form itself. This apparently lead to the creation of the interface form to enforce the same business rules at the Filter level, and push it to the incident form when everything is copasetic....the question I'm raising is really 'what does it do'...what sort of validations does it perform that I won't get if I push directly to the incident form itself? > > -----Original Message----- > From: Action Request System discussion list(ARSList) [mailto:[email protected]] On Behalf Of ravi rai > Sent: Wednesday, June 06, 2012 10:01 AM > To: [email protected] > Subject: Re: IncidentInterface_Create > > ** > LJ , > Greetings .... > IncidentInterface_Create act as intermidiate form for landing request to create incident SRM also use this form. > webservice "HPD_IncidentInterface_Create_WS" > It works fine in 7604 not sure about 7.57 or previous version > > Ravi > > > > Date: Wed, 6 Jun 2012 11:24:52 -0400 > > From: [email protected] > > Subject: Re: IncidentInterface_Create > > To: [email protected] > > > > For whatever it may be worth, I recall problems with this form and the > > WS associated with it in its OTB state - I do not recall which version > > but it wasn't any of the most recent ones.. One of the required fields > > was missing.. I had to create that field both on the form as well as > > modify the WS to include that.. I do not recall much beyond that.. > > > > Maybe its been fixed and your problem is something else - but I just > > thought I'd throw this there.. > > > > Joe > > > > -----Original Message----- > > From: Longwing, LJ CTR MDA/IC > > Sent: Wednesday, June 06, 2012 11:18 AM Newsgroups: > > public.remedy.arsystem.general > > To: [email protected] > > Subject: IncidentInterface_Create > > > > I'm getting thrown into the deep end of ITSM and trying not to splash > > too much trying to stay afloat and would love some assistance from the > > more experienced swimmers in these waters. > > > > I'm in a situation where I'm creating incidents through a non 'gui' method. > > From discussions on the list I know that you don't want to do it > > directly into the incident form directly, and that I 'should' do it > > through the IncidentInterface_Create form...but in this situation I > > can't. I'm looking for either guidance to documentation that discusses > > the interface form, and what it does for me, or either straight from > > the horses mouth information about the things I need to look out for > > when loading these directly in the table. One thing that may be > > important...the records that I'm creating don't need to 'flow' > > anywhere....they are being created strictly from a historical perspective and will be created already in the 'Closed' status. > > > > Remedy 7.5 Patch 7 > > ITSM 7.5 > > > > ______________________________________________________________________ > > _________ UNSUBSCRIBE or access ARSlist Archives at www.arslist.org > > attend wwrug12 www.wwrug12.com ARSList: "Where the Answers Are" > > _attend WWRUG12 www.wwrug.com ARSlist: "Where the Answers Are"_ > > ____________________________________________________________________________ ___ > UNSUBSCRIBE or access ARSlist Archives at www.arslist.org > attend wwrug12 www.wwrug12.com ARSList: "Where the Answers Are" _attend WWRUG12 www.wwrug.com ARSlist: "Where the Answers Are"_ ____________________________________________________________________________ ___ UNSUBSCRIBE or access ARSlist Archives at www.arslist.org attend wwrug12 www.wwrug12.com ARSList: "Where the Answers Are" NOTICE: This email message is for the sole use of the intended recipient(s) and may contain confidential and privileged information. Any unauthorized review, use, disclosure or distribution is prohibited. If you are not the intended recipient, please contact the sender by reply email and destroy all copies of the original message. ____________________________________________________________________________ ___ UNSUBSCRIBE or access ARSlist Archives at www.arslist.org attend wwrug12 www.wwrug12.com ARSList: "Where the Answers Are" -- John Sundberg Kinetic Data, Inc. "Your Business. Your Process." WWRUG10 Best Customer Service/Support Award WWRUG09 Innovator of the Year Award 651-556-0930 I [email protected] <http://www.kineticdata.com/> www.kineticdata.com I <http://community.kineticdata.com/> community.kineticdata.com _attend WWRUG12 www.wwrug.com ARSlist: "Where the Answers Are"_ _attend WWRUG12 www.wwrug.com ARSlist: "Where the Answers Are"_ _______________________________________________________________________________ UNSUBSCRIBE or access ARSlist Archives at www.arslist.org attend wwrug12 www.wwrug12.com ARSList: "Where the Answers Are"
<<image003.jpg>>
smime.p7s
Description: S/MIME cryptographic signature
