Tag: EJB

Posted on

EJB 3.0 and the TransactionAttributeType REQUIRES_NEW

Today I would like to share my experience about the EJB  TransactionAttributeType “REQUIRES_NEW”. The goal of this attribute is to isolate a method from the current transaction context and run the code in a new separate transaction. The transaction attribute can simply be annotated to a method:

@TransactionAttribute(value = TransactionAttributeType.REQUIRES_NEW)
 public void processSingleWorkitem(ItemCollection aWorkitem) {
 workflowService.processWorkItem(aWorkitem);
 }

But this annotation can become a little bit tricky if you need such a construction in a single EJB. Continue reading “EJB 3.0 and the TransactionAttributeType REQUIRES_NEW”

Posted on

Model-Binding versus Method-Binding

The common way to implement an Imixs Workflow application is to bind a business object to a workflow model and process it by calling the Imixs Workflow engine.

  @EJB
  WorkflowService wfm;
  ItemCollection workitem=new ItemCollection();
  .... 
  // set model data
  workitem.replaceItemValue("$modelversion", "1.0.0");
  workitem.replaceItemValue("$processid", 100);
  workitem.replaceItemValue("$activityid", 10);
  // process workitem
  workitem=wfm.processWorkItem(workitem);

We call this a ‘model-binding’ because you bind your business object during the development of your application to a workflow model. This means that you typical first design your workflow model and after that you start implementing your application. So as a developer you know the model and can assign a possible workflow activity into your business object. Imixs Workflow provides different methods to compute the possible workflow activities during runtime so you are not forced to hard code the activities in your code.

THE METHOD-BINDING

But in some cases you might need to follow a different strategy. In a scenario where the modeling process takes place very late, you may not be able to bind your business objects to an workflow activity by assigning an activityID. This situation occurs when you first develop your business methods, and then need to link them to workflow activities of a workflow model. This means that the method call itself identifies the activity in the workflow model to be processed by the workflow engine. So each method call is bound to an workflow activity. We call it the ‘method-binding’. To provide an appropriate model, the process designer need to know the different business methods implemented from the workflow application. So he can bind the method-name directly to the workflow activities of a workflow model.

This kind of late binding enforces to work with Interceptor classes. This concept is a common way in Java EE to implement cross-cutting functionality. So the solution here is to intercept the call of a business method and find the corresponding workflow activity in a model. Then you can process the business object.

 

   @EJB
   WorkflowService wfm;
   ItemCollection workitem=findWorkitem();
   ItemCollection activity=findActivityByMethod(workitem,methodName); 
  .... 
  // set activityid
  workitem.replaceItemValue("$activityid", activity.getItemValueInteger("numActivityID");
  // process workitem
  workitem=wfm.processWorkItem(workitem);

 

Posted on

JPA – WORKING WITH GENERIC VALUE OBJECTS

Working with generic value objects and jpa is shown by the implementation of the ImixsEntityService EJB. This service ejb is provided by the Imixs Workflow Project. It can be used to store objects independent from a specific Entity Bean. Also queries with JPQL are possible.
See: http://www.imixs.org/jee/examples/entityservice.html
Posted on

HIDING ACTIVIES FROM USER

Today I stumbled into an issue with hidden workflow activities. Normally you can simple hide an activity to unauthorized users by adding an application specific access role to the property section ‘Visiblity and Access’. For example you can add the role ‘org.imixs.ACCESSLEVEL.MANAGERACCESS’ to allow only Managers to use this workflow activity.

But this seems not to work. The reason is that the Imixs Modeler stores the read-access restriction into the property ‘namReaders’. And this is no read-access property per default. Only the property ‘$readAccess’ will be recognized by the workflow system to protect workitems.

But the solution is quite simple. You only need to add the field name to the Imixs EntityService Bean declaration from the ejb-jar.xml descriptor:

            <ejb-name>EntityServiceBean</ejb-name>
            <ejb-class>org.imixs.workflow.jee.ejb.EntityServiceBean</ejb-class>
            <session-type>Stateless</session-type>
            <env-entry>
                <description>Additional Reader Field for Workflow Model</description>
                <env-entry-name>READ_ACCESS_FIELDS</env-entry-name>
                <env-entry-type>java.lang.String</env-entry-type>
                <env-entry-value>namreaders</env-entry-value>
            </env-entry>            
        </session>

No the property ‘namReaders’ is treated by the Imixs Workflow System as a reader field.

I think we will change the Imixs Modeler in the next release to support also the default field ‘$readAccess’. So no further configuration will be necesary here.

Proudly powered by WordPress