Enable notifications

Notifications is the ability of a mobile device to receive messages that are “pushed” from a server.
Notifications are received regardless of whether the application is currently running in the foreground or background.

Persistent Mobile Foundation provides a unified set of API methods to send either push or SMS notifications to iOS, Android, and Cordova (iOS, Android) applications. The notifications are sent from the PMF to the vendor (Apple, Firebase) infrastructure, and from there to the relevant devices. The unified notification mechanism makes the entire process of communicating with the users and devices completely transparent to the developer.

For more information on supported operating systems, see System requirements - Mobile operating system.

Push notifications

Push notifications can be of following formats:

Format	Supported mobile operating system	Description
Alert	iOS, Android	A pop-up text message.
Sound	iOS, Android	A sound file plays when a notification is received.
Badge	iOS	A graphical representation that allows a short text or image.
Banner	iOS	A disappearing pop-up text message at the top of the device display.
Interactive	iOS	Action buttons inside the banner of a received notification.
Silent	iOS	Send notifications without disturbing the user.

Types of Push notifications

Following are types of Push notifications.

Tag notifications

Tag notifications are notification messages that are targeted to all the devices that are subscribed to a particular tag.

Tags-based notifications allow segmentation of notifications based on subject areas or topics. Notification recipients can choose to receive notifications only if it is about a subject or topic that is of interest. Therefore, tags-based notification provides a means to segment recipients. This feature enables you to define tags and send or receive messages by tags. A message is targeted to only the devices that are subscribed to a tag.
Broadcast notifications

Broadcast notifications are a form of tag push notifications that are targeted to all subscribed devices, and are enabled by default for any push-enabled PMF application by a subscription to a reserved Push.all tag (auto-created for every device). Broadcast notifications can be disabled by unsubscribing from the reserved Push.all tag.
Unicast notifications

Unicast notifications, or User Authenticated Notifications are secured with OAuth. These are notification messages targeted to a particular device or a userID. The userID in the user subscription can come from the underlying security context.
Interactive notifications

With interactive notification, when a notification arrives, users can take actions without opening the application. When an interactive notification arrives, the device shows action buttons along with the notification message. For more information, see Interactive notifications.
Silent notifications

Silent notifications are notifications that do not display alerts or otherwise disturb the user. When a silent notification arrives, the application handing code runs in background without bringing the application to foreground. For more information, see Silent notifications.

Note: Unicast notifications do not contain any tag in the payload. The notification message can target multiple devices or users by specifying multiple deviceIDs or userIDs respectively, in the target block of the POST message API.

Multiple-application support

Release 10.0

Push Notification service supports multiple applications on the same server. Each application can send push notifications independently while sharing the same infrastructure.

This allows enterprises running multiple mobile apps (for example Banking App, Insurance App, HR App) to use the same infrastructure while keeping push credentials isolated.

Each application is identified by an Application ID and Environment ID (dev, test, or prod) and has following unique Firebase configuration.

senderId (Google project number)
serviceAccount.json file (Service Account File path)

Configuration matrix per App

Application ID	Environment	Sender ID (Google Project)	Service Account File Path	Push Enabled
app1	Dev	12345678	/opt/firebase/app1-dev.json	✔
app1	Prod	87654321	/opt/firebase/app1-prod.json	✔
app2	Test	11223344	/opt/firebase/app2-test.json	✖
app3	Prod	55667788	/opt/firebase/app3-prod.json	✔

Process flow

For each application and environment, following is the process flow.

Load configuration (senderId and service account file path).
Validate the service account JSON file.
If the service account JSON file is missing, empty, or invalid, an error will be displayed in the console.
Initialize FirebaseApp with credentials.
If Firebase already initialized for that app, delete, and reinitialize.
Log the result as follows.
- INFO: Firebase application initialized.
- WARN: Push disabled (missing credentials).
- ERROR: Initialization failed.

Sending push notifications

