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"
