Using ENS
We provide this use case to help you understand how to use the Event Notification Web Service. While there may be other ways to use the Event Notification Web Service, this use case represents the most common use case and the method we recommend.
1. When your application first starts, you have not yet retrieved any events and you have no stored paging cookies. To retrieve your first “page” of events, call the Get Events operation with the Event Type you want and the Start Date and Quantity Limit combination that suits your needs. For example, you can use only the Start Date parameter to retrieve all events since a certain date, or use the Quantity Limit parameter to retrieve a certain number of recent events. Or you can combine the two and retrieve a certain number of events since a certain date. You can also provide an Events Per Page parameter to specify the number of events you want to retrieve each time you call the service, or you can simply omit this parameter to allow the Event Notification Web Service (ENS) to decide how many events to send you.
2. ENS will respond with a set of Event Notifications for the Event Type you specified. Since you need to use the paging cookie to pick up where you left off and retrieve additional events, save the paging cookie in a safe place when you are done processing those events. If you are using a database to store event data, the best approach is to process and store all events within a database transaction, and then also before committing the transaction, store the paging cookie in the same transaction context. That way, if your application fails while processing a set of events, it can automatically fall back to your previous paging cookie and there is no risk of losing or missing events.
If the More Pages Available flag is set to Yes, there are more new events to retrieve. In this case, you may want to call Get More immediately to retrieve more events. Note: You still have to wait for the time specified by the Backoff Time in the paging cookie to pass, otherwise your call will be rejected and you will still have to wait.
If the More Pages Available flag is set to No, there are no more new events to retrieve. In this case, you will need to wait for some time until new events appear. How long you want to wait is up to you, but be aware that you must wait at least the Backoff Time to pass before you can use the paging cookie again.
3. When you are ready to call Get More, use the paging cookie returned from a previous call to Get Events or Get More. For convenience, you do not need to preserve the Expiration and Backoff Time fields, but the Paging Cookie fields must be passed back to Get More without being tampered with. Like Get Events, Get More also allows you to specify a value for Events Per Page to limit the number of events received in each call.
4. Return to step 2 and process the events returned by Get More. You can repeat this process of calling Get More for each new paging cookie and processing the events retrieved as long as you like; you will continue to get new events entering the system.
Original details from Amazon’s official website:
Use Case for Event Notification Web Service
This use case can help you understand how to use the Event Notification Web Service (ENS). Although there may be other ways to use the ENS, this represents the most common use case and the method we recommend.
The first time your application starts, you will have retrieved no events and you will not have a storedPagingCookie. To retrieve your first “page” of events, callGetEventswith theEventTypeyou want and a combination ofStartDateandLimitthat fits your needs.
For example, you can use just theStartDateparameter to retrieve all the events since a particular date, or theLimitparameter to retrieve just a certain number of your latest events. Or you can combine the two to limit the number of events retrieved after a certain date. You can also provide theEventsPerPageparameter to specify how many events you would like to retrieve in each call to the service, or you can leave it out to allow ENS to decide how many events to retrieve. , since you will need it to pick up where you left off and retrieve additional events. If you are using a database to store event data, the best way to do this is to process and store all the events inside a database transaction, and then also store thePagingCookiein the same transaction context before committing the transaction. That way, if your application fails while processing a set of events, it can automatically roll back to your previousPagingCookieand there is no risk of losing or missing events.
If theMorePagesExistflag was set to "true," that means there are more new events waiting to be retrieved. In this case, you will probably want to callGetMoresoon to retrieve more events.
Note:You must still wait until any specifiedBackOffTimein thePagingCookie has passed, otherwise your call will be rejected and you will have to wait.
If theMorePagesExistflag was set to "false," that means there are no more new events to be retrieved. In this case, you will want to wait for some period of time for new events to come in. That amount of time is up to you, but note that you must wait at least the amount of time specified inBackOffTimebefore using thePagingCookieagain.
When you are ready to callGetMore, use thePagingCookiereturned by your previous call toGetEventsorGetMore. For convenience, it is not necessary to preserve theTimeToLiveandBackOffTimefields, but thePagingCookiefield must be passed back toGetMorewithout being tampered with. LikeGetEvents,GetMorealso allows you to specify a value forEventsPerPageto limit the number of events you receive in each call.
Return to step 2 and process the events returned byGetMore. You can repeat this process of callingGetMorewith each newPagingCookieand processing events retrieved as long as you like, and you will continuously retrieve new events as they come into the system.
Article source: Amazon official website