API clients must specify applicationId and environment. The system picks the correct Firebase configuration (senderId and credentials) and the Push message is delivered through that FirebaseApp instance. After successful delivery to a topic, the app instance may be unsubscribed if configured (to avoid stale subscriptions).

SMS notifications

To start receiving SMS notifications, an application must first register to an SMS notification subscription. To subscribe to SMS notifications, the user supplies a mobile phone number and approves the notification subscription. A subscription request is sent to the PMF upon receipt of the user approval. When a notification is retrieved from the PMF Operations Console, it is processed and sent through a preconfigured SMS gateway.

For more information, on configuring a gateway, see the Sending Notifications.

Proxy settings

Use the proxy settings to set the optional proxy through which notifications are sent to Apple Push Notification service (APNs) and Firebase Cloud Messaging (FCM). You can set the proxy by using the push.apns.proxy. and push.fcm.proxy. configuration properties.

For more information, see List of JNDI properties for PMF push service.

Using IBM DataPower as notification endpoint

You can setup DataPower to accept notification requests from the PMF server and redirect it to FCM and SMS.

Note: This is not supported by APNs.

Proceed as follows.

Configure PMF Server.

In the server.xml file configure the following JNDI property:
```
 <jndiEntry jndiName="imfpush/mfp.push.dp.endpoint" value = '"https://host"' /->
 <jndiEntry jndiName="imfpush/mfp.push.dp.fcm.port" value = '"port"' /->
```
Where,

host is the hostname of DataPower.

port is the port number on which HTTPS Front Side Handler is configured for FCM.

For SMS, configuration settings are provided as part of REST API call. No need to provide JNDI properties.
Configure DataPower.
1. Log in to the DataPower appliance.
2. Navigate to Services -> Multi-Protocol Gateway -> New Multi-Protocol Gateway.
3. Provide a name with which you can identify the configuration.
4. Select XML Manager, Multi-Protocol Gateway Policy as default and URL Rewrite Policy to none.
5. Select static-backend radio button, and select any of the following options for set Default Backend URL.
  - FCM: https://http.googleapis.com
  - SMS: http://<samplegateway->/gateway
6. Select the Response Type, Request Type as pass through.
Generate a certificate.

FCM
1. From command line, issue Openssl command to get the FCM certificates.
2. Run the following commands:
```
 openssl s_client -connect iid.googleapis.com:443 -showcerts
 openssl s_client -connect oauth2.googleapis.com:443 –showcerts
 openssl s_client -connect fcm.googleapis.com:443 -showcerts
```
3. Copy the encrypted content from -----BEGIN CERTIFICATE----- to -----END CERTIFICATE----- and save it as a <certificate_name>.cer file.
SMS

No certificates are required.
Import the saved client certificate to your TrustStore file.
1. Go to opt/IBM/WebSphere/Liberty/usr/servers/demo/resources/security folder where key.p12 file is located and check the list of imported certificates by using the following command.
```
 keytool -list -keystore key.p12
```
2. Import the <certificate_name>.cer file into the truststore file.
```
 keytool -import -keystore key.p12 -alias certificate_name -file /opt/IBM/WebSphere/Liberty/usr/servers/demo/resources/security/certificate_name.cer
```
Note: Configure the password in the server.xml file.
Import <certificate_name>.cer client certificate in your WebSphere Application Server Liberty setup.
1. Open the WebSphere Application Server Liberty administrative console.
2. Select Security -> SSL Certificate and Key Management.
3. Select SSL Configuration -> Select Node Name -> Key store and certificate-> Select nodes -> Signer certificate.
Note: You need to import certificate on keystore and truststore.
Back side settings

FCM
1. Create a Crypto certificate.
  
  a. Navigate to Objects -> Crypto Configuration and click Crypto certificate.
  
  b. Provide a name with which you can identify the crypto certificate.
  
  c. Click Upload to upload the generated FCM certificate.
  
  d. Set Password Alias to none.
  
  e. Click Generate key.
