How to implement customer push services in HANA and consume Push Notification API which is deployed in Cloud Foundry

[wilson_lee]

How to implement customer push services in sports one and consume Push Notification API which is deployed in Cloud foundry

1 PUSH NOTIFICATION OVERVIEW

1.1 Introduction

In today’s mobile-centric world, push notifications are a ubiquitous occurrence in our daily lives. They provide up-to-date relevant information in a simple and effective format, encouraging engagement and increasing involvement from users. It is no doubt that any organization would be wise to leverage the advantage of push notifications in their enterprise applications.

1.2 Push principle

1. the App registers push notifications in IOS, Then IOS asks APNS for a device token.


2. The APNS server returns the device token to the App.


3. the App sends device token to the push server


4. The push server sends the message and device token to the APNS server.


5. Finally, the APNS server pushes the notification to the App based on the device token.

2 the implement of APIs in sports one which is consumed by your customer APP

2.1 Register Device && Unregister Device && update Device Language

2.1.1 Register Device

This API is used to register a device, you can register the device when you have login your APP.

Overview:

$rest.on({

    method: $.net.http.POST,

    path: "/registerDevice",

    produces: "application/json",

    handler: $util.restOnHandlerHDB($pushService.registerDevice),

    errorhandler: $errorlog.errorhandler

});

JSON data sample:

{

    "deviceToken": "9F474D755EBB4E46B689859F0523449E",

    "userId": "XXX",

    "language": "zh",

    "timeZoneOffset": -480,

    "targetType": "aps",

    "deviceid": "abcdefg",

    "deviceType": " iphopne11",

    "appId": "com.xxx.xxxxxxx"

}

2.1.2 Unregister Device

This API is used to unregister devices, you can unregister the device when you have log out your APP

Overview:

$rest.on({

    method: $.net.http.POST,

    path: "/unregisterDevice",

    produces: "application/json",

    handler: $util.restOnHandlerHDB($pushService.unregisterDevice),

    errorhandler: $errorlog.errorhandler

});

JSON data sample:

{

    "deviceToken": "9F474D755EBB4E46B689859F0523449E"

}

2.1.3 update Device Language

The API is used to update your device's language, you can change your app notification language when you have changed the APP’s language

Overview:

$rest.on({

    method: $.net.http.POST,

    path: "/updateDeviceLanguage",

    produces: "application/json",

    handler: $util.restOnHandlerHDB($pushService.updateDeviceLanguage),

    errorhandler: $errorlog.errorhandler

});

Json data sample:

{

    "deviceToken": "9F474D755EBB4E46B689859F0523449E",

    " language ": "en"

}

Table:

2.2 create Notification && get Notification List && get Unread Notification Count && update Notification List to Read && delete Notification List

2.2.1 create Notification

the default notification will be generated by the job/trigger, you still can generate personalized notifications by calling this API, the notification message will be generated by your app provided language, if your app has multiple languages, then the notification message will be generated by all corresponding language.

Overview:

$rest.on({

    method: $.net.http.POST,

    path: "/createNotification",

    produces: "application/json",

    handler: $util.restOnHandlerHDB($pushService.createNotification),

    errorhandler: $errorlog.errorhandler

});

Json data sample:

{

    "aNotification": [

        {

            "NOTIFICATION_ID": "9595FC5DCE80AC39E200BC68E2623BE1",

            "RECEIVER_USER_ID": "GUCHAO",

            "REFERENCE_TYPE": "TRAINING",

            "REFERENCE_ID": "1263F891857A8742A59891A9A26B65D2",

            "TEAM_ID": "9D612DB59EA63C46AF8664E6FA88BE18",

            "USER_PERSON_ID": "9FE3E121A9ECE04DB194672AF58D479A",

            "OPERATION_TYPE": "DELETE",

            "DATETIME_PARAMETER1": "2019-12-22 05:40:54.0710000",

            "SCENARIO": 1,

            "PUSH_STATUS": "UNPUSH",

            "READ_STATUS": "UNREAD"

        }

    ],

    "aNotificationMessages": [

        {

            "NOTIFICATION_ID": "9595FC5DCE80AC39E200BC68E2623BE1",

            "LANGUAGE": "en",

            "TITLE": "test title en 1",

            "MESSAGE": "test message en 1 at {0}"

        }

    ]

}

2.2.2 get Notification List

This API is used to get the corresponding user’s notification list

Overview:

$rest.on({

    method: $.net.http.GET,

    path: "/getNotificationList",

    produces: "application/json",

    handler: $util.restOnHandlerHDB($pushService.getNotificationList),

    errorhandler: $errorlog.errorhandler

});

Json data sample:

[

    {

        "notificationId": "55EBB4E46B689859F0523449E",

        "language": "zh",

        "title": "test title",

        "message": "test message test message",

        "referenceType": "TRAINING",

        "referenceId": "6B689859F0523449E",

        "operationType": "DELETE",

        "messageSendDateTime": "2019-12-26T12:00:00:000Z",

        "teamId": "XXEBB4E46B689859F052ABCDH ",

        "userId": "FRANKLIN",

        "userPersonId": "9FE3E121A9ECE04DB194672AF58D479A",

        "status": 0

    }

]

2.2.3 get Unread Notification Count

This API used to check where the special user has unread notifications

Overview:

$rest.on({

    method: $.net.http.GET,

    path: "/getUnreadNotificationCount",

    produces: "application/json",

    handler: $util.restOnHandlerHDB($pushService.getUnreadNotificationCount),

    errorhandler: $errorlog.errorhandler

});

Json data sample:

