Mark,
I already had the exact same issue on a (too) fast machine with the standard
ITSM application (change module). Here is my explanation for a change ticket
(the behaviour I noticed was by design, so I have never found a real solution).
Basically, it is due to multithreading.
The normal behaviour is the following
- Hit the save button of a change ticket
- Process the filters (phase 1)
- Commit to the DB
- Process the actions of phase2 filters
Now imagine this scenario:
During level 1 phase, you can run set action or push action (as long as the
filter name ends with `!). Imagine you push a command to the CAI. Another
thread (the CAI thread) is monitoring the CAI queue, and might execute the
command before the Commit of the normal flow. So in fact the sequence is this:
- Hit the save button of a change ticket
- Process filters of phase 1
=> Triggers push to CAI
- CAI processes command
=> Modifies something in the ticket we started with. Initial commit is
not yet executed, so filters are executed exactly as in the initial transaction
=> Commit is done for this action
=> Process phase 2 filters
- Commit is done in the DB for the initial action
- Process phase 2 filters.
In my case, my change requester sometimes received 2 notifications for the
creation of one change.
I hope this helps you a little.
Best regards,
Jean-Louis Halleux
ARSmarts Support
On 07 May 2013, at 14:46, Govind M <govind....@wipro.com> wrote:
> **
> Is there any possibility on this scenario like opening a record in two
> windows or clients. One console gets the change and triggered the filter A on
> save. And if the user tries to make the same changes in second console and
> click save. The second save will have the transaction values which qualifies
> for filter Runif to trigger. I am not sure. But it would throw an error like
> “This form was modified by another user and making changes and save would
> override it”. Pls correct me if am wrong.
>
> From: Action Request System discussion list(ARSList)
> [mailto:arslist@ARSLIST.ORG] On Behalf Of Brittain, Mark
> Sent: Thursday, May 02, 2013 7:24 PM
> To: arslist@ARSLIST.ORG
> Subject: Re: Filter - Webservice
>
> **
> Does another filter which fires before this one set field2=No? If so maybe
> the response to web service call is modifying the record, workflow sets
> field2 to No and the cycle starts over when filter A fires again.
>
> From: Action Request System discussion list(ARSList)
> [mailto:arslist@ARSLIST.ORG] On Behalf Of Govind M
> Sent: Thursday, May 02, 2013 7:51 AM
> To: arslist@ARSLIST.ORG
> Subject: Filter - Webservice
>
> **
> I have been looking into one scenario to reproduce in test env but I just
> confused more on this. It is like I have a filter with below syntax,
>
> Filter name : Filter A
> Filter runif : field1 = abdc AND field2 = No
> Actions : Set field -> field 2 = Yes
> Set field -> Trigger 3rd party webservice.
>
> After firing the filter A for first time, field2 was set to the value “Yes”
> and triggered the wbs request to a middle ware app for a record. After few
> minutes, the same request has been triggered thrice with the intervals of
> milliseconds which make me to think, after the value change in Runif field2,
> is it possible to trigger the filter again? L From the user tool wise, there
> is no track of changes in the record and we don’t have logs as well. I
> suspect this can’t be by user action, since it of milliseconds interval.
>
> Does any come across in ARS 7.1 patch 8 in solaris box.? Any solutions/
> ideas are much appreciated to reproduce/resolve.
>
> Regards,
> Govind
> Please do not print this email unless it is absolutely necessary.
>
> The information contained in this electronic message and any attachments to
> this message are intended for the exclusive use of the addressee(s) and may
> contain proprietary, confidential or privileged information. If you are not
> the intended recipient, you should not disseminate, distribute or copy this
> e-mail. Please notify the sender immediately and destroy all copies of this
> message and any attachments.
>
> WARNING: Computer viruses can be transmitted via email. The recipient should
> check this email and any attachments for the presence of viruses. The company
> accepts no liability for any damage caused by any virus transmitted by this
> email.
>
> www.wipro.com
>
> _ARSlist: "Where the Answers Are" and have been for 20 years_
>
> This e-mail is the property of NaviSite, Inc. It is intended only for the
> person or entity to which it is addressed and may contain information that is
> privileged, confidential, or otherwise protected from disclosure.
> Distribution or copying of this e-mail, or the information contained herein,
> to anyone other than the intended recipient is prohibited.
> _ARSlist: "Where the Answers Are" and have been for 20 years_
> Please do not print this email unless it is absolutely necessary.
>
> The information contained in this electronic message and any attachments to
> this message are intended for the exclusive use of the addressee(s) and may
> contain proprietary, confidential or privileged information. If you are not
> the intended recipient, you should not disseminate, distribute or copy this
> e-mail. Please notify the sender immediately and destroy all copies of this
> message and any attachments.
>
> WARNING: Computer viruses can be transmitted via email. The recipient should
> check this email and any attachments for the presence of viruses. The company
> accepts no liability for any damage caused by any virus transmitted by this
> email.
>
> www.wipro.com
>
> _ARSlist: "Where the Answers Are" and have been for 20 years_
_______________________________________________________________________________
UNSUBSCRIBE or access ARSlist Archives at www.arslist.org
"Where the Answers Are, and have been for 20 years"
