Hi Frank, Thanks for the clarification. I have created [1] to track the issue.
Thank you. Malintha [1] https://wso2.org/jira/browse/APIMANAGER-4295 On Sat, Nov 28, 2015 at 6:57 PM, Frank Leymann <[email protected]> wrote: > Hi Malintha, > > using 202 Accepted without returning a Content-Location header that the > client can poll is no real solution. This is because the client needs a URL > to poll for the actual status whenever the client wants. If this is to > much to implement for the next release, we should note that issue and > implement it for the release after the next. > > > Best regards, > Frank > > 2015-11-27 17:20 GMT+01:00 Malintha Amarasinghe <[email protected]>: > >> Hi All, >> >> Thanks a lot for all the suggestions. >> >> Hi Frank, >> >> According to your suggestion, is it OK to change the response type 202 >> Accepted, but keeping the response as it is?. We might be able to check if >> the status is ON_HOLD and change the response code accordingly to 202 >> Accepted. If the status is UNBLOCKED, we can set the status code to 201 >> Created. Would this solution be OK for the moment till we implement this >> properly? >> >> Thank you, >> Malintha >> >> On Fri, Nov 27, 2015 at 3:11 PM, Frank Leymann <[email protected]> wrote: >> >>> +1 on REST APIs for BPS. >>> >>> I'll be in Colombo for WSO2Conn Asia in February. I know it's a long >>> time until than, but I suggest to have a joint design session on that >>> subject - let me know if we should pursue this... >>> >>> >>> Best regards, >>> Frank >>> >>> 2015-11-27 6:31 GMT+01:00 Sanjeewa Malalgoda <[email protected]>: >>> >>>> >>>> >>>> On Thu, Nov 26, 2015 at 11:28 PM, Joseph Fonseka <[email protected]> >>>> wrote: >>>> >>>>> Hi All >>>>> >>>>> Did some background check on possibility of having a task resources. >>>>> >>>>> Nandika informed us about the REST service support in BPS. As of now >>>>> BPEL implementation in BPS only deals with SOAP services and BPMN has a >>>>> REST API. So this will give us few complications. >>>>> >>>>> 1. IMO task resource should be provided from BPS which we can point to >>>>> from our REST API. >>>>> 2. Even though BPMN has a REST service currently our workflows works >>>>> with BPEL which require us to do a migration to BPMN if we want to use the >>>>> REST API. >>>>> 3. Given the time I do not think switching to BPMN is possible ( Even >>>>> if we decides that is the correct thing to do ) and we need to think about >>>>> existing customers. >>>>> 4. Or implement REST support to BPEL ( again hard to do with the time >>>>> line ) >>>>> >>>>> That leads us to following options. >>>>> 1. Implement REST API to fetch task resources in API manager. >>>>> 2. Send the workflow related data in a resource it self ( Or we can >>>>> send it in a header ). >>>>> 3. Postpone the workflow integration with REST API to next release. ( >>>>> We will be still supporting workflows but REST API will not send workflow >>>>> related data ) >>>>> >>>> Yes i also agree with you Jo. The reason is we have very little time to >>>> complete this task and it will not allow us to spend enough time on this. >>>> And By the time we plan next release we will have some better solution >>>> from BPS side. >>>> As we discussed we may wrap BPEL admin services with REST API. But it >>>> will not added value to both products. >>>> Next release we need to come to conclusion about BPMN. If that is >>>> possible then we can use same rest API. >>>> >>>> Thanks, >>>> sanjeewa. >>>> >>>> >>>>> >>>>> I favor 3rd option since that will give us enough time to properly >>>>> evaluate the options and come up with a good design. >>>>> >>>>> WDYT? >>>>> >>>>> Thanks >>>>> Jo >>>>> >>>>> >>>>> >>>>> >>>>> On Thu, Nov 26, 2015 at 7:54 PM, Frank Leymann <[email protected]> wrote: >>>>> >>>>>> Dear all, >>>>>> >>>>>> why do we want to express by returning "ON_HOLD"? I assume (correct >>>>>> me if I am wrong) we want to say that the resource has not yet been >>>>>> created >>>>>> because the workflow is still running: it depends on the result of the >>>>>> workflow whether finally the subscription will be made or not. >>>>>> >>>>>> If this is the case, we must not return a "201 Created" because the >>>>>> resource is not created. But we have to return "201 Accepted" with a task >>>>>> resource in the body of the response; also, a Content-Location header has >>>>>> to be returned that contains the URL of the task resource; this URL will >>>>>> be >>>>>> used by the client to check changes in the status of the task (i.e. the >>>>>> workflow). >>>>>> >>>>>> If the long running request (the workflow) completed successfully, a >>>>>> GET on the URL of the task resource will return with "303 See Other" and >>>>>> a >>>>>> Location header field containing the URL of the created resource (i.e. >>>>>> the >>>>>> subscription). >>>>>> >>>>>> It the long running request completes UNsuccessfull, a GET on the URL >>>>>> of the task resource will return a "200 OK" BUT the task resource (i.e. >>>>>> the >>>>>> information about the status of the workflow) in the body will contain >>>>>> the >>>>>> information that the request failed together with other information we >>>>>> deem >>>>>> appropriate. >>>>>> >>>>>> >>>>>> >>>>>> Best regards, >>>>>> Frank >>>>>> >>>>>> 2015-11-24 14:21 GMT+01:00 Nuwan Dias <[email protected]>: >>>>>> >>>>>>> >>>>>>> >>>>>>> On Tue, Nov 24, 2015 at 6:25 PM, Malintha Amarasinghe < >>>>>>> [email protected]> wrote: >>>>>>> >>>>>>>> Hi All, >>>>>>>> >>>>>>>> I configured the subscription creation workflow and tested it with >>>>>>>> the current implementation of the REST API. >>>>>>>> >>>>>>>> When we add a subscription in normal scenario we get the following >>>>>>>> response. >>>>>>>> >>>>>>>> *Request*: >>>>>>>> >>>>>>>> POST http://127.0.0.1:9764/api/am/store/v1//subscriptions HTTP/1.1 >>>>>>>> >>>>>>>> { >>>>>>>> "tier": "Silver", >>>>>>>> "apiId": "2f4a020b-2a0d-4a47-b385-a22a93577082", >>>>>>>> "applicationId": "69041195-1e81-48f5-8892-2ab053b0501c", >>>>>>>> } >>>>>>>> >>>>>>>> >>>>>>>> *Response:* >>>>>>>> >>>>>>>> HTTP/1.1 *201* Created >>>>>>>> >>>>>>>> Location: http://127.0.0.1:9764/api/am/store/v1/subscriptions/ >>>>>>>> 63ab53d3-0cb7-46df-8ce9-cd84f2882b27 >>>>>>>> Content-Type: application/json >>>>>>>> >>>>>>>> >>>>>>>> { >>>>>>>> "tier": "Silver", >>>>>>>> "subscriptionId": "63ab53d3-0cb7-46df-8ce9-cd84f2882b27", >>>>>>>> "apiId": "2f4a020b-2a0d-4a47-b385-a22a93577082", >>>>>>>> "applicationId": "69041195-1e81-48f5-8892-2ab053b0501c", >>>>>>>> *"status": "UNBLOCKED"* >>>>>>>> } >>>>>>>> >>>>>>>> >>>>>>>> When we have a subscription creation workflow enabled, we receive a >>>>>>>> response like follow. >>>>>>>> >>>>>>>> HTTP/1.1 *201* Created >>>>>>>> >>>>>>>> Location: http://127.0.0.1:9764/api/am/store/v1/subscriptions/ >>>>>>>> def79733-e55e-464f-9630-c1ae595344f2 >>>>>>>> Content-Type: application/json >>>>>>>> >>>>>>>> { >>>>>>>> "subscriptionId": "def79733-e55e-464f-9630-c1ae595344f2", >>>>>>>> "apiId": "admin-pubApi-1.0", >>>>>>>> "tier": "Silver", >>>>>>>> "applicationId": "69041195-1e81-48f5-8892-2ab053b0501c", >>>>>>>> *"status": "ON_HOLD"* >>>>>>>> } >>>>>>>> >>>>>>>> >>>>>>>> Here we can see that the status is ON_HOLD. In this case we can >>>>>>>> also see some more information that are coming from APIM underline >>>>>>>> implementation, which are follows: >>>>>>>> >>>>>>>> - redirectUrl : "http://google.lk"; >>>>>>>> - displayUrl : "http://wso2.com"; >>>>>>>> - workflowRefId : "0b94b11a-2736-48a0-b43e-c7cc35d8516d" >>>>>>>> - CallbackUrl : http://google.lk >>>>>>>> >>>>>>>> >>>>>>>> Do we need to include this info in the response object? If so what >>>>>>>> would be the best approach? >>>>>>>> >>>>>>> >>>>>>> What if we add this info to the response payload under a section >>>>>>> called something like "workflowInformation" ? >>>>>>> >>>>>>>> >>>>>>>> Few ways that are possible include: >>>>>>>> >>>>>>>> - Add those additional information into the response object >>>>>>>> - Add this redirect URL as HTTP 302 redirection as the Location >>>>>>>> header >>>>>>>> >>>>>>>> Please share your thoughts. >>>>>>>> >>>>>>>> Thank you, >>>>>>>> Malintha >>>>>>>> >>>>>>>> -- >>>>>>>> Malintha Amarasinghe >>>>>>>> Software Engineer >>>>>>>> *WSO2, Inc. - lean | enterprise | middleware* >>>>>>>> http://wso2.com/ >>>>>>>> >>>>>>>> Mobile : +94 712383306 >>>>>>>> >>>>>>> >>>>>>> >>>>>>> >>>>>>> -- >>>>>>> Nuwan Dias >>>>>>> >>>>>>> Technical Lead - WSO2, Inc. http://wso2.com >>>>>>> email : [email protected] >>>>>>> Phone : +94 777 775 729 >>>>>>> >>>>>> >>>>>> >>>>> >>>>> >>>>> -- >>>>> >>>>> -- >>>>> *Joseph Fonseka* >>>>> WSO2 Inc.; http://wso2.com >>>>> lean.enterprise.middleware >>>>> >>>>> mobile: +94 772 512 430 >>>>> skype: jpfonseka >>>>> >>>>> * <http://lk.linkedin.com/in/rumeshbandara>* >>>>> >>>>> >>>> >>>> >>>> -- >>>> >>>> *Sanjeewa Malalgoda* >>>> WSO2 Inc. >>>> Mobile : +94713068779 >>>> >>>> <http://sanjeewamalalgoda.blogspot.com/>blog >>>> :http://sanjeewamalalgoda.blogspot.com/ >>>> <http://sanjeewamalalgoda.blogspot.com/> >>>> >>>> >>>> >>> >> >> >> -- >> Malintha Amarasinghe >> Software Engineer >> *WSO2, Inc. - lean | enterprise | middleware* >> http://wso2.com/ >> >> Mobile : +94 712383306 >> > > -- Malintha Amarasinghe Software Engineer *WSO2, Inc. - lean | enterprise | middleware* http://wso2.com/ Mobile : +94 712383306
_______________________________________________ Dev mailing list [email protected] http://wso2.org/cgi-bin/mailman/listinfo/dev
