Workflow hanging due dump, SWF_RUN 661 CONTAINER
SAP worklfows can be hanging for numerous reasons. This article explains about detecting the failure of saving workflow container data to database, where the container conversion to the database format fails in the middle. This approach applicable to resolve root cause of dumps (happening in the SAP standard WF classes) of hanging workflows.
When the workflow is hanging, you can expect to see an error somewhere during the flow in transaction SWIA within the workflow log. The last step is completed, but the new one is not started and no errors shown in the log. You can check transaction SWU2 when the next step to be executed is a background task to see errors, otherwise you can check ST22 for dumps directly.
The dump is explaining about message
SWF_RUN 661 and
CONTAINER. The exception is often just the picture of an arror, but does not show you directly the place the issue originates. The original exception is handled/covered during the layers of processing with other excpetions raised afterwards.
The first step is – seeing an exception in the ST22 dump – to put an external break-point in the constructor of the exception, to see where it is actually raised, and for which reason.
The problematic point in case of workflows is the debugging. To overcome this problem activate workflow debugging in transaction SWW_BREAKPOINT.
Next step is to restart the workflow. In case the workflow ran to error, use transaction SWPR (Restart Workflow) to continue the same workflow. In our case the last work item is completed, no errors shown in the log, and the top workflow is still in process. In that case transaction SWUS_WITH_REFERENCE (Start with Reference) is the appropriate one. Here you can also activate debugging and tracing.
After execution debugger should stop for you, to see where the exception is created and raised. In lot of cases previous exceptions are not set as previous in the current exception where you put the break-point, but rather handled explicitly. You will find such exceptions around your current exception is raised. You will find soon or later the roout cause going backwards.
After some iterations, you will find, that conversion of the workflow container data to xml uses class
cl_swf_cnt_conversion_service to do the mapping and conversion. During the process validation of field values by DDIC happens. Here conversion issues might happen. In the mentioned case a value of elementary type NUMC of length 4 was expected, but it was an empty. Of course this is an issue, due initial value of NUMC data types is a character series of 0 in the given length on DB, so in our case it should be ‘0000’. The mapping failed. How did I saw that ? I saw the XSLT error finally in method
CL_SWF_CNT_CONVERSION_SERVICE=>TO_XML_XSLT. The debugger showed exactly which field are we talking about, because the exception/message type X did not gave me the root cause unfortunately. The id XSLT conversion raised exception
CX_XSLT_SERIALIZATION_ERROR with previous
CX_SY_CONVERSION_NO_NUMBER (CL_SWF_RUN_WIM_LOCAL, CX_SWF_RUN_WIM_DB_FAILED, CX_SWF_CNT_INVALID_POR). The ABAP_POISTION attribute gives you the problematic field/value name.
SAAB swf_cnt_xml 🙂