BPM Troubleshooting for Beginners
Many documents and blogs have been written about How to Develop BPM Components, How to integrate external components into BPM, How to consume BPMs in other applications, BPM APIs etc.
But, after the development of these objects, when the time comes to actually use them, run them on the server for testing, quality or even end-user usage, very little is known to BPM Developers at the beginner level as to how and where can we check what is going wrong with our processes.
Where is it stuck? Why is it stuck? Is there a technical issue? Is there a modelling issue? ….. and the list goes on.
In this blog, I would like to help you guys out with a few steps which can help you in finding the causes of disruptions of your process executions on the server.
For finding the exact root cause of the problems, we will follow a classic 4-step approach, which should be followed in chronological order while troubleshooting your BPM Processes in the NetWeaver Administrator, which can be accessed by logging in to “http://<host>:<port>/nwa”.
Note: For troubleshooting your Business Processes, you need to have appropriate authorizations on the server. You can refer This Article for all roles & authorizations related to BPM. I would suggest having the “BPM_SuperAdmin”/ “NWA_SuperAdmin” role.
Please follow these steps in the exact order in which they are listed.
Step 1: Process Repository-Error Log
Log-in to NWA –> Configuration –> Processes and Tasks –> Process Repository:
Once you click on the Process Repository, you will see all the BPM Components deployed on your server. Select your concerned BPM Component, Scroll the page down, select the Parent Process Instance & click on the Process Link:
This will open up the Process Instance Repository (which will contain all the Process Instances-Running and completed) for the selected BPM Component:
The very first step we will do here is to click on the button, which will open up the process design of the BPM, to see where exactly the process is stuck. If the process is stuck at a Human Activity, it will have a RED token on that particular activity.
Moving ahead, if you see this repository closely, you will have a lot of options which you can operate upon your BPM Process Instances.
At the bottom, you will see a tab-strip:
The last tab here is that of the “Error Log”. If the process instance is in a Suspended/Error status, this error log gets enabled and you will be able to find the full error stack trace here. In case the status of the Process is OK/In-progress, this tab will be greyed out (as above).
However, there are quite a few instances where the process is erroneous but you may not find anything in the error-log tab. This is when we go to the 2nd step.
Step-2: Process Repository-History
In the same tab-strip above, the 4th tab you will see is the “History” tab. This section will actually list out all the process execution steps of the BPM Process execution.
If step-1 does not help you, click on this History Tab and from the available dropdown-options, select Advanced:
In the description details listed, you will be able to find the exact detailed error trace in approximately the 3rd entry.
Note: I would personally suggest to copy this full error trace onto a notepad and then check the problem. Sometimes, the table limits the display of the error text.
This step traditionally takes care of Process Modelling issues, Data and other issues which might not be build-errors, but run-time errors.
The only error this step may not track is a Service Execution in an Automated Activity, in which case, we move to step-3.
Step-3: NWA-Connectivity Logs
In NWA Home-page, go to SOA –> Logs & Traces –> Connectivity Logging & Tracing:
When you open this, you will see all the error traces pertaining to service connectivity errors. You may search for your interface (which has failed to execute and we identified it in Step-2, but we do not know the exact error-cause) and check for the errors:
You are bound to find the final error here. But, however, if you fail to do so (which is a very rare case), we move to Step-4.
Step-4: NetWeaver Logs
You can directly access the NetWeaver error-logs by logging-in to http://<host>:<port>/nwa/logs.
This log engine stores all the error logs of the errors which occur on the server (of all the running applications, as well as the configurations logs).
Firstly, change the error-log prioritization as shown in the below snapshots:
You may enter the Development Component Name in the search criteria to search for errors pertaining to your Development Component.
You may then expand the error by clicking on the “+” sign on the left of the selected error entry and then check for the error details:
Note: Please use this step as the last resort to finding the error details. It is very time-consuming to search for a single error among thousands of records on the server.
That’s it. I think these steps above will surely help somehow to track the cause of the error.
But please note that you should follow these steps in the order in which they are listed.
For an overview of the errors on all the BPM Components on a whole, you may check the BPM-System Overview option in NWA.
Check This Document for BPM System Overview.
You may also refer the excellent article: A day in the life of an SAP NetWeaver Business Process Management Administrator by Birgit Heilig
Hope this helps.