Rabobank_NL Super Contributor.
Super Contributor.
308 views

Delays and retry for OOTB event pipeline steps

Jump to solution

Hi there,

 

We are facing regular event update failures on different pipeline steps. Looks like next pipeline step begins when the current one is not finished yet (may be still busy with event update).

 

In some pipeline steps we can build in retry after some period of time (like OO flow or EPI), some of them have this retry by default (like SM backsync), but for some of them we don't have any control about retries and delays between steps (like time-based automation, stream-based correlation, close related events etc.). It also looks like some rules work already with delay (may be due to some caching, waiting queues or processing bunches), but the next step begins without waiting result of the current one.

 

So I've got some questions:

- It there a way to say, for instance "wait 10 sec after TBEA rule or closed related events step and before going to the next step"?

- How can I get the overview/control about retries for OOTB pipeline steps?

 

 

Actually I've asked it in another topic, but seeing no answer I decided to create a new topic.

 

That's the reference to the related topic: 

http://h30499.www3.hp.com/t5/Operations-Manager-i-Support/OMi-Support-Tip-Deduplication-of-Events-based-on-attributes-amp/m-p/6771662/thread-id/1187/highlight/true#.Vd6xycvovIU

 

Regards,

Svetlana

0 Likes
1 Solution

Accepted Solutions
Highlighted
Micro Focus Expert
Micro Focus Expert

Re: Delays and retry for OOTB event pipeline steps

Jump to solution

Hi,

 

- It there a way to say, for instance "wait 10 sec after TBEA rule or closed related events step and before going to the next step"?

 

No, its not possible.

 

- How can I get the overview/control about retries for OOTB pipeline steps

You see the event pipeline diagram in the other post you provided a link to, pl note that most of the steps execute sequentially (except the orange ones) and those pipeline steps are for NEW events coming into OMi (SM backsync for example, will not go through the pipeline).  I think the issues you mention could be due to updates on events from multiple sources and it will need to be looked into on  a case to case basis.

 

For troubleshooting specific scenarios, you can enable debug logs for opr-flowtrace-backend, opr-backend and opr-gateway-flowtrace, opr-event-sync-adapter (for event updates); This should help to trace an event or event update flow.

 

Thanks & Regards,

Mamta

1 Reply
Highlighted
Micro Focus Expert
Micro Focus Expert

Re: Delays and retry for OOTB event pipeline steps

Jump to solution

Hi,

 

- It there a way to say, for instance "wait 10 sec after TBEA rule or closed related events step and before going to the next step"?

 

No, its not possible.

 

- How can I get the overview/control about retries for OOTB pipeline steps

You see the event pipeline diagram in the other post you provided a link to, pl note that most of the steps execute sequentially (except the orange ones) and those pipeline steps are for NEW events coming into OMi (SM backsync for example, will not go through the pipeline).  I think the issues you mention could be due to updates on events from multiple sources and it will need to be looked into on  a case to case basis.

 

For troubleshooting specific scenarios, you can enable debug logs for opr-flowtrace-backend, opr-backend and opr-gateway-flowtrace, opr-event-sync-adapter (for event updates); This should help to trace an event or event update flow.

 

Thanks & Regards,

Mamta

The opinions expressed above are the personal opinions of the authors, not of Micro Focus. By using this site, you accept the Terms of Use and Rules of Participation. Certain versions of content ("Material") accessible here may contain branding from Hewlett-Packard Company (now HP Inc.) and Hewlett Packard Enterprise Company. As of September 1, 2017, the Material is now offered by Micro Focus, a separately owned and operated company. Any reference to the HP and Hewlett Packard Enterprise/HPE marks is historical in nature, and the HP and Hewlett Packard Enterprise/HPE marks are the property of their respective owners.