Re: [Architecture] Generic workflow support

2015-04-16 Thread Sumedha Rubasinghe 
Pulasthi,
Sorry for the late reply. But check how API Manager and App Manager has
implemented workflow support.

It has been implemented in a generic way that can be used by other products.

API Manager's workflow support was added about 1.5 years ago.

On Sat, Apr 4, 2015 at 5:31 PM, Pulasthi Mahawithana 
wrote:

> Hi,
>
> Following is the architecture of the workflow support framework. This was
> initially planned for IS, but can be used across the platform.
>
>
>
> ​
>
> *Workflow Request Handler*
> Build workflow requests and handle the callback requests. This interface
> can be implemented to be used for any event that need to trigger workflows.
> The request will have a uuid, and a set of parameters with their values.
> All these parameters are persisted and will be available at the callback
> handler by the time of response. However the requester can decide which of
> these parameters should be sent to the workflow executor and which should
> not.
>
> The callback handler will get the same request generated by the request
> builder, along with the status from the executor (approved, rejected or
> custom status). Based on the status the event can be completed or cancelled
> at the callback handler.
>
> *Workflow Executor*
> Execute the workflow engine and provide the response back along with the
> uuid. One implementation of this will be the BPEL/WS executor and will be
> available by default. However any other java implementation can also be
> used here.
>
> *WorkflowManager*
> Both RequestHandlers and Executors need to be registered here as OSGI
> services. In addition to that, WorkflowManager will
>
>- Decide which executor should be invoked for each request.
>- Persist the requests and maintain their state.
>- Receive responses from the executors and forward them to their
>respective callbackHandler.
>
>
> --
> *Pulasthi Mahawithana*
> Software Engineer
> WSO2 Inc., http://wso2.com/
> Mobile: +94-71-5179022
> Blog: http://blog.pulasthi.org
>
> ___
> Architecture mailing list
> Architecture@wso2.org
> https://mail.wso2.org/cgi-bin/mailman/listinfo/architecture
>
>


-- 
/sumedha
m: +94 773017743
b :  bit.ly/sumedha
___
Architecture mailing list
Architecture@wso2.org
https://mail.wso2.org/cgi-bin/mailman/listinfo/architecture

Re: [Architecture] Generic workflow support

2015-04-11 Thread Frank Leymann 
Hi Pulasthi,

based on what information will the Workflow Manager decide which Workflow
Executor to use?


Best regards,
Frank

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

> Hi,
>
> Following is the architecture of the workflow support framework. This was
> initially planned for IS, but can be used across the platform.
>
>
>
> ​
>
> *Workflow Request Handler*
> Build workflow requests and handle the callback requests. This interface
> can be implemented to be used for any event that need to trigger workflows.
> The request will have a uuid, and a set of parameters with their values.
> All these parameters are persisted and will be available at the callback
> handler by the time of response. However the requester can decide which of
> these parameters should be sent to the workflow executor and which should
> not.
>
> The callback handler will get the same request generated by the request
> builder, along with the status from the executor (approved, rejected or
> custom status). Based on the status the event can be completed or cancelled
> at the callback handler.
>
> *Workflow Executor*
> Execute the workflow engine and provide the response back along with the
> uuid. One implementation of this will be the BPEL/WS executor and will be
> available by default. However any other java implementation can also be
> used here.
>
> *WorkflowManager*
> Both RequestHandlers and Executors need to be registered here as OSGI
> services. In addition to that, WorkflowManager will
>
>- Decide which executor should be invoked for each request.
>- Persist the requests and maintain their state.
>- Receive responses from the executors and forward them to their
>respective callbackHandler.
>
>
> --
> *Pulasthi Mahawithana*
> Software Engineer
> WSO2 Inc., http://wso2.com/
> Mobile: +94-71-5179022
> Blog: http://blog.pulasthi.org
>
> ___
> Architecture mailing list
> Architecture@wso2.org
> https://mail.wso2.org/cgi-bin/mailman/listinfo/architecture
>
>
___
Architecture mailing list
Architecture@wso2.org
https://mail.wso2.org/cgi-bin/mailman/listinfo/architecture

Re: [Architecture] Generic workflow support

2015-04-08 Thread Vinod Kavinda 
Hi,

We[BPS team] have plans to develop workflow Integration components that
will tally with this implementation. Hence different products will not
require to build workflow extensions to obtain human intervention for
approval processes for certain activities performed within these products.

