topic Re: How to verify user task assignment at runtime? in Alfresco Archive

How to verify user task assignment at runtime?

raj1 — Wed, 04 May 2011 12:03:33 GMT

I have a Business Process with two user tasks ut1 and ut2 namely. Both usertasks have same candidate group Management. After deploying the process, at runtime, the requirement is to ensure that usertasks ut1 and ut2 are preformed by different users in the Candidate groups Management. For e.g. if Ke

Re: How to verify user task assignment at runtime?

heymjo — Wed, 04 May 2011 13:02:30 GMT

i was just looking at this recently, what you describe is the four-eyes principle (but can be extended to any number of eyes really)


<userTask id="payment_execute" name="Execute Payment" >
  <extensionElements>
    <!– upon task creation the listener is called –>
    <activiti:taskListener event="create" class="my.FourEyesTaskListener">
       <!– here we set the id of the other task –>
       <activiti:field name="fourEyesTask" stringValue="payment_approve" />
    </activiti:taskListener>
  </extensionElements>
</userTask>

and the task listener something like


public class FourEyesTaskListener implements TaskListener {

  // injected by activiti
  private String fourEyesTask;

  // see http://www.activiti.org/javadocs/org/activiti/engine/delegate/DelegateTask.html
  public void notify(DelegateTask delegateTask) {
    // find out the user id that executed the four eyes task 
    String userId = ….
    //
    delegateTask.deleteCandidateUser(userId);
  }
}

so yes pretty much as you describe it but i would use deleteCandidateUser instead of unassign so that the second user would never even see the task for assignment, and also the listener runs on 'create' event instead of 'assignment'.

HTH
Jorg

Re: How to verify user task assignment at runtime?

raj1 — Wed, 04 May 2011 18:29:40 GMT

Thanks for your reply. I get the approach but to obtain the user id of the executed task I need to use the History service provided by the Activiti Engine . History service can be accessed via the instance of Process engine using getHistoryService();
How do I obtain the instance of process engine inside the task listener? I am not sure if my understanding is correct.

Please guide me!!!

Re: How to verify user task assignment at runtime?

heymjo — Thu, 05 May 2011 07:09:25 GMT

Well if you use Spring you can make the listener a managed bean and have it wire the historyservice to the listener.

Re: How to verify user task assignment at runtime?

frederikherema1 — Mon, 09 May 2011 09:22:52 GMT

The engine API shouldn't be used from within service-tasks, execution- and tasklisteners now. If you do, it can mess up transactions/connections, especially if you update data that is related to the current process…

Re: How to verify user task assignment at runtime?

raj1 — Mon, 09 May 2011 13:46:45 GMT

Frederikheremans, thanks for your reply.

Is there any work arround available currently in Activiti to achieve the above mentioned requirement of verifying user task assignment at runtime?

Kindly guide me!!!

Re: How to verify user task assignment at runtime?

frederikherema1 — Tue, 10 May 2011 07:23:11 GMT

The only way you achieve this, is to use the internal sessions (you hear it, internal - no guerantees of backward compatibility):


org.activiti.engine.impl.context.Context.getCommandContext()
   .getHistoricTaskInstanceManager()
   ….

Re: How to verify user task assignment at runtime?

heymjo — Wed, 15 Jun 2011 09:07:20 GMT

Hi,

Can you please elaborate on this

The engine API shouldn't be used from within service-tasks, execution- and tasklisteners now. If you do, it can mess up transactions/connections,

It is also said here http://forums.activiti.org/en/viewtopic.php?f=6&t=1353. In what way could connections/transactions be messed up , and if so is that not a serious limitation of the engine ? Introspecting the process from a listener seems something a lot of people will want to do.

My use case is that of four-eyes principle. For this i need to lookup a previously executed task on the same process instance, obtain the user that executed it, and then exclude that user from the candidate users on the current task.

Re: How to verify user task assignment at runtime?

frederikherema1 — Wed, 15 Jun 2011 09:18:18 GMT

When activiti executes a command (for example complete task) it will have a single command-context where modifications to entities are stored. Once the command finishes, all modifications are flushed onto the SQLConnection. Depending on your transaction-strategy, these changes will be comitted.

