Push notifications with OData SDK and Iphone with non-SAP provider

[Former Member]

Hello,

There are quite a few guides available explaining how to set up offline/online push notifications for iphone apps in conjunction with SAP Netweaver Gateway.

Recently however I have started working on an iphone app that consumes OData services from a non-SAP system, more specifically .Net WCF Data Services.

I am building this application to consume data through the SUP 2.1.3. (OData Online Data Proxy).

The application is capable all right to consume the WCF Data Services, so it IS possible to consume non-SAP OData services through SUP using the OData SDK.

However, I am now at the point that I also want to use push notifications for my app.

At this level I am currently rather stuck, in the sense that this seems to be documented only for scenarios where the SAP Netweaver Gateway is involved.

The SAP Netweaver Gateway has built-in support for subscriptions and notifications and integrates nicely with the SUP platform.

The question now is : how can I achieve the same thing if SAP Netweaver Gateway is not involved.

It appears to me that this could be achieved by :

1. Adding a writable subscription collection too on the WCF Data Services endpoint, so that the iphone app can post subscriptions for specific collections to the WCF Service. That of course means we need to provide additional coding to store the subscriptions.

2. What's not clear to me at this point is how the message exchange should look between the .Net system (the provider) and the SUP system, that will allow the WCF Data Service to send notifications through SUP to the subscribed devices.

Is there anyone here who could shed some light on this ?

Thanks in advance for the input.

[Former Member]

Theo,

Online Data Proxy can be used against any web services back-end. We have live examples of that (SAP Business Objects Mobile).

A small explanation on how APNS works with SUP server (Generally push).

1. The client ALWAYS has to subscribe to the entity, on changes to which it will get notified.

2. The logic of persisting this subscription, intelligently determining whether a notification to this subscription has to be sent or not has to be pure back-end logic

3. Along with the subscription in step 1, the client also sends a 'Push End-point' to the back-end, which it has to persist. The backend on data change will call this URL and notify of changes. What Ambika has given above is the format of this URL.

4. You don't need to necessarily remember this URL as long as you use the ODP client SDK to call 'getPushEndPoint' and submit it to the server. The format is automatically taken care of by the client SDK.

5. On datachanges in the Enterprise Information System, the backend just needs to call this URL. The rest will be taken care of by the SUP server.

Best Regards, Pramod

[Former Member]

Hello,

Thanks all for your remarks.

We have implemented an OData service to manage the subscriptions on the non-SAP provider.

So, correct me if I am wrong, but this the setup I see :

1. We expose an OData Service on the non-SAP OData provider that allows the mobile client application to subscribe to collection(s).

2. When a subscription is created, the delivery address field is filled with the result from the SUP client invocation of getPushEndpoint(). This gives you the app & device specific URL for sending push notifications via the SUP server.

3. Business logic on the non-SAP backend system will trigger the distribution of the notifications. These notifications are sent to the SUP server and depending on the online/offline state of the device the notification will be delivered either through the SUP client connection directly or via APNS (the app we are building is an iphone app)

Now, when sending a message to APNS, we know exactly how the binary format of such a message should be. However, in the case where SUP is in the middle, we are still left with the question : how should the payload to the SUP server look like ?

That's the missing piece in the puzzle. I guess this is not very well documented at the moment cause subscription/notification with the OData SDK typically assumes the use of the SAP Netweaver Gateway which probably takes care of the proper format automatically.

This time however we are working with a non-SAP provider and we have to figure out ourselves what the correct format of the notification payload should be.

In one of the documents published by SAP for subscription/notifications with OData SDK (How-To…Subscription & Notification with SAP NetWeaver Gateway - iOS + Code Sample), they do a simple test of the setup using the REST-client FireFox plugin. They simply post a string to that delivery address and we see a message pop up on the device. Typically for APNS we have the option of providing additional information like a badge number or a sound to play... How would we add that to the payload then ? Do we adhere to the same rules as for native APNS messages, meaning : JSON formatted payload ? or do we send an SUP specific payload instead ?

[ambika_kv]

Hi,

You can include the badge, alert and other information in the header,with header name and value

x-sap-alert "your msg"

x-sap-badge 1

Regards,

Ambika

[Former Member]

Hi Ambika,

I have seen documentation on HTTP headers for that purpose in the SUP 2.2 documentation.

The question is :  is this also supported on SUP 2.1.3. ?

are you sure about the header names you mention, cause when I run a search for these I can't find them.

[ambika_kv]

Hi Theo,

You should subscribe to your subscription collection - here you will be saving the push end point/ delivery address to which you need to push the notification.

From the BE do a post to the delivery address/ push endpoint, changes can be part of payload/ body.

format of the delevary address (push end point) -

http://<sup server address:port>/GWC/SUPNotification/<Application Connection ID>/<Domain>

Hope this is helpful.

Regards,

Ambika