This 10 minute 55 second podcast from gives you a short introduction to BPEL4People, the joint white paper from SAP and IBM proposing an extension to BPEL to cover human integration in processes. It touches on the following themes:
The podcast is primarily intended for those who want to add BPEL to their vocabularly. Just download the media file and listen to it on your pc's speakers or transfer it to any mp3 player to accompany you on your next jog, shopping expedition...
Many of the podcasts in this series have already taken place with others due to follow, soon:
To read these white papers or to find out about the other standards that SAP supports then you'll find all you want on the standards pages in SDN.
Alan & Ivana
new 16.05.2007 we've added this transcript
Reasonable accurate transcript:
activity, be used to specify the human activities in the process and add a parameter about who should perform them? +
Yes, there are workarounds. And indeed because BPEL does not currently cater for human interaction in the process that is the only way you have of handling it right now. But this simplistic approach compromises the affectivity of the process because it can’t reflect typically human interaction patterns that will occur. There’s a lot of wastage involved and a lot of information lost.
Could you describe the human integration side of things?
Well the human interaction will usually be a lot longer lived, taking minutes or even days or weeks to complete whereas the typical picture of Web Service interaction expects the result to return in an instant. The longevity of the activity leads to serious problems. You – know …How do you ensure that people don’t continue to work on activities that are long since obsolete? This wastage is a significant cost factor..
</i>So why can’t you deal with that by treating the activity simply as an asynchronous interaction or sub-process..</i>
That’s a good rhetorical question, Ivana. We’re both involved in the BPEL-SPE extension authoring, so we both know that although there are similarities between these specifications and indeed can suggest identical mechanisms where appropriate, the differences are still too big to simply delegate the human interaction to a single-activity sub-process.
We haven’t talked about UI aspects so far. The fact that a human participant in a process can see or hear unstructured information and in fact will need some extra governance as to how to process the activity or task and this changes the requirements. There’s an element of ad hoc in the nature of human interaction that we would like to enable in the specification. Vanilla BPEL does not predict the ad hoc nature of human interaction so this opportunity is lost in BPEL processes.
But is this gap so significant that we need a standard to cover it.
It’s a question of consolidating best-practices and expanding the value of BPEL without compromising the independence of those supplying the services. This is particularly important in the Enterprise SOA environment, where both automatic services and people productivity are significant factors.
SAP NetWeaver is committed to standards. And if we locate a significant gap that’s not plugged with a standard, then it’s our responsibility (with our customer’s and their varied investments in mind) to develop the missing standard.
Now Ivana, I’ve painted a very rosy picture of what we’re trying to achieve by developing this specification. Here’s your chance to get us down to reality by describing some of the aspects that are out of scope of this specification.
+Well, there’s a limit to the amount you can describe in a specification without making it too restrictive. We want to enable interoperability between different software vendors but we don’t want to dictate too exactly how things are done because that would stifle creativity beyond the point of being useful. So monitoring, administration, organizational models and the details of how people are assigned to tasks is out-of-scope. In addition, we don’t prescribe how the rendering of the tasks is done. Different companies use different UI technologies and it would be utopian to believe that to enable their particular application to be deployable as a task in a process they have to render it in such and such a way or give it such-and-such an appearance. It is a question of scope, too. We’re keen on delivering the specification, soon and have to be realistic about what we can deliver in the first release.
But let’s get back to the focus of our podcast series… In a previous podcast about BPEL we covered the terminology involved. What are the principle terms in BPEl4People.+
It’s pretty straight forward really.
People activities. These are the human equivalent of invoking a service in BPEL. Tasks, are the equivalent of the services. These are associated with items of work associated with human participants – someone doing the work. The process won’t continue until the task is completed or at least reaches a final state. Notifications on the other hand are items of information sent to participants. Like tasks, there are multilingual aspects associated with the notification because they’re intended for a human recipient. But unlike tasks, they don’t hold up a process in anyway. It’s an important distinction.
Generic Human roles are also described in the paper. These generic roles relate to the way a person interacts with the process, tasks and notifications, one example being the determination of who actually receives a particular task – this role is the potential owner. The process stakeholder is another example of a generic role. Someone who has an interest in seeing that particular process instance through to conclusion, irrespective of the services and tasks invoked along the way. mySAP SRM uses this concept extensively and very successfully.
The paper also describes different typical user interactions in processes such as the 4-eyes principle or nomination. These terms are useful in terms of terminology and making sure everyone is talking about the same thing (as we described in other podcasts) but they are used in the white paper from a scenario (or use-case) point of view to illustrate aspects of the upcoming specification, rather than from a normative point of view.
+One more detailed question: What is so special about Figure 2. in the bpel4people white paper showing the different constellations? +
These different constellations show ways of deployment of BPEL4People. A very important aspect is the non-disruptive transition between automatic services and human execution. It’s a simple statement but the enablement is non-trivial. Particularly, as the specification is adding semantics to BPEL and expanding it’s range. If you look at these constellations you’ll see that there are aspects of BPEL4People which apply above and below the line. In other words to different types of software.
For example the task list client – I guess this is the sort of no-mans land between processes and tasks.
Yes, without taking into account the software landscape the BPEL4people specification would have purely academic value. In the white paper we identified the task list as an entity worthy of special attention. It makes the task life-cycle transparent to the user so if you focus on this you can crystallize out some of the fundamental characteristics of task-behavior that need to be taken into account. For example, the issue of ad hoc attachments makes it clear that there are run-time aspects that need to be considered, as well as the design-time.
+Wrapping up, why did SAP and IBM partner on this paper? +
IBM and SAP have had a longstanding partnership and provide complementary components for many customer solutions. This reflects more than 30 years of leadership. In fact, SAP and IBM joint solutions are at work at more than 10,000 sites around the globe. With this background it is not surprising that both companies have a common view of requirements and similar priorities for driving solutions, so we have collaborated on standards, including WS-BPEL, WS-Addressing, WS-Policy and SCA.
Simply to speed up the process of development of such specifications, in case we worked directly with each other the initial proposal.
+Thank you Alan, that concludes this podcast – the next podcast will talk about the second SAP/IBM white paper, BPEL-SPE – The BPEL Sub-Process Extension enabling process-fragment re-use.
Thank you for listening, and enjoy the rest of your day.+
- Basic BPEL4People terminology
- Differences and similarities between traditional workflow and BPEL
- Ways in which users play a role in executable processes
- Constellations covered by the BPEL4People white paper
- The standardization process itself
- Work-arounds to enable humans to perform tasks in standard BPEL processes
The podcast is primarily intended for those who want to add BPEL to their vocabularly. Just download the media file and listen to it on your pc's speakers or transfer it to any mp3 player to accompany you on your next jog, shopping expedition...
Many of the podcasts in this series have already taken place with others due to follow, soon:
- [BPEL in a nutshell | BPEL in a Nutshell]
- BPEL4People - Explanation of the joint SAP/IBM human-participation white paper (you're reading it)
- BPEL-SPE - Explanation of the joint SAP/IBM sub-proces white paper
To read these white papers or to find out about the other standards that SAP supports then you'll find all you want on the standards pages in SDN.
Alan & Ivana
new 16.05.2007 we've added this transcript
Reasonable accurate transcript:
activity, be used to specify the human activities in the process and add a parameter about who should perform them? +
Yes, there are workarounds. And indeed because BPEL does not currently cater for human interaction in the process that is the only way you have of handling it right now. But this simplistic approach compromises the affectivity of the process because it can’t reflect typically human interaction patterns that will occur. There’s a lot of wastage involved and a lot of information lost.
Could you describe the human integration side of things?
Well the human interaction will usually be a lot longer lived, taking minutes or even days or weeks to complete whereas the typical picture of Web Service interaction expects the result to return in an instant. The longevity of the activity leads to serious problems. You – know …How do you ensure that people don’t continue to work on activities that are long since obsolete? This wastage is a significant cost factor..
</i>So why can’t you deal with that by treating the activity simply as an asynchronous interaction or sub-process..</i>
That’s a good rhetorical question, Ivana. We’re both involved in the BPEL-SPE extension authoring, so we both know that although there are similarities between these specifications and indeed can suggest identical mechanisms where appropriate, the differences are still too big to simply delegate the human interaction to a single-activity sub-process.
We haven’t talked about UI aspects so far. The fact that a human participant in a process can see or hear unstructured information and in fact will need some extra governance as to how to process the activity or task and this changes the requirements. There’s an element of ad hoc in the nature of human interaction that we would like to enable in the specification. Vanilla BPEL does not predict the ad hoc nature of human interaction so this opportunity is lost in BPEL processes.
But is this gap so significant that we need a standard to cover it.
It’s a question of consolidating best-practices and expanding the value of BPEL without compromising the independence of those supplying the services. This is particularly important in the Enterprise SOA environment, where both automatic services and people productivity are significant factors.
SAP NetWeaver is committed to standards. And if we locate a significant gap that’s not plugged with a standard, then it’s our responsibility (with our customer’s and their varied investments in mind) to develop the missing standard.
Now Ivana, I’ve painted a very rosy picture of what we’re trying to achieve by developing this specification. Here’s your chance to get us down to reality by describing some of the aspects that are out of scope of this specification.
+Well, there’s a limit to the amount you can describe in a specification without making it too restrictive. We want to enable interoperability between different software vendors but we don’t want to dictate too exactly how things are done because that would stifle creativity beyond the point of being useful. So monitoring, administration, organizational models and the details of how people are assigned to tasks is out-of-scope. In addition, we don’t prescribe how the rendering of the tasks is done. Different companies use different UI technologies and it would be utopian to believe that to enable their particular application to be deployable as a task in a process they have to render it in such and such a way or give it such-and-such an appearance. It is a question of scope, too. We’re keen on delivering the specification, soon and have to be realistic about what we can deliver in the first release.
But let’s get back to the focus of our podcast series… In a previous podcast about BPEL we covered the terminology involved. What are the principle terms in BPEl4People.+
It’s pretty straight forward really.
People activities. These are the human equivalent of invoking a service in BPEL. Tasks, are the equivalent of the services. These are associated with items of work associated with human participants – someone doing the work. The process won’t continue until the task is completed or at least reaches a final state. Notifications on the other hand are items of information sent to participants. Like tasks, there are multilingual aspects associated with the notification because they’re intended for a human recipient. But unlike tasks, they don’t hold up a process in anyway. It’s an important distinction.
Generic Human roles are also described in the paper. These generic roles relate to the way a person interacts with the process, tasks and notifications, one example being the determination of who actually receives a particular task – this role is the potential owner. The process stakeholder is another example of a generic role. Someone who has an interest in seeing that particular process instance through to conclusion, irrespective of the services and tasks invoked along the way. mySAP SRM uses this concept extensively and very successfully.
The paper also describes different typical user interactions in processes such as the 4-eyes principle or nomination. These terms are useful in terms of terminology and making sure everyone is talking about the same thing (as we described in other podcasts) but they are used in the white paper from a scenario (or use-case) point of view to illustrate aspects of the upcoming specification, rather than from a normative point of view.
+One more detailed question: What is so special about Figure 2. in the bpel4people white paper showing the different constellations? +
These different constellations show ways of deployment of BPEL4People. A very important aspect is the non-disruptive transition between automatic services and human execution. It’s a simple statement but the enablement is non-trivial. Particularly, as the specification is adding semantics to BPEL and expanding it’s range. If you look at these constellations you’ll see that there are aspects of BPEL4People which apply above and below the line. In other words to different types of software.
For example the task list client – I guess this is the sort of no-mans land between processes and tasks.
Yes, without taking into account the software landscape the BPEL4people specification would have purely academic value. In the white paper we identified the task list as an entity worthy of special attention. It makes the task life-cycle transparent to the user so if you focus on this you can crystallize out some of the fundamental characteristics of task-behavior that need to be taken into account. For example, the issue of ad hoc attachments makes it clear that there are run-time aspects that need to be considered, as well as the design-time.
+Wrapping up, why did SAP and IBM partner on this paper? +
IBM and SAP have had a longstanding partnership and provide complementary components for many customer solutions. This reflects more than 30 years of leadership. In fact, SAP and IBM joint solutions are at work at more than 10,000 sites around the globe. With this background it is not surprising that both companies have a common view of requirements and similar priorities for driving solutions, so we have collaborated on standards, including WS-BPEL, WS-Addressing, WS-Policy and SCA.
Simply to speed up the process of development of such specifications, in case we worked directly with each other the initial proposal.
+Thank you Alan, that concludes this podcast – the next podcast will talk about the second SAP/IBM white paper, BPEL-SPE – The BPEL Sub-Process Extension enabling process-fragment re-use.
Thank you for listening, and enjoy the rest of your day.+
2 Comments
