Workflow operates via the RFC queue, which needs to be up and running. There are many possible problems with this queue which can easily be checked. 2 problems I've come across so far:

The password of user WF-BATCH is no longer valid: on some systems this password can be reset. The RFC queue behind transaction SM58 uses an RFC user which is normally user WF-BATCH. Resetting the password of WF-BATCH also means this password needs to be reset on RFC settings (which can be done via transaction SWU3, see test 5.)

Workflows that threw an error message: If en error message (statement MESSAGE E123(V0) is thrown in a report, it will be stopped. If the report ran in the background,

the error will be logged. If it's on a screen, the screen will freeze on the field that has error handling. But what is a workflow method throws a message (which it should never do) ? It's also logged: as problem with Transactional RFC. 

• Measurements: Faulty transactional RFC entries from user WF-BATCH should not be found
• Tools: SWU2 Transactional RFC for workflow or SM58 Transactional RFC (general)
• Impact: Workflows seem to freeze when a dialog work item is started impacts all workflows...
  Instances for workflow or single step tasks are stopped, even though the workflow logs report e.g. "In process"... forever !

• Prev
• Next