anchor.diff:  
   ==== Working with @BusinessProcessScoped beans
   
  -Using flowable-cdi, the lifecycle of a bean can be bound to a process instance. To this extend, a custom context implementation is provided, namely the BusinessProcessContext. Instances of BusinessProcessScoped beans are stored as process variables in the current process instance. BusinessProcessScoped beans need to be PassivationCapable (for example Serializable). The following is an example of a process scoped bean:
  +Using flowable-cdi, the lifecycle of a bean can be bound to a process instance. To this extent, a custom context implementation is provided, namely the +BusinessProcessContext+. Instances of +BusinessProcessScoped+ beans are stored as process variables in the current process instance. +BusinessProcessScoped+ beans need to be +PassivationCapable+ (for example +Serializable+). The following is an example of a process scoped bean:
   
   [source,java,linenums]
   ----
  
positive.code: 
  This observer would be notified of all events. If we want to restrict the set of events the observer receives, we can add qualifier annotations:
  		
  * ++@BusinessProcess++: restricts the set of events to a certain  process definition. Example: +@Observes @BusinessProcess("billingProcess") BusinessProcessEvent evt+
  * ++@StartActivity++: restricts the set of events by a certain activity. For example:  +@Observes @StartActivity("shipGoods") BusinessProcessEvent evt+ is invoke whenever an activity with the  id "shipGoods" is entered. 	  		
  * ++@EndActivity++: restricts the set of events by a certain activity. For example:  +@Observes @EndActivity("shipGoods") BusinessProcessEvent evt+ is invoke whenever an activity with the  id "shipGoods" is left. 	  		
  * ++@TakeTransition++: restricts the set of events by a certain transition.
  * ++@CreateTask++: restricts the set of events by a certain task's creation.
  * ++@DeleteTask++: restricts the set of events by a certain task's deletion.
  * ++@AssignTask++: restricts the set of events by a certain task's assignment.
  * ++@CompleteTask++: restricts the set of events by a certain task's completion.
  	  		
  The qualifiers named above can be combined freely. For example, in order to receive all events generated when  leaving the "shipGoods" activity in the "shipmentProcess", we could write the following observer method:
  
  [source,java,linenums]
  ----
  public void beforeShippingGoods(@Observes @BusinessProcess("shippingProcess") @EndActivity("shipGoods") BusinessProcessEvent evt) {
  	// handle event
  }	  	  	
  ----
  
  In the default configuration, event listeners are invoked synchronously and in the context of the same transaction. CDI transactional observers (only available in combination with JavaEE / EJB), allow to control  when the event is handed to the observer method. Using transactional observers, we can for example assure that an observer is only  notified if the transaction in which the event is fired succeeds: 
  
  [source,java,linenums]
  ----
  public void onShipmentSuceeded(@Observes(during=TransactionPhase.AFTER_SUCCESS) @BusinessProcess("shippingProcess") @EndActivity("shipGoods") BusinessProcessEvent evt) {
  	// send email to customer.
  }	  	
  ----
  
  
  ==== Additional Features
  
  
  * The ProcessEngine as well as the services are available for injection: +@Inject ProcessEngine, RepositoryService, TaskService+, ...
  * The current process instance and task can be injected: +@Inject ProcessInstance, Task+,
  * The current business key can be injected:  +@Inject @BusinessKey String businessKey+,
  * The current process instance id be injected:  +@Inject @ProcessInstanceId String pid+,
  
  === Known Limitations
  
  
  Although flowable-cdi is implemented against the SPI and designed to be a "portable-extension" it is only tested using Weld.	  	 
  	  	
  
  
negative.code: 
  === Setting up flowable-cdi
  
  Flowable-cdi can be set up in different environments. In this section we briefly walk through the configuration options.
  
  
  ==== Looking up a Process Engine
  
  The CDI extension needs to get access to a +ProcessEngine+. To achieve this, an implementation of the interface +org.flowable.cdi.spi.ProcessEngineLookup+ is looked up at runtime. The CDI module ships with a default implementation named +org.flowable.cdi.impl.LocalProcessEngineLookup+, which uses the ++ProcessEngines++-Utility class for looking up the ProcessEngine. In the default configuration +$$ProcessEngines#NAME_DEFAULT$$+ is used to look up the +ProcessEngine+. This class might be subclassed to set a custom name. NOTE: You need a +flowable.cfg.xml+ configuration on the classpath.
  	
  Flowable-cdi uses a +java.util.ServiceLoader+ SPI for resolving an instance of +org.flowable.cdi.spi.ProcessEngineLookup+. In order to provide a custom implementation of the interface, we need to add a plain text file named +META-INF/services/org.flowable.cdi.spi.ProcessEngineLookup+ to our deployment, in which we specify the fully qualified class name of the implementation. 
  
  [NOTE]
  ====
  If you do not provide a custom +org.flowable.cdi.spi.ProcessEngineLookup+ implementation, Flowable will use the default +LocalProcessEngineLookup+ implementation. In that case, all you need to do is providing a flowable.cfg.xml file on the classpath (see next section).
  