As Fazlan said, if we first publish and then only do API processing, it will remove the need to rollback. If the API processing failed after publishing, we can publish another event saying processing failed.
--Srinath On Tue, May 9, 2017 at 11:06 AM, Fazlan Nazeem <fazl...@wso2.com> wrote: > > > > On Mon, May 8, 2017 at 7:33 PM, Lakmal Warusawithana <lak...@wso2.com> wrote: >> >> Hi Thilini, >> >> We had an offline discussion. Please see following scenarios and flow. Generally we need to add timestamp with the event. GW need to validate its action with the API core with timestamp of the event. This is valid for all event with relevant action. Believed these flow will solve the issue. >> >> Scenario 1: Success MB connection & Success DB entry >> >> Publisher UI: >> >> Create API à API Core >> >> >> >> API Core: >> >> API Core à MB: Publish to topic API + Event + Timestamp >> >> Success >> >> API Core à DB >> >> Success >> >> API Core à API Publisher: API Create Success >> >> >> >> API GW: >> >> MB à GW: received API + Event + Timestamp >> >> GW à API Core: Service call to Core with API + Event + Timestamp >> >> If matching with timestamp, retrieve the API >> >> >> >> Scenario 2: Success MB connection & Failed DB entry >> >> Publisher UI: >> >> Create API à API Core >> >> >> >> API Core: >> >> API Core à MB: Publish to topic API + Event + Timestamp >> >> Success >> >> API Core à DB >> >> Failed >> >> API Core à API Publisher: Don’t allow save: ERROR >> >> >> >> API GW: >> >> MB à GW: received API + Event + Timestamp >> >> GW à API Core: Request API with API + Event + Timestamp >> >> If not matching with timestamp ignore the event. No action >> >> >> >> Scenario 3: Failed MB connection >> >> Publisher UI: >> >> Create API à API Core >> >> >> >> API Core: >> >> API Core à MB: Publish to topic API + Event + Timestamp >> >> Failed >> >> API Core à API Publisher: Don’t allow save: ERROR Failed >> >> > > > So in summary, what we are doing here is persist in API Core DB only if publisihing to the MB is successful. First publish and then persist? > > isf so +1 >> >> >> >> >> On Mon, May 8, 2017 at 2:38 PM, Thilini Shanika <thili...@wso2.com> wrote: >>> >>> Hi All, >>> >>> As per the APIM 3.0.0 architecture, the events such as APIM create, update, delete, subscription create etc are notified to gateways through JMS Topic in the broker. Thus, we need to smoothly handle the scenarios like broker not available and APIM to Broker connection(network) failure, since the flow cannot be completed without notifying the gateway (A blocking call). Ideally, if the API action cannot be completed due to broker connection failure, the users should be notified about the failure and the action should be rolled back. >>> >>> But, we are facing some difficulties to handle topic publishing failures and rollback API action(API create, API state change, API update, API delete, subscription create, subscription block) since the API action is getting persisted in APIM db layer prior to publishing to Gateway. >>> >>> For example, if an API create request is initiated from API core, first, the API will be persisted in db layer. Then the API create event will be published to Topic and the registered gateways will be notified. But if the broker publishing step is failed, the gateways will not be notified on the newly created API so that the API won't be published to gateway. This might lead the API to go to an inconsistent/partially created state (API is successfully created in db, but not pushed to gateway). >>> >>> >>> Currently, we have not implemented any mechanism to >>> >>> Rollback the action, or >>> Persist the inconsistent state as a flag in API so that the user is aware of the inconsistent state >>> >>> What would be the best way to handle broker failures? Any suggestions? >>> >>> Thanks >>> -- >>> Thilini Shanika >>> Senior Software Engineer >>> WSO2, Inc.; http://wso2.com >>> 20, Palmgrove Avenue, Colombo 3 >>> >>> E-mail: tgtshan...@gmail.com >>> >> >> >> >> -- >> Lakmal Warusawithana >> Director - Cloud Architecture; WSO2 Inc. >> Mobile : +94714289692 >> Blogs : https://medium.com/@lakwarus/ >> http://lakmalsview.blogspot.com/ >> >> >> _______________________________________________ >> Architecture mailing list >> Architecture@wso2.org >> https://mail.wso2.org/cgi-bin/mailman/listinfo/architecture >> > > > > -- > Thanks & Regards, > > Fazlan Nazeem > Senior Software Engineer > WSO2 Inc > Mobile : +94772338839 > fazl...@wso2.com > > _______________________________________________ > Architecture mailing list > Architecture@wso2.org > https://mail.wso2.org/cgi-bin/mailman/listinfo/architecture > -- ============================ Srinath Perera, Ph.D. http://people.apache.org/~hemapani/ http://srinathsview.blogspot.com/
_______________________________________________ Architecture mailing list Architecture@wso2.org https://mail.wso2.org/cgi-bin/mailman/listinfo/architecture
