Currently Being Moderated

Push with Sybase Unwired Platform 2.2

Push with Sybase Unwired Platform 2.2

 

 

Push is an important feature from SUP 2.2 stable allowing a backend or EIS to send or push business information to a registered device. This information is generated as a result of a business event or change in the enterprise backend. This could be any changes in the backend data. In simplest form it can be when a sales order is created or a new leave request is available for approval from a manager or a new business report is ready for analysis etc. The scenarios can be multiple where a backend will like to notify a mobile user of a change.

 

 

What does it mean for an application user?

 

·       For an end application user this serves to be one of the important application features where he is notified and prompted for action on a backend event. This helps him to be informed and allows him to take actions based on the changes in the data, even though in some cases he might not be running the application on his smart phone. Based on the notification end user may enable the application and perform his duties.

Example: A new travel request is available for approval. End user opens the application, does a refresh to fetch/pull the request from backend and takes action. (Poke n Pull)

·      With reliable push from SUP, even the actual business data can also be pushed directly to the application in case the device application is online or in connected state.

Example: A new travel request is available for approval. The travel request data is actually pushed to the device application and is directly available for action from end user, in case the device application was already running and connected to SUP.

 

 

HOW DOES PUSH WORK?

 

 

Push Behavior on SUP

 

There are 2 primary ways of achieving push with SUP.  Details will help you understand the push subsystem.

·     Native Push Notification:

What is a Notification?

Notification is an event, to support backend triggered events containing very minimal information that will enable the mobile user to know that there is something new and catch his/her attention with contextual information for a specific application. Example, 5 Items pending for an approval app.  The notifications are not needed to be reliable in nature. It is a general expectation that notification would be followed by a pull request from the application running on the device.  This pull will not be triggered by the underlying platform, but will be application logic.  These events are calculated and generated by individual applications on the backend system.  Backend system is responsible for considering all the scalability aspects related to calculating contextual information for all the devices and their subscriptions based on contextual events or scheduled jobs.  It is not required to deliver all the notifications in exact same sequence to the device and the notifications should not be mission critical in nature. 

 

Notification Context: Notification events pushed from the backend system will have sufficient contextual information in order to help both the mobile user and the application to take further action.

 

               How does SUP help here?

SUP as an enterprise mobile platform integrates the usage of the 3rd party notification services to help enterprise mobile applications make use of native notification push.

Device platform vendors like Apple, Google, and RIM provide their respective notification services such as APNS, GCM, and BIS/BES respectively.

 

On the client SDK such as OData SDK helpers are provided which enable an application developer to enable and consume these native notifications with 3rd party service providers and SUP with Backend.

 

Points to Note

Apple and Google do not suggest any payload be delivered over their systems.  The systems are unreliable.  Data may not be delivered or be delivered out of sequence.  Actual payloads must be tiny. 

 

RIM does support a model of guaranteed delivery.  This system includes callbacks to notify the sender (SUP in this case) that the message was delivered or when it failed.  However, this is a different message format.   RIM messaging has many, many limitations including size of a packet, number of packets for a single user that BES will keep, and etc.  Therefore, BES & BIS should also only be used to send the Notification, but not used to actually send payloads.

You may find details on the 3rd party platform notification services at the public links below:

 

APNS:

http://developer.apple.com/library/mac/#documentation/NetworkingInternet/Conceptual/RemoteNotificationsPG/ApplePushService/ApplePushService.html

GCM:

http://developer.android.com/guide/google/gcm/index.html

 

BB Push Service:

https://developer.blackberry.com/develop/platform_services/push_overview.html

·        

      Reliable Online Push

SUP provides a reliable or online Push service to all supported device platforms, where a backend is looking to push actual payload or business data reliably to the device application. Here in this case you are allowed to push anything to the device and is reliable to be delivered unlike the case of native push notifications.

This service should only be used when the backend actually wants to delivery actual/critical business data directly to the application on the device.

This uses the SUP proprietary Messaging Channel to provide push service.

SUP Mobile SDKs provide inherent support for this push service. Application developers can directly make use of this feature for business data or payload push reliably.

 

 

ADMINISTRATIVE STEPS

 

·       In context of application connection the administrator can configure the push behavior based on the business requirement using Sybase Control Center

  • Type of Push Services:

1.        Native Notification Only

   This option signifies that the application will use only native push notification service.

 

2.        Reliable Online/Payload Push & Native Notification if device is offline.

    This option is the default option and delivers backward compatibility with older versions. This signifies that the application will use reliable online push always until the device is offline. If the device goes offline then SUP will make use of native push notification with a generic push context not the actual backend data.

 

3.        Reliable Online/Payload Push Only

   This option is the same as above with the exception that there is no native notification sent to the device when the device is offline.

 

         More details on this can be found at the link:

        http://infocenter.sybase.com/help/index.jsp?topic=/com.sybase.infocenter.dc01852.0220/doc/html/apr1349367442458.html

 

  • Each push message can be monitored via Domain Logs for the Push Bucket. Any exceptions raised can be found in the server logs for push bucket.
  • Push URL End Point: Push URL is available as an application setting in the proxy tab. The URL appended with the application connection ID (<Push URL>’/’<Application Connection ID>) is the HTTP end point used by backend to perform a push.
  • The backend pushing the data need to have a SUP Push User Role to be able to push to the above URL.

 

Push Behavior on Backend

 

Following are the details on the Notification API provided by SUP for the backend implementation.

http://infocenter.sybase.com/help/index.jsp?topic=/com.sybase.infocenter.dc01852.0220/doc/html/apr1349367442458.html

 

Notification URL

SUP push end point is the HTTP end point to which the backend will the push the message. In order to push backend needs to have a SUP Push User Role. Whenever backend application calls the push notification URL (which is specific for the combination of Device + application that is made known to the backend during subscription) SUP will read the configurations and will deliver the notification through appropriate device channel.

http://infocenter.sybase.com/help/index.jsp?topic=/com.sybase.infocenter.dc01852.0220/doc/html/apr1349367502399.html

 

Native Notification Headers

Backend application would be able to pass all the native notification context information/data as custom HTTP headers. The body of the HTTP request is discarded for native push notifications. Details on the header structure can be seen at this location:

http://infocenter.sybase.com/help/index.jsp?topic=/com.sybase.infocenter.dc01852.0220/doc/html/apr1349367539604.html

 

Reliable Online Push

To be able to use the reliable online push service, the backend needs to send the business data or payload as the HTTP Request Body with the notification request to the notification URL. The notification headers are ignored in this case & the body is delivered reliably to the application when the device is in connected or online state.

 

 

Push Behavior on Device

 

  • Native Notification Behavior for each of the device platform is defined by the 3rd party platform/device vendor.

          IOS – Defined by APNS. 

          Android – Defined by GCM

          Blackberry – Defined by BB Push Services 

  • Reliable Online Push behavior is consistent across all supported device platforms for SUP Mobile SDKs.

·                SUP Mobile SDKs provide helpers & listeners to manage the above push services for the applications.

 

                  Details on the same for online/OData Applications can be seen in the OData Developer Guide at the link below:

       http://infocenter.sybase.com/help/index.jsp?topic=/com.sybase.infocenter.dc01708.0220/doc/html/title.html

 

Application Responsibility

  1. Scalability & performance aspects of notification context/business data computation in the backend
  2. Implementing all the relevant interfaces on the device
  3. Passing contextual information or business data to SUP from enterprise backend like SAP Gateway.
  4. Not passing secure or business critical information as part of native push notification (please see APNS guidelines)

Comments

Delete Document

Are you sure you want to delete this document?

Actions