1. Create a Crypto validation credential.
  
  a. Navigate to Objects -> Crypto Configuration and click Crypto Validation Credential.
  
  b. Provide a unique name.
  
  c. In the Certificates field, select the Crypto Certificate that you had created in the preceding step.
  
  d. For Certificate Validation Mode select Match exact certificate or immediate issuer.
  
  e. Click Apply.
1. Create a Crypto validation profile.
  
  a. Navigate to Objects -> Crypto Configuration and click Crypto Profile.
  
  b. Click Add.
  
  c. Provide a unique name.
  
  d. For Validation Credentials, select the validation credential created in the preceding step from the drop-down list, set Identification Credentials to none.
  
  e. Click Apply.
1. Create a SSL proxy profile.
  
  a. Navigate to Objects -> Crypto Configuration -> SSL Proxy Profile.
  
  b. Choose either of the following option.
  - FCM with a secure backend URL (HTTPS), complete the following steps:
    1. Click Add.
    2. Provide a name with which you can identify the ssl proxy profile later.
    3. Select SSL Direction as Forward from drop down.
    4. For Forward (Client) Crypto Profile, select the crypto profile created in the preceding step.
    5. Click Apply.
```
  - **SMS:** Select **SSL Proxy Profile** as `none`.
```
1. On Multi-Protocol Gateway window, under Back side settings, select Proxy Profile as the SSL client type and select the SSL Proxy Profile created in the preceding step.
SMS

No backend settings are required.
Front end settings

FCM and SMS
1. Create a key-certificate pair with Common Name (CN) value as the hostname of DataPower.
  
  a. Navigate to Administration -> Miscellaneous and click Crypto Tools.
  
  b. Enter hostname of datapower as the value for Common Name (CN).
  
  c. Select Export private key if you plan to export the private key later, and click Generate Key.
1. Create a Crypto identification credential.
  
  a. Navigate to Objects -> Crypto Configuration and click Crypto Identification Credentials.
  
  b. Click Add.
  
  c. Provide a unique name.
  
  d. In the Crypto Key and Certificate field, select the key and certificate generated in the preceding step from the drop down list.
  
  e. Click Apply.
1. Create a Crypto profile.
  
  a. Navigate to Objects -> Crypto Configuration and click Crypto Profile.
  
  b. Click Add.
  
  c. Provide a unique name.
  
  d. In Identification Credentials field, select the identification credential created in the preceding step from the drop down list. Set Validation credentials to none.
  
  e. Click Apply.
1. Create a SSL Proxy profile.
  
  a. Navigate to Objects -> Crypto Configuration -> SSL Proxy Profile.
  
  b. Click Add.
  
  c. Provide a unique name.
  
  d. Select SSL Direction as Reverse from the drop-down list.
  
  e. In Reverse (Server) Crypto Profile field, select the crypto profile created in the preceding step.
  
  f. Click Apply.
1. Create a HTTPS front side handler.
  
  a. Navigate to Objects -> Protocol Handlers -> HTTPS Front Side Handler.
  
  b. Click Add.
  
  c. Provide a unique name.
  
  d. In Local IP address field, either select the correct alias or leave it at the default value (0.0.0.0).
  
  e. Provide an available port.
  
  f. In Allowed methods and versions field, select HTTP 1.0, HTTP 1.1, POST method, GET method, URL with ?, URL with #, and URL with ...
  
  g. Select Proxy Profile as the SSL server type.
  
  h. In SSL proxy profile (deprecated) field, select the ssl proxy profile created in the preceding step.
  
  i. Click Apply.
2. On Configure Multi-Protocol Gateway page, under Front side settings, in the Front Side Protocol field, select the https front side handler created in the preceding step, and click Apply.
Note: The certificate used by DataPower in the Front side settings, is a self-signed one. Unless that certificate is added to the JRE keystore used by PMF, connections to DataPower will fail.