When you use the API from within a taskListener, you actually execute a new command from within a running command. If the datasource is transaction-aware (in case of spring), you'll use the same connection as the command-context of the calling command. If not, a fresh one is used. In both cases, all changes done in the first command, aren't visible to the second command, since the changes aren't flushed yet.

Most of the time (when reading stuff from activiti in the second API-call) you won't see an issue. But when, eg. the taksListener/executionListener is executed, when other activities are executed before that, that part of the data will be invisible. The same with process/execution-state of the process that is currently running and caling the listener…

I agree that this is a limitation of the system, but exposing the full API from within the context isn't safe (eg. signalling the same process etc. from within the process).

Anyone else thoughts about this?

Re: How to verify user task assignment at runtime?

heymjo — Wed, 15 Jun 2011 10:03:24 GMT

i agree that the processengine cannot be completely reentrant. But there is probably a big portion of the api which is 'safe' to use and it would suffice to just document this.

However, i just tried to let Spring wire the historyservice to a listener bean and it throws a NPE. Looking at the way the activiti spring config works it does not look trivial to avoid this:


  <bean id="myProcessEngineConfiguration" class="org.activiti.spring.SpringProcessEngineConfiguration">
   …..
    <property name="beans">
      <map>
        <entry key="fourEyesTaskListener" value-ref="fourEyesTaskListener"/>
      </map>
    </property>
  </bean>

  <bean id="fourEyesTaskListener" class="my.FourEyesTaskListener"/>

This listener is referenced from the process engine config and will be initialized first. Since the listener holds an @Autowired reference to the ProcessEngine factory bean it will throw NPE because this bean has not been instantiated yet (it is instantiated by the process engine configuration bean) 😐 I might need to resort to a BeanFactoryPostProcessor but it's not so nice a solution.

So i tried going via Context.getCommandContext().getHistoricTaskInstanceManager() but i cannot seem to obtain the specific task as via the historyservice


        HistoricTaskInstance instance = processEngine.getHistoryService().createHistoricTaskInstanceQuery()
                .processInstanceId(delegateTask.getExecution().getProcessInstanceId())
                .taskName(fourEyesTask.getExpressionText()).singleResult();

Re: How to verify user task assignment at runtime?

frederikherema1 — Wed, 15 Jun 2011 14:05:13 GMT

