Why are most skeptic about ccBPM and its usage in PI?

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?

Assigned tags

Related Blogs

Related Questions

People should stop spreading negative perception about ccBPM in SDN,we have developed almot 40 BPM scenarios for one of my customer,most of the interfaces logic very complex, but till now we never got any negative feed back from client.

Yes it true the some of the customers not interested to use ccBPM in older days, but not now.

pls write one thread in sdn pi forum,so that people stop giving false allegation against ccBPM.

Especially the Java based BP(N)M engine makes us hold back on ABAP based ccBPM processes in order to allow an easy future migration. Furthermore we try to minimize the amount of business logic in the integration middleware. As you said in many cases this can be prevented with small modifications of the backend systems.

Yes. The new kid on the block ‘BPMN’ is causing concerns for customers. When you are required to meet your integration requirements with ccBPM based scenario currently with a knowledge that tomorrow this could be obsolete with no visible migration path (currently) it does get a bit disturbing.

I think the answer here is not to take a hard stand but try an cut down on its usage as seen appropriate.

Hi,I have also done numerus processes in ccBPM. They have all worked out quite nicely. So there is no reason not to use the tool.

From what I learned at SAP TEched will PI 7.31 contain NW BPM. The it should only be the WS* adapter and ccBPM that holds back. If you are planing to upgrade to PI731 soon, I would recommend not developing to many ccBPMs. If you dont have any ccBPMs, it is possible to use the single stack. That said, it cannot be to deficult to recode the interfaces to run on NWBPM instead of ccBPM. It though requires testing.

I agree there are a lot of misconceptions about ccBPM which prejudice many people against using it. Much of this may stem from the early 3.0 days when ccBPM was anything but mature. But this is simply no longer the case.

The new (-ish) user decision step bridges a major gap in the original functionality and should be extremely useful for instance in enhancing exception handling to allow users to signal when data errors have been fixed so the process can proceed.

Above all, an informed decision should be made on a case by case basis whether to orchestrate using ccBPM or in some other component. Blanket decisions to never use ccBPM (made in some organizations I know) are simply nonsense.

As to the future direction of ccBPM, NW BPM, etc: only time will tell exactly what happens, and doubts in this regard should be used as an excuse to not utilize ccBPM where it is appropriate.

Very nice of you to bring up this topic. I have met many avid customer using ccBPM with moderation and creating good value for their company.The core technology behind ccBPM is the good Business Workflow with its strengths and weaknesses. As you pointed in your blog with a few tweaks and good design practices ccBPM can be used as a great tool.

Now, with Netweaver Process Orchestration at our feet the question should be another one: With many critical productive systems relying on ccBPM what are the benefits and fit-gaps to motivate migrations to a single Process Engine?According to the BPM+PI (aka NW Process Orchestration) merging roadmap it would take another 2-3 years for all the use cases from ccBPM to be translated into the single stack platform. What are your thoughts about this?

From what I heard at Teched NW BPM should be fully integrated with PI 7.31. So it will only take ½ year to GA of that platform. Then migrating to 7.31 will take time, and removing the need for the dual stack even longer.

There will from SAP side not be spend more on maintain the ccBPM. All focus is on NW BPM.

If it was as simple matter of rewriting BPEL modeling into BPMN notation would be a smooth migration path, but we know is much more than that.Our ccBPM is tightly integrated to the ABAP core and there will be disruption on the way.Get ready to see this topic in many TechEds to come 😉

no 🙂 I meant “ccBPM” as a functionality of modeling persistent integration flows – NW BPM is not designed for that now, so I don’t want to confuse 🙂 NW BPM in 7.31 is not integrated with PI in terms of modeling, monitoring, etc. so let’s keep those two things separated still 🙂

Hi michal, sorry a so late post, but let me be sure if I understood. In PI 7.31 we can model ussing BPMN but it has a limited functionality regarding to modeling and monitoring. So i the company decides to implemente an standalone and a orchestation scenario arise. what should need to consider? what are the limitations of this engine compare to BPE?

IMHO the mess with ccBPM has been the collect pattern and customers trying to create reporting by collecting tons of data.

Consultants lack the knowledge to know that when you collect and wait, you are taking up memory which means you throttle the processing of the rest of your scenarios. A badly designed ccBPM collecting tons of data makes the server goes down, consultants lay the blame on the product and the circle continues.

What I have learnt is avoid collect pattern in your ccBPM – do it with multiple options available on your Source or just use some simpler logic on XI and the rest of your ccBPM patterns would work perfectly fine.

What would also go a long way is some additional documentation from SAP on Transaction Handling & Queue Management. There seems to be a lack of knowledge in the Consultant space on these topics and also how it affects monitoring of ccBPM’s etc. But with NW 7.3.1, I doubt we will hear any additional stories on the ccBPM. It will die a natural death but for the wrong reasons!

Very well written blog (as usual). We have had issues with Synch Asynch bridge pattterns. We faced time outs quite often when the load was a bit high (say 100 requests in 5 min). First there was a time delay for the BPM to get started meaning the request was received by IE and transferred to BPE but there was a delay in the rage of 5-20 seconds before this message triggered a BPM instance. We eventually ended up tuning the sender and receiver applications in such a way that we dint need the BPM.