Shafqat, I understand the problem at hand. But I have to question only one part of your explanation:
"
in the olden days since it was being done via SQL there could be a delay of upto 30 to 40 minutes before the new entry showed up(sometimes, but it had happened).
" Given what I know of how the ARS server Push action works. I can not imagine that under a normal operating condition (barring bugs in the design implementation) that even a delay of 1 minute would be possible. Now if your actually using an Escalation to create the "consolidated" record then I can see how such a delay would be possible. But that seems like a poor way to design this feature in my mind. As Michiel pointed out, use Push actions from Submit and Modify to create/update/remove these consolidated records and the timing should be almost instantaneous to the action done on the "source" records. -- Carey Matthew Black Remedy Skilled Professional (RSP) ARS = Action Request System(Remedy) Solution = People + Process + Tools Fast, Accurate, Cheap.... Pick two. Never ascribe to malice, that which can be explained by incompetence. On 5/5/06, Shafqat Ayaz <[EMAIL PROTECTED]> wrote:
** Hi Carey I agree with your post, but here is the situation, maybe it will make a little bit more sense. Say we have a company, which has a helpdesk, they are using a solution developed specifically for them, so it is not an Off the Shelf product. the way the original system was designed, rather than consolidating all the diverse requirements into some sort of coherent form, they decided to develop a different form for each ticket type, there are at least 20 odd types, so that gives you 20 forms to start with, now each form can also have child tickets, for which they have separate forms, so that makes it 40 forms altogether, plus a few other types of tickets. So you have roughly say, around 45 to 48 forms. Now each form has a lot of tickets logged to them each day, also creating a vast number of child tickets. Most technicians work with around 8 to 10 ticket types, but the higher level ones might be working with tickets from diverse ones and concievably either all or most of them. so the first issue is how to show all the tickets in the system, where a user might only want to see for example tickets from 10 or 15 types, but depending on each tech. they will be different forms, or the 2nd line or 3rd line might want to see tickets from all the forms, they might be new tickets, open tickets or assigned tickets and so on and so forth. Re-designing or re-writing the app at the moment is not an option. so it comes back to my quandry, how to show maybe upto hundred of thousand tickets(even if they are only open ones!) and how to constantly keep the list updated, because the tickets might have an SLA ranging from 10 minutes to days. So say even if i filter the tickets, I still have to show tickets from 45 plus forms into a consolidated view. The current solution, have a separate form, each time a ticket is created anywhere on the system, an entry is created in this form, showing the main details, the user can then click on the ticket nr and see the ticket. the problem with this solution, the consolidated form can have thousands of open tickets or tickets being worked on, plus everytime a new ticket is created an entry is created in this form, and depending on how many new tickets are being created, there is a time lag, because of the sheer number of tickets being created at any one time. in the olden days since it was being done via SQL there could be a delay of upto 30 to 40 minutes before the new entry showed up(sometimes, but it had happened). now if you have a SLA of 10 minutes, you failed your SLA even before you knew there was a ticket logged!! now with improved hardware and optimization, this delay has come down, but still not enough for some tickets and some peak times. so a double problem how to create tickets fast enough and how to show them fast them enough!! sorry for such a long explanation, but to understand the problem fully i think it was the right thing. kind regards shafqat Carey Matthew Black <[EMAIL PROTECTED]> wrote: Shafqat, I will only try to address this one part of your questions: "and how to display something like a half million tickets intelligently?" There are exactly zero known ways to do this in a tabular form. (Which is the best a table field in ARS can do for you.) There are ways to build summary reports. However, most of those are still not "intelligent" when your dealing with that kind of volume. Most humans can only really focus on a few simultaneous things at a time. Anything over say a couple of hundred (semi-simultaneous things) is well beyond most peoples abilities. Spend your efforts trying to figure out what the users want and why they think they want it instead of working on a performance/technical issue. They will be much happier with the results. Even though you likely will have to drag them kicking and screaming to the final solution. Good luck. -- Carey Matthew Black Remedy Skilled Professional (RSP) ARS = Action Request System(Remedy) Solution = People + Process + Tools Fast, Accurate, Cheap.... Pick two. Never ascribe to malice, that which can be explained by incompetence. Shafqat Ayaz
_______________________________________________________________________________ UNSUBSCRIBE or access ARSlist Archives at http://www.wwrug.org
