Skip to Content

This is the second part of my 4-part blog series about HCP, ABAP and websocket(s). You can find the first part here: HCP, ABAP and websocket part 1 (contains links to all other parts).

This week, we will see how I managed to move the application from part 1 to an ABAP system.

The code for this week can be found in this commit: 9119b2d.

Creating the OData Service (NW Gateway)

Let’s take it in the same order as in the first part. So, I had to make the OData service using the available mechanisms on the AS ABAP. Therefore, I used the SAP Netweaver Gateway (tcode SEGW) to build the service. First, the data model was created. Luckily, the GW offers the possibility to import it from an metadata file. So I just accessed the $metadata URL of the original service (which we made in part 1) and saved it to a file. Then I uploaded it to the GW (left click on “Data Model” -> Import -> Data Model from File) and the data model was finished.

Untitled.png

Now, for the service implementation I did something not-so-pretty. Normally, the data should be pulled from RFCs/BAPIs or some other decoupled source, but I did it in some other, “not recommended” way. This is because this blog does not focus on the GW part (there is a separate space just for that: SAP NetWeaver Gateway Developer Center) and we would wish to make things a little faster.

So I proceeded to generate the classes and register the service. After this, I went to the MPC (model provider) class and saw what local data types (structures and table types) were generated. I used them as a model to create transparent tables (DB) for the entities. These tables will store the mock data used by the app.

Untitled.png

I also made a static method in the DPC_EXT (data provider – extension) class to populate the database. The get_entity, get_entity_set and delete_entity methods for the entities were also be overridden. In these methods, I simply did selects and deletes from the DB (this is the “un-recommended” coding — DB operations should not be done directly in the DPC_EXT).

To test this we open the GW again, right click on the OData Service Maintenance entry and choose “Gateway Client” (and play a little with some OData requests to see if they work).

Untitled.png

The UI5 app

The next step would be to adjust the UI5 app to work on the AS ABAP. The only modification really necessary are: to change the OData and the WS URLs (the WS URL is not known yet, I will update it later) and to simply deploy it to the BSP repository. But, we would also like the app to still work in the cloud (i.e. to not have 2 different versions of the same app — one for the AS ABAP and one for the HCP), so I just used a simple URL parameter which acts as a switch between these two sets of URLs. I called this parameter “location”: by default the app uses the HCP URL set, but if the “location” parameter equals “abap”, it uses the AS ABAP URL set. This coding is done in the Component.js file:


config : {
            resourceBundle : "i18n/messageBundle.properties",
            serviceConfig : { // cloud service config
            name: "",
            serviceUrl: "model.svc/"
        },
  ws: {                  //cloud WS config
      url: "./ws",
      cooldown: 1000
  },
  abapServiceConfig : {
      name: "",
      serviceUrl: "/sap/opu/odata/SAP/Z<GW_SERVICE_NAME>/"
  },
  abapWs: {
      url: "/sap/bc/apc/sap/z<push_channel_name>",
      cooldown: 1000
  }
},
//...
var p = getQueryParams(document.location.search);
if (p.location == "abap") {
      mConfig.serviceConfig = mConfig.abapServiceConfig;
      mConfig.ws = mConfig.abapWs;
}


The WS Endpoint

The last step is to create the WS “part” of the application. This can be done using the ABAP push channel (APC) and the ABAP messaging channels (AMC). More information can be found in this document ABAP Channels Part 1: WebSocket Communication Using ABAP Push Channels .

First I made a push channel and create an empty protocol implementation class.

Untitled.png

Then, I created an messaging channel and listed the APC class and the DPC_EXT class as authorized objects.

Untitled.png

In the APC class, I wrote some simple code for the onMessage / onStart methods: just simply publish / subscribe to the AMC. The APC can be tested very simply at this point, by just using the “Test (F8)” button in SE80.

Untitled.png

I also updated the DPC_EXT class: added a new static method (I called it refresh), which is used to send a “refresh” message on the AMC previously created (and subsequently on the APC).

As a last step, the WS connection URL from the UI5 app was also updated accordingly (to the APC’s URL).

We are done. Now the application should run exactly like it does on the HCP (only the “location” URL parameter must be set accordingly). Next week, we will attempt to link the UI5 application (on the AS ABAP) with a classic dynpro screen.

To report this post you need to login first.

Be the first to leave a comment

You must be Logged on to comment or reply to a post.

Leave a Reply