Dieser Blogartikel schließt die Reihe „Konfiguration, Implementierung und Triggering von Push-Nachrichten“ ab. In diesem letzten Teil beschreibe ich, wie man Push-Nachrichten aus dem SAP-System heraus auslöst.

Hierzu sind folgende Aktivitäten notwendig:

• Erweiterung des OData-Service um Push-Funktionalität
• Anmeldung des Devices an einem bestimmten OData-Service
• Konfiguration des Destinationsystems
• Auslösen der Push-Nachricht

Voraussetzungen:

• Eine Push-fähige App (mit entsprechendem OData-Service) auf einem mobilen Gerät (siehe Blog 1+ Blog 2)
• Konfiguriertes SAP-System zum Auslösen von Push-Nachrichten (siehe Blog 3)

Erweiterung des OData-Service um Push-Funktionalität

In den vorangegangen Blogartikeln habe ich beschrieben, wie man mit Hilfe eines REST-Clients Push-Nachrichten triggern kann. Hier haben wir die ApplikationId verwendet, mit deren Hilfe wir dann die Geräte gefunden haben, denen wir eine Push-Nachricht schicken wollen. Im SAP-System ist zum jetzigen Zeitpunkt aber weder eine ApplikationId, noch die Geräte bekannt. Außerdem ist eine Versendung von Push-Nachrichten im Bezug auf eine ApplikationId nicht gerade sinnvoll. Hat man z.B. mehrere Anwendungen, die sich auf eine SalesOrder beziehen, muss man für all diese ApplikationIds Push-Nachrichten triggern. An dieser Stelle ist es also sinnvoller, Push-Nachrichten im Bezug auf den OData-Service, bzw. noch genauer auf ein bestimmtes EntitySet, zu triggern – das ist auch der Ansatz den SAP verfolgt. So hat man z.B. einen OData-Service, der bei einer Änderung der SalesOrder angesprochen wird und alle Applikationen, bzw. die registrierten Geräte, werden daraufhin per Push-Nachricht informiert. Aus diesem Grund muss ein OData-Service dahingehend konfiguriert/implementiert werden. 

Folgende Schritte sind dafür notwendig:

Wir starten die Transaktion „SEGW“ und öffnen den OData-Service, den wir für die Push-Nachrichten verwenden wollen. Unter „Data Model“ -> „Entitätsmengen“ findet man die zugehörigen Entity-Sets. An dieser Stelle setzt man das Flag auf „Abonnierbar“.Anschließend muss man die Laufzeitobjekte über den entsprechenden Button neu erzeugen lassen. Nachfolgend muss man die Laufzeitobjekte „…MPC_EXT“ sowie „…DPC_EXT“ anpassen. In der „…DPC_EXT“ muss die Methode „CHECK_SUBSCRIPTION_AUTHORITY“ redefiniert werden. An dieser Stelle braucht es nicht mehr Funktionalität und wir speichern diese Methode ab. Generell können aber hier z.B. Authority checks eingebaut werden.

In der Klasse „…MPC_EXT“ muss die Methode „DEFINE“ redefiniert werden. Hier muss nur folgende Zeile eingefügt werden, damit die define-Methode der Superklasse ausgeführt wird:

super->define().

Nun kann überprüft werden, ob unsere Änderungen greifen und ob der OData-Service „subscribable“ ist. Hierzu öffnet man den GatewayClient und führt ihn direkt aus. Im HTTP-Response sollten nun zwei neue Collections erscheinen:Wenn das nicth der Fall sein sollte, kann das ein Caching-Problem sein. Folgende Möglichkeiten können Abhilfe schaffen:

• Cache löschen über
  • Transaktion /IWFND/CACHE_CLEANUP (im Gateway Hub)
  • Transaktion /IWBEP/CACHE_CLEANUP (im SAP Backend
• Generell Deaktivierung des Caching währen der Programmierung über SPRO -> SAP -> Netweaver -> Gateway -> OData Channel -> Administratin -> Cache-Einstellungen -> Metadata -> Active or Deactivate Cache

Anmeldung des Device an einem bestimmten OData-Service

Wie im letzten Kapitel beschrieben, macht es Sinn, Push-Nachrichten im Bezug zu einem OData-Service zu triggern. Hierzu ist es notwendig diese Beziehung im SAP-System zu hinterlegen. Dies wird dadurch ermöglicht, dass über einen REST-Client (s. letzten Kapitel) die „SubscriptionCollection“ aufgerufen wird. Dadurch wird ein Eintrag in der Tabelle „/IWBEP/D_MGW_SUB“ erzeugt, der die Beziehung von einem OData-Service zu einem Device enthält.

Wie das in der Praxis funktioniert, wird nachfolgend beschrieben.

Als erstes muss über ein GET-Request im REST-Client (ich benutze an dieser Stelle Postman) der CSRF-Token ausgelesen werden. Dieser dient als zusätzliche Sicherheitsmaßnahme und muss mit jedem Request mitgeschickt werden. Folgende Parameter müssen mit angegeben werden:

Method - GET
URL - https://<hcmps server>/<ApplicationId>
Headers: X-CSRF-Token = Fetch
          X-SMP-APPCID = <RegistrationId>
          Content-Type = application/atom+xml; charset=UTF-8

Zusätzlich muss bei der Verwendung von Postman als REST-Client, der Benutzername und das Passwort für das HCP mitgeschickt werden.

Die RegistrationId ist eine Unique-ID für ein Device. Diese wird gesetzt, wenn man sich das erste Mal mit dem Device in der App anmeldet. Man kann sie danach im HCPms unter dem Menüpunkt „Registrations and Users“ auslesen.Sendet man diesen ab, so erhält man im Response unter dem Reiter „Headers“ das angesprochene CSRF-Token, welches für den nachfolgenden Aufruf benötigt wird.

Nachdem wir nun die Vorarbeit geleistet haben, können wir jetzt den POST-Request abschicken, der die Registrierung des Devices zu dem OData-Service vornimmt.

Method - POST
URL - https://<hcmps server>/<your app id>/SubscriptionCollection
Headers - X-CSRF-Token = <CSRF_Token_von_oben>
          X-SMP-APPCID = <RegistrationId>
          Content-Type = application/atom+xml; charset=UTF-8

So sollte der der Request aufgebaut sein: 

Dazu muss noch folgender Test-Body mitgegeben werden. Hier ist zu beachten, dass in den Knoten „deliveryAddress“ sowie „collection“ die Werte entsprechend Ihrer Konfiguration ausgetauscht werden müssen. Der Aufbau des Knoten ist wie folgt:
<d:deliveryAddress>urn:sap-com:channel:<HTTP destination of HCPms defined in SM59>:<RegistrationId></d:deliveryAddress>
<d:collection><Name_des_EntitySets></d:collection>

<?xml version="1.0" encoding="UTF-8"?>
<atom:entry xmlns:atom="http://www.w3.org/2005/Atom">
  <atom:id />
  <atom:title>Subscription for sample user</atom:title>
  <atom:author />
  <atom:updated />
  <atom:content type="application/xml">
    <m:properties xmlns:m="http://schemas.microsoft.com/ado/2007/08/dataservices/metadata" xmlns:d="http://schemas.microsoft.com/ado/2007/08/dataservices">
      <d:deliveryAddress>urn:sap-com:channel: <HTTP destination of HCPms defined in SM59>:<RegistrationId></d:deliveryAddress>
      <d:collection>><Name_des_EntitySets></d:collection>
      <d:filter></d:filter>
      <d:select>*</d:select>
      <d:persistNotifications>false</d:persistNotifications>
      <d:changeType>created</d:changeType>
    </m:properties>
  </atom:content>
</atom:entry>

Aufbau des Request-Headers:

Aufbau des Request-Bodys:Aufbau des Response-Headers:Hier ist wichtig, dass wir als Statuscode „201 Created“ zurückgeliefert bekommen.

Ist dies der Fall, sollten wir im SAP Backend in der Tabelle „/IWBEP/D_MGW_SUB“ folgenden Eintrag finden:Somit ist der OData-Service richtig registriert. Im nächsten Schritt muss noch eine Einstellung überprüft werden und danach können wir die Push-Nachricht auslösen.

Konfiguratin des Destinationssystems

An dieser Stelle muss sichergestellt werden, dass der Wert „SOURCE SYSTEM ID“ aus dem Response in dem SPRO Pfad „SAP NetWeaver“ -> „Gateway-Service-Aktivierung“ -> „Backend OData Channel“ -> „Verbindungseinstellungen zu SAP NetWeaver Gateway“ -> „SAP-NetWeaver-Gateway-Einstellungen“ zu finden ist. Wenn es diesen Eintrag momentan nicht gibt, sollte ein neuer mit den Werten „Systemalias = LOCAL“ und „RFC-Destination = NONE“ angelegt werden.Nun haben wir alle Vorarbeiten geleistet und können jetzt eine Push-Nachricht auslösen.

Auslösen der Push-Nachricht

Zu diesem Zweck gibt es eine Notification API, mit derer wir ein Push-Event triggern können. Hier sind folgende Aufrufe nötig, um eine Push-Nachricht zu schicken:

• /IWBEP/CL_MGW_SUB_REGISTRY=>GET_SUBSCRIPTION_REGISTRY( ): Liefert die Instanz der Subscription Registry zurück.
• GET_SUBSCRIPTIONS( ): Liefert alle Subscriptions für den OData-Service/EntitySet zurück.
• /IWBEP/CL_MGW_NOTIF_PUBLISHER=>GET_NOTIFICATION_PUBLISHER(): Liefert die Instanz des Notification Publisher zurück.
• CREATE_NOTIFICATION_ENDPOINTS(): Erzeugt die Notification Endpoints, d.h. bereitet das Senden der Nachrichten vor. Hier wird ebenfalls der Payload angehängt.
• SEND_NOTIFICATIONS(): Sendet für jeden Endpoint die Nachricht.

Soviel zur Theorie – nachfolgend ein Test-Programm, in dem diese API bereits inkludiert ist und somit Push-Nachrichten versenden kann. Dieses Programm finden Sie auch unter http://scn.sap.com/docs/DOC-68562. Es wurden geringfügig Anpassungen vorgenommen.

*&---------------------------------------------------------------------*
*& Report  ZPUSH_SUBSCRIBE
*&
*&---------------------------------------------------------------------*
*&
*&
*&---------------------------------------------------------------------*
REPORT zpush_subscribe.

* Fixed values for /IWBEP/D_MGW_SUB table
  CONSTANTS: lc_technical_group_name TYPE /iwbep/med_grp_technical_name VALUE 'ZBAST_PERSONAL_SRV',
             lc_group_version        TYPE /iwbep/med_grp_version        VALUE 0001,
             lc_collection           TYPE /iwbep/mgw_sub_collection     VALUE 'zvw_t_perSet',
* The push text message
             lc_text                 TYPE string                        VALUE 'Created!'.
* Vars for Subscriptions
  DATA: lo_sub_registry  TYPE REF TO /iwbep/if_mgw_sub_registry,
        lt_subscriptions TYPE        /iwbep/t_mgw_sub_data,
        ls_entityset TYPE vbak,
* Vars for Notifications
        lo_notification_publisher TYPE REF TO /iwbep/if_mgw_notif_publisher,
        ls_notification_endpoint  TYPE /iwbep/if_mgw_notif_publisher=>ty_s_notification_endpoint,
        lt_notification_endpoints TYPE /iwbep/if_mgw_notif_publisher=>ty_t_notification_endpoint,
        lr_data                   TYPE REF TO data,
        lv_notification_type      TYPE char1,
        lx_mgw_tech_exception     TYPE REF TO /iwbep/cx_mgw_tech_exception.

  FIELD-SYMBOLS: <ls_subscription> TYPE /iwbep/s_mgw_sub_data.

* Type is either ID or Data (Full Payload) - for HCPms, it doesn't matter if it is "ID" or "DATA",
* as HTTP body will be ignored by /Notification/ Push URL of HCPms
  lv_notification_type = /iwbep/if_mgw_notif_publisher=>gcs_notification_types-id.
* Obtain /IWBEP/D_MGW_SUB table
  lo_sub_registry = /iwbep/cl_mgw_sub_registry=>get_subscription_registry( ).
* Obtain a list of subscribers
  lt_subscriptions = lo_sub_registry->get_subscriptions(
                      iv_internal_service_name    = lc_technical_group_name
                      iv_internal_service_version = lc_group_version
                      iv_collection               = lc_collection ).
* Object to push
  lo_notification_publisher = /iwbep/cl_mgw_notif_publisher=>get_notification_publisher( ).

  LOOP AT lt_subscriptions ASSIGNING <ls_subscription>.
    IF  <ls_subscription>-language IS INITIAL.
      <ls_subscription>-language = sy-langu.
    ENDIF.
  ENDLOOP.

  GET REFERENCE OF ls_entityset INTO lr_data.
* Set the required params for push
  lo_notification_publisher->create_notification_endpoints(
    EXPORTING
* those two value are mandatory but ignored
      is_data           = lr_data
      iv_type           = lv_notification_type
* type "create"
      iv_operation_type = /iwbep/if_mgw_notif_publisher=>gcs_operation_types-create
* push text
      iv_text           = lc_text
* additional info (this example is entity data)
      ir_poke_data = lr_data
* "Badge" value
*      iv_entries_of_interest =
      it_subscriptions  = lt_subscriptions
    IMPORTING
      et_notification_endpoints = lt_notification_endpoints ).

* Push the text message to relevant subscribers - this will create a bgRFC queue
  LOOP AT lt_notification_endpoints INTO ls_notification_endpoint.
    TRY.
      lo_notification_publisher->send_notifications(
              is_notification_endpoint = ls_notification_endpoint ).
    CATCH
      /iwbep/cx_mgw_tech_exception INTO lx_mgw_tech_exception.
    ENDTRY.
  ENDLOOP.

Vor Ausführung des Programms ist es wichtig, den OData-Service und das EntitySet im Programm anzupassen, da diese vom Namen her mit dem Eintrag in der Tabelle „/IWBEP/D_MGW_SUB“ übereinstimmen müssen.Nach Ausführung des Programms sollte auf ihrem Device eine Push-Nachricht erscheinen. Diese gibt entsprechend der Implementierung aus Blogartikel 1 nur den Payload aus, der mitgeschickt wurde.Quellen: http://scn.sap.com/docs/DOC-68426