[ 
https://issues.apache.org/jira/browse/SYNCOPE-1020?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=15964322#comment-15964322
 ] 

ASF subversion and git services commented on SYNCOPE-1020:
----------------------------------------------------------

Commit 4c2dd4433353a47b98fbdc4a9706ba6726b9fd44 in syncope's branch 
refs/heads/master from [~ilgrosso]
[ https://git-wip-us.apache.org/repos/asf?p=syncope.git;h=4c2dd44 ]

[SYNCOPE-1020] Implementation completed: now several sub-processes can be 
managed besides the main workflow definition


> Support for BPMN call activity
> ------------------------------
>
>                 Key: SYNCOPE-1020
>                 URL: https://issues.apache.org/jira/browse/SYNCOPE-1020
>             Project: Syncope
>          Issue Type: Improvement
>          Components: core
>            Reporter: Francesco Chicchiriccò
>            Assignee: Francesco Chicchiriccò
>             Fix For: 2.0.3, 2.1.0
>
>
> From the [Activiti User 
> Guide|https://www.activiti.org/userguide/#bpmnCallActivity]:
> {quote}
> BPMN 2.0 makes a distinction between a regular subprocess, often also called 
> embedded subprocess, and the call activity, which looks very similar. From a 
> conceptual point of view, both will call a subprocess when process execution 
> arrives at the activity.
> The difference is that the call activity references a process that is 
> external to the process definition, whereas the subprocess is embedded within 
> the original process definition. The main use case for the call activity is 
> to have a reusable process definition that can be called from multiple other 
> process definitions.
> {quote}
> It is currently possible to create more process definitions (besides the 
> default {{userWorkflow}}) by empowering the REST endpoint
> {code}
> PUT /workflows/{anyTypeKind}
> {code}
> The new process(es) defined can then be called from the main {{userWorkflow}} 
> via the {{<callActivity/>}} element(s): the main advantage is that, by doing 
> so, there are no more problems about the process definition versions, as they 
> only apply to the main process (e.g. {{userWorkflow}}).
> What is currently lacking is:
> # proper management for getting all available process definitions
> # proper handling for initial loading of several process definitions from XML 
> files
> # proper editing features from Admin Console
> as all the items above only consider the possibility that a single process 
> definition is available.



--
This message was sent by Atlassian JIRA
(v6.3.15#6346)

Reply via email to