Hello everyone, Thank you for all your responses. I believe this is enough to keep me going. I will update you all with my results!! Thanks!
Mikhail On Apr 18, 10:42 am, Chris Williams <[EMAIL PROTECTED]> wrote: > Mikhail, > Also be aware that in Incident Management 7.0, there is a form called > "HPD:CFG > Ticket Num Generator". Entries are submitted here during the process for > entering > a new ticket (I believe this is after you select the customer the ticket is > for). > > To avoid unexpected behaviour of Incident Management (possible duplicate > ticket > numbers), I would think that your API must first submit a record to this form > and > retrieve the Incident Number from it (via the LASTID keyword if possible in > the API, > or by using a getEntry call), then use this value as the IncidentId to then > create > your Incident with. > > Have a look at Active link "HPD:INC:GIN_010_SetINCNumber-P", which does the > push to > this form from the "HPD:Help Desk" form. Turn on the logging during Incident > creation as Carey suggested, and you should see all of this. > > If you use the LASTID keyword value without first creating a record in the > "HPD:CFG > Ticket Num Generator", then your ticket numbers might not have an "INC" > prefix, and > might not be unique. This could lead to further problems down the line. > > HTH > Chris. > > > > > > > Mikhail, > > > I was suggesting, although not very explicitly, that you use the User > > Tool to trace the Active Links that are triggered during the create of > > a record via that client. Your API program may need to set other > > fields ( hidden to the user UI ) that correspond to the fields of > > interest. [Assigned Support Company > > (1000000251), Assigned Support Organization (1000000014), Assigned > > Group (1000000217)] The workflow log (active links, maybe filters) > > should provide the details that you need. > > > If you can find the workflow that has a message action that gives the > > error in question then you also would have a clue about the exact test > > condition that is triggering the (ARERR 44699) error message too. > > > -- > > 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 4/18/07, Mikhail <[EMAIL PROTECTED]> wrote: > >> Hello Carey, > > >> Thanks for the reply. > > >> Yes, the ARCreateEntry returns the EntryID. However, the ARCreateEntry > >> would give me an error since I did not supply a value for the field > >> Incident ID (1000000161), which is a required field. I need to fill up > >> the Incident ID field before running ARCreateEntry. > > >> As for turning an Active Link logging, I don't know if I can do this > >> in the API? I am filling in the fields: [Assigned Support Company > >> (1000000251), Assigned Support Organization (1000000014), Assigned > >> Group (1000000217)] through the API. When I submit this using > >> ARCreateEntry, I get an error saying "No groups were found using > >> automated routing. You need to manually select a group. (ARERR 44699)" > >> in the command line where I am running this C API. Now if I use the > >> User Tool, it works perfectly fine when I fill in the fields with the > >> same values as the ones I used in the C API. > > >> Mikhail > > >> On Apr 17, 4:51 pm, Carey Matthew Black <[EMAIL PROTECTED]> wrote: > >> > Mikhail, > > >> > The LASTID keyword is a way to reference the last Entry-Id (or > >> > 'Request ID') of the record that was just created. So in your C > >> > program the "LASTID" would have been returned from a ARCreateEntry > >> > call just prior to your need for the LASTID value. > > >> > As far as the second part of your original question.... > >> > I would suggest that you turn on Active Link logging and see if > >> > when you set each of the fields that you referenced [Assigned Support > >> > Company (1000000251), Assigned Support Organization (1000000014), > >> > Assigned Group (1000000217)] if active links are setting other fields > >> > with "ID" type values that map to the values that the user sees. It > >> > could explain why you get the message when you think you supplied the > >> > correct values. > > >> > You also might track down the workflow that is issuing the message > >> > and look at the Run If. It likely would also tell you what fields it > >> > ultimately cares about and help you to better understand the Active > >> > Link logs from above. > > >> > Oh.. and keep in mind that other active links (like on Submit, Loose > >> > Focus, button, etc...) could also be part of this puzzle too. You > >> > might have to trace the whole client process to create an issue to see > >> > everything you need to see. [ You might even need to trace several > >> > ticket creates due to possible variability in inputs that your script > >> > might have 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. > > > _______________________________________________________________________________ > > UNSUBSCRIBE or access ARSlist Archives atwww.arslist.orgARSlist:"Where the > > Answers > > Are" > > _______________________________________________________________________________ > UNSUBSCRIBE or access ARSlist Archives atwww.arslist.orgARSlist:"Where the > Answers Are"- Hide quoted text - > > - Show quoted text - _______________________________________________________________________________ UNSUBSCRIBE or access ARSlist Archives at www.arslist.org ARSlist:"Where the Answers Are"
