How to send rich and actionable desktop notifications from SAP to Windows 10 devices

This blog/demo is divided into two segments. Part I is about sending the toast notifications into the device from SAP backend. Part II will be about making them actionable and accepting actions on the notifications and sending them back to SAP.

DISCLAIMER

This tutorial is for proof of concept only. It only implements essential functionalities and does not follow strict development standards. To generate request, we will not be using SAP workflows but a simple ABAP report. We will create a basic UWP app to establish device to SAP connection instead of an SSO/AD setup. It will not teach how to code in C#, XAML or set up Netweaver Gateway services. The app can be found and installed from the Windows Store but it will only work with our SAP server which has been hardcoded in the App.

PROBLEM STATEMENT

Often, in a business suite, a user must react to or be made aware of certain events occurring in the system. Such events can be generated by the system or can be initiated by another user. For example, a request being sent to a manager for approval by a subordinate, or an alert, generated by the monitoring system when a business metric fails, being sent to the process owner. Traditionally, such approval processes are implemented by SAP Workflows and the stakeholders are notified by sending workitems to their SAP Inbox. Monitoring systems have their own Alert Inboxes. In Fiori 2.0, users can see actionable workitems on the Fiori launchpad itself. An email can also be configured to be sent to their corporate email accounts when there is a workitem requiring attention.

However, there are two drawbacks to this process.

1. The users will have to pro-actively check their SAP Inbox by logging into SAP and going into the transaction code (SBWP), or must be on the Fiori Launchpad browser tab to view them. If the user is working on another application, they will not see any new notifications.
2. Email notifications, even though they can pop-up on the screen, are not directly actionable nor are they customized for any particular business process. The user will still need to go into the email and then click on a link that will launch the web-app to perform the desired action. Often notification emails clutter up the inbox and reduce visibility to more important mails.

SOLUTION – PART I

Purpose of this blog is to create a UWP application, which when installed in your PC, will be able to receive notifications ‘pushed’ into the Windows 10 device of the device owner from SAP backend. This kind of notifications is called ‘Toast Notifications’ since they slide out of the side of the screen much like what we see on our mobile phones.

ADVANTAGES

1. Notifications will non-intrusively slide from the side of the screen to notify the user no matter what application the user is working on currently.
2. Notification toasts can have rich contents with text, icons, images, selection boxes, input fields, GPS location and buttons.
3. User can choose to act on the toast itself or launch the app in the foreground and take further action.
4. User can snooze a notification for it to re-appear after a stipulated amount of time.
5. The notification will become a part of the device’s notification center and can be viewed later or dismissed using the notification center icon on the taskbar.
6. Notifications can have custom sound alerts.
7. Users can turn off notifications from system settings or can also temporarily suppress them by turning on ‘Quiet hours’ from the notification panel.
8. The notification app can also be pinned on the start menu as a live tile. This tile can display slides of information and a notification badge to show count of notifications etc.
9. With some limitations, it is possible to show notification even when the screen is locked.
10. Native nature.

DISADVANTAGES

1. User will have to install an app from the windows store in the device where they wish to receive the notifications. They are required to launch that app at least once every month unless the app supports background processing (not covered in this demo).
2. From a development perspective, the app mentioned in the above point is a UWP (Windows Universal Platform) app that needs to be built and deployed to the windows store. There is a learning curve involved if the developer is not from a C#/XAML background.
3. The developer must be registered to the windows store by paying the necessary fees (one-time).
4. There needs to be Active Directory/SSO connection set up between SAP and the system. In the absence of such a setup, our UWP app itself requires the user to enter their SAP credentials. The best practices and security considerations are not within the scope of this article.
5. Limited to Windows 10 only for now.

PREREQUISITES

1. Visual Studio Community Edition 2017.
2. Microsoft Developer Registration. (paid service)
3. SAP Netweaver Gateway system and SAP logon.
4. Installation of certificates in SAP for Windows Push Notification Service.

DEVELOPMENT COMPONENTS

1. Universal Windows Platform App
2. SAP Gateway Service
3. ABAP Report to generate request
4. ABAP Utility classes to create toast notification layout
5. ABAP Exception Class to throw HTTP exceptions
6. SAP Table to store the SAP user and device token mapping

