Hi all,
As mentioned in a previous mail ( [ES] Workflow extensions support -
Approval task pages or app ? ), we are planning to develop a workflow
extension model for Enterprise strore. Following is the proposed
architecture.
Below diagram explains how the workflow structure fits in to the ES
extension model.
*Types of extensions*
As illustrated in the digram, there are two types of workflows.
- Global worlfows which are common to all types of assets (in blue
colour)
- Asset level workflows which are asset specific (in yellow colour)
Both types of workflows can be overided using the ES extension model.
(shown in purple and orange respectively)
*Function Flow*
js file inside each workflow will implement two functions.
- *execute*
- contains the BPEL endpoint calling logic
- *process*
- handle callback from the endpoint
- does the actual functionality upon admin approval
Within the actual function where we want to trigger a workflow (Ex : Inside
self sign up function ), a function with the following definition will be
called.
*workflow ( workflow_name, context, function(){*
* // does the actual implementation (Ex: in self sign up, add the user
into relevant user store)*
* // this is called when workflows are not enabled.*
*})*
If workflows are enabled, inside the *workflow* function, perform the
validations of the workflow and call *execute* method of the relevant
workflow.
If workflows are not enabled, function passed into the *workflow* function
will be called.
*execute *function should return an object in the following (standard)
format so that page rendering that depends on workflow enabled/disabled can
be easily handled.
{
metadata :
data :
status :
message :
}
Appreciate any feedback regarding the above model.
Thanks,
Tanya
--
Tanya Madurapperuma
Software Engineer,
WSO2 Inc. : wso2.com
Mobile : +94718184439
Blog : http://tanyamadurapperuma.blogspot.com
_______________________________________________
Architecture mailing list
[email protected]
https://mail.wso2.org/cgi-bin/mailman/listinfo/architecture
