Background Task status IN PROGRESS for Long Time

[jampani_sridhar]

Hi Friends,

Thanks in Advance,

Background task, which calls a custom method in the workflow is displaying as IN PROGRESS state for long time and the workflow is not completing.

The same workflow is behaving properly in Quality Environment.

The Background task is executed by WF-BATCH and having all the necessary authorizations.

Cross checked the Workflow Configuration, Even Linkage and seems to be perfect.

No Data Problem, No Authorization Problem, No Workflow Config Problem, No Event Linkage Problem, No Short Dump,

Cross check all the areas, but found no solution.

When we tried to execute the respective task in Background, it is getting completed successfully.

Also, if we restart the same workflow again, it is completing perfectly, only we are getting for the first time.

Using SWIA, the workflow is getting completed manually.

Please suggest some solution for this.

Regards,

Sridhar.J

[saravanakumar_mac]

Dear All,

I am also getting same issue. Using my workflow task getting updated  all tables but workflow status still coming as progress status previously it was working fine.

[vishesh_malik]

Hi Sridhar,

Try to run BOR method standalone in debug mode rather than initiating new workflow instance. It might be ending up in DUMP for the first run.

Regards,

Vishesh

[former_member16044]

Sridhar,

In case you are using the BOR and delegated it, verify the delegation is proper in the competency system after transport.Sometimes, when you omit that TR to transport such problems occur.

Also, check for syntax errors in the active version of workflow in the competency system. There might be issues in transport.

Regards,

Rahul Kulkarni

[I042439]

Hi Sridhar

what do we see in the 'Step History' for that 'In progress step' in the technical workflow log? Do we have an error there?

What do we see in ST22 for the same date and around the same time of the step start date and time? Do we have any dump for WF-BATCH?

Regards,

Modak

[pokrakam]

Hmmm, HR stuff. Authorizations (normal and HR structural)? Does this step run after a dialog step? If so, be aware that some bits will still execute under the previous user's context and may cause issues (low likelyhood, but with HR I don't take anything for granted). If so either switch off advance with dialog for the previous step, or for troubleshooting purposes insert a dummy background task just to force a complete separation of user contexts.

Is the step actually busy - can you see it in SM66? If not, check update failures (SM13).

[jampani_sridhar]

Hi Mike,

Could you please more clear on the 'Advance with dialog' check box, but what makes difference if we un check or check the 'Advance with dialog'.

No entries found in SM66 and SM13 Update is Active status.

Regards,

Sridhar.J

[pokrakam]

Hi Sridar,

It is quite rare, I've only seen it when people have unusual authorisation setups. After completion of a dialog step, WF will advance and create the next step under the user's session context. Only at that point does it check who/how/when it should be executed, and if the previous user is not supposed to execute it, it will switch context to background. I've seen rare cases where some auth restriction affected things, e.g. It could not determine agents because the user was not authorised to access the org structure. So by switching off advance in dialog for a step you will force the system to create the next step in background.

It is an unusual scenario, but worth checking as you've tried all the usual things.

[jampani_sridhar]

Hi Mike,

Agreed with you, but we tried with the role SAP_ALL for the Approver, but there is no progress still the

same issue exists.

Will simulate the workflow by Unchecking "Advance with Dialog" and update.

Regards,

Sridhar.J

[pokrakam]

Well I did say it was a long shot ...

If updating a production version isn't too much effort, I'd suggest sending in a version with a dummy task between and a 5 min requested start on the BG step. If that works, remove the dummy step. If that works then there's a synch/update issue somewhere.

If it doesn't work it's something weird, maybe it only fails the first time but if it's been attempted recently it works (don't laugh, this type of thing is possible with stuff like shared memory objects and other things that may behave differently the first time they're created/accessed). In that case try executing the same task first thing in the morning before any workflow has run and see if it works.

[former_member185167]

I would double-check ST22 for dumps.

[anjan_paul]

Hi,

  Could you share some screenshot of the background task property and method property.

[Former Member]

One thing you can try is to insert a conditional infinite loop and then debug the task in the background to figure out what is causing the first instance to get stuck in "IN PROGRESS"

[jampani_sridhar]

Hi Abdullah,

I had tried like this, in debugging it is completed successfully.

Even if we re-start the workflow of using SWIA, it is completing successfully.

Only for the first time, without debugging.. it is holding up like this.

Checked all the roles issues also, even provided WF-BATCH as dialog user.

All the other workflows executing perfectly except the one which i discussing, seems to be strange.

Regards,

Sridhar.J

[Former Member]

Well, the fact that you experience the problem always when the workflow first starts and that it works when you debug and not when you let it run points towards some sort of locking/commit issue. I have seen this behavior before and the problem was locking. As others suggested, add a dummy waiting step or something to make sure that sessions are completely separated and records are completely unlocked before your background task starts.

[pokrakam]

Is anything or anyone changing the data shortly before the step?

[jampani_sridhar]

Hi Mike,

No body changing the data in between or parallely

regards,

Sridhar.J

[paul_bakker2]

Hi,

You forgot to include some important information.. what does this background task do?

cheers

Paul

[jampani_sridhar]

Hi Paul,

We are trying to update a Job code to a Position with the below standard function module. RH_INSERT_INFTY_1001_EXT

The same is executed independently, and is working fine.

Same task and the same functionality is working fine in another Quality Clients.

Regards,

Sridhar.J

[Former Member]

Check if you have any "locking" issues. Workflow will wait if the record is locked.

[jampani_sridhar]

Hi Abdullah,

There is no Locking issues, as this is working fine independently and also we had cross checked the data whether it is locked or not.

Regards,
Sridhar.J

[ronen_weisz]

have you checked transaction SWU3 for process waiting in the RFC queue?

[jampani_sridhar]

Hi Ronen,

Checked in the qRFC, but no entries, every thing perfect.

Regards,

Sridhar.J