Why do I sense there is a significant amount of skepticism when it comes to adoption of ccBPM in SAP PI scenarios? The feeling is based on the numerous threads on SDN and many conversations I have had with consultants and customers.So is the feeling mutual? Do you think the same?
Some of the hardline comments that I have come across are, ‘Do not model any of the PI scenarios using BPM. It will decrease performance’, ‘My customer has informed us that we are not supposed to create any ccBPM components’ and the most radical is ‘SAP doesn’t recommend using ccBPM’.
The question that comes to my mind is ‘Why such a feeling amongst a majority of consultants and customers?’. Is it because of their own experience? Or is it because they were told so by others? Is it a myth that has been passed down over the last few years or is that the truth?
My view: It is ‘Full Of Hot Air’. I admit ccBPM was a risky venture in the days of XI 3.0 but we have come way past that. Maybe its a grudge held back by those with burnt fingers that makes them unwilling to accept the capabilities of ccBPM even today. Another thing I have come to believe is that it could be the lack of skill set to develop and support such scenarios that make consultants reluctant. End of it all, it is a bunch of ill informed people that have successfully penetrated the mind of many.
I have been working with PI 7.11 for the last couple of years and we use ccBPM based scenarios on a large scale. Some of them are highly complex in design and are frequently triggered interfaces from a business usage. Guess what? Nobody has complained. You might assume it is only a matter of time before the whole thing comes tumbling down like a pack of cards but I doubt that.
It is about how you choose to design and build your scenarios. There are already a lot of clues available to assist on how this can be done. I suppose most of us overlook the same.
One of the main factor is making the decision of going with a BPM. How do you decide if you really need a BPM as part of your interface design? The trick is KISS! Yes, Keep It Simple, Stupid! If you can avoid a BPM by making minor tweaks and design changes at your source or target end, then this should worth pursuing. The idea is not to overdo, not to over engineer.
A starting point is this. Those come as guidelines to help in the decision making.
Another major factor I believe that attributes to the failure of ccBPM to gain popularity, is handling ccBPM failures (OK… I admit that was a failure from my end at communicating it right). In simple terms what I mean is Error Handling. Writing any good piece of code involves handling exceptions. Assume that is why try-catch in a way is the favorite syntax of many. If a good code needs to have error handling, a good BPM design definitely requires error handling.
Additionally, there are tweaks you can do with respect to your integration process’s performance. A good example is queue assignment. Using this feature has provided us significant improvements in processing times. Along with queue assignments, handling and determining the transactional behaviour is another attribute that boosts performance.
So rest assured, from my personal experience a well built integration process works and delivers what it promises.
Q1: Are you a skeptic? If so, why?
Q2: If you are not a skeptic, how do you make the best out of your integration process? What are your best practices?
ccBPM and the future role of NW BPM
This is something that is slowly gathering moss. One thing is for sure. We are soon to see the death of ccBPM (BPEL based) in PI. A reincarnation if you like it, is in the form of NW BPM getting plugged in providing service orchestration via BPMN. So how is your organization gearing up to this? What is the strategy in place?