On Tue, Nov 26, 2013 at 1:48 PM, Chan <[email protected]> wrote: > +1 for having a workflow approach. This would allow a much more complex > approval process to be built as well. When the APIM calls the user defined > interface it can go through a business logic of getting approval via > workflow (Go from one user to another user for approval) also it will > enable the user to delegate it to an assigned user or user category. > > But I still have a question regarding the security of the endpoint. How do > we secure it? Basic Auth? >
Yes we're planning to support Basic Auth for this phase. Credentials will be stored in the configuration file, with securevault support of course. > > > *Peace~* > --- > Chan (Dulitha Wijewantha) > Software Engineer - Mobile Development > WSO2Mobile > Lean.Enterprise.Mobileware > * ~Email [email protected] <[email protected]>* > * ~Mobile +94712112165 <%2B94712112165>* > > * ~Website dulithawijewantha.com <http://dulithawijewantha.com/>* > > * ~Blog blog.dulithawijewantha.com > <http://dulichan.github.io/chan/>* > * ~Twitter @dulitharw <https://twitter.com/dulitharw>* > > On November 26, 2013 at 12:24:01 PM, Nuwan Dias > ([email protected]<//[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. > > 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<%2B34%20616050684> >>>> >>>> >>>> >>>> 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<%2B34%20616050684> >>>>>> >>>>>> >>>>>> >>>>>> 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 > > -- 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
