<?xml version="1.0" encoding="UTF-8"?>
<rss xmlns:content="http://purl.org/rss/1.0/modules/content/" xmlns:dc="http://purl.org/dc/elements/1.1/" xmlns:rdf="http://www.w3.org/1999/02/22-rdf-syntax-ns#" xmlns:taxo="http://purl.org/rss/1.0/modules/taxonomy/" version="2.0">
  <channel>
    <title>topic Re: Activiti 5.22: Message-Cancelled Call Activity doesn't fire subprocess PROCESS_CANCELLED in Alfresco Forum</title>
    <link>https://connect.hyland.com/t5/alfresco-forum/activiti-5-22-message-cancelled-call-activity-doesn-t-fire/m-p/40134#M16827</link>
    <description>&lt;HTML&gt;&lt;HEAD&gt;&lt;/HEAD&gt;&lt;BODY&gt;&lt;P&gt;With no response from either Alfresco or the community regarding this question, we did arrive at a solution.&amp;nbsp; That solution, however, is horribly ugly in my opinion.&lt;/P&gt;&lt;P&gt;&lt;/P&gt;&lt;P&gt;What we did was add a manual input variable to&amp;nbsp;&lt;EM&gt;every&lt;/EM&gt; Call Actvity where the subprocess is an "order" and will contain our completeEventTrackingId.&amp;nbsp; &amp;nbsp;That variable is something like "parentCallActivityElementId" and contains the same ID as that Call Activity element, obviously.&amp;nbsp; For example, if the element ID is "subCompleteTitleOrder", then we'll have an input variable of parentCallActivityElementId="subCompleteTitleOrder".&amp;nbsp; This requires all of our BPM developers to perform this extra design step.&amp;nbsp; (Yes, we could modify the XML at deployment time, but we aren't quite there yet.)&lt;/P&gt;&lt;P&gt;&lt;/P&gt;&lt;P&gt;When "PROCESS_START" fires on the subprocess, we look for a process variable named "parentCallActivityElementId".&amp;nbsp; If it is found, we retrieve the parent process, and create a variable that follows the convention, in this case, of subCompleteTitleOrder&lt;STRONG&gt;_pid&lt;/STRONG&gt; and store the&amp;nbsp;&lt;EM&gt;subprocess'&amp;nbsp;&lt;/EM&gt;processInstanceId on it.&amp;nbsp; Note that the convention is "parent Call Activity element ID" plus underscore plus "pid" to hold that value.&lt;/P&gt;&lt;P&gt;&lt;/P&gt;&lt;P&gt;When the parent Call Activity is&amp;nbsp;&lt;EM&gt;cancelled &lt;/EM&gt;(either by a boundary event or by the parent process being canceled), the listener point "ACTIVITY_CANCELLED" does fire for any &lt;EM&gt;open, unfinished&lt;/EM&gt;&amp;nbsp;elements.&amp;nbsp; We check to see if it's of the Call Activity type and, if so, we grab that element ID, then look for convention-based "thatId_&lt;EM&gt;pid"&lt;/EM&gt; process variable (in this case: "&lt;SPAN&gt;subCompleteTitleOrder&lt;/SPAN&gt;&lt;STRONG&gt;_pid")&lt;/STRONG&gt; in the containing process.&amp;nbsp; If it's found, then we can grab (either from live or historical process search) for that sub-processInstanceId, look for the completeEventTrackingId variable on that subprocess... and fire our postProcessEnded() custom function that closes that task ID in the legacy system.&lt;/P&gt;&lt;P&gt;&lt;/P&gt;&lt;P&gt;A couple of points here that I can see for improvement for Activiti:&lt;/P&gt;&lt;OL&gt;&lt;LI&gt;When a process is cancelled, regardless of how it is spawned (Process self-terminates, Call Activiti cancelled, Parent Process is cancelled, boundary events, etc.) that PROCESS_CANCELLED is fired.&amp;nbsp; In our opinion, this is a bug, that cancelled Call Activities don't fire PROCESS_CANCELLED on their spawned subprocesses.&lt;/LI&gt;&lt;LI&gt;It would nice if there was a way to be able to configure the input/output variables for a Call Activity at runtime.&amp;nbsp; If there's a way, we couldn't find it.&lt;/LI&gt;&lt;LI&gt;We know that when a subprocess ends, that control is returned to the parent process and the Call Activity ends and the flow moves on.&amp;nbsp; There is&amp;nbsp;&lt;EM&gt;obviously&lt;/EM&gt; a connection between a Call Activity and it's spawned process.&amp;nbsp; But there seems to be no way at runtime to obtain the spawned sub-processInstanceId.&amp;nbsp; At least not that is publicly exposed.&amp;nbsp; Adding the abiltity to ask the Call Activity, when it ends, "what was the processInstanceId of the process you spawned?" would be mighty helpful.&amp;nbsp; Or even to have access to the sub-process' variables would be even better, without having to specifically create an output variable, which, again, seems impossible to modify at runtime.&lt;/LI&gt;&lt;/OL&gt;&lt;/BODY&gt;&lt;/HTML&gt;</description>
    <pubDate>Thu, 13 Sep 2018 16:31:35 GMT</pubDate>
    <dc:creator>willb</dc:creator>
    <dc:date>2018-09-13T16:31:35Z</dc:date>
    <item>
      <title>Activiti 5.22: Message-Cancelled Call Activity doesn't fire subprocess PROCESS_CANCELLED</title>
      <link>https://connect.hyland.com/t5/alfresco-forum/activiti-5-22-message-cancelled-call-activity-doesn-t-fire/m-p/40133#M16826</link>
      <description>(Title originally indicated v5.18, but we are on 5.22).When a process instance ends via an end event a PROCESS_COMPLETE listener event fires.&amp;nbsp; If the process hits a terminate end event PROCESS_CANCELLED fires.When that subprocess is the result of a Call Activity and the Call Activity receives a boun</description>
      <pubDate>Wed, 29 Aug 2018 13:52:23 GMT</pubDate>
      <guid>https://connect.hyland.com/t5/alfresco-forum/activiti-5-22-message-cancelled-call-activity-doesn-t-fire/m-p/40133#M16826</guid>
      <dc:creator>willb</dc:creator>
      <dc:date>2018-08-29T13:52:23Z</dc:date>
    </item>
    <item>
      <title>Re: Activiti 5.22: Message-Cancelled Call Activity doesn't fire subprocess PROCESS_CANCELLED</title>
      <link>https://connect.hyland.com/t5/alfresco-forum/activiti-5-22-message-cancelled-call-activity-doesn-t-fire/m-p/40134#M16827</link>
      <description>&lt;HTML&gt;&lt;HEAD&gt;&lt;/HEAD&gt;&lt;BODY&gt;&lt;P&gt;With no response from either Alfresco or the community regarding this question, we did arrive at a solution.&amp;nbsp; That solution, however, is horribly ugly in my opinion.&lt;/P&gt;&lt;P&gt;&lt;/P&gt;&lt;P&gt;What we did was add a manual input variable to&amp;nbsp;&lt;EM&gt;every&lt;/EM&gt; Call Actvity where the subprocess is an "order" and will contain our completeEventTrackingId.&amp;nbsp; &amp;nbsp;That variable is something like "parentCallActivityElementId" and contains the same ID as that Call Activity element, obviously.&amp;nbsp; For example, if the element ID is "subCompleteTitleOrder", then we'll have an input variable of parentCallActivityElementId="subCompleteTitleOrder".&amp;nbsp; This requires all of our BPM developers to perform this extra design step.&amp;nbsp; (Yes, we could modify the XML at deployment time, but we aren't quite there yet.)&lt;/P&gt;&lt;P&gt;&lt;/P&gt;&lt;P&gt;When "PROCESS_START" fires on the subprocess, we look for a process variable named "parentCallActivityElementId".&amp;nbsp; If it is found, we retrieve the parent process, and create a variable that follows the convention, in this case, of subCompleteTitleOrder&lt;STRONG&gt;_pid&lt;/STRONG&gt; and store the&amp;nbsp;&lt;EM&gt;subprocess'&amp;nbsp;&lt;/EM&gt;processInstanceId on it.&amp;nbsp; Note that the convention is "parent Call Activity element ID" plus underscore plus "pid" to hold that value.&lt;/P&gt;&lt;P&gt;&lt;/P&gt;&lt;P&gt;When the parent Call Activity is&amp;nbsp;&lt;EM&gt;cancelled &lt;/EM&gt;(either by a boundary event or by the parent process being canceled), the listener point "ACTIVITY_CANCELLED" does fire for any &lt;EM&gt;open, unfinished&lt;/EM&gt;&amp;nbsp;elements.&amp;nbsp; We check to see if it's of the Call Activity type and, if so, we grab that element ID, then look for convention-based "thatId_&lt;EM&gt;pid"&lt;/EM&gt; process variable (in this case: "&lt;SPAN&gt;subCompleteTitleOrder&lt;/SPAN&gt;&lt;STRONG&gt;_pid")&lt;/STRONG&gt; in the containing process.&amp;nbsp; If it's found, then we can grab (either from live or historical process search) for that sub-processInstanceId, look for the completeEventTrackingId variable on that subprocess... and fire our postProcessEnded() custom function that closes that task ID in the legacy system.&lt;/P&gt;&lt;P&gt;&lt;/P&gt;&lt;P&gt;A couple of points here that I can see for improvement for Activiti:&lt;/P&gt;&lt;OL&gt;&lt;LI&gt;When a process is cancelled, regardless of how it is spawned (Process self-terminates, Call Activiti cancelled, Parent Process is cancelled, boundary events, etc.) that PROCESS_CANCELLED is fired.&amp;nbsp; In our opinion, this is a bug, that cancelled Call Activities don't fire PROCESS_CANCELLED on their spawned subprocesses.&lt;/LI&gt;&lt;LI&gt;It would nice if there was a way to be able to configure the input/output variables for a Call Activity at runtime.&amp;nbsp; If there's a way, we couldn't find it.&lt;/LI&gt;&lt;LI&gt;We know that when a subprocess ends, that control is returned to the parent process and the Call Activity ends and the flow moves on.&amp;nbsp; There is&amp;nbsp;&lt;EM&gt;obviously&lt;/EM&gt; a connection between a Call Activity and it's spawned process.&amp;nbsp; But there seems to be no way at runtime to obtain the spawned sub-processInstanceId.&amp;nbsp; At least not that is publicly exposed.&amp;nbsp; Adding the abiltity to ask the Call Activity, when it ends, "what was the processInstanceId of the process you spawned?" would be mighty helpful.&amp;nbsp; Or even to have access to the sub-process' variables would be even better, without having to specifically create an output variable, which, again, seems impossible to modify at runtime.&lt;/LI&gt;&lt;/OL&gt;&lt;/BODY&gt;&lt;/HTML&gt;</description>
      <pubDate>Thu, 13 Sep 2018 16:31:35 GMT</pubDate>
      <guid>https://connect.hyland.com/t5/alfresco-forum/activiti-5-22-message-cancelled-call-activity-doesn-t-fire/m-p/40134#M16827</guid>
      <dc:creator>willb</dc:creator>
      <dc:date>2018-09-13T16:31:35Z</dc:date>
    </item>
  </channel>
</rss>

