Month: January 2015

Posted on

Drag & Drop Fileuploads with Imixs-Workflow

With the latest Update of the Imixs-Workflow the project now supports Drag&Drop functionallity for FileUplods. The Imixs-Web-Tool libray provide several JSF Components for building workflow forms fast and easy. The library extends the functionality of the FileUpload Component.

Files which where uploaded can now be viewed in the browser before they are persisted by the Imixs-Workflow Engine. The new FileUpload widget includes the jquery fileupload plugin and supports most browser platforms.

In different to most other frameworks Imixs-Workflow persists files with an access-control-list (ACL). This ACL can be configured by the Workflow Model and restricts access to files for different actors. Each process instance controlled by Imixs-Workflow can have an individual access list. With this functionality also confidential documents can be controlled by the Workflow Engine.

The integration of the new FileUpload control is quite simple as Imixs-Workflow provides a custom tag library:

<i:imixsFileUpload workitem="#{workflowController.workitem}"
   context_url="#{facesContext.externalContext.requestContextPath}/rest/workflow/workitem/#{workflowController.workitem.item['$uniqueid']}" />

The component can be tested within the Imixs Sample Web Application.

imixs_fileupload_032

 

 

Posted on

Building transaction save business logic

As I posted in my last blog about JSF and Transactioncontext, it is importend to keep the transaction context in mind when developing a business application within JSF. When you use the Imixs-Workflow Engine you normaly don’t need to think about transactions because Imixs-Workflow takes care about processing a workitem in a full controlled transaction context. But developing with JSF can lead into situations where the business logic is not allways encapsulated correctly in a single transaction. Look at the following example of an Imixs-Workflow web application based on JSF:

//jsf bean...
@EJB WorkflowService workflowService;
...
public String process(ItemCollection workitem) {
 workitem=workflowService.process(workitem);
 // evaluate result and trigger another process step...
 if (workitem.getItemValueString('department').equals('finance')) {
    workitem.replaceItemValue('$activity',APPROVE_BY_MANAGEMENT);
    workitem=workflowService.process(workitem);
 }
 ....
}

In this example, the process method of the front-end controller evaluates the result of a process step and calls a second process for the same business object. Now you have the problem that the workflowService will run in two separate transactions. As I mentioned in my blog this can result into unexpected database results.

When you are working with Imixs-Workflow, the solution is quite simple: Just put your business logic into Imixs-Workflow Plugi-In. Plug-Ins are always controlled by the WorkflowManager and called inside a single transaction. So there is no risk that your business process runs in an undefined context.

Proudly powered by WordPress