09/01/2016

PlayingwithFilterPhase|BMCCommunities

BMC.com > All Places > Products > Remedy AR System > Documents

Playing with Filter Phase

Version 5

Created by Vincent RIEDWEG on Jun 6, 2013 9:17 AM. Last modified by Vincent RIEDWEG on Jul 16, 2013 9:19 AM.

Hi all,

I have seen too often some people always asking about Filter Phase and how it works.

This is actually very well documented here https://docs.bmc.com/docs/display/ars81/Filter+processing+in+BMC+Remedy+AR+System+server .

This document objectives are not to explain again that documentation, but just giving some tech tips that you should know if you want to play with
Filter Phase.

Small basic reminders

You have different way to override the Filter Phase:
Adding `! at the end of the Filter name forces all actions in Phase 1.
Using Application-Release-Pending is always executed in Phase 1 and force the commit transaction to the database.
Using Application-Set-Filter-Phasing to delay some operation.
Error Handler filters are always executing in Phase 1.
If an Error Handler is specified and an error occur, the workflow continue with the next action of the Filter.

In a Filter Guide, the Filter Phase are still used!

Time to play
Let's take the following scenario: From a staging form, we want to create CI Unavailability record that record to an incident.
In that scenario, to be able to create the relationships, we must retrieve some information from the CI Unavailability record first. So the
database transaction must be committed.
There are different ways to design and build that. Let's talk about 3 different ways.

https://communities.bmc.com/docs/DOC24740

1/9

09/01/2016

PlayingwithFilterPhase|BMCCommunities

I take my gun to hunt butterflies

1. Create a record in the staging form.

2. Get some information from HPD:Help Desk.
3. Create AST:CI Unavailability record.
4. Use Application-Release-Pending.
5. Get the information from the created record in AST:CI Unavailability.
https://communities.bmc.com/docs/DOC24740

2/9

09/01/2016

PlayingwithFilterPhase|BMCCommunities

6. Create the AST association record.

7. Create the HPD association record.

I don't like that method. I never use Application-Release-Pending process if I have another way to do.

I am a lemming

1. Create a record in the staging form.

2. Get some information from HPD:Help Desk.
3. Create AST:CI Unavailability record.
4. An escalation fires and continues that processing.
5. Get the information from the created record in AST:CI Unavailability.
6. Create the AST association record.
7. Create the HPD association record.
https://communities.bmc.com/docs/DOC24740

3/9

09/01/2016

PlayingwithFilterPhase|BMCCommunities

I have used that method and continue to use it specially during my unit test. But when my workflow is shielded and works fine, if there is no
requirements to follow up that process, I jump to the next method.

The cons of that method is the relationship's records creation is delayed.

I am a player

https://communities.bmc.com/docs/DOC24740

4/9

09/01/2016

PlayingwithFilterPhase|BMCCommunities

1. Create a record in the staging form.

2. Get some information from HPD:Help Desk.
3. Create AST:CI Unavailability record.
4. Delete the current stagging record. And on Delete, do the action 5, 6 & 7.
5. Get the information from the created record in AST:CI Unavailability.
6. Create the AST association record.
7. Create the HPD association record.

With that method, it's quite difficult to debug as the record in the stagging form it deleted just after the creation. There is no escalation and the
relationship's records are created immediately.

Quick summary
If you prefer the "I take my gun to hunt butterflies" method, search on eBay for a new brain.
reread all the documentation closely.

Then have a look on the documentation and

If you prefer the "I am a lemming" method, I am pretty sure you looks like an old school man or you are not a player.

You can just try and adopt

the "I am a player" method. I am pretty sure you will enjoy it.

If you prefer and use the "I am a player" method, you are a winner as you already know all you need to know on Filter Phase.

Now we can play with Filter Phase and Error Handler

To illustrate that, I will use the following scenario:
In a unique Filter I want to:
1. Set some fields from form A (Set fields to null if no match).
2. Push fields to form B (with required fields).
3. Set the status to "Record B Created".

For that it's quite simple. It's one filter with the following actions:
1. Set Field from Form A (Phase 1)
2. Push Field to Form B (Phase 2)
3. Set Field (current transaction) (Phase 1)
https://communities.bmc.com/docs/DOC24740

5/9

09/01/2016

PlayingwithFilterPhase|BMCCommunities

Now we want to add an Error Handler filter to avoid ARERR 326 if the record in the form A has not been yet created by another process.
The Error Handler filter have a single action:
1. Set the status to "Retry".

If you enable the Error Handler filter on your first filter, no Retry will never Occur.
In that case and if error occurs, the following actions are executed (And you can't see that in the filter logs

):

1. Set Field from Form A (Phase 1)

2. Push Field to Form B (Phase 2) => Error
3. Error Handler action fire Set the status to "Retry". (Phase 1)
4. Set Field (current transaction) (Phase 1)

But in that case you can see the following in the filter logs. Have some fun...
1. Set Field from Form A (Phase 1)
2. Set Field (current transaction) (Phase 1)
3. Push Field to Form B (Phase 2) => Error
4. Error Handler action fire Set the status to "Retry". (Phase 1)

So for that kind of scenario, you must change the order of the actions of the first filter if you want the error handling works as expected.
1. Set Field from Form A (Phase 1)
2. Set Field (current transaction) (Phase 1)
3. Push Field to Form B (Phase 2)

So in with Error Handling filters, just remember the following:

Error Handler filters are always executing in Phase 1.
If an Error Handler is specified and an error occur, the workflow continue with the next action of the Filter.

Vincent.
2022Views

Categories: Best Practices, Developer Guides, Tips and Techniques

https://communities.bmc.com/docs/DOC24740

Tags: ars, arsystem, best, practices

6/9

09/01/2016

PlayingwithFilterPhase|BMCCommunities

Average User Rating

(3 ratings)

4 Comments
Login or Register to comment
RLA NameToUpdate Jun 6, 2013 11:42 AM

Good one. To add on, probably playing safe is a good option. After 7th step, 8th step is to Push to duplicate staging form "Staging Form2"
with matching Ids to copy the staging form data for record purpose.

-remedyloganalyzer.com
Actions

Like (0)
Vincent RIEDWEG Jun 6, 2013 1:13 PM (in response to RLA NameToUpdate)

RLA,

For a real design if it's required, for sure. That's just some examples to illustrate the Filter Phase. And if it helps someone having a
better understanding of how Filter Phase works, I win.
For that illustration, there is no added value, from my point of view,
having a use case "I am a paranoiac player".

I have decided to write this short document because that's some design tips that I can see too rarely if I am not in charge of the
design.

Vincent,
Actions

Like (2)

LJ LongWing Jun 6, 2013 11:44 AM

Vincent, I like your documentation here...i wanted to offer a 4th option that steps 'out of the box' a bit, but if you can live with that, then it's
an options.
https://communities.bmc.com/docs/DOC24740

7/9

09/01/2016

PlayingwithFilterPhase|BMCCommunities

an options.

"I'll take a break, then come back and finish this later"
- I have in the past written a command line client that is called on submit. This command line client logs into the Remedy server and
performs an update on the record post-submit...so, basically your 3 approaches are 'how do I wait for this data to be available before I
create the other records....so this process does a fire/forget run process, that has a built in 'pause' because of the need to start the
command line, but you can build in whatever delay you need within the program...then do a setEntry call which does the same thing as the
Escalation....but 'quicker' than an escalation, without the 'polling'
Actions

Like (2)
Vincent RIEDWEG Jun 6, 2013 1:30 PM (in response to LJ LongWing)

LJ, I like your option. Indeed, if we can achieve a requirement without doing anything, I choose that one and take a coffee.

That's quite the same approach, from a Filter Phase perspective, than "I am a player". But with your tool can you read some
information that are required from the previously created record before creating the other request? I already know that with API's I
can do it for sure.

The cons of your solution it that a login / logout call made to the AR System server consumes more resources.
Actions

Find People
Support Login

Like (1)

Community Help
Worldwide

About BMC

BMC.com

Google+

1322

Copyright 2005-2016 BMC Software, Inc. Use of this site signifies your acceptance of BMC's Terms of Use, Privacy Policy and Cookie Notice.
BMC, BMC Software, the BMC logos, and other BMC marks are trademarks or registered trademarks of BMC Software, Inc. in the U.S. and/or certain
other countries.

https://communities.bmc.com/docs/DOC24740

8/9

09/01/2016

PlayingwithFilterPhase|BMCCommunities
Manage Cookies

https://communities.bmc.com/docs/DOC24740

9/9