Re: [Architecture] Generic workflow executor across the platform

[Colin Roy-Ehri]

I agree, +1 for a form-based approach.  Being able to make changes there
and observe the output BPEL would help users learn the format and structure.


Thanks,
Colin Roy-Ehri
Software Engineer
*WSO2, Inc. : wso2.com *
*Mobile*  : 812-219-6517

On Sat, Apr 25, 2015 at 6:07 AM, Frank Leymann  wrote:

> Dear Pulasthi,
>
> having a way to define simple BPEL processes in a form-based manner would
> be great!  Do you have some details on this?
>
>
> Best regards,
> Frank
>
> 2015-04-20 8:42 GMT+02:00 Pulasthi Mahawithana :
>
>> Hi Frank,
>>
>> We thought of having a simple form based approach at user end. We will
>> use some BPELs as templates and get the inputs from a form to customize it.
>>
>> On Sat, Apr 11, 2015 at 8:02 PM, Frank Leymann  wrote:
>>
>>> Hi Pulasthi,
>>>
>>> when you have "users without BPEL knowledge" in mind, you assume that
>>> these users have programming skills, correct?  I.e. that they provide the
>>> "workflow process" in JavaScript, for example, correct?
>>>
>>> Or do you work on a new very easy-to-use workflow language?
>>>
>>>
>>> Best regards,
>>> Frank
>>>
>>> 2015-04-04 14:40 GMT+02:00 Pulasthi Mahawithana :
>>>
 Hi Frank,

 I sent a separate mail[1] with the architecture. Our main objective was
 to provide the workflow support for the events in IS and [1] was designed
 to address that. Furthermore we plan to provide a way to easily configure a
 workflow process and deploy it at BPS (for the users without BPEL
 knowlege). The work for that is in progress and we will update with the
 details soon.

 [1] [Architecture] Generic workflow support

 On Thu, Apr 2, 2015 at 8:31 PM, Frank Leymann  wrote:

> Hi Pulasthi, hi Tanja,
>
> can you provide a consolidated architecture figure, please?  Can you
> also position in your architecture BPS?  I assume the requirements you
> address by your architecture is the ability to create an "on-ramp 
> workflow"
> for ES, AM,... in a "fast" way, correct?
>
> Thanks!
>
>
> Best regards,
> Frank
>
> 2015-04-02 12:54 GMT+02:00 Pulasthi Mahawithana :
>
>> Hi Tanya,
>>
>> The actual architecture is bit different from the one you mentioned
>> here (I'll send a separate mail with details). The executors are
>> responsible only for executing workflow in some manner (can be BPEL, Web
>> Service or even some java code), and they can be registered as OSGI
>> services. The persisting is done by the WorkflowManager before calling 
>> the
>> executor.
>>
>> The WorkflowRequestHandler is the one responsible for creating
>> workflow requests for an event, and handling the callback for the same
>> event. So, what you said can be achieved at this point by customizing the
>> workflow request creation (persist somewhere and provide link in workflow
>> request). Since you create asset disabled and enable it after workflow
>> completion it will work. However there are some events where we have to
>> wait till the workflow completion to perform the actual action. That was
>> the reason to persist the request. Also note that all workflow parameters
>> are not set to the workflow executor. We can filter out parameters that
>> won't be needed at workflow (I will send those details in a separate 
>> mail).
>>
>>
>>
>>
>> On Thu, Apr 2, 2015 at 3:26 PM, Tanya Madurapperuma 
>> wrote:
>>
>>> Hi Johann and all,
>>>
>>> As per the offline chat with Pulasthi, the executor serialize the
>>> workflow info and save in the database before calling the bpel service.
>>> (see the diagram below)
>>>
>>>
>>> ​So in our case if we are to use this component, we will have to do
>>> a network call with all the information for the workflow request (might
>>> include large files such as images and videos etc as admin needs to 
>>> approve
>>> them)
>>> Also at the call back we have to resend the same info back.
>>>
>>> We thought it would be more convienient and performance friendly, if
>>> we persist those information at our end and provide an endpoint where 
>>> the
>>> admin can access all the information.
>>>
>>> For an example, say asset creation process.
>>> Once the user fills the asset creation form, we will persist that
>>> info in a database with a flag so that it won't be visible in the store 
>>> to
>>> the other users. And when triggering the workflow we send an endpoint 
>>> with
>>> a token and admin can view the created asset info with that endpoint. 
>>> Admin
>>> will be redirected to store to display the newly created (pending) 
>>> asset.
>>> With that we don't need to worry about sending/rendering images at the
>>> workflow admin application.
>>>
>>> WDYT?
>>>
>>> Thanks,
>>> Tanya

Re: [Architecture] Generic workflow executor across the platform

[Frank Leymann]

Dear Pulasthi,

having a way to define simple BPEL processes in a form-based manner would
be great!  Do you have some details on this?


Best regards,
Frank

2015-04-20 8:42 GMT+02:00 Pulasthi Mahawithana :

> Hi Frank,
>
> We thought of having a simple form based approach at user end. We will use
> some BPELs as templates and get the inputs from a form to customize it.
>
> On Sat, Apr 11, 2015 at 8:02 PM, Frank Leymann  wrote:
>
>> Hi Pulasthi,
>>
>> when you have "users without BPEL knowledge" in mind, you assume that
>> these users have programming skills, correct?  I.e. that they provide the
>> "workflow process" in JavaScript, for example, correct?
>>
>> Or do you work on a new very easy-to-use workflow language?
>>
>>
>> Best regards,
>> Frank
>>
>> 2015-04-04 14:40 GMT+02:00 Pulasthi Mahawithana :
>>
>>> Hi Frank,
>>>
>>> I sent a separate mail[1] with the architecture. Our main objective was
>>> to provide the workflow support for the events in IS and [1] was designed
>>> to address that. Furthermore we plan to provide a way to easily configure a
>>> workflow process and deploy it at BPS (for the users without BPEL
>>> knowlege). The work for that is in progress and we will update with the
>>> details soon.
>>>
>>> [1] [Architecture] Generic workflow support
>>>
>>> On Thu, Apr 2, 2015 at 8:31 PM, Frank Leymann  wrote:
>>>
 Hi Pulasthi, hi Tanja,

 can you provide a consolidated architecture figure, please?  Can you
 also position in your architecture BPS?  I assume the requirements you
 address by your architecture is the ability to create an "on-ramp workflow"
 for ES, AM,... in a "fast" way, correct?

 Thanks!


 Best regards,
 Frank

 2015-04-02 12:54 GMT+02:00 Pulasthi Mahawithana :

> Hi Tanya,
>
> The actual architecture is bit different from the one you mentioned
> here (I'll send a separate mail with details). The executors are
> responsible only for executing workflow in some manner (can be BPEL, Web
> Service or even some java code), and they can be registered as OSGI
> services. The persisting is done by the WorkflowManager before calling the
> executor.
>
> The WorkflowRequestHandler is the one responsible for creating
> workflow requests for an event, and handling the callback for the same
> event. So, what you said can be achieved at this point by customizing the
> workflow request creation (persist somewhere and provide link in workflow
> request). Since you create asset disabled and enable it after workflow
> completion it will work. However there are some events where we have to
> wait till the workflow completion to perform the actual action. That was
> the reason to persist the request. Also note that all workflow parameters
> are not set to the workflow executor. We can filter out parameters that
> won't be needed at workflow (I will send those details in a separate 
> mail).
>
>
>
>
> On Thu, Apr 2, 2015 at 3:26 PM, Tanya Madurapperuma 
> wrote:
>
>> Hi Johann and all,
>>
>> As per the offline chat with Pulasthi, the executor serialize the
>> workflow info and save in the database before calling the bpel service.
>> (see the diagram below)
>>
>>
>> ​So in our case if we are to use this component, we will have to do a
>> network call with all the information for the workflow request (might
>> include large files such as images and videos etc as admin needs to 
>> approve
>> them)
>> Also at the call back we have to resend the same info back.
>>
>> We thought it would be more convienient and performance friendly, if
>> we persist those information at our end and provide an endpoint where the
>> admin can access all the information.
>>
>> For an example, say asset creation process.
>> Once the user fills the asset creation form, we will persist that
>> info in a database with a flag so that it won't be visible in the store 
>> to
>> the other users. And when triggering the workflow we send an endpoint 
>> with
>> a token and admin can view the created asset info with that endpoint. 
>> Admin
>> will be redirected to store to display the newly created (pending) asset.
>> With that we don't need to worry about sending/rendering images at the
>> workflow admin application.
>>
>> WDYT?
>>
>> Thanks,
>> Tanya
>>
>> On Wed, Apr 1, 2015 at 10:20 AM, Tanya Madurapperuma 
>> wrote:
>>
>>> Hi Johann,
>>>
>>> Thanks for the response.
>>> IMO it is better if we can make the WorkflowRequestDAO more generic
>>> where we can plug any storing mechanism. WDYT?
>>>
>>> Thanks,
>>> Tanya
>>>
>>> On Tue, Mar 31, 2015 at 5:29 PM, Johann Nallathamby >> > wrote:
>>>
 Hi Tanya,

 On Tue, Mar 31, 2015 at 4:59 PM, Tanya 

