Guided Procedures Explorations: BPEL Integration – The long answer

[richard_hirsch]

I once asked a question in Use of Aris models for Guided Procedures or VC possible. I never really thought about the reasons behind his answer. I was curious what the long answer might have been but I forgot about it and started exploring other topics.

Recently, I was reading the BPEL4People specification (supported by IBM and SAP) which is an optional extension to BPEL 2.0 that would standardize human tasks in a BPEL process, and I started to think about my old forum post.

I asked myself what might the long answer for my question look like.

A Caveat: I am not a BPEL expert who know the specification (this Blog reflects BPEL 1.1 more than BPEL 2.0) inside and out. So, if this blog contains any errors concerning BPEL, then please yell and scream in the comments.  As mentioned in other blogs, my desire is to start others thinking and discussing these issues.  

Caveat 2:  I am not a SAP “Insider”, so I have no idea what the internal product managers for GP are thinking/doing about this issue.  I do, however, have a Java decompiler and have found some “intriguing” Java classes in the trial version of the 2004s WAS. So, I know that somebody at SAP is looking at this stuff.

Motivation

Let’s first look at my motivation for asking the question.  I was examining the gap between the work of the BPX at a design level and the technical implementation of this design.  SAP Enterprise Modeling Applications by IDS Scheer, so I decided to use it as my starting point.  I knew that ARIS could export BPEL and that there was an interface for Exchange Infrastructure (XI)., so I started looking for information regarding 1) ARIS- Guided Procedure (GP) interaction and 2) BPEL – GP interaction.  I didn’t find anything, so I posted my forum question.

Why the answer is “no”

After reading the BPEL4People specification, it became clear why a complete mapping between BPEL and GP is unlikely.

GP ≠ XI

As I mentioned above, XI has the ability to import BPEL. This means that in general SAP has enough technical knowledge regarding BPEL to provide a BPEL import for GP – if this was technically possible.  The reason that this import functionality doesn’t exist in GP is that BPEL and GP don’t really match well. Furthermore,  XI is not the same product as GP.

If you tried to create a table with the appropriate mappings for BPEL and GP (just a quick attempt), you might end up with a table like this:

BPEL	GP
process	process
sequence	sequential block
flow	parallel block
assign & copy	set parameters for actions
variables	parameter in the process context

Obviously, there are a variety of missing GP elements / mappings. For example:

• Actions are missing.  Actions are sort of similar to BPEL “invoke” elements in that the represent the last process element but they are not web-services.
• Callable Objects are missing as well.
• What about names of certain GP elements (Blocks, etc)? These are not included in the BPEL standard.

Thus, from a technical perspective, a possible BPEL – GP mapping would leave much to be desired.

BPEL is a standard

BPEL and BPEL4People both intend to be standards that are product-independent – this means that the technology of a particular product should not be included/promoted at the expense of other products / technologies.  GP is part of the SAP NetWeaver and includes special features that take advantage of other SAP products/ technologies (BSP, CAF Core, Web Dynpro, etc.). This is also understandable from the perspective of SAP.  If you look at GP, you notice that many of these special features are based on the Callable Object level – the diversity and power of these objects is, in my opinion, what really makes GP stand out.  Thus, although a partial integration of BPEL in GP may be possible at the Process, Block and Action level, a standard will probably be unable to include those SAP-specific objects at the Callable Object level.

Effects of the Developmental Process

In general, the relationship between GP and the design environment of the BPX is still largely undefined.  It is obvious that processes that involve human interaction should in all likelihood be “implemented” using GP. Does this mean, however, that the BPX can change processes in GP that he designed using an external tool (for example, ARIS)?  If this is permitted in GP, there must be round-trip possible from GP to this external tool; otherwise, there will be a discrepancy between the realization in GP and the design in the external tool.  Or do these environments represent different design platforms:  a theoretical and a technical design? Irregardless, this question is still largely unclear and the answers might even be different based on organizational context.

This discussion has an impact of the use of BPEL in GP, because it impacts both the depth and basic characteristics of the relationship (who has the lead – design tool or GP?) (Or are the tool environments placed on equal footing, meaning that changes in both environments must be reflected in the other?) that must reflected in a potential BPEL<->GP implementation.

Repercussions of the “NO”

Based on the realization that a complete BPEL-GP interaction is unlikely what are the repercussions of this supposition?

• Manual interaction with GP User Interfaces (especially the Designtime Environment) is not going away. Evenwith a partial integration of BPEL (perhaps to generate the first version of a process with processes, blocks, actions), someone still has to map actions to callable actions as well as configure other aspects of the process environment (attachments, info objects, etc) that are not included in the BPEL specification. Whether this individual is a BPX or a GP technician might be the subject for another blog.
• As the questions raised in this blog reveal, there are still unanswered questions regarding the role of GP in the NetWeaver environment as well as more fundamental questions regarding the transition of process design to process implementation in an Enterprise SOA environment.

Summary

Thus, the long answer is still basically “NO” but at least I now know why.