ARCHITECTURE

The push notification process for windows 10 is documented in detail in the Microsoft portal. We will refer to them frequently here.

The below paragraph is taken from https://docs.microsoft.com/en-us/windows/uwp/controls-and-patterns/tiles-and-notifications-windows-push-notification-services–wns–overview

The following diagram shows the complete data flow for sending a push notification. It involves these steps:

1. Your app requests a push notification channel from the Universal Windows Platform.
2. Windows asks WNS to create a notification channel. This channel is returned to the calling device in the form of a Uniform Resource Identifier (URI).
3. The notification channel URI is returned by Windows to your app.
4. Your app sends the URI to your own cloud service. You then store the URI on your own cloud service so that you can access the URI when you send notifications. The URI is an interface between your own app and your own service; it’s your responsibility to implement this interface with safe and secure web standards.
5. When your cloud service has an update to send, it notifies WNS using the channel URI. This is done by issuing an HTTP POST request, including the notification payload, over Secure Sockets Layer (SSL). This step requires authentication.
6. WNS receives the request and routes the notification to the appropriate device.

In our case, the App’s cloud service is a SAP system having a gateway component.

IMPLEMENTATION STEPS

1. Create a UWP App
   a. Register as a developer –

Go to https://developer.microsoft.com/en-us/store/register and register as a developer by following the instructions.

b.Reserve a name in the store –

Go to https://developer.microsoft.com/en-us/dashboard/apps/overview and reserve the app name.

Provide a unique name

c. Get the app credentials – (keep this secret )

After reservation, go to https://apps.dev.microsoft.com/#/appList to see your app list.

Click on your app and go to the next screen.

Copy the Application Secrets and the Package ID and keep it aside for later use.

d. Open Visual Studio and create a new windows universal app.

e. Build the app – The app code can be found in the location https://shinjan.visualstudio.com/_git/Workflow%20Notification%20Test which you can download and use (after making changes to the backend service URL). Below are the artifacts.

Since the code is available to download, we will only talk about key functionality of this app and not cover every step in detail.

f. In the UserAssignment.xaml file, create the layout. I have added a background image to give it a sleek look. You don’t have to. When the app loads, we are randomly generating a USER ID.(Remember to make the UserAssignment page as your startup page in App.xaml.cs)

g. In the code behind file of this page (UserAssignment.xaml.cs) write code to do the following

i. Create a text file in the app data to store the user ID and the channel URI (obtained in the next step) and load it every time the app starts.

ii. Get the WNS Channel URI from “PushNotificationChannelManager”. This is a unique URI that is tied to your device and your user.

iii. When the app loads, call the SAP Gateway Service ( refer to point 2. below) to

1. Get the CSRF token and the cookies.
2. Post the channel URI into SAP and the generated device user ID using a test SAP user. Use the CSRF token and cookies.
3. Save the user ID number and channel URI locally in the file mentioned in point i.iv. You can find more information here – https://msdn.microsoft.com/en-us/library/windows/apps/xaml/hh868221(v=win.10)

   v. Excerpts from the file:

h. This is what the app should look like upon completion

i. Deploy the app to the store after everything has been done.

i. Create the app package from Visual Studio and associate the app with the one that you reserved on the dashboard.

ii. You will need to comply to all the standards before you can submit the app to the store:

1. Your app should pass all certification checks and have the icons and logos as part of the app package.
2. The store listings must be created and uploaded.
3. You will have to wait for your account to be validate by Microsoft team to be able to complete submission.iii. More information can be found here – https://docs.microsoft.com/en-us/windows/uwp/publish/app-submissions.

 

2. Create Gateway service to store user details in SAP
   a. Create table ZSS_NOTIF_CHANNEL (or give any other suitable name) with the following fields

b. Create service in SEGW –

c. Implement the CREATE ENTITY method for ChannelSet – Add the incoming payload into the Z-table

3. Generate Notification – Note: These ABAP classes are created with full functionality in mind and goes beyond the proof of concept level. They are still a work in progress and will only work for sending texts and not actions for now. I am adding these ABAP artifacts to the GIT repository of the UWP app.  

a. ZCL_HTML utility class – This class will help generate HTML files. Call the methods as you’d in ABAP and it will return the HTML/XML string.

