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 ) 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>*
_______________________________________________ Dev mailing list [email protected] http://wso2.org/cgi-bin/mailman/listinfo/dev
