topic Re: Using Error Events as general shortcutting solution in Alfresco Archive

Using Error Events as general shortcutting solution

ekolesnikov — Wed, 18 Jun 2014 02:57:53 GMT

Hi guys,Been a while since I last visited forums.We have quite interesting approval process - the "manager" does not just approves or rejects, but also have an option to "escalate" the request (business case being "I have no objections, but I'm not comfortable authorising this on my own") to one or

Re: Using Error Events as general shortcutting solution

martin_grofcik — Wed, 18 Jun 2014 05:08:53 GMT

Hi,

Is it possible to use messages? (http://www.activiti.org/userguide/#bpmnMessageEventDefinition)

Unlike a signal, a message event is always directed at a single receiver.

Regards
Martin

Re: Using Error Events as general shortcutting solution

ekolesnikov — Wed, 18 Jun 2014 06:55:51 GMT

Hi Martin,

Thanks for the swift reply - I'm actually looking at the messages right now. I've used Error events to kick off "Your application has been rejected" event subprocess, which kind of makes sense to me.

My problem with messages is similar to signals - they are definition-specific, rather than instance-specific. I.e. if there are two process instances in the same state and one of them throws an error, I'm sure that only relevant process will be affected. However, I understand that it is possible to overcome this by using service tasks.

From where I am, it looks like the service task is going to be a one-liner:

public void execute(DelegateExecution execution) throws Exception {
execution.getEngineServices().getRuntimeService().messageEventReceived("approval-task-assigned", execution.getId());
}

In my case, the "approval-task-assigned" kicks off the message-activated subprocess that will send an email to the assignee, an email to the initiator and also start the nagging cycle to annoy the heck out of assignee every 7 days. That would mean that sub-process has to have access to all process variables and also be asynchronous. Is it necessary to make the service task async, or messaging is itself asynchronous?

Many thanks.

Re: Using Error Events as general shortcutting solution

ekolesnikov — Thu, 19 Jun 2014 03:38:05 GMT

Ok, so I "kind of" have a solution for that. Frankly, I hate its guts, I believe what I did was wrong and there should be a better way of doing something as simple as this.

What I was trying to achieve was reusable sub-routine that could be called from various steps within the process, with the following capabilities:

1. It should have full access to process instance variables;
2. Event handling should be contained within current process instance.

Using "Call Activity" node failed (1) - it could not access anything from parent process.
Using "Normal" signal start event failed both (1) and (2)
Using event sub-process with message start event (http://www.activiti.org/userguide/#bpmnEventSubprocess : "Activiti only supports Event Sub-Process triggered using an Error Start Event or Message Start Event") did not work for me at all, I was unable to start sub-process by sending message event.

"Real" business case behind all that is described in the OP post: I need "Your request has progressed", "You have a new request, please approve" and "You still have a request to approve, please do it right now!" trio to get started each time process arrives to one of the "approval" or "escalation approval" stages. Implementing it directly will make the whole process look like a bowl of fettuccine (it's already quite complicated, just with its bare functionality) and I would like to avoid it at all costs.

The process definition looks like this: http://www.screencast.com/t/R0IorQnS96D

<code>
<?xml version="1.0" encoding="UTF-8"?>
<definitions xmlns="http://www.omg.org/spec/BPMN/20100524/MODEL" xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance" xmlns:xsd="http://www.w3.org/2001/XMLSchema" xmlns:activiti="http://activiti.org/bpmn" xmlns:bpmndi="http://www.omg.org/spec/BPMN/20100524/DI" xmlnsmgdc="http://www.omg.org/spec/DD/20100524/DC" xmlnsmgdi="http://www.omg.org/spec/DD/20100524/DI" typeLanguage="http://www.w3.org/2001/XMLSchema" expressionLanguage="http://www.w3.org/1999/XPath" targetNamespace="http://www.activiti.org/processdef">
<signal id="approval-task-assigned" name="approval-task-assigned"></signal>
<process id="tester" isExecutable="true">
    <startEvent id="sid-DAA05B35-BF2C-4037-9DB6-4E600A5BDD49"></startEvent>
    <sequenceFlow id="sid-C05B750B-2E48-4A9E-9F38-8D80D232F64A" sourceRef="sid-DAA05B35-BF2C-4037-9DB6-4E600A5BDD49" targetRef="sid-E7959CD3-49FB-455F-B1FB-EF02237B3143"></sequenceFlow>
    <scriptTask id="sid-95C593A2-189C-4650-BAAC-86860CC0E33C" name="Print stuff" scriptFormat="groovy" activiti:autoStoreVariables="false">
      <script>System.err.println(myname + " is soooo cool!")</script>
    </scriptTask>
    <endEvent id="sid-8AC46B0F-7600-4075-AB7B-1FD449EAB0B2"></endEvent>
    <sequenceFlow id="sid-3DFC62F0-52E8-4DF9-9080-227CE4A80D26" sourceRef="sid-8490F6D3-35B2-477D-9C91-498AF1D6027B" targetRef="sid-95C593A2-189C-4650-BAAC-86860CC0E33C"></sequenceFlow>
    <scriptTask id="sid-4DC4085B-D0F9-48EE-9014-BA4E8DA9F37F" name="Set up variable" scriptFormat="groovy" activiti:autoStoreVariables="false">
      <script>execution.setVariable("myname", "scripto");</script>
    </scriptTask>
    <sequenceFlow id="sid-21531192-0351-412A-BCF9-6DB586F625F6" sourceRef="sid-95C593A2-189C-4650-BAAC-86860CC0E33C" targetRef="sid-8AC46B0F-7600-4075-AB7B-1FD449EAB0B2"></sequenceFlow>
    <serviceTask id="sid-8490F6D3-35B2-477D-9C91-498AF1D6027B" name="Kick off subprocess" activiti:class="com.servian.activiti.service.message.MessageDelegate"></serviceTask>
    <sequenceFlow id="sid-AF71E44A-3585-4077-A761-5C7D59DEF6BA" sourceRef="sid-4DC4085B-D0F9-48EE-9014-BA4E8DA9F37F" targetRef="sid-8490F6D3-35B2-477D-9C91-498AF1D6027B"></sequenceFlow>
    <scriptTask id="sid-DE4D72FE-0EF6-445F-9305-3454F12B6504" name="Print stuff" scriptFormat="groovy" activiti:autoStoreVariables="false">
      <script>System.err.println(myname + " is available in subprocess!")</script>
    </scriptTask>
    <sequenceFlow id="sid-3AA8A9EB-DA8E-48CB-A8D5-2158E273F9CC" sourceRef="sid-F2599F55-5FB2-431E-8303-E1A60D9866B5" targetRef="sid-DE4D72FE-0EF6-445F-9305-3454F12B6504"></sequenceFlow>
    <intermediateCatchEvent id="sid-B7623845-A147-4949-91D5-68E7F741930C">
      <signalEventDefinition signalRef="approval-task-assigned"></signalEventDefinition>
    </intermediateCatchEvent>
    <parallelGateway id="sid-E7959CD3-49FB-455F-B1FB-EF02237B3143"></parallelGateway>
    <sequenceFlow id="sid-9A88BB2E-6FC0-40B1-85F4-F01A1A798C68" sourceRef="sid-E7959CD3-49FB-455F-B1FB-EF02237B3143" targetRef="sid-B7623845-A147-4949-91D5-68E7F741930C"></sequenceFlow>
    <parallelGateway id="sid-F2599F55-5FB2-431E-8303-E1A60D9866B5"></parallelGateway>
    <sequenceFlow id="sid-8DFFF4E7-5C95-4473-AB72-85E70C8238EA" sourceRef="sid-B7623845-A147-4949-91D5-68E7F741930C" targetRef="sid-F2599F55-5FB2-431E-8303-E1A60D9866B5"></sequenceFlow>
    <intermediateCatchEvent id="sid-23B344B0-B7BB-4745-A2BC-1A043802748C">
      <timerEventDefinition>
        <timeDuration>PT2S</timeDuration>
      </timerEventDefinition>
    </intermediateCatchEvent>
    <sequenceFlow id="sid-4E1058B3-901C-48E8-8779-861B85394E09" sourceRef="sid-23B344B0-B7BB-4745-A2BC-1A043802748C" targetRef="sid-4DC4085B-D0F9-48EE-9014-BA4E8DA9F37F"></sequenceFlow>
    <sequenceFlow id="sid-30F1215F-DB65-448B-A879-4C70B77880B5" sourceRef="sid-E7959CD3-49FB-455F-B1FB-EF02237B3143" targetRef="sid-23B344B0-B7BB-4745-A2BC-1A043802748C"></sequenceFlow>
    <sequenceFlow id="sid-0A925249-B329-4AB6-B512-7CDFBA8A56EA" sourceRef="sid-F2599F55-5FB2-431E-8303-E1A60D9866B5" targetRef="sid-B7623845-A147-4949-91D5-68E7F741930C"></sequenceFlow>
    <endEvent id="sid-45723BBA-1078-4479-ACE3-5EE15D9ED834"></endEvent>
    <sequenceFlow id="sid-71088E0C-E6C9-4121-9501-AEBB29913270" sourceRef="sid-DE4D72FE-0EF6-445F-9305-3454F12B6504" targetRef="sid-45723BBA-1078-4479-ACE3-5EE15D9ED834"></sequenceFlow>
</process>
</definitions>
</code>

Re: Using Error Events as general shortcutting solution

martin_grofcik — Thu, 19 Jun 2014 06:41:21 GMT

Hi Egor,

Using "Call Activity" node failed (1) - it could not access anything from parent process.

If this is the only issue with call activity, you can create your own org.activiti.engine.impl.el.ExpressionManager and ELResolver to get variables from the process hierarchy.

Regards
Martin

Re: Using Error Events as general shortcutting solution

ekolesnikov — Thu, 19 Jun 2014 07:14:33 GMT

If this is the only issue with call activity, you can create your own org.activiti.engine.impl.el.ExpressionManager and ELResolver to get variables from the process hierarchy.

Hi Martin,

The problem with process hierarchy in Call Activity is that there is no process hierarchy. Calling process is not available via execution.getParentId(); neither it is available through execution.getProcessInstanceId(); which points to sub-process instance ID rather than caller process instance ID.

There is, however, getSuperExecution() method declared on InterpretableExecution interface implemented by Execution and it does point to proper processInstanceId of calling process. However, since it is a part of org.activiti.engine.impl.pvm.runtime package, I'd assume it to be internal, private, undocumented, implementation-specific and prone-to-change-without-notice. Therefore, any client code relying on it would be categorised as a "hack" in my book.

All of that is as of Activiti 5.15.1.

Re: Using Error Events as general shortcutting solution

trademak — Thu, 19 Jun 2014 16:57:58 GMT

You can use the ProcessInstanceQuery to retrieve the parent process of a specific sub process using the subProcessInstanceId method.

Best regards,

Re: Using Error Events as general shortcutting solution

ekolesnikov — Fri, 20 Jun 2014 01:06:12 GMT

You can use the ProcessInstanceQuery to retrieve the parent process of a specific sub process using the subProcessInstanceId method.

"There is no end to it…"
OK, so I am able to resolve parent process from the sub, but there's another issue: there seems to be no way to resolve expressions against parent process:

<code>
private Object resolveVar(Expression expr, DelegateExecution execution, ProcessInstance parent) {
Object result = null;
try {
   //first attempt to resolve on local scope
   result = expr.getValue(execution);
} catch(Exception ex) {
   //if we're in subprocess, check the parent instance.
   if(parent != null) {
    //ERROR - ProcessInstance does not implement VariableScope!
    result = expr.getValue(parent);
   } else {
    throw new ActivitiException("Unable to resolve property and there is no parent scope.", ex);
   }
}
return result;

}
</code>

I'll be working around this issue today - but anyways, any ideas how to overcome this?

For now, I simply "fixed" the offending line by casting ProcessInstance into VariableScope: <code>result = expr.getValue((VariableScope)parent);</code>, but this is basically implementation-specific workaround which will break as soon as you guys decide to change ProcessInstance -> ExecutionEntity <== VariableScopeImpl hierarchy in any future versions.

Re: Using Error Events as general shortcutting solution

trademak — Fri, 20 Jun 2014 07:02:39 GMT

It's really difficult to provide help when you paste a snippet of code without any context. What are you trying to do here? Do you want to get a specific variable value from the parent process instance? Why are you not using the RuntimService getVariable method for that?

Best regards,

Re: Using Error Events as general shortcutting solution

ekolesnikov — Mon, 23 Jun 2014 00:44:27 GMT

Hi Tijs,

Apologies for being ambiguous. What I was trying to do was this:

OK, so I am able to resolve parent process from the sub, but there's another issue: there seems to be no way to resolve expressions against parent process.

What I have now is "request" email and "nagging cycle" of emails running in a sub-process using Service tasks. Some of the tasks need access to parent process variables via expressions (i.e. ${approverFullName} in sub-process with approverFullName defined in parent).

What the code snippet above was all about is that the resolver first tries to resolve the expression in the current execution scope (which works fine because it's represented by the DelegateExpression which implements VariableScope). If it fails, the parent scope is consulted - now that's where I have a problem, because ProcessInstance is not VariableScope.

Re: Using Error Events as general shortcutting solution

trademak — Mon, 30 Jun 2014 15:15:14 GMT

Hi,

So why are you not using the RuntimeService getVariable method to get the approverFullName variable? You can first try via the sub process id and then via the parent process id. That should work, or doesn't it?

Best regards,

Re: Using Error Events as general shortcutting solution

ekolesnikov — Tue, 01 Jul 2014 01:18:35 GMT

Yeah, I ended up mapping parent->child variables through IN parameters of the Call Activity task. Appears to be doing what I want. Thanks a lot!

Re: Using Error Events as general shortcutting solution

bardioc — Wed, 02 Jul 2014 21:04:08 GMT

Hello,

just my two cents here, but have you tried to query the variables via execution.getSuperExecution().getProcessInstance().getId()

We've learned the hard way that in case you have a process started via CallActivity, any execution within the called process has a parentId of null, though a super execution that is present and is the execution of the call activity itself. You can then directly cast this super execution to VariableScope to get the process variables from the super process OR us the above mentioned call to get the super process Id and query the variables directly via Runtime Service.

Regards,

Heiko

Re: Using Error Events as general shortcutting solution

ekolesnikov — Thu, 03 Jul 2014 06:19:41 GMT

Hi Heiko

getSuperExecution() is private API and therefore can not be used in production.

Re: Using Error Events as general shortcutting solution

bardioc — Thu, 03 Jul 2014 07:08:03 GMT

That is your decision of what can be used in production or not. Just because the Activiti developers did not add this to public API, it does not mean it may make sense to do so. You have described yourself how you suffer from the lack of features like this. What you did is (from my perspective) just a workaround for the problem of a too restrictively handled "public" API.

Sometimes you need to use things like that. We have to use it too, because there is actually no other known way to have the same business key available in a process called via call activity as the "parent" (or "super" or how you would like to call it) process has. More importantly, for call activities, there is no parent process, which is indeed odd, cause thats how I (and others too I suppose) understand it. I might be wrong here.

Regards,

Heiko

Re: Using Error Events as general shortcutting solution

ekolesnikov — Fri, 04 Jul 2014 06:36:56 GMT

Hi Heiko

There are two issues discussed in this topic.
First, general ability to access parent process instance and its variables from within call activity listeners and service tasks. This can be achieved by using subProcessInstanceId query which is a proper (although sub-optimal, in my personal opinion) way of doing this.

Second, ability to resolve expressions against parent process. After having internal architecture discussion, we decided this was a bad idea anyway - too many assumptions on what has to be included in the parent process and generally as bad as using un-encapsulated global variables in programming languages. Using IN parameters is the right (and documented) way of doing this - i.e. parent process decides what goes into reusable call activity task.

I can agree on the part that public Activiti APIs appear to be quite restrictive, however, since we are committed to using Activiti as our workflow engine, we have to deal with what we have. It may look appealing to hack one's way by creating implementation-specific code, however, this creates maintainability risk that can cause severe impact on projects' schedules and budgets in future.