{children:excerpt=true}
* How to add an extended activity in a BPEL process?
The [WS-BPEL 2.0 standard|http://docs.oasis-open.org/wsbpel/2.0/Primer/wsbpel-v2.0-Primer.pdf] provides the possibility to add activities for specific usage. These extensions can be formalized in a BPEL process with the following mechanism:
We define an extension as following:
{code:xml}
<bpel:extensions>
<bpel:extension
namespace="http://easybpel.ebmwebsourcing.com/extension/oneextension"
mustUnderstand="yes">
</bpel:extension>
</bpel:extensions>
{code}
The namespace attribute corresponds to the namespace of the extended activity. The mustUnderstand attribute specifies if the BPEL engine must understand the extended
activity (that is mandatory for the process to be successfully executed) or if it can ignores it (i.e. a debug activity).
Then the extended activity can be placed in the BPEL process, embedded in a {{<bpel:extensionActivity></bpel:extensionActivity>}} couple of tags.
* How to implement an extended activity in EasyBPEL?
As EasyBPEL is put upon EasyVIPER, an extended behavior is expected to be developed for each extended activity in EasyBPEL.
First we consider an extended behavior is available (see the specific how-to on EasyVIPER page (TODO link to easyviper how to)).
The following figure shows this principle of EasyBPEL activity mapped into an EasyVIPER behaviour. For the *Invoke* activity defined in the BPEL specification, a corresponding *Send* behavior has been implemented in EasyVIPER. In a same way, any extended activity defined at EasyBPEL level corresponds to an extended behavior at EasyVIPER level.
!extended_activity.gif|border=1!
An extended activity implementation must be composed of a JAVA interface extending the {{ExtendedActivity}} interface:
{code:title=MyExtendedActivity.java|borderStyle=solid}
import com.ebmwebsourcing.easybpel.model.bpel.api.activity.extension.ExtendedActivity;
public interface MyExtendedActivity extends ExtendedActivity {
//Some specific stuff related to MyExtendedActivity
}
{code}
A JAVA class must implement this {{MyExtendedActivity}} interface:
{code:title=MyExtendedActivityImpl.java|borderStyle=solid}
...
import mypackage.MyExtendedActivity;
...
@org.oasisopen.sca.annotation.Scope("COMPOSITE")
@org.oasisopen.sca.annotation.Service(value=MyExtendedActivity.class,names="service")
@PolicySets("frascati:scaEasyPrimitive")
public class MyExtendedActivityImpl extends DebugPackageExtendedActivityImpl<TMyExtendedActivity> implements MyExtendedActivity {
}
{code}
* How to add an extended activity in a BPEL process?
The [WS-BPEL 2.0 standard|http://docs.oasis-open.org/wsbpel/2.0/Primer/wsbpel-v2.0-Primer.pdf] provides the possibility to add activities for specific usage. These extensions can be formalized in a BPEL process with the following mechanism:
We define an extension as following:
{code:xml}
<bpel:extensions>
<bpel:extension
namespace="http://easybpel.ebmwebsourcing.com/extension/oneextension"
mustUnderstand="yes">
</bpel:extension>
</bpel:extensions>
{code}
The namespace attribute corresponds to the namespace of the extended activity. The mustUnderstand attribute specifies if the BPEL engine must understand the extended
activity (that is mandatory for the process to be successfully executed) or if it can ignores it (i.e. a debug activity).
Then the extended activity can be placed in the BPEL process, embedded in a {{<bpel:extensionActivity></bpel:extensionActivity>}} couple of tags.
* How to implement an extended activity in EasyBPEL?
As EasyBPEL is put upon EasyVIPER, an extended behavior is expected to be developed for each extended activity in EasyBPEL.
First we consider an extended behavior is available (see the specific how-to on EasyVIPER page (TODO link to easyviper how to)).
The following figure shows this principle of EasyBPEL activity mapped into an EasyVIPER behaviour. For the *Invoke* activity defined in the BPEL specification, a corresponding *Send* behavior has been implemented in EasyVIPER. In a same way, any extended activity defined at EasyBPEL level corresponds to an extended behavior at EasyVIPER level.
!extended_activity.gif|border=1!
An extended activity implementation must be composed of a JAVA interface extending the {{ExtendedActivity}} interface:
{code:title=MyExtendedActivity.java|borderStyle=solid}
import com.ebmwebsourcing.easybpel.model.bpel.api.activity.extension.ExtendedActivity;
public interface MyExtendedActivity extends ExtendedActivity {
//Some specific stuff related to MyExtendedActivity
}
{code}
A JAVA class must implement this {{MyExtendedActivity}} interface:
{code:title=MyExtendedActivityImpl.java|borderStyle=solid}
...
import mypackage.MyExtendedActivity;
...
@org.oasisopen.sca.annotation.Scope("COMPOSITE")
@org.oasisopen.sca.annotation.Service(value=MyExtendedActivity.class,names="service")
@PolicySets("frascati:scaEasyPrimitive")
public class MyExtendedActivityImpl extends DebugPackageExtendedActivityImpl<TMyExtendedActivity> implements MyExtendedActivity {
}
{code}