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 pulast...@wso2.com:
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 fr...@wso2.com 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 pulast...@wso2.com:
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 ta...@wso2.com
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 ta...@wso2.com
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 joh...@wso2.com
wrote:
Hi Tanya,
On Tue, Mar 31, 2015 at 4:59 PM, Tanya Madurapperuma ta...@wso2.com
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
