NetWeaver PI - I want my ccBPM's back!

[js2]

I probably won't make too many friends with this blog, but in any case I wanted to voice my concerns about where PI is...

Firstly, I've been using PI (PO, XI and whatever else it's called this month) since version XI3.0 first became available quite a few years ago. I've probably built several hundred interfaces to-date and have always been a staunch supporter of the product. So long as an interface is designed appropriately, PI can do many things that others say it can't.

The product has come a long way since those early days and the new development environment with iFlows in eclipse is fantastic. Once you are used to it, it's far better than navigating the Directory tree and managing heaps of receiver determination and interface determinations, and even ICO's (integrated Configuration Objects).

For stateful processing, PI used to have ccBPM as the integrated BPM tool. It was based on ABAP-stack Business Workflow, although this was largely hidden from the development environment. It definitely had its issues, but it worked and was nicely integrated into the toolset.

Now with the java-only versions of PI we have PO which includes NetWeaver BPM as a replacement for ccBPM (it can do more but here I'm only talking about interfacing). SAP have kind of taken away our ccBPM and then made us pay to get it back as NW BPM.

I've been playing around with the combination of PI and BPM (as a PO install) for a couple of months now and have the following points to make:

• Even though PI and BPM are on the one system, they are not integrated well (if at all). In fact in the latest sp the integration is nothing more than the message id.
• BPM uses a very clunky java build process with software components and development components that don't match nicely with PI's SLD based software logistics.
• What you would think are core use-cases fail in BPM. For example a web service call from a BPM process step, through PI, resulting in a soap-fault crashes the BPM process. This is a known fault and SAP have been working on a fix for about 4+ weeks now.
• The development environment is clunky. There is a known bug where sometimes your deployed BPM process is always one version behind.
• The BPM history is next to useless for a developer and you constantly need to be checking the java traces.
• For logging purposes during build you need to write your own java beans as the context variable display is not enough.
• I honestly don't believe it's a production grade system yet (although I'm sure their are customers using it).

As a staunch supporter of the PI product for years now, its disappointing that it seems to have taken a leap backwards here. I never thought I'd say it, but I want my ccBPM's back. It just makes it harder to defend the product with the constant barrage of un-informed information from SI's about how we should use WebSphere, Tibco, or whatever else...

What SAP need to do (and quickly):

1. Get rid of the BPM software component, development component, NWDI (yuck!) nonsense and bring it inline to how PI manages objects.
2. Integrate the logs asap. From the PI message monitor I want to be able to click a link to view a graphical log of any BPM process.
3. Fix up the bugs around soap faults (SAP have this underway, but it was promised a few weeks ago and its not ready yet - how could they release the software in that state?).
4. The BPM process history needs to be greatly expanded to show "actual", "useful" error messages and not just "an error occurred" (that's rubbish SAP!). Developers also need the capability to fully inspect data elements throughout the process and not just 'data objects' that have been placed in the process.

Enough of a rant from me... I'm sure the product will be more integrated and more bug-free as time goes on, but for those of us at the coalface who are evangelising the use of PI/PO, it certainly makes life more difficult right now.