fork in workflow

[Former Member]

Hi I have a fork in my workflow having three branches.

Two of the branches are having wait for events and the third one is having a no. of tasks.

When I check in the technical details of log, one of the wait for events is in "ready" state. But when I see the corresponding graphical log that particular branch is shown in green indicating completion of that branch.

In the fork, 2 out of the 3 branches are necessary for completing the step. One of the wait step is completed. The second one, though in ready state is showing as completed as explained above. Due to this the actual task (which is in the third branch) is not completing and the workflow is ending ( as 2 out of 3 steps are complete).

Can anyone explain this? I am not able to figure out the reason.

Again this is not happening all the time rather only sometimes. At all other times the workflow is successfully completed with one wait event branch and third branch being completed and the other wait event branch being logically deleted.

Please help. Urgently required.

regards,

Abhishek

[pokrakam]

Hello Abhishek,

Don't trust the graphical log. It lies. It's never been reliable since day one. The technical log is always the correct one.

Sounds like you're missing an event. If your wait step has received an event then you should see it when you expand the tech log for that ste ("Expected event received"). I would also suggest switching on the event trace (SWELS) and checking it (SWEL) to see that your events correctly trip the wait step.

Hope that helps,

Mike

[Former Member]

Hi Mike,

thanks.. at least one part is clear...

yes I have checked...

the wait step which has been completed has "expected event received" while the wait step which is in ready state doesn't have it..

Can you tell me what could be the reason then that the third branch ( the one with actual tasks) is not getting completed at a particular task.

The task is to post a document. When the task is executed the document is successfully posted but the task is still in "in process" state. There is no macro (EXIT_CANCELLED) used within the method nor is it having any terminating event.

Again let me reiterate that this is happening only in some particular cases and not everytime.

[Former Member]

To add to this..

when i expand the technical details for the step which is remaining in process the first error which is displayed is this.

Work item 000xxxxxxx: Object MYyyyyyyyyyyyy

method SWW_WW_EXECUTE_S cannot be executed

[pokrakam]

Hi,

Sounds like the problem is with your posting step. Is it background or dialog? Synch/asynch task (i.e. does it have terminating events?). Also check for dumps in ST22 (expecially if it's in background).

Cheers,

Mike

[Former Member]

Is that TASK is dialog?

IF that TASK is dialog, just check ' Agent Assignment' is green.

or check the Workflow ID of the AGENT.

[Former Member]

Hi,

I have checked the task.

Yes it is a dialog task and agent assignment is green.

I couln't get the last point. pls tell me if I need to check somewhere else.

regards,

Abhishek

[KKilhavn]

Perhaps you could tell us what business object and method you use in your dialog task, and if it is a customer object type explain what the method does (or in your case: tries to do). As suggested by Mike, this is probably not a problem in the workflow itself, but rather in your method.

You have said that the task is to post a document. An FI document? Then you should be able to use BKPF.Created (or BSEG.Created?) as terminating event for your task. However, this is pretty standard, so you shouldn't have a problem with it. You say your task does not have a terminating event. Perhaps it should?

If the document that is posted is not an accounting document, please enlighten us.

The behaviour is not consistent you say, but can you confirm that the workflow can both fail and complete normally for the same user?

Give information and you will probably get information.

[Former Member]

Hi,

the business object used is FIPP and the method is POSTDIALOG.

In fact it is a customer object whose supertype is FIPP.

Yes it is used to post an FI document.

Yes I have also checked that the workflow is failing and completing normally for the same user.

[KKilhavn]

I take it that you have not re-implemented POSTDIALOG.

Hmm... in the system I have access to there is no method POSTDIALOG, so perhaps this is something you have implemented for your customer object.

Back to you

[Former Member]

Hi,

yes u are right. The method POSTDIALOG is a method of the customer object which is implemented using method POST of the standard object FIPP.

One more thing which I see is that the method POSTDIALOG has not been released. I don't know if that could be a reason. Can you find anything with these observations??

Thanks

Abhishek

[KKilhavn]

Released status or not should not have any effect. As long as the workflow only fails sometimes it must be something else.

This method, it is dialog (not background) I assume.

For the most part you have ruled out authorizations for those agents that were executing the workitem when it failed, since it both fails and executes successfully for the same agent. However, I know that in FI the authorizations can be given on quite specific levels (vendor items in one company code OK, but not in another company code). Perhaps a new and more thorough investigation to rule out authorization problems is necessary?

Anyway, if that doesn't help, or is not necessary I have no better suggestion than changing your business object. If you don't already have it in your method, perhaps you need to add some code to detect problems at runtime, missing authorizations as well as other kinds of problems - and raise temporary or application errors - so you can pinpoint the exact cause of the problem.

[Former Member]

Hi Abhishek

Is your method using the function PRELIMINARY_POSTING_POST_D or similar, or have you set up a BDC to facilitate posting? If the latter, is the document actually being posted in the system?

Regards

Gareth