We are trying to send push notifications to user based on user's location, for eg when user reaches near a location he/she will get a notification from the application, we are currently using Mobilefirst 8.0.
I would adopt a solution like this:
When the location plugin has detected that the user is in a specific location or zone, it fires.
Within the action ( success callback), call a MFP adapter with all the relevant information.
This adapter can either call the MFP Push service REST endpoints directly. The invocation looks this.
OR
The adapter calls a backend, that will invoke the Push service REST endpoints. This will give more flexibility in terms of pushing customized payload , that can change according to business cases ( eg: festivals,discounts).
The complete list of Push service REST endpoints are here.
Related
I am answering my own question here in case anyone runs into a similar problem.
I recently have been working with GoNative to spin up a hybrid native application for DoneDone, a task management and shared inbox tool.
I am also using OneSignal's push notification integration with GoNative to handle native push notifications to the user. In addition, I am sending out push notification messages from the server-side (C#/.NET in my case, but the server-side platform is irrelevant here).
I have already set up the necessary files to get universal links to open up in the native app rather than the browser (e.g. the apple-app-association-file). I am getting push notifications created and sent correctly.
However, I cannot get the push notification to link to a specific page on the application via the server-side API.
In OneSignal's Create Notification API doc, it seems like you would send across either the url, web_url, or app_url parameter in your JSON request. However, none of these work correctly if you are using GoNative's push notification integration with OneSignal.
For instance, if you use the url or app_url parameter, you get a secondary browser pop-up inside your native app, instead of a load from just your native app.
You need to set your own url value in the "Additional Data" property of your push notification. GoNative has documentation on this if you are creating push notifications from within OneSignal's web platform, but not specific guidance if you are programmatically creating push notifications via their API.
To do this via JSON, you add a targetUrl value to the data property.
{
"app_id":"3baaa656-8832-4733-a88b-b83aba2598a7",
"include_player_ids":[
"3baaa656-8832-4733-a88b-b83aba2598a7",
"3baaa656-8832-4733-a88b-b83aba2598a7"
],
"headings":{
"en":"DoneDone Project"
},
"subtitle":{
"en":"#123: This is a bug!"
},
"contents":{
"en":"Ka Wai Cheung created the task."
},
"data":{
"targetUrl":"[LINK TO THE WEB APP]"
}
}
Once you specify the targetUrl, it works. I hope this saves someone time one day!
I want to implement a connected OAuth app in Salesforce which should trigger push events in case some entities changed, for example an opportunity was closed.
Zapier implemented something similar
https://zapier.com/apps/salesforce/integrations/webhook
Could not find something I need which is a simple way to subscribe to entity changes using the OAuth client's token and passing a webhook endpoint. I read about apex callouts, streaming API and outbound messages.
Yeah, we solved this exact problem at Fusebit and I can help you understand the process as well.
Typically speaking here's what you need to do:
Create triggers on the Salesforce Objects you want to get updates for
Upload Apex class that will send an outgoing message to a pre-determined URL
Enable Remote Site Setting for the Domain you want to send the message to
Add in Secret Verification (or other auth method) to prevent spamming of your external URL
If you're leveraging javascript, then you can use the jsforce sdk & salesforce tooling API to push the code into the salesforce instance AFTER the Auth flow has occurred AND on Salesforce Instances that have API access enabled (typically - this is enterprise and above OR professional with API enabled).
This will be helpful for you to look through: https://jamesward.com/2014/06/30/create-webhooks-on-salesforce-com/
FYI - Zapier's webhooks implementation is actually polling every 15 minutes, instead of real-time incoming events.
In which programming language?
For consuming outbound messages you just need to be able to accept an XML message and send back "Ack" message to acknowledge receiving, otherwise SF will keep trying to resend it for 24h.
For consuming platform events / streaming API / Change Data Capture (CDC) you'll need to raise the event in SF (Platform Event you could raise from code, flow, process builder, CDC would happen automatically, you just tell it which objects it should track).
And then in client app you'd need to login to SF (SOAP or REST API), subscribe to channel (any library that supports cometd should be fine). Have you seen "EMP Connector", mentioned for example in https://trailhead.salesforce.com/en/content/learn/modules/change-data-capture/subscribe-to-events?trail_id=architect-solutions-with-the-right-api ?
Picking right messaging way is an art, there's free course that can help: https://trailhead.salesforce.com/en/content/learn/trails/architect-solutions-with-the-right-api
And pretty awesome PDF if you want to study for certification: https://resources.docs.salesforce.com/sfdc/pdf/integration_patterns_and_practices.pdf
The Problem
The SharePoint adapter for Breeze expects a model with a SharePoint list name and then attempts by default to access _api/web/lists/getbytitle('<DefaultResourceName>') and I have not found a way to over ride that. The problem with this behavior is that if a user who is not a site collection admin accesses the User Information List using the web/lists/ end point they will receive a 404 error. Instead, for whatever reason, regular users must access the same exact information via _api/Web/SiteUserInfoList/items.
The Question
What would be the best way to add functionality to the Breeze SharePoint adapter to get user details or a list of site users? In my existing solution I have merely changed my data context object to use $http and the _api/Web/SiteUserInfoList/itemsend point but I'd like to still be able to use Breeze's amazing filtering ability but it's not clear to me the best path to begin adding this functionality to the adapter.
With breeze you can configure specific AJAX requests using a request interceptor.
The example below changes the timeout but you could just as easily change the url.
var ajaxAdapter = breeze.config.getAdapterInstance('ajax');
ajaxAdapter.requestInterceptor = function (requestInfo) {
requestInfo.config.timeout = 5000;
// todo: examine the requestInfo.config object and change the url as-needed
}
here's the relevant code in the breeze source
How does automatic updates work in passbook available in backfield of the pass, how to use webserviceURL key to get update from the server.
in webserviceURL key i have provided remote path from where updated pass can be downloaded, but even after content changed in server, it does not reflects in pass.
This question has been asked so many times, in so many ways, in so many forums; mostly by people that are too lazy to read the manual, or are too inexperienced / incompetent to understand it.
The first paragraph of the Passbook Web Service Reference explains why simply adding a link to an updated pass will not work.
A REST-style web service protocol is used to communicate with your server about changes to passes, and to fetch the latest version of a pass when it has changed. The endpoints always begin with the web service URL, as specified in the pass, followed by the protocol version number. For example, a request for the latest version of the pass of type com.apple.pass.example and serial number ABC123 might look like the following:
The Passbook web service is an integral part of the Passbook eco system. Anyone wishing to issue passes that change their content (either in response to a push message or in response to a user requesting fresh content by pulling down on the back of the pass), needs to implement their own Passbook web service.
This entails building a server capable of responding to the following to authenticated requests from each device that has installed your pass.
There are 5 methods that your web service should respond to:
1. Registering a Device to Receive Push Notifications for a Pass
POST request to https://webServiceURL/v1/devices/deviceLibraryIdentifier/registrations/passTypeIdentifier/serialNumber
2. Getting the Serial Numbers for Passes Associated with a Device
GET request to https://webServiceURL/v1/devices/deviceLibraryIdentifier/registrations/passTypeIdentifier?passesUpdatedSince=tag
3. Getting the Latest Version of a Pass
GET request to https://webServiceURL/v1/passes/passTypeIdentifier/serialNumber
4. Unregistering a Device
DELETE request to https://webServiceURL/v1/devices/deviceLibraryIdentifier/registrations/passTypeIdentifier/serialNumber
5. Logging Errors
POST request to https://webServiceURL/v1/log
In order to have a pass respond to a manual refresh or push request you need to implement at least the first 3 methods. This is because the device will not issue any further requests until it has received a valid response to the registration request.
Furthermore, the web service must be available over https. An unsecured http service can be used for development, but production devices will only recognise a webServiceURL key that begins with https.
I made a pass web service already. Next, I need to make a push notification when my pass is updated. From Updating a pass of passkit programming guide, it is not in detail. Can you explain this in detail ?
The requirements and protocol for push notifications is documented in the Push Notification Programming Guide.
There are a few special considerations for Passbook:
All Pass push requests must be sent to the production APNS server (gateway.push.apple.com on port 2195)
You must use your Pass Type ID certificate and key to authenticate with the APNS server (do not use App APNS certificates)
There is no need to handle device registrations, you simply use the pushToken that your web service received when the device registered the pass
The payload should be an empty - E.g. {"aps":""}
alert, badge, sound and custom property keys are all ignored - the push's only purpose is to notify Passbook that your web service has a fresh pass. The notification text will be determined by the changeMessage key in pass.json and the differences between the old and the new .pkpass bundles
ThechangeMessage string should contain %# if you wish for the content of the value key to be displayed. Change messages may have static text in addition to the %# variable, such as this: "changeMessage":"New updates: %#". If no %# is provided, a generic message with the kind of pass is displayed: "Store card changed".
As of iOS9, if you modify more than one field at a time, only one generic message will be displayed on the lock screen.
You still need to regularly query the feedback service and purge expired/invalid pushTokens from your database
Note that push updates can be implemented independently of your web service. Apple provide some sample objective-c code in Listing 5-1 here.