Hi all, Workflows aren't tied to BPS (BPEL nor BPMN). BPS is our workflow engine of choice for the OOTB implementation.
Someone could well write a workflow extension in java which says, "your subscription would be active/created in 24 hours just because I want it to be that way". We could drop the workflow support for the immediate release, but our solution to the problem shouldn't be tied with BPS. Thanks, NuwanD. On Fri, Nov 27, 2015 at 11:01 AM, Sanjeewa Malalgoda <sanje...@wso2.com> wrote: > > > On Thu, Nov 26, 2015 at 11:28 PM, Joseph Fonseka <jos...@wso2.com> 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 <fr...@wso2.com> 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 <nuw...@wso2.com>: >>> >>>> >>>> >>>> On Tue, Nov 24, 2015 at 6:25 PM, Malintha Amarasinghe < >>>> malint...@wso2.com> 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 : nuw...@wso2.com >>>> 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/> > > > -- Nuwan Dias Technical Lead - WSO2, Inc. http://wso2.com email : nuw...@wso2.com Phone : +94 777 775 729
_______________________________________________ Dev mailing list Dev@wso2.org http://wso2.org/cgi-bin/mailman/listinfo/dev
