Our Amazon SQS Queue is not receiving messages from Amazon MWS for the AnyOfferChanged notification.
We send a test notification and this is sent to the Queue and available when we get the notification.
We have set up two AWS accounts, we are using one AWS account to register the queue destination and create the subscription to AnyOfferChanged. The other AWS account gets the test notifications from our Queue successfully.
We can see that the competitors of the merchant have changed their price for a listing, but no notifications have been sent to us.
Has anyone encountered this issue?
Sounds like you've done most of the things correctly (registering destination and creating subscription). Have you given Amazon themselves permission to write to the SQS queue?
On the SQS page in AWS Console, select the queue
In the pane that appears below, click on the Permissions tab
Click on the Edit pencil and give the Principal value "437568002678" for Amazon
Select some Actions (would depend on your use; I've used 'SendMessage' and 'GetQueueAttributes')
Save
That "Principal" value I got from this PDF:
Hope that sorts it out!
Related
What I am trying to do is basically to automatize the FCM service, so I don't need to create the messages and schedule its action from the firebase messaging panel, but instead use SQL database will create that instance or schedule that notification automatically to be send at a certain hour. (Example: a delivery man ends its shift and a Store procedure register the hour so the supervisor knows the status of the route via the notification, something like the amazon delivery tracking works to notify the status of your delivery). What I want to know is if there is any way to integrate SQL to create those messages so firebase can send them. And if there is a way, how it works.
I would write a trigger in my backend service so that when certain a database table/column changed or some query is executed, it will trigger an HTTP request to send a FCM message.
https://firebase.google.com/docs/reference/fcm/rest/v1/projects.messages/send
I'm working with AWS SNS API for mobile notification,
along with AWS CloudWatch for message monitoring.
There's currently only 5 metrics to be watched:
NumberOfMessagesPublished
PublishSize
NumberOfNotificationsDelivered
NumberOfNotificationsFailed
SMSSuccessRate
None of these seems to be like message content, recipient platforms, or delivered date/time. (contents that make more sense to marketers rather than developers)
How could I query the history of all my sent messages or a specific message?
SNS does not retain sent messages. You would have to archive the sent messages yourself as you send them.
One idea is to let SNS itself do the message archiving for you, so that you can then query the archive for the analytics that are relevant to you.
This can be done by subscribing a Kinesis Data Firehose to the SNS topic that you use for sending these mobile notifications. You can configure your Firehose stream to store the SNS notifications in S3, Redshift, Elasticsearch, Datadog, Splunk, New Relic, or MongoDB.
Check this out: https://aws.amazon.com/about-aws/whats-new/2021/01/amazon-sns-adds-support-for-message-archiving-and-analytics-via-kineses-data-firehose-subscriptions/
SNS is a wrapper around a number of similar notification APIs. The APIs for Apple (APNS) and Google (Most Android) GCN don't offer any kind of receipt confirmation.
If you need receipt confirmation you would have to build that into the application on the mobile device to inspect messages received that were for that application and there is no universal way to do that either. The other issue is that you are totally at the mercy of the user authorizing notifications.
I suggest you incorporate messaging of your own inside the app and have push notifications as an optional enhancement. In order to get badges to work right you also need cooperation with the app since there is no way using SNS to react to actions taken in the app to clear the notifications or adjust the badge value.
I've implemented Future Payment in my iOS app. Now the problem is I have to send the metaclientid to the server in order to make the payment however the trigger of "its time to charge paypal" is on a different device. Think of the app like uber wherein the passenger only gets charged when they arrived on their destination. And "arrived" is triggered from the driver app.
There are ways I'm thinking on how to go with it
Through push notif. I'll send a push -> catch it -> send metaClientID
(Issue: Probably unreliable since push can fail and user can go offline and not receive the push at all)
Store the MetaClientID to the server (As per paypal storing this is not recommended)
Would appreciate your feedback or suggestions.
I am new to iOS development and started a tutorial on a simple messaging app using Parse as the server. The way they have it coded, the app queries parse every time a message is sent(to save the message) but seeing as Parse only allows 30 req/sec under its FREE plan how would one go about making a messaging app? Is it standard convention to save data to the server for each message? It just doesnt seem practical to have a substantial user base on an app that can only query the serve 30 times a second.
The question simplified is: what is the standard convention for the relationship with servers for a simple messaging apps? Does the app save each message to a server or is there a work around using push notifications? (But even with push notifications the app would have to be opened to receive them, at least thats from my limited understanding of pushes)
It is not practical to have a substantial user base for a messaging app with only 30 queries per second. Parse is running a business. They give you 30 API req/sec so that you can try out their service and see how it works. But if you are designing an app for a significant user base, you will surely have to pay, as you are expecting Parse to run the servers for you.
With that out of the way, it would be normal for a (typical) messaging app to make at least one API request per sent message to the server. The server is responsible for accepting, routing, holding, and delivering messages. It would also be normal for that sent message to result in a push notification, and an API request from the client app to retrieve the message. The general workflow would be:
User sends message
App uploads message to server
Server determines where message is headed
Server sends push notification to recipient
Recipient app queries server for pending message(s)
Recipient app displays message(s) for recipient user
That's two API requests and a push notification for each sent message.
Beyond that, depending on your messaging service design, the server may also store all messages so that later, on a different device, a user can open the app and it will download the history, so as to appear synchronized.
Now, surely there are ways to reduce the number of server API requests. Your app could batch messages locally, your server could batch push notifications, and your clients could batch queries (or you could do all three). All of these options could help dramatically reduce the number of server API requests you pay for, but they will also reduce the responsiveness and user experience of your messaging service.
You could also design a sophisticated peer-to-peer communication system (like Skype was in the past) removing servers from the messaging flow. However, you would have to design complicated authentication and verification systems, complicated routing systems, complicated storage systems, etc. A lot of work. And even if you did, I don't know if Apple would allow it on the App Store. A lot of time, work, and uncertainty to avoid paying the small cost for a server.
Regarding push notifications: Push notifications are sent from a server to a recipient client app. Your iPhone cannot push notification another iPhone. There will always be a server in the middle. Your app does not need to be open to receive a push notification. iOS will receive it, and then deliver it to your app. If your app is closed, iOS will (partly) open it in the background to deliver the message.
I need to update my users for things that happened around their current location while the app is in the background.
To my understanding:
If my server sends a Push Notification to a client, the client would immediately show that message.
I can set up the app so that there is a specific location, with a given radius could fire a message.
So what I want to understand if it is even possible to update my users about things that are new in their locations.
I was thinking of two possible solutions, I am not sure they are possible.
One, I guess if the Push Notifications would allow a function to run prior to its display,
deciding if the message should appear.
For example: something happened in area x,y - The server initiates a message to all devices. Only the devices within range of x,y and a radius z, would show the message to the users.
Maybe the Regional Monitoring service can send a message to my server and my server can then decide if to send a Push Notification back to the client...
For example
The user has entered a defined location, determined by the app. The app sends a message to the server. The server decides if a message is due.
Any ideas? is that even possible?
Filtering push notifications by topic is something you need to do on the server side, not the client side. Apple specifically states not to send messages to users that aren't relevant and you won't be able to block them when the app isn't running. Additionally, if you are using a service to manage your push notifications you don't want to pay for messages that aren't relevant.
So when you register a device into your database, you should register what topics that person is subscribing to (ie. save a list of topics that user is eligible to receive). Then when the event is triggered that generates the push notification only send to devices that are registered to that topic. I believe a number of push platforms have this capability already built in. On UrbanAirship and Azure Notification Hubs you can use their tags feature. Or you can develop it yourself if you do your own push server.
Take a look at Parse. They have this kind of functionality baked right in, just send the push to clients that match a geoPoint query.