This blog takes a look at debugging a process instance graphically with SAP NetWeaver BPM. The composite business process leverages a business rule, defined in the Rules Composer of SAP NetWeaver BRM - and shows how you can step over activities within a process and literally watch the data flowing through the process from human activities to automated decision making thru the rule and finally to the creation of an order in the backend system via an automated activity and a web service call.
So let us take a look at the demo process we are using: it is an Investment Approval Process (those of you who have seen our presentations and attended the workshops in Las Vegas know it already), a simple example of a "before" composition use case.
It basically consists in its simplified form out of three human activities (the request, the approval, the notification) and two automated activities. Here we are using a rule that is exposed from SAP NetWeaver BRM as a service to validate and check a decision table to see if an approval is necessary based on the region and the total order amount. The second automated activity leverages a web service to book the order in the backend system.
Check out the properties of the automated activity that calls the rule.
So, let's take a closer look at the rule and we switch to the Rules Composer perspective, where we see the approval ruleset and the simple approval rule that validates if the precondition is true to evaluate the approvalmatrix decision table:
Here's the decision table that evaluates the input parameters regarding requester country, the total amount of the order and returns "true" or "false" for the necessity of an approval.
How does this look like now at runtime. We will check the process debugger for this little exercise, switch to the debugging perspective, select the right process and open a debugging dialog.
Let's now trigger manually the process out of the process repository (BPM process starter) and check also if we have the right one by opening up the process viewer (a Flex-based representation of the deployed process model):
As we have triggered the starting event, the debugging sessions gets instantiated and we can see that the process container is displayed, not yet filled with variables:
After stepping over, the first breakpoint is utilized and we can open up the first task from the process desk, the UWL (we routed all tasks to the same user):
Well, we are in the US and order 1.000 notebooks which will give us a total amount of 956.000 $ (any laptops still needed for TechEd Bangalore?)
Check out the behaviour of our debugger after submitting the thing - well, here are my variables now populating the process container, the memory of my process brain:
Fast forward: we step over, the rule is being checked and, yes, approval is necessary!
Again, after a step over, we see that the next activity is the approval task which is instantiated:
Well, now let's do the same thing again, so I am kicking off a new process:
Let's see how that path is taken, if I order just one notebook.
Fast forward - stepping over the breakpoint and now my rule service is invoked again, but this time eventually with a different result:
This time, we see the statement "false" as a returning result, so it is only natural, that once we again step over the breakpoint, the order is directly created in the backend:
A second (or millisecond or what, I was actually too slow to check it fast enough) later, the order ID arrives in my process container and here it is:
As debugging is pretty much an interactive thing, I hope this little introduction just gave you some idea of how this tool is usefull in cases where you really got a problem in a more complex composite process, and you really have no clue why on earth there's not the expected result and orders are not created or people don't get their tasks that they should get....
Enjoy, Thomas.
PS: Thanks to my colleagues Jie Deng and Rajagopalan Narayanan for providing our different demo scenarios in BPM and BRM.
1 Comment