If you remove the "beans" property, ALL spring beans will be available, and than your listener will no longer be a circular reference… (in case you're using the SpringProcessEngineConfiguration) Not sure if this is a good solution for you, just suggesting

Re: How to verify user task assignment at runtime?

heymjo — Mon, 20 Jun 2011 13:39:43 GMT

i'm having a similar issue with defining a BpmnParseListener. They need to be injected in the (Spring)ProcessEngineConfiguration, but if the parselistener depends on the engine itself i get a nullpointer exception because the engine has not been initialized via the ProcessEngineFactoryBean. If i wouldn't use factorybeans i would get circular references instead.


  <bean id="config" class="org.activiti.spring.SpringProcessEngineConfiguration">
    <property name="customPreBPMNParseListeners">
      <util:list>
        <ref bean="userGroupsCheckParseListener"/>
      </util:list>
    </property>
  </bean>

  <bean id="userGroupsCheckParseListener" class="my.UserGroupsCheckParseListener">
    <property name="userGroupsCheckTaskListener">
      <bean class="my.UserGroupsCheckTaskListener"/>
    </property>
  </bean>

and the tasklistener needs the RepositoryService to lookup a ProcessDefinitionEntity.

The springprocessengineconfiguration could add value here maybe by scanning for @PreParseListener, @PostParseListener annotations and add them dynamically. Then again i don't know how often this feature will get used so is there much point ?

Also, doing ProcessEngineConfiguration.getPreParseListeners().add(myparselistener) does not work because the processengine is already initialized. so we cannot dynamically add a parselistener after the processengine has been created, that is a bit suprising but only slightly inconvenient.

Re: How to verify user task assignment at runtime?

frederikherema1 — Mon, 20 Jun 2011 13:42:53 GMT

Once the engine is created, the ProcessEngineConfiguration shouldn't be altered, so adding parselisteners indeed won't do anything…

Don't see much advantage in creating annotations for that, since it's not commonly used…

Re: How to verify user task assignment at runtime?

heymjo — Mon, 20 Jun 2011 14:51:15 GMT

Once the engine is created, the ProcessEngineConfiguration shouldn't be altered

yet adding custom groupmanager and usermanager implementations via the SpringProcessEngineConfiguration requires us to do exactly that, and that's even the "official" way of doing it AFAIK 🙂

Re: How to verify user task assignment at runtime?

frederikherema1 — Mon, 20 Jun 2011 14:57:25 GMT

The official way? Should be added before the buildEngine() is called (the engine is created). In spring, the factory-bean calls the buildEngine method. Adding stuff to it is offcourse possible, but not all configuration is updatable (like the bpmn-listeners, since they are added to the BPMNParser only once, when process-engine is built).

Re: How to verify user task assignment at runtime?

mahavirj — Mon, 20 Jun 2011 17:24:55 GMT

I just tried autowiring the taskService into the listener to perform some task inquiries in the listener and it works ok.

However, as per this discussion, should we not be using engine APIs (within listeners) even for inquiries? This can be quite a limitation:

When you use the API from within a taskListener, you actually execute a new command from within a running command. If the datasource is transaction-aware (in case of spring), you'll use the same connection as the command-context of the calling command. If not, a fresh one is used. In both cases, all changes done in the first command, aren't visible to the second command, since the changes aren't flushed yet

When the datasource is transaction-aware, the same connection is used as the calling command. If the connection is the same across contexts, why can't other changes changes in the context be shared? I mean, this sounds like there is no read-consistency within the same transaction. Maybe flushing those changes in the parent context to the sqlconnection without committing them would solve this? The alternative appears to be to use activiti internals (as frederikheremans points out earlier in this thread) and that's not a good option.

Re: How to verify user task assignment at runtime?

frederikherema1 — Mon, 20 Jun 2011 19:10:32 GMT

As I stated in another thread (somewhere on the forum here, can't remember where ), the changes from a single command are only flushed to the SQLConnection at the end of the command… So even when datasource is transaction-aware (and returning same connection) the changes still won't be visible in eg. a query launched from an executing tasklistener, since they aren't flushed yet.

We can't just commit the changes before, this is done for optimization (creates, updates and deletes are optimized to limit the number of DB-queries).

So you CAN off course use the API from "within" (if you're using spring, the datasource is always transaction aware) as long as you don't WRITE anything related to the process the parent context is operating, this will cause optimistic lock exception and rollback when touching the same entity.

Any way, any input is welcome. Since I answered the API/Context question many times, this indicates this is a frequently used feature and needs to be tackled.

Re: How to verify user task assignment at runtime?

heymjo — Tue, 21 Jun 2011 10:13:07 GMT

I think as a first thing it should be made easier to access the engine services through the listener interface, by providing a reference to them in the callback method signature. Then with javadoc you can mark methods as safe or not, or you handle this in code even if possible.

Re: How to verify user task assignment at runtime?

raki1497 — Wed, 10 Apr 2019 04:50:08 GMT

Am very new to this , can you please explain in detail steps for how to achieve this .

1. I cliked on task listner of userTask B ..... and event on Create and i gave task listner class(which is showing error that class not found exception " my.FourEyesTaskListener")

2. Where to write this class and the below code ... and how to get task A assigne here (String userId = … Is it some thing like task.getAssignee():smileywink: please correct me if am wrong.

public class FourEyesTaskListener implements TaskListener {

// injected by activiti
private String fourEyesTask;

// see http://www.activiti.org/javadocs/org/activiti/engine/delegate/DelegateTask.html
public void notify(DelegateTask delegateTask) {
    // find out the user id that executed the four eyes task
    String userId = ….
    //
    delegateTask.deleteCandidateUser(userId);
}
}

Please help me with some screenshot example.

Re: How to verify user task assignment at runtime?

mdtabrezmca — Wed, 10 Apr 2019 05:20:21 GMT

Hi,

Please have a look at this blog post if you are using APS enterprise.

https://community.alfresco.com/community/bpm/blog/2016/11/16/activiti-enterprise-developer-series-process-and-task-listeners

If you are using activiti 6 and want to accomplish the custom task assignement please use custom taskk listeners

Activiti User Guide

Note: you can use the above code by just annotating it with @componenet steroetype from spring so that you will not get class not found exception.

I hope this much info is useful for you.