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
On Mon, May 8, 2017 at 2:38 PM, Thilini Shanika <[email protected]> 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: [email protected]
>
>
--
Lakmal Warusawithana
Director - Cloud Architecture; WSO2 Inc.
Mobile : +94714289692
Blogs : https://medium.com/@lakwarus/
http://lakmalsview.blogspot.com/
_______________________________________________
Architecture mailing list
[email protected]
https://mail.wso2.org/cgi-bin/mailman/listinfo/architecture
