You are viewing a plain text version of this content. The canonical link for it is here.
Posted to dev@syncope.apache.org by "Francesco Chicchiriccò (JIRA)" <ji...@apache.org> on 2017/02/22 06:44:44 UTC
[jira] [Updated] (SYNCOPE-1020) Support for BPMN call activity
[ https://issues.apache.org/jira/browse/SYNCOPE-1020?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ]
Francesco Chicchiriccò updated SYNCOPE-1020:
--------------------------------------------
Description:
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.
was:
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.
> 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ò
> 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)