+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? Peace~ --- Chan (Dulitha Wijewantha) Software Engineer - Mobile Development WSO2Mobile Lean.Enterprise.Mobileware ~Email [email protected] ~Mobile +94712112165 ~Website dulithawijewantha.com ~Blog blog.dulithawijewantha.com ~Twitter @dulitharw On November 26, 2013 at 12:24:01 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. 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] - 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] - 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</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 blog :http://sanjeewamalalgoda.blogspot.com/ -- /sumedha m: +94 773017743 b : bit.ly/sumedha -- Sanjeewa Malalgoda WSO2 Inc. Mobile : +14084122175 | +94713068779 blog :http://sanjeewamalalgoda.blogspot.com/ -- Sanjeewa Malalgoda WSO2 Inc. Mobile : +14084122175 | +94713068779 blog :http://sanjeewamalalgoda.blogspot.com/ -- Sanjeewa Malalgoda WSO2 Inc. Mobile : +14084122175 | +94713068779 blog :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
_______________________________________________ Architecture mailing list [email protected] https://mail.wso2.org/cgi-bin/mailman/listinfo/architecture
