on ‎2018 Mar 08 1:38 PM
We have a number of custom workflows that have been working for years. Now we ran into a couple of cases where a workitem remains in status STARTED for no apparent reason.
The cases were created in two time windows of about 1.5 hours each, seemingly sporadically. For example, workitem 17389204 was stuck, but a couple of minutes later, another workitem 17389225 relating to the same task was created and processed successfully. All stuck workitems are for custom, synchronous background tasks.

There are no errors in ST22. There's no error, so SWWERRE won't pick the items up for reprocessing. Instead, they just remain STARTED, and due to that, won't process automatically.
I executed the workitems without check in SWIA, and the workflow continued normally. No urgent problem, but I'd like to know what could cause this. One guess of mine is that there were no background work processes available, but can't prove that post hoc.
The cases are rare: I've found 10 in total, while in the past 365 days, a good 400,000 workflows were processed successfully, each including several background tasks.
Given that the vast majority of cases work OK, I could say with confidence that the basic settings are OK, but I still cross-checked with Rick's blog.
Request clarification before answering.
Any dumps around that time?
Another common load-related issue might be RFC resources - see if anything is sitting in SM58
You must be a registered user to add a comment. If you've already registered, sign in. Otherwise, register and sign in.
Hi,
It seems you have covered all of the options already. Please check SM21 using the time when the task is called to look for out of the ordinary messages, sometimes a DB error or insufficient memory can be the culprit.
It also wouldn't harm to execute SWU7 on production for these templates.
Please keep us updated I would love to know the cause of this issue.
Kind regards, Rob Dielemans
You must be a registered user to add a comment. If you've already registered, sign in. Otherwise, register and sign in.
Hi Arto,
I agree with Mike, the RFC processing status should also be checked in SM58. If you see "transaction recorded" or "transaction executing", then probably there were RFC resource issue when the tRFCs were processed. In SM58 you may also see errors during LUW processing.
One suggestion is to register the workflow RFC destination WORKFLOW_LOCAL_XXX (XXX is client number) in SMQS. This will rule out the possible issue caused by RFC resource situation.
Another way to check the situation is to see the technical workflow log for the affected background step, the TID should be shown in the log. After clicking on the TID it will take you to the corresponding LUW in SM58.
Hope it helps,
Kelly
You must be a registered user to add a comment. If you've already registered, sign in. Otherwise, register and sign in.
| User | Count |
|---|---|
| 9 | |
| 7 | |
| 6 | |
| 4 | |
| 3 | |
| 3 | |
| 3 | |
| 2 | |
| 2 | |
| 2 |
You must be a registered user to add a comment. If you've already registered, sign in. Otherwise, register and sign in.