FCM Migration Guide for APEX

Introduction

FCM, or Firebase Cloud Messaging, has always been a leading choice for reaching your users with notifications and messages regardless of the platform. Nevertheless, the technology is not limited to communication methods; instead, the methods and protocols are also moving along with the evolution of the technology. Hence, following the development, HTTP v1 is implemented instead of the IPv0 FCM. Replacing the old protocol with a new one will help us to reach higher reliability, better security, and, at the same time, include some extra functions. In this blog, we will discuss migration of legacy FCM to HTTP v1 using apex in salesforce.

Why Migrate to HTTP v1?

Migrating to HTTP v1 offers several compelling advantages:

• Improved Reliability: HTTP v1 uses the channels with greater stable performance for reliability in delivering the messages to the FM servers that are Cloud Messaging.
• Enhanced Security:  HTTP v1 is focusing on authentication that is using OAuth 2.0, in order to ensure secure interaction of Salesforce environment and FCM servers.
• Support for New Features: HTTP v1 creates new features: the message batching , by using it, the transmission of multiple messages in a single data package helps expedite such processes.

Sending Push Notification using the FCM Legacy

Currently, developers comprising the FCM Legacy team place the JSON containing the packet of necessary details, for instance, the recipient’s device ID, within the phone’s device memory. The device ID is identified through settings, under a hidden ID field. And it sends an HTTP request to the FCM endpoint (HTTP includes appropriate headers and payload) with the content above

Here’s a simplified example of how notifications might have been sent using FCM Legacy in Salesforce Apex:

Migrating to HTTP v1

In order to migrate from FCM Legacy to HTTP v1, we have to perform different sets of variation to the implementation, for example payload structure adjustment, endpoints adjustment, authentication/authorization method changing and response/error handling.

Let’s walk through the updated implementation using HTTP v1:

Methods to generate JWT and Access Token

Here are the methods that you can use to generate the JWT and Access token required for the FCM HTTP V1 API:

Comparing Changes:

Here’s a comparison of changes between FCM Legacy and HTTP v1:

	FCM Legacy	HTTP v1
Payload Structure	{    “to”: “DEVICE_ID”,    “notification”: {        “title”: “Title”,        “body”: “Body”    }}	{    “message”: {        “token”: “DEVICE_ID”,        “notification”: {            “title”: “Title”,            “body”: “Body”        }    }}
Endpoint	https://fcm.googleapis.com/fcm/send	https://fcm.googleapis.com/v1/projects/YOUR_PROJECT_ID/messages:send
Authorization	key= YOUR_LEGACY_SERVER_KEY	Bearer YOUR_ACCESS_TOKEN
Response	{    “multicast_id”: 1591429548771005280,    “success”: 0,    “failure”: 2,    “canonical_ids”: 0,    “results”: [        {            “error”: “NotRegistered”        },        {            “error”: “NotRegistered”        }    ]}	On Success:{    “name”:  “projects/[your-project-id]/messages/[messageId]” } On Failure:{    “error”: {        “code”: 401,        “message”: “Request had invalid authentication credentials. Expected OAuth 2 access token, login cookie or other valid authentication credential. See https://developers.google.com/identity/sign-in/web/devconsole-project.”,        “status”: “UNAUTHENTICATED”    }}

Custom Metadata for Storing Credential

Keeping your credentials private is very recommended both project id, client id in particular private key securedly. To fulfill this objective while using Salesforce, Custom Metadata Types which help to create new, descriptive types and thereby increasing the information much more. With Custom Metadata Types storage and managing the custom data can be done seamlessly without any deployment issues when working between environments.

To store the credentials in Custom Metadata:

• 1.  Define Custom Metadata Type:
  • Go to Setup > Custom Metadata Types.
  • Let us create a new Custom Metadata Type like “FCM_Settings”.
  • Define the fields <br> <i>for <br> project ID, client ID and private <br> key</i><br>
• 2. Store Credentials:
  • Set a new space for “FCM_Settings” that the custom metadata type will be used.
  • In the fields please fill out the website, which address it is located and the phone number it has.
• 3. Retrieve Credentials in Code:
  • Investigate Apex to declare the Custom Metadata records and pull the credentials as necessary.

Here’s an example of how to retrieve credentials in Apex:

FCM_Settings__mdt firebaseConfig = [             SELECT Client_Id__c, Private_Key_HTTP_V1__c, Project_Id__c             FROM FCM_Settings__mdt             LIMIT 1         ];         String privateKey = firebaseConfig.Private_Key_HTTP_V1__c;         String clientId = firebaseConfig.Client_Id__c;         String projectId = firebaseConfig.Project_Id__c;

// Query Custom Metadata records

Use Custom Metadata to store the password instead of hard-coding so that any malicious person who views the code cannot access it.

Conclusion

Migrating from FCM Legacy to HTTP V1 in Salesforce Apex is crucial for utilization of the latest features, making the system more reliable and secured. Bearing this in mind, through implementation of the steps described in this blogpost and editing your code according to the requirements, you would successfully update your HTTP v1 and easily send stimulating notifications to your users with a sense of confidence. Anyway, through the use of the Custom Metadata Types to store the credentials the information is going to be securely managed within the Salesforce platform.