joshlong-attic / activiti Goto Github PK

@ProcessVariable String systemId vs. @ProcessVariable("systemId") String systemId.

Eg, we should take advantage of Spring's DefaultParameerNameDiscoverer which in turn makes the decision dynamically by checking the JDK version. NB that Java 8 supports native, safe, non-debug symbol oriented discovery of the class names and this in turn is also exposed through Spring 4's DefaultParameerNameDiscoverer.

The idea is that you should have a component so annotated:

@State ( "process", "state-id")
void handler ( Execution ex, @ProcessVariable long customerId ) {
   // maybe they inject other things that let them set process variables, update them, etc. 

  ex.continue() ;
} 

Optionally,they could specify which process only and let us infer it by convention and the name of the method:

@State( "process") 
public void handleCustomerServiceFulfllment ( ...) {  // method name begets state-id: "customer-service-fulfllment"
}

For example, it would be great if users could just stash process definitions in resources/processes/*xml and then inject a valid ProcessEngine if there's a PlatformTransactionManager, DataSource and so on to create the ProcessEngine in the context. Basically, it should automatically turn on @EnableActiviti for the user, and wire it to look for process definitions in that directory.

It should automatically install Activiti component support like the XML schema does, finding the appropriate DataSource and ProcessEngine in the bean context.

@ProcessHandler triggers support for POJO-centric wait-state handlers.

@Component 
@ProcessHandler("fulfillment") 
class FulfillmentComponent { 

     @State("request-to-external-webservice")
     public void makeRequestToExternalWebService ( Execution execution, @ProcessVariable long customerId){ 
        // ... 
     }

}

Wait-states may both be synchronous (e.g., the wait-state is entered and exited in the same transaction) or asynchronous (e.g., the wait-state is entered in one transaction, and then passivated to disk until such time as somebody signals the execution back into life).

I'm not sure how to handle this. Perhaps we could let the user return a Future<?> whenever the wait-state should be signaled asynchronously?

e.g.,

  // enter wait-state and sleep 
  Future<?> handlerResult = // invoke method 
  Object result = handlerResult.get() 
  // signal wait-state to continue processing 

a bean annotated with @ProcessHandler signals to the Spring Activiti support that this bean should handle wait states with a given name. As a wait state may be entered, sleep, and then be signaled, we should also support this idiom in our API. Thus, a component might look like this:

@Component 
@ProcessHandler("fulfillment")
class FulfillmentComponent { 

      @State("fulfillment-wait-state")
      Future<Customer> sleepWaitStateWhileFutureExecutes( Execution ex, @ProcessVariable long customerId ){ 

      }
}

fire ApplicationContext events on important changes like task completion/deletion

We'll register a global ProcessInstance object that's injectable anywhere that's just a thread-safe proxy for the current globally available ProcessInstance.

@ProcessHandler("fulfillment") 
class StateHandler {

   @Autowired ProcessInstance currentProcessInstance ; // thread-local proxy

    @StartProcess(processKey = "fulfillment") 
      public void beginCustomerFulfllment( @ProcessVariable long customerId ){ 

     }

    @State( waitState = "mail-newsletters") 
    public void mailNewsletters ( ProcessInstance pi ){ 
       //// ...
     }

   @State(waitState = "print-labels") 
    public void fulfillment ( Execution ex, @ProcessVariable long customerId ){ 
       /// ...
    }
}

On startup, there could be an optional (on by default?) check to make sure there are actually processes deployed with that state in it. This is a poor man's compiler check.

we can take advantage of Java 8 support, the default parameter name discover thats also included with Spring 4 and a whole slew of other good stuff. Spring Integration 3 is also a rock solid release and Spring Integration 4's already starting to ship milestones.

Plus, if ever there was a good time to build a workflow-aware fork of Spring @MVC, with the new Link support and web socket support, there's a lot to recommend Spring 4 :)

check to make sure there are actually processes deployed for the given process && state handlers. Otherwise, throw exception.

Optional.

@ProcessHandler("fulfillment") 
class StateHandler {

   @State(waitState = "print-labels") 
    public void fulfillment ( Execution ex ){ 
       /// ...
    }
}

On startup, there could be an optional (on by default?) check to make sure there are actually processes deployed with that state in it. This is a poor man's compiler check.