Idea is to provide two UI components and a feature inside BPS to support
workflow integration.

UI components



   Task UI  Notification UI

 Task List : list of submitted tasks.

Task UI : provide generic task interaction functionality on a selected task.

Statistics : Statistics on overall tasks and processes. (states of
tasks,avg approval time etc.)

Port,Hostname : configurations to connect BPS

Notification UI widget : This is a separate UI component that provide
notifications on pending tasks to the user

Workflow enablement component

BPEL : generic BPEL process that can used by other products

Human Task : Human Task with externalized endpoints embedded.

Web page : allows to register configurations for callbacks and
notifications.

So, these two will provide end to end workflow management support for any
product. It is better if we can collaborate on certain areas such as DB.

Please provide your feedback.


Regards.

Vinod


On Sat, Apr 4, 2015 at 5:31 PM, Pulasthi Mahawithana 
wrote:

> Hi,
>
> Following is the architecture of the workflow support framework. This was
> initially planned for IS, but can be used across the platform.
>
>
>
> ​
>
> *Workflow Request Handler*
> Build workflow requests and handle the callback requests. This interface
> can be implemented to be used for any event that need to trigger workflows.
> The request will have a uuid, and a set of parameters with their values.
> All these parameters are persisted and will be available at the callback
> handler by the time of response. However the requester can decide which of
> these parameters should be sent to the workflow executor and which should
> not.
>
> The callback handler will get the same request generated by the request
> builder, along with the status from the executor (approved, rejected or
> custom status). Based on the status the event can be completed or cancelled
> at the callback handler.
>
> *Workflow Executor*
> Execute the workflow engine and provide the response back along with the
> uuid. One implementation of this will be the BPEL/WS executor and will be
> available by default. However any other java implementation can also be
> used here.
>
> *WorkflowManager*
> Both RequestHandlers and Executors need to be registered here as OSGI
> services. In addition to that, WorkflowManager will
>
>- Decide which executor should be invoked for each request.
>- Persist the requests and maintain their state.
>- Receive responses from the executors and forward them to their
>respective callbackHandler.
>
>
> --
> *Pulasthi Mahawithana*
> Software Engineer
> WSO2 Inc., http://wso2.com/
> Mobile: +94-71-5179022
> Blog: http://blog.pulasthi.org
>
> ___
> Architecture mailing list
> Architecture@wso2.org
> https://mail.wso2.org/cgi-bin/mailman/listinfo/architecture
>
>


-- 
Vinod Kavinda
Software Engineer, *WSO2, Inc .*
Mobile : +94 (0) 712 415544
vi...@wso2.com
___
Architecture mailing list
Architecture@wso2.org
https://mail.wso2.org/cgi-bin/mailman/listinfo/architecture

[Architecture] Generic workflow support

2015-04-04 Thread Pulasthi Mahawithana 
Hi,

Following is the architecture of the workflow support framework. This was
initially planned for IS, but can be used across the platform.



​

*Workflow Request Handler*
Build workflow requests and handle the callback requests. This interface
can be implemented to be used for any event that need to trigger workflows.
The request will have a uuid, and a set of parameters with their values.
All these parameters are persisted and will be available at the callback
handler by the time of response. However the requester can decide which of
these parameters should be sent to the workflow executor and which should
not.

The callback handler will get the same request generated by the request
builder, along with the status from the executor (approved, rejected or
custom status). Based on the status the event can be completed or cancelled
at the callback handler.

*Workflow Executor*
Execute the workflow engine and provide the response back along with the
uuid. One implementation of this will be the BPEL/WS executor and will be
available by default. However any other java implementation can also be
used here.

*WorkflowManager*
Both RequestHandlers and Executors need to be registered here as OSGI
services. In addition to that, WorkflowManager will

   - Decide which executor should be invoked for each request.
   - Persist the requests and maintain their state.
   - Receive responses from the executors and forward them to their
   respective callbackHandler.


-- 
*Pulasthi Mahawithana*
Software Engineer
WSO2 Inc., http://wso2.com/
Mobile: +94-71-5179022
Blog: http://blog.pulasthi.org
___
Architecture mailing list
Architecture@wso2.org
https://mail.wso2.org/cgi-bin/mailman/listinfo/architecture