{

    "haveUnreadNotification": true,

    "unreadNotificationCount": 20

}

2.2.4 updateNoticationList2Read

If the user has read this message or has marked serval message to read, then the APP should call the API to update the notification status

Overview:

$rest.on({

    method: $.net.http.POST,

    path: "/updateNotificationList2Read",

    produces: "application/json",

    handler: $util.restOnHandlerHDB($pushService.updateNotificationList2Read),

    errorhandler: $errorlog.errorhandler

});

JSON data sample:

[

    {

        "notificationId": "9595FC5DCE80AC39E200BC68E2623BE1"

    },

    {

        "notificationId": "9595FC5DCE80AC39E200BC68E2623BE2"

    }

]

2.2.5 deleteNoticationList

If the user has deleted this message or has deleted serval message, then the APP should call the API to delete the corresponding notification

Overview:

$rest.on({

    method: $.net.http.POST,

    path: "/deleteNotificationList",

    produces: "application/json",

    handler: $util.restOnHandlerHDB($pushService.deleteNotificationList),

    errorhandler: $errorlog.errorhandler

});

JSON data sample:

[

    {

        "notificationId": "9595FC5DCE80AC39E200BC68E2623BE1"

    },

    {

        "notificationId": "9595FC5DCE80AC39E200BC68E2623BE2"

    }

]

Tables:

3. Implement of framework

3.1 Generate notification

You can schedule a job or a trigger to generate notifications and save it in the table of NOTIFICATION and NOTIFICATION_MESSAGE

The app languages can be configured in table PUSH_PARAMETERS

For the notification messages, you should generate them by the corresponding languages





3.2 the job of deleting all invalid notification and generate the valid notification to the push queue

Notifications are time-sensitive and should be deleted if they are out of date.

Notifications within the timeliness and the push status is UNPUSH need to generate corresponding push queues based on payload type and scenario, the payload type can be aps or fcm, the scenario can be configured base on customer requirement, eg: 1 for training, 2 for questionnaire, then push queue payload can be generated by the corresponding function.





3.3 the job of push the queue to APNS/FCM/JPUSH

The corresponding TARGET_TYPE & APP_ID can be found according to the DEVICE_TOKEN of

table REGISTER_DEVICE, the corresponding AGGREGATION_TYPE can be found according to APP_ID  & TARGET_TYPE of table PUSH_TARGET, and the corresponding request generation FUNCTION can be found according to AGGREGATION_TYPE of table PUSH_AGGREGATION.

The push job will generate the push request according to the function then push it by Http request.









The push queue payload will be generated by the languages of APP, and it will only be sent the corresponding language of the payload of registered device language.









If push succeeded (Http status equals 200), then you can get the HTTP response, according to the response, you can do the following:

1. delete the succeeded push queue entry and update PUSH_STATUS of table NOTIFICATION


2. unregister device of invalid DEVICE_TOKEN


3. update failed push queue ATTEMPT_NO of PUSH_QUEUE

4.JAVA API overview

This API will according to APP_ID, TARGET_TYPE & channel type to use the corresponding certificate to create the connection to the APNS/FCM, then push the notification to the server.

Then the API will response to the succeeded queue entries, failed queue entries, invalid token.

5.the App registers push notifications

// Required to register for notifications

- (void)application:(UIApplication *)application didRegisterUserNotificationSettings:(UIUserNotificationSettings *)notificationSettings

{

  //remote notification

  [RCTPushNotificationManager didRegisterUserNotificationSettings:notificationSettings];

}

// Required for the registrationError event.

- (void)application:(UIApplication *)application didFailToRegisterForRemoteNotificationsWithError:(NSError *)error

{

  NSLog(@"Registfail，Register failed reason%@",error);

  [RCTPushNotificationManager didFailToRegisterForRemoteNotificationsWithError:error];

}



// Required for the register event.

- (void)application:(UIApplication *)application didRegisterForRemoteNotificationsWithDeviceToken:(NSData *)deviceToken

{

  [RCTPushNotificationManager didRegisterForRemoteNotificationsWithDeviceToken:deviceToken];

}



// Required for the notification event. You must call the completion handler after handling the remote notification.

- (void)application:(UIApplication *)application didReceiveRemoteNotification:(NSDictionary *)userInfo

fetchCompletionHandler:(void (^)(UIBackgroundFetchResult))completionHandler

{

   NSLog(@"%@", userInfo);

  [RCTPushNotificationManager didReceiveRemoteNotification:userInfo fetchCompletionHandler:completionHandler];

}

6. Conclusion

The most important thing is the state change. When the NOTIFICATION job is executed, the corresponding PUSH_STATUS of NOTIFICATION which is added to the PUSH_QUEUE table should be changed to ‘PUSHING’ to prevent repeated processing of data. When the PUSH job is executed, the status of PUSH_QUEUE & NOTIFICATION should be updated at the same time, the notifications of successful push should be deleted from PUSH_QUEUE, the PUSH_STATUS of NOTIFICATION should be changed to ‘PUSHED’, the notifications of failed push should change the ATTEMPT_NO of PUSH_QUEUE, and the push continues. The notifications with invalid device token should unregister the device token and delete the corresponding data in PUSH_QUEUE.

7. Citations:

iOS remote message push APNS push principle and step-by-step development
https://www.jianshu.com/p/032bfc949917
How to config and consume Push Notification from SAP Mobile Services (Part1)
https://blogs.sap.com/2017/03/22/how-to-enable-push-notifications-%ef%bc%88part1/#Role
APNs Overview
https://developer.apple.com/library/archive/documentation/NetworkingInternet/Conceptual/RemoteNotifi...