Rabi,

The logic is actually wrapped up in a set of functions.  In my post I
used the word "function" just to make it more clear to convey the
approach.  It could have been programmed into a single function but, at
least to me, was quicker to write this way and easier to maintain.  Here
are the details of how it works.  It actually was much easier to program
than I had thought before starting.

There is a main function that is called by Remedy to obtain the
auto-assignee.  When calling, I pass in the request type (HD, CHG, TSK),
also with CTI and RSD.

This main function begins calling each of the 15 possible matches
(Weighted by Remedy as 1-15).  Here is a snippet from the comments in
the function:

/*
Example: SELECT dbo.fnAutoAssignment('HD', '$Category$', '$Type$',
'$Item$', '$Region$', '$Site$', '$Department$')

Level   Fields 
1       Category, Type, Item, Region, Site, Department 
2       Category, Type, Item, Region, Site     
3       Category, Type, Item, Region   
4       Category, Type, Item   
5       Category, Type 
6       Category, Region, Site, Department     
7       Category, Region, Site 
8       Category, Region       
9       Category, Type, Region, Site, Department       
10      Category, Type, Region, Site   
11      Category, Type, Region 
12      Category       
13      Region, Site, Department       
14      Region, Site   
15      Region
*/

If level 1 does not match then I check level 2, then level 3, etc.,
until I find a match.  If nothing matches then the default assignee from
ASN:Process is returned.  Each of the 15 functions [that correspond to
the 15 levels] perform SELECTs on the SHR:Assignment form based on the
possible combinations of CTI and RSD. These functions are small and are
almost identical.  I haven't time it but I am almost certain that
calling this function is as fast or faster than processing a bunch of
filters.

At my company we are not auto-assigning tickets based on workdays or
holidays, so that was not programmed.  If ever needed it could be
quickly added. 

In most situations programming in Remedy (eg. Filters) is the best
method.  For certain situations where precise control or formatting is
required I find using SQL is better.  I really like only making 1 call
to a function instead of 200 filters :)

Side note: 
For those that also know traditional programming languages, this project
reminded me of when, as a new programmer, your assignment was to write a
calculator program.  Everyone knew was it was supposed to do but trying
to program it took some thought.  Like the calculator, I enjoyed writing
it.

Stephen

 

-----Original Message-----
From: Action Request System discussion list(ARSList)
[mailto:[EMAIL PROTECTED] On Behalf Of Rabi Tripathi
Sent: Friday, May 12, 2006 11:52 AM
To: [email protected]
Subject: Re: Possibility of additional parameters with Skills in
addition to CTI and RSD

--- "Heider, Stephen" <[EMAIL PROTECTED]> wrote:
> Tarun,
> After
> creating a number of
> test tickets just to see who got auto-assigned I decided to create a 
> SQL function that would show me what I wanted without creating 
> tickets.

It is quite a feat to code the entire logic of 200 autoassignment
filters in a single sql function as you have done. I am wondering if it
does exaclty what the filters do--take into account info on ASN:Process,
Business Time Workdays and Business Time Holidays forms as well as loop
around to find progressively less specific records on SHR:Assignment? 

-Rabi Tripathi

__________________________________________________
Do You Yahoo!?
Tired of spam?  Yahoo! Mail has the best spam protection around
http://mail.yahoo.com 

________________________________________________________________________
_______
UNSUBSCRIBE or access ARSlist Archives at http://www.wwrug.org

_______________________________________________________________________________
UNSUBSCRIBE or access ARSlist Archives at http://www.wwrug.org

Reply via email to