On Wed, Nov 27, 2013 at 11:47 AM, Pulasthi Supun <[email protected]> wrote:
> > > Hi, > > On Mon, Nov 25, 2013 at 5:53 PM, Nuwan Dias <[email protected]> wrote: > >> Hi, >> >> We are about to start work on $subject. We have identified 4 locations >> where we can integrate with workflows. Those are, >> >> 1. Self Sign-Up on the API Store. >> 2. Application Creation >> 3. Subscribing Applications to APIs >> 4. Adding Comments. >> >> > FYI with Greg-4.6.0 on-wards there is support to call web services or > BPELs when a lifecycle state is changed ( only SOAP based for now does not > support REST calls yet ). If all the events that need to trigger an > workflow has an lifecyle state change that feature would be useful, if not > would be better if its done as already planned :). > If we are to go with registry lifecycle state changes, we would first have to have a registry artifact per each item above. Ex: Each subscription would first have to map to a registry artifact so that we can attach a lifecycle to it. This is not the case as of now, therefore it would be best to stick to the first suggested approach IMO. > > Whenever a user attempts to perform one of the actions above, there will >> be an extension point from the API Manager which will be invoked. This >> would be a service endpoint (REST?) where users can have their own >> implementation. >> >> Whenever this service endpoint is invoked, the intended action will not >> be performed completely. Rather it will end up in an intermediary state. >> Ex: If a workflow is executed on creating a subscription, the database >> entry will be created with its state as Inactive. Upon completion of the >> workflow, there will be an endpoint exposed on the API Manager which >> clients need to invoke so that the subscription will now move into Active >> state. >> >> > Would this also support asynchronous invocation of workflows were the > action ( like app creation ) does not need to know about the out come of > the workflow that is executed and can complete after just invoking the > workflow. not sure if there are many valid use cases for this scenario but > for completeness. > > Yes, each action is asynchronous. If we take the example of Application Creation, the application will be created irrespective of the workflow execution outcome. But for someone to use that Application to subscribe to APIs, then it would require the workflow to be completed. > > Regards, > Pulasthi > >> The same model described above will be used for all usecases given above. >> For this to be possible, the following columns need to be added to the >> relevant tables. >> >> i) Status - Active/Inactive >> ii) Workflow ID - This is for having a reference id between the executed >> workflow and the relevant database entry. >> iii) Workflow Status Message - This if for storing a message which can be >> useful meta information. Ex: If a subscription approval was rejected, why? >> >> Appreciate your thoughts and suggestions on this. >> >> Thanks, >> NuwanD. >> >> -- >> Nuwan Dias >> >> Senior Software Engineer - WSO2, Inc. http://wso2.com >> email : [email protected] >> Phone : +94 777 775 729 >> >> _______________________________________________ >> Architecture mailing list >> [email protected] >> https://mail.wso2.org/cgi-bin/mailman/listinfo/architecture >> >> > > > -- > -- > Pulasthi Supun > Software Engineer; WSO2 Inc.; http://wso2.com, > Email: [email protected] > Mobile: +94 (71) 9258281 > Blog : http://pulasthisupun.blogspot.com/ > Git hub profile: https://github.com/pulasthi > > _______________________________________________ > Architecture mailing list > [email protected] > https://mail.wso2.org/cgi-bin/mailman/listinfo/architecture > > Thanks, NuwanD. -- Nuwan Dias Senior Software Engineer - WSO2, Inc. http://wso2.com email : [email protected] Phone : +94 777 775 729
_______________________________________________ Architecture mailing list [email protected] https://mail.wso2.org/cgi-bin/mailman/listinfo/architecture
