OK, this is going to get rather long-winded, but if you want details, here goes:
The main form is "IT:PIQ". "PIQ" stands for "Project Initiation
Questionnaire." Customers submit descriptions of projects they want other
people to do. A manager gets appointed to oversee the project. Various
"Authorizers" get appointed to review, and either approve or reject the
project. "Resource" people get appointed to do the actual work. The
Authorizers record their decisions in an "IT:Authorization" form, and the
Resources in an "IT:Resource" form. Both of these are subfiles to the IT:PIQ
form.
Whenever anything important happens, one or more persons get email. When a
manager gets appointed to a project, the customer gets an email. If someone
approves or rejects a project the manager of the project get an email. If
someone gets appointed as a resource, that person gets an email. If the
Resource finishes her work and changes the status of the IT:Resource to
"Completed" the manager gets an email, etc, etc, etc.
What all of these emails have in common is that somewhere in the subject line
there will be the Entry ID of the IT:PIQ entry. A typical subject will say
something line "abcde has completed IT:Resource ITR00345 for PIQ PIQ00534."
On the IT:PIQ form is a diary field called "Email Log". What is supposed to
happen is whenever an email gets sent with "PIQ0..." in the subject line, the
email "To" person, the subject and the first 180 characters of the message get
written to the Email Log. So when someone says, "Nobody told me about
such-and-such" we can look in the Email Log and say, "On May 12 you got an
email that said. . ."
So I have a filter that runs on Submit on the AR System Email Messages form
whenever the Subject is LIKE "PIQ0%"
The filter:
-Gets the position in the subject string of "PIQ0"
-Takes the eight characters beginning at that position and writes the substring
into an "Other Call Entry" temporary field. The result is something like
"PIQ00534," which is the call number of the IT:PIQ.
-Concatenates the "To", "Subject" and the first 180 chars of the message into a
"Temp Char Display" field.
-Pushes "Temp Char Display" to the IT:PIQ/Email Log field where "'PIQ ID' =
$Temp Char Display$". ("PIQ ID" is the renamed "Entry ID", field 1.) This Push
Field is set to send an error if no such entry is found.
That's the process, and most of the time it works, but sometimes the filter log
shows the push happening, no error gets generated, but no value is entered into
the Email Log. And the failures don't just happen at random. They fail for
particular actions. For example, Authorizers get an email telling them that
such-and-such a PIQ is awaiting their approval. That goes into the Email Log.
But if an Authorizer approves a PIQ, an email goes to the PIQ Manager. That
does NOT go into the Email Log. The filter log is identical (except for the
wording of the message) in both cases.
The filter that sends the email has no way of knowing what process spawned the
email, so it must have something to do with the message itself. There are
obviously differences in the wording of the emails, but the overall process,
including the approximate length of the message, is the same.
One other complication: Most of the time when an Authorizer approves a PIQ it
does not get into the PIQ Email Log. But we had one incident when an
authorization did not show up in the Email Log at first. But about five
minutes later we looked, and there it was. We might have overlooked it the
first time, but there were two of us looking.
Oh, wait, another complication: I am FAIRLY sure that when I started
investigating this problem, when an Authorizer authorized a project the email
went into the Email Log, but now it doesn't. But it could be that my brain is
fried from trying to figure out all this and I am not remembering properly.
My guess is that most of you who have managed to wade thru all this are as
confused as I am. But if anyone has any suggestions on what to look for, I
would sure appreciate it.
Dwayne Martin
---- Original message ----
>Date: Wed, 12 Sep 2007 17:40:21 -0400
>From: "Joe D'Souza" <[EMAIL PROTECTED]>
>Subject: Re: Push field sometimes happens and sometimes doesn't
>To: [email protected]
>
> **
> Lets try this a little differently...
>
> What exactly are you trying to achieve
> functionality-wise.. What is your application like
> and when you insert data as a new record in your
> main form, where do you push and what do you push in
> the underlying forms?
>
> Joe
>
> -----Original Message-----
> From: Action Request System discussion list(ARSList)
> [mailto:[EMAIL PROTECTED] Behalf Of Dwayne
> Martin
> Sent: Wednesday, September 12, 2007 5:05 PM
> To: [email protected]
> Subject: Re: Push field sometimes happens and
> sometimes doesn't
>
> Thanks for the suggestions, Carey.
>
> I put "`!" after the filter name, then I ran the
> function. The log showed the push happening in
> Phase 1 instead of 2, but the value didn't appear in
> the target field.
>
> This time only one AR Systems Email Messages entry
> got created, so the workflow only happened once, but
> it didn't make the push successful.
>
> What really makes this puzzling is that many
> different functions trigger emails (and message
> entries), but the push action fail for some actions,
> but not others. Yet the push action itself has
> nothing to do with what action spawned the creation
> of the AR System Email Messages entry.
>
> Thanks again,
> Dwayne Martin
>
> ---- Original message ----
> >Date: Wed, 12 Sep 2007 16:42:15 -0400
> >From: Carey Matthew Black <[EMAIL PROTECTED]>
> >Subject: Re: Push field sometimes happens and
> sometimes doesn't
> >To: [email protected]
> >
> >Dwayne,
> >
> >Just a few guesses... ( It is very hard to tell
> without seeing all of the logs.)
> >
> >Well.. it actually could have something to do with
> it.
> >
> >What if... the ARS server is holding on to the old
> results of this SQL:
> >SELECT C536870931 [the field getting updated] FROM
> T580 WHERE C1 = 'PIQ00083'
> >
> >And using it from the first time around rather than
> the second time?
> >
> >Basically if the select is done to return the whole
> blob, and then the
> >whole blob is re-written every time, then if the
> first copy of the
> >blob is used during the second trip through the
> workflow the final
> >data would look like the first pass through the
> workflow never
> >happened. However that would be a real bug that BMC
> would have to fix.
> >
> >
> >Another possibility might be that you have a filter
> phasing issue
> >where the second push is not seeing the changes
> from the first push.
> >(Assuming your updating a record in your "diary"
> form.) If that is the
> >case try to set the filter that is doing the push
> to be non-phased and
> >see if that fixes the issue.
> >
> >
> >--
> >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 9/12/07, Dwayne Martin <[EMAIL PROTECTED]> wrote:
> >> I figured out why the filter is firing twice. We
> have a bug in our system that causes emails to be
> sent in duplicates or sometimes in triplicates. I
> knew it was happening in our live system but didn't
> realize it was happening in our test system till
> now.
> >>
> >> An event triggers an email, which spawns two AR
> System Email Messages entries instead of one. Each
> one of them pushes a value to the other form, which
> is why the workflow happens twice.
> >>
> >> Unfortunately, this has nothing to do with why
> the pushed values aren't showing up.
> >>
> >> Dwayne Martin
> __20060125_______________________This posting was
> submitted with HTML in it___
Dwayne Martin
Computing Support
James Madison University
_______________________________________________________________________________
UNSUBSCRIBE or access ARSlist Archives at www.arslist.org ARSlist:"Where the
Answers Are"