Re: [Architecture] Generic workflow executor across the platform

[Pulasthi Mahawithana]

Hi Frank,

We thought of having a simple form based approach at user end. We will use
some BPELs as templates and get the inputs from a form to customize it.

On Sat, Apr 11, 2015 at 8:02 PM, Frank Leymann  wrote:

> Hi Pulasthi,
>
> when you have "users without BPEL knowledge" in mind, you assume that
> these users have programming skills, correct?  I.e. that they provide the
> "workflow process" in JavaScript, for example, correct?
>
> Or do you work on a new very easy-to-use workflow language?
>
>
> Best regards,
> Frank
>
> 2015-04-04 14:40 GMT+02:00 Pulasthi Mahawithana :
>
>> Hi Frank,
>>
>> I sent a separate mail[1] with the architecture. Our main objective was
>> to provide the workflow support for the events in IS and [1] was designed
>> to address that. Furthermore we plan to provide a way to easily configure a
>> workflow process and deploy it at BPS (for the users without BPEL
>> knowlege). The work for that is in progress and we will update with the
>> details soon.
>>
>> [1] [Architecture] Generic workflow support
>>
>> On Thu, Apr 2, 2015 at 8:31 PM, Frank Leymann  wrote:
>>
>>> Hi Pulasthi, hi Tanja,
>>>
>>> can you provide a consolidated architecture figure, please?  Can you
>>> also position in your architecture BPS?  I assume the requirements you
>>> address by your architecture is the ability to create an "on-ramp workflow"
>>> for ES, AM,... in a "fast" way, correct?
>>>
>>> Thanks!
>>>
>>>
>>> Best regards,
>>> Frank
>>>
>>> 2015-04-02 12:54 GMT+02:00 Pulasthi Mahawithana :
>>>
 Hi Tanya,

 The actual architecture is bit different from the one you mentioned
 here (I'll send a separate mail with details). The executors are
 responsible only for executing workflow in some manner (can be BPEL, Web
 Service or even some java code), and they can be registered as OSGI
 services. The persisting is done by the WorkflowManager before calling the
 executor.

 The WorkflowRequestHandler is the one responsible for creating workflow
 requests for an event, and handling the callback for the same event. So,
 what you said can be achieved at this point by customizing the workflow
 request creation (persist somewhere and provide link in workflow request).
 Since you create asset disabled and enable it after workflow completion it
 will work. However there are some events where we have to wait till the
 workflow completion to perform the actual action. That was the reason to
 persist the request. Also note that all workflow parameters are not set to
 the workflow executor. We can filter out parameters that won't be needed at
 workflow (I will send those details in a separate mail).




 On Thu, Apr 2, 2015 at 3:26 PM, Tanya Madurapperuma 
 wrote:

> Hi Johann and all,
>
> As per the offline chat with Pulasthi, the executor serialize the
> workflow info and save in the database before calling the bpel service.
> (see the diagram below)
>
>
> ​So in our case if we are to use this component, we will have to do a
> network call with all the information for the workflow request (might
> include large files such as images and videos etc as admin needs to 
> approve
> them)
> Also at the call back we have to resend the same info back.
>
> We thought it would be more convienient and performance friendly, if
> we persist those information at our end and provide an endpoint where the
> admin can access all the information.
>
> For an example, say asset creation process.
> Once the user fills the asset creation form, we will persist that info
> in a database with a flag so that it won't be visible in the store to the
> other users. And when triggering the workflow we send an endpoint with a
> token and admin can view the created asset info with that endpoint. Admin
> will be redirected to store to display the newly created (pending) asset.
> With that we don't need to worry about sending/rendering images at the
> workflow admin application.
>
> WDYT?
>
> Thanks,
> Tanya
>
> On Wed, Apr 1, 2015 at 10:20 AM, Tanya Madurapperuma 
> wrote:
>
>> Hi Johann,
>>
>> Thanks for the response.
>> IMO it is better if we can make the WorkflowRequestDAO more generic
>> where we can plug any storing mechanism. WDYT?
>>
>> Thanks,
>> Tanya
>>
>> On Tue, Mar 31, 2015 at 5:29 PM, Johann Nallathamby 
>> wrote:
>>
>>> Hi Tanya,
>>>
>>> On Tue, Mar 31, 2015 at 4:59 PM, Tanya Madurapperuma >> > wrote:
>>>
 Hi all,

 We are in the process of implementing the workflow support for ES
 and came across the $Subject.
 Although many products have worflow support, seems there is no
 generic component to achieve this.

 The workflow executor for APIM [1] cannot be used platfo

Re: [Architecture] Generic workflow executor across the platform

[Frank Leymann]

Hi Pulasthi,

when you have "users without BPEL knowledge" in mind, you assume that these
users have programming skills, correct?  I.e. that they provide the
"workflow process" in JavaScript, for example, correct?

Or do you work on a new very easy-to-use workflow language?


Best regards,
Frank

2015-04-04 14:40 GMT+02:00 Pulasthi Mahawithana :

> Hi Frank,
>
> I sent a separate mail[1] with the architecture. Our main objective was to
> provide the workflow support for the events in IS and [1] was designed to
> address that. Furthermore we plan to provide a way to easily configure a
> workflow process and deploy it at BPS (for the users without BPEL
> knowlege). The work for that is in progress and we will update with the
> details soon.
>
> [1] [Architecture] Generic workflow support
>
> On Thu, Apr 2, 2015 at 8:31 PM, Frank Leymann  wrote:
>
>> Hi Pulasthi, hi Tanja,
>>
>> can you provide a consolidated architecture figure, please?  Can you also
>> position in your architecture BPS?  I assume the requirements you address
>> by your architecture is the ability to create an "on-ramp workflow" for ES,
>> AM,... in a "fast" way, correct?
>>
>> Thanks!
>>
>>
>> Best regards,
>> Frank
>>
>> 2015-04-02 12:54 GMT+02:00 Pulasthi Mahawithana :
>>
>>> Hi Tanya,
>>>
>>> The actual architecture is bit different from the one you mentioned here
>>> (I'll send a separate mail with details). The executors are responsible
>>> only for executing workflow in some manner (can be BPEL, Web Service or
>>> even some java code), and they can be registered as OSGI services. The
>>> persisting is done by the WorkflowManager before calling the executor.
>>>
>>> The WorkflowRequestHandler is the one responsible for creating workflow
>>> requests for an event, and handling the callback for the same event. So,
>>> what you said can be achieved at this point by customizing the workflow
>>> request creation (persist somewhere and provide link in workflow request).
>>> Since you create asset disabled and enable it after workflow completion it
>>> will work. However there are some events where we have to wait till the
>>> workflow completion to perform the actual action. That was the reason to
>>> persist the request. Also note that all workflow parameters are not set to
>>> the workflow executor. We can filter out parameters that won't be needed at
>>> workflow (I will send those details in a separate mail).
>>>
>>>
>>>
>>>
>>> On Thu, Apr 2, 2015 at 3:26 PM, Tanya Madurapperuma 
>>> wrote:
>>>
 Hi Johann and all,

 As per the offline chat with Pulasthi, the executor serialize the
 workflow info and save in the database before calling the bpel service.
 (see the diagram below)


 ​So in our case if we are to use this component, we will have to do a
 network call with all the information for the workflow request (might
 include large files such as images and videos etc as admin needs to approve
 them)
 Also at the call back we have to resend the same info back.

 We thought it would be more convienient and performance friendly, if we
 persist those information at our end and provide an endpoint where the
 admin can access all the information.

 For an example, say asset creation process.
 Once the user fills the asset creation form, we will persist that info
 in a database with a flag so that it won't be visible in the store to the
 other users. And when triggering the workflow we send an endpoint with a
 token and admin can view the created asset info with that endpoint. Admin
 will be redirected to store to display the newly created (pending) asset.
 With that we don't need to worry about sending/rendering images at the
 workflow admin application.

 WDYT?

 Thanks,
 Tanya

 On Wed, Apr 1, 2015 at 10:20 AM, Tanya Madurapperuma 
 wrote:

> Hi Johann,
>
> Thanks for the response.
> IMO it is better if we can make the WorkflowRequestDAO more generic
> where we can plug any storing mechanism. WDYT?
>
> Thanks,
> Tanya
>
> On Tue, Mar 31, 2015 at 5:29 PM, Johann Nallathamby 
> wrote:
>
>> Hi Tanya,
>>
>> On Tue, Mar 31, 2015 at 4:59 PM, Tanya Madurapperuma 
>> wrote:
>>
>>> Hi all,
>>>
>>> We are in the process of implementing the workflow support for ES
>>> and came across the $Subject.
>>> Although many products have worflow support, seems there is no
>>> generic component to achieve this.
>>>
>>> The workflow executor for APIM [1] cannot be used platform wide
>>> since they pass the ApiMgtDAO to execute method in their executor.
>>>
>>> Similar issue is there with the IS workflow executor where they
>>> preserve the workflow information in the identity database [2] (refer
>>> addWorkflowEntry method)
>>>
>>
>> The work flow component that was designed for IS was designed wit

Re: [Architecture] Generic workflow executor across the platform

[Pulasthi Mahawithana]

Hi Manfred,

The workflow support is not coupled to WSO2 BPS (except the tool for
creation and deployment of simple workflows which I mentioned in the
previous mail), it can be used with any external BPEL engine. So, In the
case of an external BPEL engine we cannot share the data at DB level. That
was the reason for storing the data at product level.


On Tue, Apr 7, 2015 at 3:57 AM, Manfred Herrmann <
herrmann.manf...@googlemail.com> wrote:

> Hi Pulasthi,
>
> thank you for info about BPMN implementation.
>
> Is the workflow executor database a datastore for workflow-data at
> product-level? The called workflow engine stores the workflow-data for
> execution in BPS, right? This leads to redundant workflow-data.
>
> Why should/can I not install "BPS-frontent-features" in a product like IS
> or APIM?
>
> best regards
> Manfred
>
>
> 2015-04-06 14:42 GMT+02:00 Pulasthi Mahawithana :
>
>> Hi Manfred,
>>
>> The executor can be used with both. "BPEL only" support is for the tool
>> we plan to provide for creation and deployment of simple workflows. We will
>> consider extending it to support BPMN also when the next WSO2 BPS version
>> is released with BPMN support.
>>
>> On Mon, Apr 6, 2015 at 12:11 AM, Manfred Herrmann <
>> herrmann.manf...@googlemail.com> wrote:
>>
>>> Hi Pulasthi,
>>>
>>> you mentioned only BPS/BPEL-engine. What about the
>>> BPS/BPMN-activiti-engine? Should it not a prefered way to define workflows?
>>>
>>> best regards
>>> Manfred
>>>
>>> 2015-04-04 14:40 GMT+02:00 Pulasthi Mahawithana :
>>>
 Hi Frank,

 I sent a separate mail[1] with the architecture. Our main objective was
 to provide the workflow support for the events in IS and [1] was designed
 to address that. Furthermore we plan to provide a way to easily configure a
 workflow process and deploy it at BPS (for the users without BPEL
 knowlege). The work for that is in progress and we will update with the
 details soon.

 [1] [Architecture] Generic workflow support

 On Thu, Apr 2, 2015 at 8:31 PM, Frank Leymann  wrote:

> Hi Pulasthi, hi Tanja,
>
> can you provide a consolidated architecture figure, please?  Can you
> also position in your architecture BPS?  I assume the requirements you
> address by your architecture is the ability to create an "on-ramp 
> workflow"
> for ES, AM,... in a "fast" way, correct?
>
> Thanks!
>
>
> Best regards,
> Frank
>
> 2015-04-02 12:54 GMT+02:00 Pulasthi Mahawithana :
>
>> Hi Tanya,
>>
>> The actual architecture is bit different from the one you mentioned
>> here (I'll send a separate mail with details). The executors are
>> responsible only for executing workflow in some manner (can be BPEL, Web
>> Service or even some java code), and they can be registered as OSGI
>> services. The persisting is done by the WorkflowManager before calling 
>> the
>> executor.
>>
>> The WorkflowRequestHandler is the one responsible for creating
>> workflow requests for an event, and handling the callback for the same
>> event. So, what you said can be achieved at this point by customizing the
>> workflow request creation (persist somewhere and provide link in workflow
>> request). Since you create asset disabled and enable it after workflow
>> completion it will work. However there are some events where we have to
>> wait till the workflow completion to perform the actual action. That was
>> the reason to persist the request. Also note that all workflow parameters
>> are not set to the workflow executor. We can filter out parameters that
>> won't be needed at workflow (I will send those details in a separate 
>> mail).
>>
>>
>>
>>
>> On Thu, Apr 2, 2015 at 3:26 PM, Tanya Madurapperuma 
>> wrote:
>>
>>> Hi Johann and all,
>>>
>>> As per the offline chat with Pulasthi, the executor serialize the
>>> workflow info and save in the database before calling the bpel service.
>>> (see the diagram below)
>>>
>>>
>>> ​So in our case if we are to use this component, we will have to do
>>> a network call with all the information for the workflow request (might
>>> include large files such as images and videos etc as admin needs to 
>>> approve
>>> them)
>>> Also at the call back we have to resend the same info back.
>>>
>>> We thought it would be more convienient and performance friendly, if
>>> we persist those information at our end and provide an endpoint where 
>>> the
>>> admin can access all the information.
>>>
>>> For an example, say asset creation process.
>>> Once the user fills the asset creation form, we will persist that
>>> info in a database with a flag so that it won't be visible in the store 
>>> to
>>> the other users. And when triggering the workflow we send an endpoint 
>>> with
>>> 

Re: [Architecture] Generic workflow executor across the platform

[Manfred Herrmann]

Hi Pulasthi,

thank you for info about BPMN implementation.

Is the workflow executor database a datastore for workflow-data at
product-level? The called workflow engine stores the workflow-data for
execution in BPS, right? This leads to redundant workflow-data.

Why should/can I not install "BPS-frontent-features" in a product like IS
or APIM?

best regards
Manfred


2015-04-06 14:42 GMT+02:00 Pulasthi Mahawithana :

> Hi Manfred,
>
> The executor can be used with both. "BPEL only" support is for the tool we
> plan to provide for creation and deployment of simple workflows. We will
> consider extending it to support BPMN also when the next WSO2 BPS version
> is released with BPMN support.
>
> On Mon, Apr 6, 2015 at 12:11 AM, Manfred Herrmann <
> herrmann.manf...@googlemail.com> wrote:
>
>> Hi Pulasthi,
>>
>> you mentioned only BPS/BPEL-engine. What about the
>> BPS/BPMN-activiti-engine? Should it not a prefered way to define workflows?
>>
>> best regards
>> Manfred
>>
>> 2015-04-04 14:40 GMT+02:00 Pulasthi Mahawithana :
>>
>>> Hi Frank,
>>>
>>> I sent a separate mail[1] with the architecture. Our main objective was
>>> to provide the workflow support for the events in IS and [1] was designed
>>> to address that. Furthermore we plan to provide a way to easily configure a
>>> workflow process and deploy it at BPS (for the users without BPEL
>>> knowlege). The work for that is in progress and we will update with the
>>> details soon.
>>>
>>> [1] [Architecture] Generic workflow support
>>>
>>> On Thu, Apr 2, 2015 at 8:31 PM, Frank Leymann  wrote:
>>>
 Hi Pulasthi, hi Tanja,

 can you provide a consolidated architecture figure, please?  Can you
 also position in your architecture BPS?  I assume the requirements you
 address by your architecture is the ability to create an "on-ramp workflow"
 for ES, AM,... in a "fast" way, correct?

 Thanks!


 Best regards,
 Frank

 2015-04-02 12:54 GMT+02:00 Pulasthi Mahawithana :

> Hi Tanya,
>
> The actual architecture is bit different from the one you mentioned
> here (I'll send a separate mail with details). The executors are
> responsible only for executing workflow in some manner (can be BPEL, Web
> Service or even some java code), and they can be registered as OSGI
> services. The persisting is done by the WorkflowManager before calling the
> executor.
>
> The WorkflowRequestHandler is the one responsible for creating
> workflow requests for an event, and handling the callback for the same
> event. So, what you said can be achieved at this point by customizing the
> workflow request creation (persist somewhere and provide link in workflow
> request). Since you create asset disabled and enable it after workflow
> completion it will work. However there are some events where we have to
> wait till the workflow completion to perform the actual action. That was
> the reason to persist the request. Also note that all workflow parameters
> are not set to the workflow executor. We can filter out parameters that
> won't be needed at workflow (I will send those details in a separate 
> mail).
>
>
>
>
> On Thu, Apr 2, 2015 at 3:26 PM, Tanya Madurapperuma 
> wrote:
>
>> Hi Johann and all,
>>
>> As per the offline chat with Pulasthi, the executor serialize the
>> workflow info and save in the database before calling the bpel service.
>> (see the diagram below)
>>
>>
>> ​So in our case if we are to use this component, we will have to do a
>> network call with all the information for the workflow request (might
>> include large files such as images and videos etc as admin needs to 
>> approve
>> them)
>> Also at the call back we have to resend the same info back.
>>
>> We thought it would be more convienient and performance friendly, if
>> we persist those information at our end and provide an endpoint where the
>> admin can access all the information.
>>
>> For an example, say asset creation process.
>> Once the user fills the asset creation form, we will persist that
>> info in a database with a flag so that it won't be visible in the store 
>> to
>> the other users. And when triggering the workflow we send an endpoint 
>> with
>> a token and admin can view the created asset info with that endpoint. 
>> Admin
>> will be redirected to store to display the newly created (pending) asset.
>> With that we don't need to worry about sending/rendering images at the
>> workflow admin application.
>>
>> WDYT?
>>
>> Thanks,
>> Tanya
>>
>> On Wed, Apr 1, 2015 at 10:20 AM, Tanya Madurapperuma 
>> wrote:
>>
>>> Hi Johann,
>>>
>>> Thanks for the response.
>>> IMO it is better if we can make the WorkflowRequestDAO more generic
>>> where we can plug any storing me

Re: [Architecture] Generic workflow executor across the platform

[Pulasthi Mahawithana]

Hi Manfred,

The executor can be used with both. "BPEL only" support is for the tool we
plan to provide for creation and deployment of simple workflows. We will
consider extending it to support BPMN also when the next WSO2 BPS version
is released with BPMN support.

On Mon, Apr 6, 2015 at 12:11 AM, Manfred Herrmann <
herrmann.manf...@googlemail.com> wrote:

> Hi Pulasthi,
>
> you mentioned only BPS/BPEL-engine. What about the
> BPS/BPMN-activiti-engine? Should it not a prefered way to define workflows?
>
> best regards
> Manfred
>
> 2015-04-04 14:40 GMT+02:00 Pulasthi Mahawithana :
>
>> Hi Frank,
>>
>> I sent a separate mail[1] with the architecture. Our main objective was
>> to provide the workflow support for the events in IS and [1] was designed
>> to address that. Furthermore we plan to provide a way to easily configure a
>> workflow process and deploy it at BPS (for the users without BPEL
>> knowlege). The work for that is in progress and we will update with the
>> details soon.
>>
>> [1] [Architecture] Generic workflow support
>>
>> On Thu, Apr 2, 2015 at 8:31 PM, Frank Leymann  wrote:
>>
>>> Hi Pulasthi, hi Tanja,
>>>
>>> can you provide a consolidated architecture figure, please?  Can you
>>> also position in your architecture BPS?  I assume the requirements you
>>> address by your architecture is the ability to create an "on-ramp workflow"
>>> for ES, AM,... in a "fast" way, correct?
>>>
>>> Thanks!
>>>
>>>
>>> Best regards,
>>> Frank
>>>
>>> 2015-04-02 12:54 GMT+02:00 Pulasthi Mahawithana :
>>>
 Hi Tanya,

 The actual architecture is bit different from the one you mentioned
 here (I'll send a separate mail with details). The executors are
 responsible only for executing workflow in some manner (can be BPEL, Web
 Service or even some java code), and they can be registered as OSGI
 services. The persisting is done by the WorkflowManager before calling the
 executor.

 The WorkflowRequestHandler is the one responsible for creating workflow
 requests for an event, and handling the callback for the same event. So,
 what you said can be achieved at this point by customizing the workflow
 request creation (persist somewhere and provide link in workflow request).
 Since you create asset disabled and enable it after workflow completion it
 will work. However there are some events where we have to wait till the
 workflow completion to perform the actual action. That was the reason to
 persist the request. Also note that all workflow parameters are not set to
 the workflow executor. We can filter out parameters that won't be needed at
 workflow (I will send those details in a separate mail).




 On Thu, Apr 2, 2015 at 3:26 PM, Tanya Madurapperuma 
 wrote:

> Hi Johann and all,
>
> As per the offline chat with Pulasthi, the executor serialize the
> workflow info and save in the database before calling the bpel service.
> (see the diagram below)
>
>
> ​So in our case if we are to use this component, we will have to do a
> network call with all the information for the workflow request (might
> include large files such as images and videos etc as admin needs to 
> approve
> them)
> Also at the call back we have to resend the same info back.
>
> We thought it would be more convienient and performance friendly, if
> we persist those information at our end and provide an endpoint where the
> admin can access all the information.
>
> For an example, say asset creation process.
> Once the user fills the asset creation form, we will persist that info
> in a database with a flag so that it won't be visible in the store to the
> other users. And when triggering the workflow we send an endpoint with a
> token and admin can view the created asset info with that endpoint. Admin
> will be redirected to store to display the newly created (pending) asset.
> With that we don't need to worry about sending/rendering images at the
> workflow admin application.
>
> WDYT?
>
> Thanks,
> Tanya
>
> On Wed, Apr 1, 2015 at 10:20 AM, Tanya Madurapperuma 
> wrote:
>
>> Hi Johann,
>>
>> Thanks for the response.
>> IMO it is better if we can make the WorkflowRequestDAO more generic
>> where we can plug any storing mechanism. WDYT?
>>
>> Thanks,
>> Tanya
>>
>> On Tue, Mar 31, 2015 at 5:29 PM, Johann Nallathamby 
>> wrote:
>>
>>> Hi Tanya,
>>>
>>> On Tue, Mar 31, 2015 at 4:59 PM, Tanya Madurapperuma >> > wrote:
>>>
 Hi all,

 We are in the process of implementing the workflow support for ES
 and came across the $Subject.
 Although many products have worflow support, seems there is no
 generic component to achieve this.

 The workflow executor for APIM [1] cannot be used p

Re: [Architecture] Generic workflow executor across the platform

[Manfred Herrmann]

Hi Pulasthi,

you mentioned only BPS/BPEL-engine. What about the
BPS/BPMN-activiti-engine? Should it not a prefered way to define workflows?

best regards
Manfred

2015-04-04 14:40 GMT+02:00 Pulasthi Mahawithana :

> Hi Frank,
>
> I sent a separate mail[1] with the architecture. Our main objective was to
> provide the workflow support for the events in IS and [1] was designed to
> address that. Furthermore we plan to provide a way to easily configure a
> workflow process and deploy it at BPS (for the users without BPEL
> knowlege). The work for that is in progress and we will update with the
> details soon.
>
> [1] [Architecture] Generic workflow support
>
> On Thu, Apr 2, 2015 at 8:31 PM, Frank Leymann  wrote:
>
>> Hi Pulasthi, hi Tanja,
>>
>> can you provide a consolidated architecture figure, please?  Can you also
>> position in your architecture BPS?  I assume the requirements you address
>> by your architecture is the ability to create an "on-ramp workflow" for ES,
>> AM,... in a "fast" way, correct?
>>
>> Thanks!
>>
>>
>> Best regards,
>> Frank
>>
>> 2015-04-02 12:54 GMT+02:00 Pulasthi Mahawithana :
>>
>>> Hi Tanya,
>>>
>>> The actual architecture is bit different from the one you mentioned here
>>> (I'll send a separate mail with details). The executors are responsible
>>> only for executing workflow in some manner (can be BPEL, Web Service or
>>> even some java code), and they can be registered as OSGI services. The
>>> persisting is done by the WorkflowManager before calling the executor.
>>>
>>> The WorkflowRequestHandler is the one responsible for creating workflow
>>> requests for an event, and handling the callback for the same event. So,
>>> what you said can be achieved at this point by customizing the workflow
>>> request creation (persist somewhere and provide link in workflow request).
>>> Since you create asset disabled and enable it after workflow completion it
>>> will work. However there are some events where we have to wait till the
>>> workflow completion to perform the actual action. That was the reason to
>>> persist the request. Also note that all workflow parameters are not set to
>>> the workflow executor. We can filter out parameters that won't be needed at
>>> workflow (I will send those details in a separate mail).
>>>
>>>
>>>
>>>
>>> On Thu, Apr 2, 2015 at 3:26 PM, Tanya Madurapperuma 
>>> wrote:
>>>
 Hi Johann and all,

 As per the offline chat with Pulasthi, the executor serialize the
 workflow info and save in the database before calling the bpel service.
 (see the diagram below)


 ​So in our case if we are to use this component, we will have to do a
 network call with all the information for the workflow request (might
 include large files such as images and videos etc as admin needs to approve
 them)
 Also at the call back we have to resend the same info back.

 We thought it would be more convienient and performance friendly, if we
 persist those information at our end and provide an endpoint where the
 admin can access all the information.

 For an example, say asset creation process.
 Once the user fills the asset creation form, we will persist that info
 in a database with a flag so that it won't be visible in the store to the
 other users. And when triggering the workflow we send an endpoint with a
 token and admin can view the created asset info with that endpoint. Admin
 will be redirected to store to display the newly created (pending) asset.
 With that we don't need to worry about sending/rendering images at the
 workflow admin application.

 WDYT?

 Thanks,
 Tanya

 On Wed, Apr 1, 2015 at 10:20 AM, Tanya Madurapperuma 
 wrote:

> Hi Johann,
>
> Thanks for the response.
> IMO it is better if we can make the WorkflowRequestDAO more generic
> where we can plug any storing mechanism. WDYT?
>
> Thanks,
> Tanya
>
> On Tue, Mar 31, 2015 at 5:29 PM, Johann Nallathamby 
> wrote:
>
>> Hi Tanya,
>>
>> On Tue, Mar 31, 2015 at 4:59 PM, Tanya Madurapperuma 
>> wrote:
>>
>>> Hi all,
>>>
>>> We are in the process of implementing the workflow support for ES
>>> and came across the $Subject.
>>> Although many products have worflow support, seems there is no
>>> generic component to achieve this.
>>>
>>> The workflow executor for APIM [1] cannot be used platform wide
>>> since they pass the ApiMgtDAO to execute method in their executor.
>>>
>>> Similar issue is there with the IS workflow executor where they
>>> preserve the workflow information in the identity database [2] (refer
>>> addWorkflowEntry method)
>>>
>>
>> The work flow component that was designed for IS was designed with
>> the intension of extensibility. The workflow components are not coupled 
>> in
>> anyway to identity components. If t

Re: [Architecture] Generic workflow executor across the platform

[Pulasthi Mahawithana]

Hi Frank,

I sent a separate mail[1] with the architecture. Our main objective was to
provide the workflow support for the events in IS and [1] was designed to
address that. Furthermore we plan to provide a way to easily configure a
workflow process and deploy it at BPS (for the users without BPEL
knowlege). The work for that is in progress and we will update with the
details soon.

[1] [Architecture] Generic workflow support

On Thu, Apr 2, 2015 at 8:31 PM, Frank Leymann  wrote:

> Hi Pulasthi, hi Tanja,
>
> can you provide a consolidated architecture figure, please?  Can you also
> position in your architecture BPS?  I assume the requirements you address
> by your architecture is the ability to create an "on-ramp workflow" for ES,
> AM,... in a "fast" way, correct?
>
> Thanks!
>
>
> Best regards,
> Frank
>
> 2015-04-02 12:54 GMT+02:00 Pulasthi Mahawithana :
>
>> Hi Tanya,
>>
>> The actual architecture is bit different from the one you mentioned here
>> (I'll send a separate mail with details). The executors are responsible
>> only for executing workflow in some manner (can be BPEL, Web Service or
>> even some java code), and they can be registered as OSGI services. The
>> persisting is done by the WorkflowManager before calling the executor.
>>
>> The WorkflowRequestHandler is the one responsible for creating workflow
>> requests for an event, and handling the callback for the same event. So,
>> what you said can be achieved at this point by customizing the workflow
>> request creation (persist somewhere and provide link in workflow request).
>> Since you create asset disabled and enable it after workflow completion it
>> will work. However there are some events where we have to wait till the
>> workflow completion to perform the actual action. That was the reason to
>> persist the request. Also note that all workflow parameters are not set to
>> the workflow executor. We can filter out parameters that won't be needed at
>> workflow (I will send those details in a separate mail).
>>
>>
>>
>>
>> On Thu, Apr 2, 2015 at 3:26 PM, Tanya Madurapperuma 
>> wrote:
>>
>>> Hi Johann and all,
>>>
>>> As per the offline chat with Pulasthi, the executor serialize the
>>> workflow info and save in the database before calling the bpel service.
>>> (see the diagram below)
>>>
>>>
>>> ​So in our case if we are to use this component, we will have to do a
>>> network call with all the information for the workflow request (might
>>> include large files such as images and videos etc as admin needs to approve
>>> them)
>>> Also at the call back we have to resend the same info back.
>>>
>>> We thought it would be more convienient and performance friendly, if we
>>> persist those information at our end and provide an endpoint where the
>>> admin can access all the information.
>>>
>>> For an example, say asset creation process.
>>> Once the user fills the asset creation form, we will persist that info
>>> in a database with a flag so that it won't be visible in the store to the
>>> other users. And when triggering the workflow we send an endpoint with a
>>> token and admin can view the created asset info with that endpoint. Admin
>>> will be redirected to store to display the newly created (pending) asset.
>>> With that we don't need to worry about sending/rendering images at the
>>> workflow admin application.
>>>
>>> WDYT?
>>>
>>> Thanks,
>>> Tanya
>>>
>>> On Wed, Apr 1, 2015 at 10:20 AM, Tanya Madurapperuma 
>>> wrote:
>>>
 Hi Johann,

 Thanks for the response.
 IMO it is better if we can make the WorkflowRequestDAO more generic
 where we can plug any storing mechanism. WDYT?

 Thanks,
 Tanya

 On Tue, Mar 31, 2015 at 5:29 PM, Johann Nallathamby 
 wrote:

> Hi Tanya,
>
> On Tue, Mar 31, 2015 at 4:59 PM, Tanya Madurapperuma 
> wrote:
>
>> Hi all,
>>
>> We are in the process of implementing the workflow support for ES and
>> came across the $Subject.
>> Although many products have worflow support, seems there is no
>> generic component to achieve this.
>>
>> The workflow executor for APIM [1] cannot be used platform wide since
>> they pass the ApiMgtDAO to execute method in their executor.
>>
>> Similar issue is there with the IS workflow executor where they
>> preserve the workflow information in the identity database [2] (refer
>> addWorkflowEntry method)
>>
>
> The work flow component that was designed for IS was designed with the
> intension of extensibility. The workflow components are not coupled in
> anyway to identity components. If there is anything which is blocking you
> from achieving what you need then we will like to know about it so that we
> can fix our design.
>
>
>> IMO other products should be able to use their own workflow info
>> preservation mechanism.
>> Ex: To store in the registry
>>To store in a database
>> Say in ES, we

Re: [Architecture] Generic workflow executor across the platform

[Frank Leymann]

Hi Pulasthi, hi Tanja,

can you provide a consolidated architecture figure, please?  Can you also
position in your architecture BPS?  I assume the requirements you address
by your architecture is the ability to create an "on-ramp workflow" for ES,
AM,... in a "fast" way, correct?

Thanks!


Best regards,
Frank

2015-04-02 12:54 GMT+02:00 Pulasthi Mahawithana :

> Hi Tanya,
>
> The actual architecture is bit different from the one you mentioned here
> (I'll send a separate mail with details). The executors are responsible
> only for executing workflow in some manner (can be BPEL, Web Service or
> even some java code), and they can be registered as OSGI services. The
> persisting is done by the WorkflowManager before calling the executor.
>
> The WorkflowRequestHandler is the one responsible for creating workflow
> requests for an event, and handling the callback for the same event. So,
> what you said can be achieved at this point by customizing the workflow
> request creation (persist somewhere and provide link in workflow request).
> Since you create asset disabled and enable it after workflow completion it
> will work. However there are some events where we have to wait till the
> workflow completion to perform the actual action. That was the reason to
> persist the request. Also note that all workflow parameters are not set to
> the workflow executor. We can filter out parameters that won't be needed at
> workflow (I will send those details in a separate mail).
>
>
>
>
> On Thu, Apr 2, 2015 at 3:26 PM, Tanya Madurapperuma 
> wrote:
>
>> Hi Johann and all,
>>
>> As per the offline chat with Pulasthi, the executor serialize the
>> workflow info and save in the database before calling the bpel service.
>> (see the diagram below)
>>
>>
>> ​So in our case if we are to use this component, we will have to do a
>> network call with all the information for the workflow request (might
>> include large files such as images and videos etc as admin needs to approve
>> them)
>> Also at the call back we have to resend the same info back.
>>
>> We thought it would be more convienient and performance friendly, if we
>> persist those information at our end and provide an endpoint where the
>> admin can access all the information.
>>
>> For an example, say asset creation process.
>> Once the user fills the asset creation form, we will persist that info in
>> a database with a flag so that it won't be visible in the store to the
>> other users. And when triggering the workflow we send an endpoint with a
>> token and admin can view the created asset info with that endpoint. Admin
>> will be redirected to store to display the newly created (pending) asset.
>> With that we don't need to worry about sending/rendering images at the
>> workflow admin application.
>>
>> WDYT?
>>
>> Thanks,
>> Tanya
>>
>> On Wed, Apr 1, 2015 at 10:20 AM, Tanya Madurapperuma 
>> wrote:
>>
>>> Hi Johann,
>>>
>>> Thanks for the response.
>>> IMO it is better if we can make the WorkflowRequestDAO more generic
>>> where we can plug any storing mechanism. WDYT?
>>>
>>> Thanks,
>>> Tanya
>>>
>>> On Tue, Mar 31, 2015 at 5:29 PM, Johann Nallathamby 
>>> wrote:
>>>
 Hi Tanya,

 On Tue, Mar 31, 2015 at 4:59 PM, Tanya Madurapperuma 
 wrote:

> Hi all,
>
> We are in the process of implementing the workflow support for ES and
> came across the $Subject.
> Although many products have worflow support, seems there is no generic
> component to achieve this.
>
> The workflow executor for APIM [1] cannot be used platform wide since
> they pass the ApiMgtDAO to execute method in their executor.
>
> Similar issue is there with the IS workflow executor where they
> preserve the workflow information in the identity database [2] (refer
> addWorkflowEntry method)
>

 The work flow component that was designed for IS was designed with the
 intension of extensibility. The workflow components are not coupled in
 anyway to identity components. If there is anything which is blocking you
 from achieving what you need then we will like to know about it so that we
 can fix our design.


> IMO other products should be able to use their own workflow info
> preservation mechanism.
> Ex: To store in the registry
>To store in a database
> Say in ES, we want to provide workflow support for asset creation.
> Storing asset level info in Identity database doesn't make sense.
>

 Don't think of it as Identity database. Think of it as a database
 coming from another feature repository. It can be any product like IS. If
 the same workflow component was developed by APIM then it would be AM_
 tables. Apart from the naming convention the functionality is generic and
 extensible. The table naming convention comes from which product team
 develops it, thats all.

 Using Identity database in ES is not wrong. If you are in

Re: [Architecture] Generic workflow executor across the platform

[Pulasthi Mahawithana]

Hi Tanya,

The actual architecture is bit different from the one you mentioned here
(I'll send a separate mail with details). The executors are responsible
only for executing workflow in some manner (can be BPEL, Web Service or
even some java code), and they can be registered as OSGI services. The
persisting is done by the WorkflowManager before calling the executor.

The WorkflowRequestHandler is the one responsible for creating workflow
requests for an event, and handling the callback for the same event. So,
what you said can be achieved at this point by customizing the workflow
request creation (persist somewhere and provide link in workflow request).
Since you create asset disabled and enable it after workflow completion it
will work. However there are some events where we have to wait till the
workflow completion to perform the actual action. That was the reason to
persist the request. Also note that all workflow parameters are not set to
the workflow executor. We can filter out parameters that won't be needed at
workflow (I will send those details in a separate mail).




On Thu, Apr 2, 2015 at 3:26 PM, Tanya Madurapperuma  wrote:

> Hi Johann and all,
>
> As per the offline chat with Pulasthi, the executor serialize the workflow
> info and save in the database before calling the bpel service. (see the
> diagram below)
>
>
> ​So in our case if we are to use this component, we will have to do a
> network call with all the information for the workflow request (might
> include large files such as images and videos etc as admin needs to approve
> them)
> Also at the call back we have to resend the same info back.
>
> We thought it would be more convienient and performance friendly, if we
> persist those information at our end and provide an endpoint where the
> admin can access all the information.
>
> For an example, say asset creation process.
> Once the user fills the asset creation form, we will persist that info in
> a database with a flag so that it won't be visible in the store to the
> other users. And when triggering the workflow we send an endpoint with a
> token and admin can view the created asset info with that endpoint. Admin
> will be redirected to store to display the newly created (pending) asset.
> With that we don't need to worry about sending/rendering images at the
> workflow admin application.
>
> WDYT?
>
> Thanks,
> Tanya
>
> On Wed, Apr 1, 2015 at 10:20 AM, Tanya Madurapperuma 
> wrote:
>
>> Hi Johann,
>>
>> Thanks for the response.
>> IMO it is better if we can make the WorkflowRequestDAO more generic where
>> we can plug any storing mechanism. WDYT?
>>
>> Thanks,
>> Tanya
>>
>> On Tue, Mar 31, 2015 at 5:29 PM, Johann Nallathamby 
>> wrote:
>>
>>> Hi Tanya,
>>>
>>> On Tue, Mar 31, 2015 at 4:59 PM, Tanya Madurapperuma 
>>> wrote:
>>>
 Hi all,

 We are in the process of implementing the workflow support for ES and
 came across the $Subject.
 Although many products have worflow support, seems there is no generic
 component to achieve this.

 The workflow executor for APIM [1] cannot be used platform wide since
 they pass the ApiMgtDAO to execute method in their executor.

 Similar issue is there with the IS workflow executor where they
 preserve the workflow information in the identity database [2] (refer
 addWorkflowEntry method)

>>>
>>> The work flow component that was designed for IS was designed with the
>>> intension of extensibility. The workflow components are not coupled in
>>> anyway to identity components. If there is anything which is blocking you
>>> from achieving what you need then we will like to know about it so that we
>>> can fix our design.
>>>
>>>
 IMO other products should be able to use their own workflow info
 preservation mechanism.
 Ex: To store in the registry
To store in a database
 Say in ES, we want to provide workflow support for asset creation.
 Storing asset level info in Identity database doesn't make sense.

>>>
>>> Don't think of it as Identity database. Think of it as a database coming
>>> from another feature repository. It can be any product like IS. If the same
>>> workflow component was developed by APIM then it would be AM_ tables. Apart
>>> from the naming convention the functionality is generic and extensible. The
>>> table naming convention comes from which product team develops it, thats
>>> all.
>>>
>>> Using Identity database in ES is not wrong. If you are installing IS
>>> feature you have to install the database scripts also. I know previously
>>> APIM did the same mistake of copying the identity tables into apim scripts
>>> and not executing identity scripts. I know how much duplication it made and
>>> how much of problems we ran into. I am -1 on that.
>>>
>>> If you have a strong reason to move away from database, and use registry
>>> then we need to think about making the data access layer extensible, which
>>> is open for discussion.
>>>
>

Re: [Architecture] Generic workflow executor across the platform

[Tanya Madurapperuma]

Hi Johann and all,

As per the offline chat with Pulasthi, the executor serialize the workflow
info and save in the database before calling the bpel service. (see the
diagram below)


​So in our case if we are to use this component, we will have to do a
network call with all the information for the workflow request (might
include large files such as images and videos etc as admin needs to approve
them)
Also at the call back we have to resend the same info back.

We thought it would be more convienient and performance friendly, if we
persist those information at our end and provide an endpoint where the
admin can access all the information.

For an example, say asset creation process.
Once the user fills the asset creation form, we will persist that info in a
database with a flag so that it won't be visible in the store to the other
users. And when triggering the workflow we send an endpoint with a token
and admin can view the created asset info with that endpoint. Admin will be
redirected to store to display the newly created (pending) asset. With that
we don't need to worry about sending/rendering images at the workflow admin
application.

WDYT?

Thanks,
Tanya

On Wed, Apr 1, 2015 at 10:20 AM, Tanya Madurapperuma  wrote:

> Hi Johann,
>
> Thanks for the response.
> IMO it is better if we can make the WorkflowRequestDAO more generic where
> we can plug any storing mechanism. WDYT?
>
> Thanks,
> Tanya
>
> On Tue, Mar 31, 2015 at 5:29 PM, Johann Nallathamby 
> wrote:
>
>> Hi Tanya,
>>
>> On Tue, Mar 31, 2015 at 4:59 PM, Tanya Madurapperuma 
>> wrote:
>>
>>> Hi all,
>>>
>>> We are in the process of implementing the workflow support for ES and
>>> came across the $Subject.
>>> Although many products have worflow support, seems there is no generic
>>> component to achieve this.
>>>
>>> The workflow executor for APIM [1] cannot be used platform wide since
>>> they pass the ApiMgtDAO to execute method in their executor.
>>>
>>> Similar issue is there with the IS workflow executor where they preserve
>>> the workflow information in the identity database [2] (refer
>>> addWorkflowEntry method)
>>>
>>
>> The work flow component that was designed for IS was designed with the
>> intension of extensibility. The workflow components are not coupled in
>> anyway to identity components. If there is anything which is blocking you
>> from achieving what you need then we will like to know about it so that we
>> can fix our design.
>>
>>
>>> IMO other products should be able to use their own workflow info
>>> preservation mechanism.
>>> Ex: To store in the registry
>>>To store in a database
>>> Say in ES, we want to provide workflow support for asset creation.
>>> Storing asset level info in Identity database doesn't make sense.
>>>
>>
>> Don't think of it as Identity database. Think of it as a database coming
>> from another feature repository. It can be any product like IS. If the same
>> workflow component was developed by APIM then it would be AM_ tables. Apart
>> from the naming convention the functionality is generic and extensible. The
>> table naming convention comes from which product team develops it, thats
>> all.
>>
>> Using Identity database in ES is not wrong. If you are installing IS
>> feature you have to install the database scripts also. I know previously
>> APIM did the same mistake of copying the identity tables into apim scripts
>> and not executing identity scripts. I know how much duplication it made and
>> how much of problems we ran into. I am -1 on that.
>>
>> If you have a strong reason to move away from database, and use registry
>> then we need to think about making the data access layer extensible, which
>> is open for discussion.
>>
>> P.S. I know we haven't sent a mail to architecture regarding the workflow
>> component design. Will do soon.
>>
>> Regards,
>> Johann.
>>
>>>
>>> Appreciate your feedback.
>>>
>>> [1]
>>> https://github.com/wso2/carbon-apimgt/blob/master/components/apimgt/org.wso2.carbon.apimgt.impl/src/main/java/org/wso2/carbon/apimgt/impl/workflow/WorkflowExecutor.java
>>> [2]
>>> https://github.com/pulasthi7/carbon-identity/blob/feature/workflow-support/components/workflows/org.wso2.carbon.workflow.mgt/src/main/java/org/wso2/carbon/workflow/mgt/dao/WorkflowRequestDAO.java
>>>
>>> Thanks,
>>> Tanya
>>>
>>> --
>>> Tanya Madurapperuma
>>>
>>> Software Engineer,
>>> WSO2 Inc. : wso2.com
>>> Mobile : +94718184439
>>> Blog : http://tanyamadurapperuma.blogspot.com
>>>
>>
>>
>>
>> --
>> Thanks & Regards,
>>
>> *Johann Dilantha Nallathamby*
>> Associate Technical Lead & Product Lead of WSO2 Identity Server
>> Integration Technologies Team
>> WSO2, Inc.
>> lean.enterprise.middleware
>>
>> Mobile - *+9476950*
>> Blog - *http://nallaa.wordpress.com *
>>
>
>
>
> --
> Tanya Madurapperuma
>
> Software Engineer,
> WSO2 Inc. : wso2.com
> Mobile : +94718184439
> Blog : http://tanyamadurapperuma.blogspot.com
>



-- 
Tanya Madurapperuma

Software Engineer,

Re: [Architecture] Generic workflow executor across the platform

[Tanya Madurapperuma]

Hi Johann,

Thanks for the response.
IMO it is better if we can make the WorkflowRequestDAO more generic where
we can plug any storing mechanism. WDYT?

Thanks,
Tanya

On Tue, Mar 31, 2015 at 5:29 PM, Johann Nallathamby  wrote:

> Hi Tanya,
>
> On Tue, Mar 31, 2015 at 4:59 PM, Tanya Madurapperuma 
> wrote:
>
>> Hi all,
>>
>> We are in the process of implementing the workflow support for ES and
>> came across the $Subject.
>> Although many products have worflow support, seems there is no generic
>> component to achieve this.
>>
>> The workflow executor for APIM [1] cannot be used platform wide since
>> they pass the ApiMgtDAO to execute method in their executor.
>>
>> Similar issue is there with the IS workflow executor where they preserve
>> the workflow information in the identity database [2] (refer
>> addWorkflowEntry method)
>>
>
> The work flow component that was designed for IS was designed with the
> intension of extensibility. The workflow components are not coupled in
> anyway to identity components. If there is anything which is blocking you
> from achieving what you need then we will like to know about it so that we
> can fix our design.
>
>
>> IMO other products should be able to use their own workflow info
>> preservation mechanism.
>> Ex: To store in the registry
>>To store in a database
>> Say in ES, we want to provide workflow support for asset creation.
>> Storing asset level info in Identity database doesn't make sense.
>>
>
> Don't think of it as Identity database. Think of it as a database coming
> from another feature repository. It can be any product like IS. If the same
> workflow component was developed by APIM then it would be AM_ tables. Apart
> from the naming convention the functionality is generic and extensible. The
> table naming convention comes from which product team develops it, thats
> all.
>
> Using Identity database in ES is not wrong. If you are installing IS
> feature you have to install the database scripts also. I know previously
> APIM did the same mistake of copying the identity tables into apim scripts
> and not executing identity scripts. I know how much duplication it made and
> how much of problems we ran into. I am -1 on that.
>
> If you have a strong reason to move away from database, and use registry
> then we need to think about making the data access layer extensible, which
> is open for discussion.
>
> P.S. I know we haven't sent a mail to architecture regarding the workflow
> component design. Will do soon.
>
> Regards,
> Johann.
>
>>
>> Appreciate your feedback.
>>
>> [1]
>> https://github.com/wso2/carbon-apimgt/blob/master/components/apimgt/org.wso2.carbon.apimgt.impl/src/main/java/org/wso2/carbon/apimgt/impl/workflow/WorkflowExecutor.java
>> [2]
>> https://github.com/pulasthi7/carbon-identity/blob/feature/workflow-support/components/workflows/org.wso2.carbon.workflow.mgt/src/main/java/org/wso2/carbon/workflow/mgt/dao/WorkflowRequestDAO.java
>>
>> Thanks,
>> Tanya
>>
>> --
>> Tanya Madurapperuma
>>
>> Software Engineer,
>> WSO2 Inc. : wso2.com
>> Mobile : +94718184439
>> Blog : http://tanyamadurapperuma.blogspot.com
>>
>
>
>
> --
> Thanks & Regards,
>
> *Johann Dilantha Nallathamby*
> Associate Technical Lead & Product Lead of WSO2 Identity Server
> Integration Technologies Team
> WSO2, Inc.
> lean.enterprise.middleware
>
> Mobile - *+9476950*
> Blog - *http://nallaa.wordpress.com *
>



-- 
Tanya Madurapperuma

Software Engineer,
WSO2 Inc. : wso2.com
Mobile : +94718184439
Blog : http://tanyamadurapperuma.blogspot.com
___
Architecture mailing list
Architecture@wso2.org
https://mail.wso2.org/cgi-bin/mailman/listinfo/architecture

Re: [Architecture] Generic workflow executor across the platform

[Johann Nallathamby]

Hi Tanya,

On Tue, Mar 31, 2015 at 4:59 PM, Tanya Madurapperuma  wrote:

> Hi all,
>
> We are in the process of implementing the workflow support for ES and came
> across the $Subject.
> Although many products have worflow support, seems there is no generic
> component to achieve this.
>
> The workflow executor for APIM [1] cannot be used platform wide since they
> pass the ApiMgtDAO to execute method in their executor.
>
> Similar issue is there with the IS workflow executor where they preserve
> the workflow information in the identity database [2] (refer
> addWorkflowEntry method)
>

The work flow component that was designed for IS was designed with the
intension of extensibility. The workflow components are not coupled in
anyway to identity components. If there is anything which is blocking you
from achieving what you need then we will like to know about it so that we
can fix our design.


> IMO other products should be able to use their own workflow info
> preservation mechanism.
> Ex: To store in the registry
>To store in a database
> Say in ES, we want to provide workflow support for asset creation. Storing
> asset level info in Identity database doesn't make sense.
>

Don't think of it as Identity database. Think of it as a database coming
from another feature repository. It can be any product like IS. If the same
workflow component was developed by APIM then it would be AM_ tables. Apart
from the naming convention the functionality is generic and extensible. The
table naming convention comes from which product team develops it, thats
all.

Using Identity database in ES is not wrong. If you are installing IS
feature you have to install the database scripts also. I know previously
APIM did the same mistake of copying the identity tables into apim scripts
and not executing identity scripts. I know how much duplication it made and
how much of problems we ran into. I am -1 on that.

If you have a strong reason to move away from database, and use registry
then we need to think about making the data access layer extensible, which
is open for discussion.

P.S. I know we haven't sent a mail to architecture regarding the workflow
component design. Will do soon.

Regards,
Johann.

>
> Appreciate your feedback.
>
> [1]
> https://github.com/wso2/carbon-apimgt/blob/master/components/apimgt/org.wso2.carbon.apimgt.impl/src/main/java/org/wso2/carbon/apimgt/impl/workflow/WorkflowExecutor.java
> [2]
> https://github.com/pulasthi7/carbon-identity/blob/feature/workflow-support/components/workflows/org.wso2.carbon.workflow.mgt/src/main/java/org/wso2/carbon/workflow/mgt/dao/WorkflowRequestDAO.java
>
> Thanks,
> Tanya
>
> --
> Tanya Madurapperuma
>
> Software Engineer,
> WSO2 Inc. : wso2.com
> Mobile : +94718184439
> Blog : http://tanyamadurapperuma.blogspot.com
>



-- 
Thanks & Regards,

*Johann Dilantha Nallathamby*
Associate Technical Lead & Product Lead of WSO2 Identity Server
Integration Technologies Team
WSO2, Inc.
lean.enterprise.middleware

Mobile - *+9476950*
Blog - *http://nallaa.wordpress.com *
___
Architecture mailing list
Architecture@wso2.org
https://mail.wso2.org/cgi-bin/mailman/listinfo/architecture

[Architecture] Generic workflow executor across the platform

[Tanya Madurapperuma]

Hi all,

We are in the process of implementing the workflow support for ES and came
across the $Subject.
Although many products have worflow support, seems there is no generic
component to achieve this.

The workflow executor for APIM [1] cannot be used platform wide since they
pass the ApiMgtDAO to execute method in their executor.

Similar issue is there with the IS workflow executor where they preserve
the workflow information in the identity database [2] (refer
addWorkflowEntry method)

IMO other products should be able to use their own workflow info
preservation mechanism.
Ex: To store in the registry
   To store in a database
Say in ES, we want to provide workflow support for asset creation. Storing
asset level info in Identity database doesn't make sense.

Appreciate your feedback.

[1]
https://github.com/wso2/carbon-apimgt/blob/master/components/apimgt/org.wso2.carbon.apimgt.impl/src/main/java/org/wso2/carbon/apimgt/impl/workflow/WorkflowExecutor.java
[2]
https://github.com/pulasthi7/carbon-identity/blob/feature/workflow-support/components/workflows/org.wso2.carbon.workflow.mgt/src/main/java/org/wso2/carbon/workflow/mgt/dao/WorkflowRequestDAO.java

Thanks,
Tanya

-- 
Tanya Madurapperuma

Software Engineer,
WSO2 Inc. : wso2.com
Mobile : +94718184439
Blog : http://tanyamadurapperuma.blogspot.com
___
Architecture mailing list
Architecture@wso2.org
https://mail.wso2.org/cgi-bin/mailman/listinfo/architecture