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. 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 which has an interface (REST?) defined by us. Users can have their own implementation of the interface. The callback URL (the endpoint to be invoked when the workflow execution is complete) will be part of the payload. 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 subscription database entry will be created with its state as Inactive. Upon completion of the workflow, the third party will invoke the callback URL. This call will complete the relevant action intended to be performed above. Ex: Change the subscription state to 'Active'. The same model described here 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. On Wed, Dec 12, 2012 at 12:04 PM, Srinath Perera <[email protected]> wrote: > When the workflow is invoked, it might takes days for it to finish > (specially if human involved) > > So App Factory has to remember the state in a DB and need a callback URL > for response. > > I think Sanjiva is also referring to the same > > > On Sun, Dec 9, 2012 at 8:55 AM, Sanjiva Weerawarana <[email protected]>wrote: > >> Is this thread pre- or post- the roadmap discussion where this issue was >> considered? >> >> I agree with Isabelle - not only an interface but also a callback URL >> scheme has to be there (not written in the config but part of the >> contract). If we are modeling the workflow stuff as "when I'm asked to do x >> I will call some external endpoint and wait for it to call me back at a >> particular place with an ok/no response" then this has nothing to do with >> BPS (which is great). We just need to design the two interfaces, document >> them and then use it. Other key part is to make the user experience in the >> API Store asynchronous as we discussed. >> >> BTW if you have a user/pass in any config file you MUST use securevault. >> NO adding it later. >> >> Sanjiva. >> >> >> On Fri, Dec 7, 2012 at 9:16 PM, Isabelle Mauny <[email protected]> wrote: >> >>> Sanjeewa, >>> >>> I don't see how we can publish an extension point with no interface >>> definition. People expect input to the service and we expect a response. >>> Without the interaction cleanly defined, we don't have a clean extension >>> point. We can't just pass a String either. All the information gathered as >>> part of the user subscription needs to be passed as parameter. >>> >>> I suspect there might be a misunderstanding here: the user creation will >>> actually happen outbound. We just pass the request to create a user. The >>> workflow and code behind it must create the user and provision it in the >>> right place. This is totally asynchronous. Makes it must simpler for >>> everybody (responsibilities are clear) >>> >>> WDYT? >>> Isabelle. >>> >>> ------ >>> Isabelle Mauny >>> Director, Product Management; WSO2, Inc.; http://wso2.com/ >>> email: [email protected] <[email protected]> - mobile: +34 616050684 >>> >>> >>> >>> On Fri, Dec 7, 2012 at 2:21 PM, Sanjeewa Malalgoda <[email protected]>wrote: >>> >>>> Hi Isabelle, >>>> >>>> On Fri, Dec 7, 2012 at 3:57 PM, Isabelle Mauny <[email protected]>wrote: >>>> >>>>> Sanjeewa, >>>>> >>>>> Just to confirm, although we are implemented a simple with BPS , this >>>>> is really just a service call right ? >>>>> >>>> Yes this is web service call to BPS. >>>> >>>>> >>>>> >>>>> Is there a specific interface to respect ? (I guess we need to pass >>>>> some specific data in ? ) >>>>> >>>> Yes providing interface is good idea. So we can ask user to implement >>>> it as they need with custom payload and parameters. For this stage we will >>>> pass single string parameter to simple work flow and continue user creation >>>> process. >>>> >>>> >>>>> >>>>> How is error handling working : for example , are you waiting for a >>>>> 202 Accepted to decide the request worked ? >>>>> >>>> With design we can call to BPS before actual user creation. So If need >>>> we can block user adding action based on the response of BPS call. >>>> >>>> Thanks. >>>> >>>> >>>>> Thanks, >>>>> Isabelle. >>>>> >>>>> ------ >>>>> Isabelle Mauny >>>>> Director, Product Management; WSO2, Inc.; http://wso2.com/ >>>>> email: [email protected] <[email protected]> - mobile: +34 616050684 >>>>> >>>>> >>>>> >>>>> On Fri, Dec 7, 2012 at 10:20 AM, Sanjeewa Malalgoda <[email protected] >>>>> > wrote: >>>>> >>>>>> Hi, >>>>>> Configuration would be like this. Extension parameters are based on >>>>>> the process. >>>>>> >>>>>> <WorkFlowExtensions> >>>>>> <SelfSignIn> >>>>>> <ProcessEnabled>true</ProcessEnabled> >>>>>> <ServerURL>http://test.com/service</ServerURL> >>>>>> <UserName>admin</UserName> >>>>>> <Password>admin</Password> >>>>>> </SelfSignIn> >>>>>> </WorkFlowExtensions> >>>>>> >>>>>> Thanks. >>>>>> >>>>>> On Fri, Dec 7, 2012 at 12:27 PM, Sanjeewa Malalgoda < >>>>>> [email protected]> wrote: >>>>>> >>>>>>> HI All, >>>>>>> I did slight modification to configuration syntax pointed out by >>>>>>> sumedha. I have to do that because current API Manager configuration >>>>>>> parser >>>>>>> is very effective and well designed to add any number of parameters in a >>>>>>> complex manner. So i didn't wanted to change it. >>>>>>> For this implementation i added user creation process listener and >>>>>>> bpel work flow. Please advice me what are the parameters we should pass >>>>>>> to >>>>>>> external work flow and what should we get back from work flow. Also if >>>>>>> we >>>>>>> create stub for workflow service and invoked it through client we cannot >>>>>>> change it in future. How should we implement this in a general way? >>>>>>> >>>>>>> Thanks. >>>>>>> >>>>>>> On Tue, Dec 4, 2012 at 6:35 PM, Sumedha Rubasinghe <[email protected] >>>>>>> > wrote: >>>>>>> >>>>>>>> On Tue, Dec 4, 2012 at 6:04 PM, Sanjeewa Malalgoda < >>>>>>>> [email protected]> wrote: >>>>>>>> >>>>>>>>> Hi All, >>>>>>>>> Over last few months we have noticed that we need to support >>>>>>>>> business process and human interaction for some of API Manager related >>>>>>>>> operations. As an example we can consider self registration process. >>>>>>>>> At the >>>>>>>>> moment anyone can come to store and create new account. So they can >>>>>>>>> use any >>>>>>>>> api without any permission check or validation. So we thought of >>>>>>>>> triggering >>>>>>>>> some business process as a part of self sign in process. So we can >>>>>>>>> direct >>>>>>>>> user creation process into business process. If we need to generate >>>>>>>>> email >>>>>>>>> or approve by super administrator, we can do it easily by using this. >>>>>>>>> For >>>>>>>>> this implementation we have identified few operations. A >>>>>>>>> 01. API Store self sign in process. >>>>>>>>> 02. Publisher API creation process. >>>>>>>>> 03. API Store application subscription. >>>>>>>>> >>>>>>>>> We will allow users to define these configurations in >>>>>>>>> api-manager.xml file. Sample configuration would be like this (For >>>>>>>>> self >>>>>>>>> sign-in). >>>>>>>>> >>>>>>>>> <SelfSignIn> >>>>>>>>> <SelfSignInProcessEnable>true<SelfSignInProcessEnable> >>>>>>>>> <ProcessServerURL>http://test.com/services/signin >>>>>>>>> </ProcessServerURL> >>>>>>>>> <UserName>admin</UserName> >>>>>>>>> <Password>admin</Password> >>>>>>>>> </SelfSignIn> >>>>>>>>> >>>>>>>>> Sanjeewa, >>>>>>>> Rather than coming up with different elements for each and every >>>>>>>> process, we can use a common configuration to define these extension >>>>>>>> points. >>>>>>>> >>>>>>>> eg: >>>>>>>> <WorkFlowExtensions> >>>>>>>> <WorkFlowExtension> >>>>>>>> <Process>StoreSelfSignIn</Process> >>>>>>>> >>>>>>>> <ProcessServerURL>http://test.com/services/signin >>>>>>>> </ProcessServerURL> >>>>>>>> <UserName>admin</UserName> >>>>>>>> <Password>admin</Password> >>>>>>>> <CallBackURL/> <!-- if any --> >>>>>>>> </WorkFlowExtension> >>>>>>>> >>>>>>>> <WorkFlowExtension> >>>>>>>> <Process>Subscription</Process> >>>>>>>> >>>>>>>> <ProcessServerURL>http://test.com/services/subscription<http://test.com/services/signin> >>>>>>>> </ProcessServerURL> >>>>>>>> <UserName>admin</UserName> >>>>>>>> <Password>admin</Password> >>>>>>>> <CallBackURL/> <!-- if any --> >>>>>>>> </WorkFlowExtension> >>>>>>>> >>>>>>>> <WorkFlowExtensions> >>>>>>>> >>>>>>>> >>>>>>>> >>>>>>>> For the first phase we will try simple workflow and then we can >>>>>>>>> move into advanced configurable processes. Ideas and comments are >>>>>>>>> welcome. >>>>>>>>> >>>>>>>>> Thanks. >>>>>>>>> -- >>>>>>>>> *Sanjeewa Malalgoda* >>>>>>>>> WSO2 Inc. >>>>>>>>> Mobile : +14084122175 | +94713068779 >>>>>>>>> >>>>>>>>> <http://sanjeewamalalgoda.blogspot.com/>blog >>>>>>>>> :http://sanjeewamalalgoda.blogspot.com/<http://sanjeewamalalgoda.blogspot.com/> >>>>>>>>> >>>>>>>>> >>>>>>>> >>>>>>>> >>>>>>>> -- >>>>>>>> /sumedha >>>>>>>> m: +94 773017743 >>>>>>>> b : bit.ly/sumedha >>>>>>>> >>>>>>>> >>>>>>> >>>>>>> >>>>>>> -- >>>>>>> *Sanjeewa Malalgoda* >>>>>>> WSO2 Inc. >>>>>>> Mobile : +14084122175 | +94713068779 >>>>>>> >>>>>>> <http://sanjeewamalalgoda.blogspot.com/>blog >>>>>>> :http://sanjeewamalalgoda.blogspot.com/<http://sanjeewamalalgoda.blogspot.com/> >>>>>>> >>>>>>> >>>>>> >>>>>> >>>>>> -- >>>>>> *Sanjeewa Malalgoda* >>>>>> WSO2 Inc. >>>>>> Mobile : +14084122175 | +94713068779 >>>>>> >>>>>> <http://sanjeewamalalgoda.blogspot.com/>blog >>>>>> :http://sanjeewamalalgoda.blogspot.com/<http://sanjeewamalalgoda.blogspot.com/> >>>>>> >>>>>> >>>>> >>>> >>>> >>>> -- >>>> *Sanjeewa Malalgoda* >>>> WSO2 Inc. >>>> Mobile : +14084122175 | +94713068779 >>>> >>>> <http://sanjeewamalalgoda.blogspot.com/>blog >>>> :http://sanjeewamalalgoda.blogspot.com/<http://sanjeewamalalgoda.blogspot.com/> >>>> >>>> >>> >>> _______________________________________________ >>> Architecture mailing list >>> [email protected] >>> https://mail.wso2.org/cgi-bin/mailman/listinfo/architecture >>> >>> >> >> >> -- >> Sanjiva Weerawarana, Ph.D. >> Founder, Chairman & CEO; WSO2, Inc.; http://wso2.com/ >> email: [email protected]; phone: +94 11 763 9614; cell: +94 77 787 6880 | +1 >> 650 265 8311 >> blog: http://sanjiva.weerawarana.org/ >> >> Lean . Enterprise . Middleware >> >> _______________________________________________ >> Architecture mailing list >> [email protected] >> https://mail.wso2.org/cgi-bin/mailman/listinfo/architecture >> >> > > > -- > ============================ > Srinath Perera, Ph.D. > http://www.cs.indiana.edu/~hperera/ > http://srinathsview.blogspot.com/ > > _______________________________________________ > Architecture mailing list > [email protected] > https://mail.wso2.org/cgi-bin/mailman/listinfo/architecture > > -- 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
