Event Receiveer someimes failing to receive events.

[soumya_ranjan_patel]

Hi guys,

The problem facing is sometimes a terminating event is getting triggered but not able to receive by the receiver function module. Some screen-shots of same is attached below.

Kindly tell me if you find any possible cause for this issue.

Screen-shot taken from 'SWEINST' t-code

These are actully sub workflows terminating event, so if any one of sub-workflow doesn't get completed the WI stays in user inbox and Main WF get stucked there.

Regards,

Soumya.

[former_member186746]

Hi,

Please follow the suggestions already given, you have to first determine if the event as it is will have a receiver (maybe there are conditions on the event or a check function module which correctly prevent the event having a receiver).

If after this is done and the event should have a receiver, check OSS to see if there are known problems with events not triggering a workflow. I know that some time ago (years) there were issues with events, depending on how up to date your SAP system is it might be worth a shot to check if there are notes.

Kind regards, Rob Dielemans

[SandySingh]

Hello,

This could be due to the COMMIT WORK called after event trigger. Ensure that event is raised in Update task. Looks like you need a WAIT step in between the trigger of events. Can you see any data in the "Receiver Data".

Regards

Sandy

[soumya_ranjan_patel]

GM Sandy,

Actually this event triggered is Standard. So is the solution you are giving will be implemented?

Regards,

Soumya.

[Former Member]

Double-click the event in the event monitor. See the object key. How does it look?

Open the workflow log (the workflow that you are expecting to get terminated by this event). See the container and check the object (I don't actually see the object type in your screenshot?). Does it have the same object key as in event monitor?

Actually if you have some kind of terminating event defined in the workflow template level, then you don't necessarily even need an entry in SWEINST to get the workflow terminated (but this should not be the cause for your problem).

Regards,

Karri

[soumya_ranjan_patel]

GM karri,

Screen-shots of failed and correctly received.

Failed receiver trace detail:

Correctly Received:

i think this error may be due same terminating event triggered multiple times during a short interval of time. Could this be a reason.

Let me know if any more data I can provide to find the cause.

Regards,

Soumya.

[SandySingh]

Hello

If you think that the same event is getting triggered multiple times, then use the check function module to stop the trigger when an existing instance is in process. Use FM CALL FUNCTION 'SAP_WAPI_WORKITEMS_TO_OBJECT'

Regards

Sandy

[Former Member]

So, take a look to the first example. You are expecting this event to terminate/complete a work item. Can you find the workflow/work item that is supposed to get terminated (or "react" to the event)? So far I am just seeing (in event monitor) that there is no receiver, but what should be the receiver?

If I remember correctly, the table that holds the link between the events and work items, is SWFDVINST. If you try to find the object, event, objkey (from your first screenshot) from this table, is there an entry?

One possibility could also be that the same event (=same object key) gets triggered twice (or several times) and the first event of course completes the work item, and then the following events of course do nothing (=you will see the no receiver message in event monitor).

Regards,

Karri

[soumya_ranjan_patel]

Hi Karri,

The receiver is 'SWW_WI_COMP_EVENT_RECEIVE_IBF'. The receiver you can see in screen-shot of correct receiver.

And the table you are mentioned, I cros checked but didn't get any entry there.

The 3rd possibility you suggested seems to be the cause. Below see the screen-shot for time stamps.

The events are triggering in close intervals. But the 1st one which was triggered 1st couldn't find the receiver. So does these creating issue.

Regards,

Soumya.

[Former Member]

I don't consider several seconds (or even minutes) a close interval.

Can you execute transaction SWUE and trigger exactly the same event that didn't work (=there was no receiver). Does it find a receiver a now when you create the event again from SWUE?

Also, what is your actual problem? Now you seem to be concentrating to the event monitor and the fact that there is no receiver. But what does this cause? Where is the problem? certain functionality is working, but what is it? Can you explain?

Regards,

Karri

[former_member185167]

Another possibility is that the event is created before the workflow is ready for it. Check the timestamps.

But first of all, as Karri says, is there actually a problem?

[SandySingh]

hello,

Have you checked if same event is triggered multiple times. If so, try to restrict the trigger using check FM. Refer to my previous post.

Regards

Sandy

[soumya_ranjan_patel]

Hi Karri,

The problem user is facing is workitems are not going out of user inbox even after he/she complets the job. This issue happens randomly not always. The screen-shots I was posting was of testing client. For now I dont have production instances but before whenever this happened another wf consultant used complete that WI by using FM 'SAP_WAPI_COMPLETE_WORKITEM'.

But now I am looking for parmanent solution this issue. So please help me on this.

Regards,

Soumya.

[Former Member]

Next time when it happens (or if you can reproduce the problem in test system):

- Check the situation in event monitor. Be absolutely sure that the correct event really was created!

- Find the work item (with SWIA or SWI5 or whatever) that was not completed. Open the WF log. Check the container (of the work item / task) and find the object (CL_EHHSS*). Check that the object key is exactly the same as the one seen in event monitor.

- Try to create the same event (same object key that you can see in event monitor) with SWUE. Did the work item get completed now? (This is perfectly safe alternative to do in production instead of SAP_WAPI_COMPLETE_WORKITEM.)

Tell the results here.

Regards,

Karri

[soumya_ranjan_patel]

Hi Everyone,

Actually I think I have found out the issue.

When such failure incident was reported in testing client, saw that Terminating event time stamp was before then the workitem creation time. For eg. WI was created in 18:27:34 then the terminating event for the same key was triggered at 18:27:15.

So  if the issue I am thinking is correct, Then how solve that? Wheather check FM in SWEINST

, if I can do some waiting there will that help. Or any other way to solne this.

Regards,

Soumya.

[Former Member]

Just like Rick said. It makes perfect sense (although I don't quite understand the process).

One possible fix could be the following:

-Open the step in WF builder (SWDD)

-Go to the conditions tab and "Complete work item" tab

-There you could set some kind of condition that completes the work item (for example if the status of the business object is <some status> (or whatever)

Regards,

Karri

[pokrakam]

Sounds to me like there is something not optimal about your overall process. What would cause a terminating event to be created at the same time as the work item is being created? Maybe take a step back and relook at the design, it seems odd to me.

[former_member185167]

Ahem.

Maybe there's an unnecessary delay in the workflow before the step listening for the event is created.

It should be created as soon as possible.

regards

Rick

[soumya_ranjan_patel]

Hi Karri,

The condition step you are mentioning can be used if any container value in WF can be cross checked with database value updation in periodic intervals. So if our required status is set for that workitem, it should get completed incase our terminating event fails.

Is that possible because condition step I think is used locally for workflow.

Regards,

Soumya.

[soumya_ranjan_patel]

Hi Rick,

Thanks for you response. But delay in WF, means how happens.

Actually There are 7 set sub-workflows triggering at one time with different key field but same event. a parent WF is there in which if particular dialog WI gets over these 7 sets get triggered.

So sometimes any 1 or 2 any of these 7 gets stucked because of failing receiver.

Now I am checking with flow design as mentioned. If you think of any other flaw please let me know.

Thanks,

Soumya.

[Former Member]

I was basically thinking that perhaps there is some kind of attribute in your class CL_EHHSS* that would indicate that the "INV_STEP_CLOSED" has already happened => the value of certain field would change. I have no idea what your solution is about, so this might not work.

In general this whole problem does not make much sense. Why the work item gets created at the first place, if the actual functionality has been already completed (and thus the terminating event created). Can you analyze the workflow log and see if there is something causing a delay?

You also said: "The problem user is facing is workitems are not going out of user inbox even after he/she complets the job."

Normally completing the job would trigger the terminating event. So how can the user complete the job (from inbox) if the work item has not been even created yet?

Regards,

Karri

[anjan_paul]

Hi,

   Please also generally whenever   its happened, what is the system load at that time?

[soumya_ranjan_patel]

hi Anjan,

How is that system load checked, can you give some more details.

Soumya.

[anjan_paul]

Hi,

   SAP workitem is generated using workflow engine, I just think due to heavy system load might be workitem generated quiet  late, before that event triggered

  Basis has some transaction like ST03N, ST06 to check system load.   You can check with them.

[Former Member]

>So sometimes any 1 or 2 any of these 7 gets stucked because of failing receiver.

There is no failing receiver. The work item is the "receiver". If the work item does not exist at the moment when the terminating event gets created, then you simply don't have a receiver for the event.

There is some kind of serious flaw in the design of the workflow (or there is some other problem in the system that makes the work items created slowly (=unlikely)).

Now you just need to:

1) Find out where/how this event gets created

2) Look at the workflow log and see the work item creation times

3) Find a logical explanation for the behavior

