[INUG-Users] Netcool/Impact 3.1 - problems with enrichment policies

[cosmos]

Hi Flaviano,

             You can use one flag to check the processing of same event by
several enrichment condition.

                  Impact 4.0 has policy chaining feature, where you can
select the sequence in which the event should go through different policy in
the service.



Regards,
Cosmos.

On Tue, Apr 1, 2008 at 4:10 AM, Flaviano Ludovino Leoncini <
flaviano at gmail.com> wrote:

> Hi guys,
>
> Thank you for this information. I think that BatchUpdate is exactly what I
> neeed. I will test it!
>
> One doubt: in Impact 4 is there an event locking when one policy is
> manupulating the event, to avoid problems related by Johannes? I not shure
> if I read something about this.
>
> Thank you again,
>
> Regards,
>
> Flaviano Leoncini.
>
> On Mon, Mar 31, 2008 at 7:30 AM, German Silva <gsilva2k5 at gmail.com> wrote:
>
> > use BatchUpdate instead of ReturnEvent. As you know ReturnEvent is
> > executed
> > at the end of the polling cycle, BatchUpdate is executed inmediatelly by
> > the
> > policy.
> >
> > Regards,
> >
> > G
> >
> > On Mon, Mar 31, 2008 at 5:31 AM, Johannes Blach <
> johannes.blach at serima.ch>
> > wrote:
> >
> > > Hello Flaviano,
> > >
> > > what you try to do sounds logical, however Micromuse decided not to
> > > design that part of Impact properly, so it won't work. We've been
> > > complaining about that for years, but nothing really happened.
> > >
> > > THe problem is, that both policies start out with the same event
> > > container, and when one policy writed changes to it, no other policiy
> > > know about.
> > >
> > > So as a result, you'll either see @Summary + "stringA" or @Summary +
> > > "stringB" randomly, but never the expected Summary + "stringA" +
> > > "stringB" or Summary + "stringB" + "stringA".
> > >
> > > To make things worse, in Impact before version 4 (that means your
> > > version too), your policies will destroy all changes that happened to
> > > any other field between reading the event and writing it back. So if
> > > that alarms happens to get cleared meanwhile, it will change Severity
> > > back to what it was before. This is extremely annoying and the only
> > > solution in Impact 3 is to never use ReturnEvent.
> > >
> > > If you use BatchUpdate instead of ReturnEvent, your policies will work
> > > as expected.
> > >
> > > Cheers,
> > >
> > >
> > > Johannes Blach
> > > serima consulting AG
> > > Alpenblick 6
> > > CH-6330 Cham
> > >
> > > Email: johannes.blach at serima.ch
> > > Web: www.ch.serimagroup.com
> > >
> > > _______________________________________________
> > > Sent by the netcoolusers.org "users" mailing list
> > > Post: users at netcoolusers.org
> > > Unsubscribe: users-unsubscribe at netcoolusers.org
> > > Search: http://netcoolusers.org/Search
> > >
> > _______________________________________________
> > Sent by the netcoolusers.org "users" mailing list
> > Post: users at netcoolusers.org
> > Unsubscribe: users-unsubscribe at netcoolusers.org
> > Search: http://netcoolusers.org/Search
> >
>
>
>
> --
> "Give a man a fish, and he'll eat for a day.
> Teach a man to fish, and he'll eat for a lifetime!"
> _______________________________________________
> Sent by the netcoolusers.org "users" mailing list
> Post: users at netcoolusers.org
> Unsubscribe: users-unsubscribe at netcoolusers.org
> Search: http://netcoolusers.org/Search
>