b. ZCL_SS_DESKTOP_NOTIFIER – Use this to create the toast layout, get the tokens and submit notification

i. Get the access token for your app from https://login.live.com/accesstoken.srf. Here you will need to provide the Package ID and the Secret ID you had obtained at step 1.c. More information here – https://msdn.microsoft.com/library/windows/apps/hh465435.aspx#access_token_request.

ii. When you POST this data, you will get the Bearer access token as a response. If you get an error, you may have to install a certificate. Contact your basis team to have that sorted out. The response will look something like:

iii. Create the notification body – method BUILD_TOAST_BODY will give you the toast notification XML. https://docs.microsoft.com/en-us/windows/uwp/controls-and-patterns/tiles-and-notifications-adaptive-interactive-toasts has instructions on how to build the body. I have created the ABAP classes to do the same thing.

iv. Get the Channel URI you had stored earlier in the table from the desktop for the recipient SAP user. Call this URI in POST by providing the required header and the access token obtained in step ii. More information and how to do it in C# here – https://msdn.microsoft.com/library/windows/apps/xaml/hh868252. The request should look like this (taken from the above link).

 

v. Call method SEND( ) to push the notification to WNS.

c. Create Notification Report – This is where you trigger the notification.

i. I am using the selection input as well some other functionality that I have implemented in the ZCL_SS_DESKTOP_NOTIFIER in building the notification body to demonstrate the UI capabilities.

The resultant XML body looks like

USING THE APP

1. Install the App – The app is in store but it has not been published at the time of publishing this blog. In future it can be downloaded from this direct link: https://www.microsoft.com/store/apps/9ndv6m6gmqt0

 

2. Launch the App from Windows Start Menu

An ID will be automatically generated for you

 

Test in SAP if the Channel URI got updated or not. Close the UWP app if you see a result like below.

3. Create a request in SAP

4. Result in the recipient’s desktop

Step 1 is a one-time step only. Step 2 however is required once every month.

RESOURCES

Notification Visualizer App – This Windows Store app lets you simulate the toast notifications. You can create your XML code accordingly. You can find it here https://www.microsoft.com/store/apps/9NBLGGH5XSL1.

Official documentation for publishing UWP to Store – https://docs.microsoft.com/en-us/windows/uwp/publish/

Official documentation for Push notifications – https://msdn.microsoft.com/en-us/library/windows/apps/xaml/hh868244.aspx

CHALLENGES AND LESSONS LEARNED

1. C# .NET- As someone from an ABAP background, I had some challenges understanding C#’s way of doing things. For example, the use of asynchronous methods. It also takes some trial and error to know which API suits your need the best for HTTP calls etc. Sometimes a popular C# API will not be available for UWP and you’d have to find a workaround.

2. Certifications – Calling windows token service requires a certificate to be installed in SAP. This needs the involvement of someone from basis team.

3. Account Verification – Have to wait for Microsoft’s team to verify your account and sometimes they take over a week. The app cannot be submitted till then and hence the notifications cannot be pushed either. It is a long wait before you can do an end-to-end test.

4. Submission of the full app even for testing purposes – Even if the app is only for testing purposes, you have to go through the full process of submission into the store. This means, certification checks of your app, maintaining all logos and icons, maintaining listing details, etc.

5. CSRF token – Calling the gateway POST service (to send the channel URI) needs a CSRF token otherwise it will throw a 403 (forbidden) error. So a separate GET service has to be called to get the tokens and supply them to the POST service.

6. Cookies – This took me a lot of time to figure out. When trying the above step through the Postman REST client, simply copying the CSRF token from the GET call to the POST call successfully posted the channel URI to SAP. However, when trying to do the same through C#, it would keep returning a 403 code by saying the CSRF token missing. Then after a lot of searching, I found out that I need to send all the cookies as well that came with the GET call, something that Postman didn’t require. Moreover, getting the cookies using the httpClient API doesn’t happen in the same GET call as getting the CSRF token. There needs to be a separate GET call just for the cookies. The cookies need to be passed to the POST call by creating a cookie container. This resolved the issue.

7. Iteration 1 of the App submission failed because it required user credentials and hence a privacy policy. So, I had to change the app to not accept any user credentials and route the request through a test user internally.