If there is no "mistake", then you need to find a way to not even create the work item at the first place. It makes no sense to create a work item for a job that is already done. You could bypass the step by condition step or whatever.

Regards,

Karri

[soumya_ranjan_patel]

Hi Karri,

There is one more thing I have noticed.

Before that WI creation step there is one more background step for fetching user. In that a requested start is avtivated with some time. That particular step has Start time and End time, so when closely checked, every time this issue has happened, the Terminating event was triggered during this periodonly.

Thinkng this might be causing issue, once will test with removing this deadline and if this doesn't workout thinking of going with another solution i.e.using a fork for parallel processing where in another line I will add one wait step for that Terminating event. I dont have much idea about Condition step, if you can help on how to proceed with, I can go with that too.

Hope any of these will work, if still it doesn't will raise OSS.

Answers to your points:

1) Checked there or four times in testing, events triggering at correct time, no issues found then

2) WF creation time is 3-4 minutes before dialog WI creation, as I mentioned above because of requested start it is taking that much time.

3)Logical explanations, how to get the Logical explanation.

Regards,

Soumya.

[Former Member]

There is no reason to raise this to OSS (unless this is a standard workflow template/solution that you are using).

You already found the reason. The background step is delaying the process and the work item gets created too late for the event. The parallel processing & wait for event step WILL work. Of course if the background step is doing something necessary that must be completed, then you cannot use the parallel processing trick, because it will cancel the background step.

Regards,

Karri

[Former Member]

Hi Sandy,

you can't use my Singleton-Concept for instance linkages, as the instance linkage DOES require another Workflow to run. A singleton would always raise an exception to prevent the terminating event from further processing.

Same thing with 'SAP_WAPI_WORKITEMS_TO_OBJECT' , which is useless, because you need that instance.

The linkage is checked in the instance-linkage tables. If there's no Event receiver waiting for that particular instance, there's the message "no receiver found", although there's an event coupled.

@Soumaya : Check transaction SWEINST  (as @Kerri had suggested in a later post)

Florin

[soumya_ranjan_patel]

Hi Florin,

I have checked SWEINST. Event linkage for that paticular WI is activated there. Everything looks fine there.

Regards,

Soumya.

[former_member185167]

Two out of two!

As I said, make sure you create that wait step (or whatever is waiting for that event) as soon as possible in the workflow or otherwise you might miss it - as you indeed have.