Regarding SWPC and stuck workflows

[andrs_sarcevic]

Hi all,

I already solved the issue but I do need to satisfy my curiosity.

Due to a particular step that remained IN PROCESS status, I had a number instances for the same workflow stucked and appearing on SWPC. Here's what I did:

1. Check and double check ST22, bindings, etc. - not likely given it's a standard step, the well known FIPP->POST.

2. Check SAP_ALL and locks for WF-BATCH.

3. Continue Workflow: ok, work item dissapeared form SWPC.

4. Check workflow log: no changes, work item remains IN PROCESS.

5. Check SWU2/SM58: found one error: "Connection closed (no data)".

6. Re-execute that LUW: ok, apparently no errors here.

7. Check Workflow log: no changes, work item remains IN PROCESS.

8. Check SWPC: workflow appeared again.. back to square 1.

Later on, I tried the method for that workflow instance with SWO1 and on first execution I got the message: "Object needs to be regenerated". I tried the method again and executes with an error I was expecting: "No authorisation for posting".

More later on, re-executed SWPC and the workflow got completed. Executed SWPC for the remaining instances and all of them worked on the first try.

Questions:

1) Why that behaviour happened? The Business Object needed to be regenerated... why? This is on a QAS system and the BOR hasn't suffered a modification.

2) I understand SWPC only reacts for workflows being stucked for more than a day. Is that true? Why?

3) "Connection closed (no data)": this means the RFC failed because of what? "Test Connection" of the RFC WORKFLOW_LOCAL_XXX in SM59 worked fine all day long...

4) Anything else relevant?

Thanks for reading.

Regards,

Andres.

[andrs_sarcevic · Accepted solution]

Just for reference of the next lucky soul that has to deal with this, I found the problem!

Short version: run report RFBIPPG0 before using workflow for Parking Documents.

Long version:

FIPP.Post executes FM 'PP_CODING_GENERATE' which does an IMPORT FROM DATABASE... and if that IMPORT fails, it triggers a SUBMIT REPORT RFBIPPG0... which does an EXPORT...TO DATABASE... -- YES, the initial set up for the first IMPORT to work properly.

Later on, because that IMPORT faled, FIPP.Post method executes a LEAVE PROGRAM. My guess is that Workflow run does not like the SUBMIT statement (perhaps due to implicit COMMIT?) So the EXPORT... TO DATABASE... never took place.

And from here onwards, every time SWPC is used to continue workflow, the same situation is presented. By running report RFBIPPG0, the EXPORT is done and workflow can be continued with no issue.

Regards,

Andres.

[Former Member · Accepted solution]

Hi Andres,

  I found an very helpful discussion,

  Even am into that 'IN PROCESS' status and this occurs in PRODUCTION server.

  Need few clarifications ?

  Can i go ahead and execute SWPC transaction ?

  what steps do i need to do in SWPC tcode ?

  what exactly happens after that action ?

  Thanks, Kishore Kumar

[keohanster · Accepted solution]

Hi Kishore,

First, you should start your question in a new thread.  But, having said that...

I would recommend that people only use SWPC for the circumstances that it was designed - after a system crash.  For 'normal' workflow administration, SWi2_DIAG works fine.  Or, you can run SWi1 on background tasks that have been in process for too long - whatever measurement is 'too long' for you.

Chances are that your task does not have the appropriate outcomes modelled correctly, therefore it just hangs 'in process'.   There are various ways to kick a workflow along, depending on what is causing it to hang in the first place.  Check OSS Note 1098805 for reference.

Then when you have figured out why the task is hanging, implement the appropriate measures back in Dev - whether trapping for an error, throwing an exception, or continuing on.

Sue