Hi Misi,
Thanks for the explanation. Now that re-read the original posting I realize
I went off on a bit of a tangent. I though you had an error handler filter
involved, the commit was happening anyways and I went down that path (what
can I say, it has been bugging me for a while). I must have mixed up your
question with part of Roberts answer where he mentions error handling :)
I agree the error handing is ideal for customizing error messages. I have
been trying to use it more for integration error handling where there is not
an end users to receive the message and branch off down an alternate path.
It still works for what we are doing it just takes a bit of planning and
pre-checking.
Your recommendation about using a Service may do exactly what we want. That
is if it is working as designed.
Thanks!
Jason
On Mon, Mar 14, 2011 at 10:53 PM, Misi Mladoniczky <m...@rrr.se> wrote:
> Hi,
>
> I have used error handling filters extensively in the following way:
>
> 1. create two display-only-fields:
> - errorhandler errno
> - errorhandler text
>
> 2. create two error handler filters
> - errorhandler Message error
> run if: ('errorhandler errno' = $ERRNO$)
> action: message error: $errorhandler text$
> - errorhandler Message warning
> run if: ('errorhandler errno' = $ERRNO$)
> action: message warning: $errorhandler text$
>
> The idea is to give better feedback to the user, and either stop (error)
> or allow (warning) the transaction to the database.
>
> 3. filter that can fail
> error handler: errorhandler Message warning
> action 1: set-fields current transaction
> errorhandler errno = 380
> errorhandler errno = "The customer " + $Customer$ " was not found, and
> the customer field has been cleared"
> action 2: set-fields from form Customer ('Customer' = $Customer$)
> if no records match: error
>
> This will allow very flexible functionality I think.
>
> Now back to your problem.
>
> With the new non-transactional-filter-service-call, you could do something
> like this:
>
> errorhandlerfilter
> action 1: call service: push the error handler ticket (invalid CTI
> combination, ...)
> action 2: message error: transaction stopped due to ...
>
> Then create the service that does the actual pushing:
> service filter:
>
>
>
> > I have the same trouble with the error handler feature. I was so excited
> > when it was introduced but then realized it wasn't exactly what I wanted
> > it
> > to be once I used it. It seems you still need many filter qualifications
> > to
> > account for all of the different situations that will cause an error in
> > your
> > process.
> >
> > For example we have a custom db table where records are inserted and an
> > escalation touches the new records using a Vendor Form to bring them into
> > ARS processing (filter pushes them to a Help Desk ticket). There are a
> > number of errors that can occur: invalid CTI combination, invalid Region,
> > Site, Department combination, missing Region, Site or Department, etc.
> > When
> > this happens we want a ticket created to review and correct the record so
> > it
> > can be processed for the customer. When we initially created the process
> > we
> > though if the push fields fails say because a require field on the
> > destination form is missing then our error handler field would create the
> > ticket to research the failure and processing would stop after that.
> This
> > statement is where our idea fell flat:
> >
> > Pg 165 of 7.5 Workflow Objects Guide
> >
> > "When all the If actions of the error handling filter complete
> > successfully,
> > *the error is considered handled*, the error information and keyword is
> > cleared, and the filter in which the error occurred continues execution
> > with
> > the next action. If another error occurs during the execution of the
> > filter,
> > the error handler is executed again."
> >
> > In our initial development attempt would end up with a ticket to research
> > the error and a ticket missing the required field(s) (who knew that was
> > possible, they are required). So then the though was to throw an error
> in
> > the error handler after the research ticket push fields but then entire
> > transaction rolled back and neither tickets were created just as if we
> > didn't even have the EH.
> >
> > We ended up having our push fields filter still evaluate that all of the
> > requirements were met in the qualification. At the very end if the
> source
> > record status is still "New" (would have been set to "Processed" if
> ticket
> > was created) then we assume an error has occurred, set the status to
> > "Error"
> > and create a ticket to research.
> >
> > Another similar process on a web service integration form varies a little
> > bit by throwing an error if a pre-check fails (CTI, RSD, item # not in
> the
> > catalog). The error handler is called and sets the status field to
> > "Error". The pre-checks continue since the error was "handled" and
> > concatenates the $ERRMSG$ and $ERRNO$ to a character field that is
> > returned
> > in web service. All of the filters that do push fields do not fire if
> > 'Status' = "Error".
> >
> > In both situations we need to figure out all of the possible points of
> > failure ahead of time. If an unexpected error is encountered then our
> > error
> > handling actions fall apart.
> >
> > I see value in the way it is designed but it would be nice if there was
> an
> > option to terminate normal processing if an EH filter is called and only
> > process the filters triggered by the EH. Sometimes you want to take a
> > special action due to an error but you still want a hard error that stops
> > the original processing.
> >
> > Jason
> >
> > On Mar 14, 2011 2:04 PM, "Misi Mladoniczky" <m...@rrr.se> wrote:
> >> Hi Robert,
> >>
> >> Maybe, but the documentation does not say anything about this.
> >>
> >> This would both limit and extend the use of servive-calls I guess.
> >>
> >> In my case, when my service picks the next of several counters, it will
> >> create holes in my counter-series. I guess I have to redesign...
> >>
> >> Best Regards - Misi, RRR AB, http://www.rrr.se
> >>
> >> Products from RRR Scandinavia (Best R.O.I. Award at WWRUG10):
> >> * RRR|License - Not enough Remedy licenses? Save money by optimizing.
> >> * RRR|Log - Performance issues or elusive bugs? Analyze your Remedy
> >> logs.
> >> Find these products, and many free tools and utilities, at
> >> http://rrr.se.
> >>
> >>> My understanding is that since you are calling a Service (just like
> >>> consuming an external web-service logically) that is an independent
> >>> transaction. So an ERROR Trap will need to be constructed, and then
> >>> service
> >>> X_rollback would need to be called in the error handling...
> >>>
> >>> Yes it adds much complication...
> >>>
> >>> HTH
> >>> Robert
> >>>
> >>> On Mon, Mar 14, 2011 at 12:48 PM, Misi Mladoniczky <m...@rrr.se> wrote:
> >>>
> >>>> Hi,
> >>>>
> >>>> I have created a Filter Service that I call from a filter. The problem
> >>>> is
> >>>> that data seems to be committed to the database even though there is
> >>>> an
> >>>> ERROR later on in the processing.
> >>>>
> >>>> A1. Modify Filter in form A: Call Service X
> >>>>
> >>>> X2. Service Filter: pushes data to form X
> >>>>
> >>>> A2. Modify Filter in form A: generates ERROR (phase 2)
> >>>>
> >>>> The data pushed to form X via the Service Filteris commited to the
> >>>> data
> >>>>
> >>>> Is this as designed???
> >>>>
> >>>> I was under the impression that everything should be rolled back if
> >>>> you
> >>>> have a failiure. At least if you refrain from meddling with the filter
> >>>> phasing, which I have not done...
> >>>>
> >>>> Any comments?
> >>>>
> >>>> ARServer version 7.6.04 on MS SQL Server.
> >>>>
> >>>> Best Regards - Misi, RRR AB, http://www.rrr.se
> >>>>
> >>>> Products from RRR Scandinavia (Best R.O.I. Award at WWRUG10):
> >>>> * RRR|License - Not enough Remedy licenses? Save money by optimizing.
> >>>> * RRR|Log - Performance issues or elusive bugs? Analyze your Remedy
> >>>> logs.
> >>>> Find these products, and many free tools and utilities, at
> >>>> http://rrr.se.
> >>>>
> >>>>
> >>>>
> >
> _______________________________________________________________________________
> >>>> UNSUBSCRIBE or access ARSlist Archives at www.arslist.org
> >>>> attend wwrug11 www.wwrug.com ARSList: "Where the Answers Are"
> >>>>
> >>>
> >>>
> >>>
> >>> --
> >>>
> >>>
> >
> _______________________________________________________________________________
> >>> UNSUBSCRIBE or access ARSlist Archives at www.arslist.org
> >>> attend wwrug11 www.wwrug.com ARSList: "Where the Answers Are"
> >>>
> >>
> >>
> >
> _______________________________________________________________________________
> >> UNSUBSCRIBE or access ARSlist Archives at www.arslist.org
> >> attend wwrug11 www.wwrug.com ARSList: "Where the Answers Are"
> >
> >
> _______________________________________________________________________________
> > UNSUBSCRIBE or access ARSlist Archives at www.arslist.org
> > attend wwrug11 www.wwrug.com ARSList: "Where the Answers Are"
> >
>
>
> _______________________________________________________________________________
> UNSUBSCRIBE or access ARSlist Archives at www.arslist.org
> attend wwrug11 www.wwrug.com ARSList: "Where the Answers Are"
>
_______________________________________________________________________________
UNSUBSCRIBE or access ARSlist Archives at www.arslist.org
attend wwrug11 www.wwrug.com ARSList: "Where the Answers Are"
