John,
>From your message, I am guessing that what you are trying to accomplish is the
>following (note that I have
simplified the situation to 2 forms just to get the concept across and then you
can expand it to 3 or 5 or 50
as you need).
You have 2 different forms. One for logging groceries and one for handling
automotive maintenance
scheduling. You have customers that call in and they may ask about either
groceries or about auto
maintenance. What you want is for your staff to have 0, 1, or 2 windows open
(there may be others but of
the windows related to this topic). They may have no window for either open.
Or, they may have a grocery
window open but no auto maintenance (or vice versa) or they may have both open.
When, a new call comes in, what you want to happen is for the system to
determine whether it is a grocery
or auto maintenance issue and if it is grocery, if there is no grocery window
open, open one and open the
ticket in that window. If however there is already a grocery window open, then
open the new ticket within the
existing grocery window and don't open a new window.
(we will ignore the case of whether you are working a grocery ticket in the
grocery window when the new call
comes in so that the new call will overlay the existing window.....)
(we will also ignore the issue of the fact that you are not opening a NEW
window in that window but are
really resetting a window to the new value -- UNLESS what you do is to close
the existing window of that
type and open a new one in the correct mode or what you are doing is having a
submit window of each type
and you just fill it in and hit submit and the new one just prepares for a new
submit and initializes the data
to be ready for the next submit)
Anyway, a technique to accomplish what this is talking about is the following:
1) For each type of window that you want to have one uniquely opened, create a
global variable.
2) Whenever a window of that type is opened, assign $WINDOWID$ (or whatever the
keyword that is the
window identifier) to this global variable. This field will be cleared
(set to $NULL$) On Close of this
window.
Now, you have a global variable that is available to anyone who wants that
holds the handle of the widow
so you can refer to that window.
3) Create a form that has EVERY global from EVERY window type on it that you
will use as your landing
pad from the outside. It will also have fields that are the ones that are
to be passed from the outside.
Define a format for serializing the data passed in to every type of window
or define gobals to hold data or
some way to get data passed between windows.
4) When a new call comes in and you determine the type of either groceries or
auto maintenance, gather the
data that is appropriate (if any) for that type and then call AR to open
the form you created in #3 passing
data and the type of the call.
5) The form will have workflow the runs on Loaded (because the data you are
passing in needs to arrive) that
will then take the type of window, check the appropriate global field. If
it is NULL, there is no window of
that type open and you can use an Open Window action to open it and pass
the data. If it is NOT NULL,
you have the window ID of the window that is open and you can send a signal
to that window either
passing the data you want passed or having it put into globals so that the
window can pick it up from
them (using them as registers). Each of the types of forms -- groceries
and auto maintenance in this
case -- would have active links firing on event that would prepare the
screen, parse data from the data
passed or get from the global registers into the appropriate fields and you
are good to go.
You have just accomplished either opening a window if not available or
sending data to the existing
window if it is available.
6) You have workflow at execution order 999 on the form in #3 that does a Close
Window action so that the
window for #3 never really actually opens.
7) Obviously, you just add more globals and more directions to pass the data if
you later add on pool
reservations and lunch ordering and 10 other divergent forms.
Hopefully, this gives you a picture of a possibility if you wanted to pursue it
for the type of situation you are
encountering (assuming I interpreted your situation and what you want to
accomplish correctly). Anyway,
this is an example of how to achieve the type of interaction like this.
I hope this is an interesting discussion of ways to use the features of the
system at least and maybe gives
some ideas.
Doug Mueller
________________________________
From: Action Request System discussion list(ARSList)
[mailto:arsl...@arslist.org] On Behalf Of Reiser, John J
Sent: Thursday, August 13, 2009 10:42 AM
To: arslist@ARSLIST.ORG
Subject: Re: Keeping track of Open forms.
**
I thought about that but the customized forms are so different that a unified
input process is not applicable, though we would like to work towards that type
of solution.
I'm not crazy about working a Midtier app through a view field in the WUT.
Seems like the long way around to accomplish what should be simple.
Hey BMC, Why can't the Target Location in an open window action work for the
WUT as it does for Midtier?
Current only opens the form in the same window if you use a browser. New works
for Wut and the browser.
---
John J. Reiser
Senior Software Development Analyst
Remedy Administrator/Developer
Lockheed Martin - MS2
The star that burns twice as bright burns half as long.
Pay close attention and be illuminated by its brilliance. - paraphrased by me
________________________________
From: Action Request System discussion list(ARSList)
[mailto:arsl...@arslist.org] On Behalf Of Jason Miller
Sent: Thursday, August 13, 2009 1:23 PM
To: arslist@ARSLIST.ORG
Subject: Re: Keeping track of Open forms.
** Would it be at all possible to create a single front end form and/or console
that would push/pull from the correct Help Desk form based on some field
selections?
Do you have Mid-Tier? Another idea would be to create a DO form with a large
view field and then you could load the URL to the correct Help Desk form in the
view field based on some field(s) on the DO form.
Jason
On Thu, Aug 13, 2009 at 9:24 AM, Reiser, John J
<john.j.rei...@lmco.com<mailto:john.j.rei...@lmco.com>> wrote:
**
Hello Listers,
ARS 7.1 Patch4
MS SSQL 2005
MS OS 2003 SP 2 Enterprise
We are looking for a way to assist our Call Center operators in managing
multiple Helpdesk Forms.
They have a telephone system that displays a popup identifying the name of the
Heldpesk that the customer is contacting.
The vendor assures us that the telephone tool can send keystroke commands to a
running app (ARUser) and retrieve the proper Helpdesk Form.
This would result in the same search or new window opening up each time a call
for Helpdesk A came in. The problem get compounded by Helpdesk B, C and D. Soon
we will have E & F.
Has anyone dealt with a method to keep track of the open windows in the WUT and
manage them so we don't open 99 windows in one working session?
I was thinking of using a Close Window Active Link firing on "After Submit" but
that may confuse and frustrate the Operators when the window disappears and
there is no Request ID feedback.
Thanks,
---
John J. Reiser
Senior Software Development Analyst
Remedy Administrator/Developer
Lockheed Martin - MS2
The star that burns twice as bright burns half as long.
Pay close attention and be illuminated by its brilliance. - paraphrased by me
_Platinum Sponsor: rmisoluti...@verizon.net<mailto:rmisoluti...@verizon.net>
ARSlist: "Where the Answers Are"_
_Platinum Sponsor: rmisoluti...@verizon.net ARSlist: "Where the Answers Are"_
_Platinum Sponsor: rmisoluti...@verizon.net ARSlist: "Where the Answers Are"_
_______________________________________________________________________________
UNSUBSCRIBE or access ARSlist Archives at www.arslist.org
Platinum Sponsor:rmisoluti...@verizon.net ARSlist: "Where the Answers Are"
