A Web Socket-based gadget developed using ABAP can improve the daily work efficiency of programmers

One of the advantages of programmers from other positions is that we can make full use of the programming language we master to automate some trivial and repetitive daily tasks through code, thereby saving more time to invest in technical content Higher work, improve work efficiency.

This article introduces an example of work automation implemented by the ABAP programming language in the author's actual project work.

Client Polling vs Web Socket API

ABAP Channel is a new event-driven front and back communication technology released by Netweaver 740. The underlying implementation is based on Web Socket and TCP Socket.

The so-called Web Socket is a technology that opens a two-way interactive communication session between the user's browser and the server. Using a Web Socket-based application programming interface, we can send messages to the server and receive event-driven responses without polling the server for replies.

CRM consultants who have done SAP CRM Call Center (Interaction Center) must be deeply impressed by the polling mechanism of this product. Because of the limitations of the technology at that time, whenever an event occurs in the ABAP background, there is no way to notify the WebClient UI interface in the foreground. In order to be able to display the latest data, the foreground can only actively initiate a poll to the ABAP background periodically at a fixed time interval.

This polling behavior can be easily observed with Chrome DevTools: The following figure shows that the CRM call center polls the background by sending an HTTP request to the background every 1 second.

In 2014, Netweaver 740 released the underlying ABAP Channel technology based on the Web Socket protocol, so the CRM call center also adopted this technology to replace the previous clumsy and inefficient polling solution.

ABAP practitioners often need to use various tracking and performance monitoring tools when doing projects, the most typical ones are ST05 and SAT. I do think these tools are very useful for ABAP developers.

However, all of these tools currently in Netweaver have a limitation: the developer must manually turn on the tool's trace mode to run the application in that mode. After the run, either manually turn off the tracking mode, or automatically turn off by the tool. That is, none of these tools can provide the information developers need in real time while the application is running.

I previously participated in the refactoring and prototyping of the original CRM One Order framework migrated to S/4HANA in Germany.

Once the prototype has been developed, it has to be tested. I had to perform a series of operations on the new S4CRM UI as in the old CRM, and then observe whether the input parameters passed into the API and the output parameters returned by the API are correct.

The way I did at first was to set breakpoints in the API and then check in the ABAP debugger. Soon I found that this is inefficient: CRM development consultants all know that APIs like CRM_ORDER_MAINTAIN/READ have a particularly large number of input and output parameters. In the ABAP debugger, you have to select one and double-click to see it. After reading, you have to go back and double-click. look at another. If you want to check all the parameters of the API, you need to click the mouse more than 100 times in total.

What I can't stand the most is this repetitive physical work. Is there a way to make Netweaver be like the CloudFoundry programming environment of the SAP cloud platform, after a cf logs app name command, the logs generated by the running application will be printed on the browser. Woolen cloth? have! Use ABAP Channel.

So I started to develop a tool. See how this tool works: a BSP application, accessed in a browser:

Then switch directly to the One Order app and proceed as usual. For example, create a new service order and maintain the following fields:

[External link image transfer failed, the source site may have an anti-leech mechanism, it is recommended to save the image and upload it directly (img-VxPADURG-1647864842811) ( https://upload-images.jianshu.io/upload_images/2085791-7308cdcd1fa77389.png ?imageMogr2/auto-orient/strip%7CimageView2/2/w/1240 )]

Switching back to the tool I made, the input and output parameters of the One Order API have been displayed in the browser in real time, and there is no need to go to the debugger for cumbersome click operations.

Because it is displayed through the browser, I can also directly use CTRL+F to search based on keywords, which is impossible in SAPGUI.

The following are the detailed development steps for this tool.

1. Transaction code SAPC, create a new APC (ABAP Push Channel) application ZORDER_LOG_APC, the connection type should be selected as WebSocket.

Click the button Generate Class and Service to automatically generate the processing class and the ICF node.

2. Transaction code SAMC, create a new AMC (ABAP Message Channel) application named ZORDERLOG.

Maintain the name of the ABAP class automatically generated by the APC application in the first step under the Authorization Program. The purpose of this step is to specify the name of the ABAP processing class that sends and receives data through WebSocket in the ABAP Channel scenario. Copy the Channel ID/order_log.

3. From the above figure, I know that I have specified the ABAP class CL_CRM_ORDER_LOGGER to send the log generated by the application calling the One Order API to the Web Socket, so this step needs to be programmed for this class.

In the static constructor, pass the AMC ID and channel ID created in the second step into the producer's constructor. Indeed, the scenario of ABAP Channel is a typical producer/consumer model. The messages produced by ABAP in the background are sent to the browser through Web Socket for consumption by the latter.

The sending of the message is done by the following SEND method.

4. Redefine the ON_START method of the processing class automatically generated by the APC application in the first step:

In this method, the APC application created in the first step is bound to the AMC application created in the second step.

5. Create an enhancement to the API CRM_ORDER_MAINTAIN and inject my CL_CRM_ORDER_LOGGER into it. This way, every time the API is called, it is automatically logged and sent to the browser via Web Socket.

The above five steps are the realization of the ABAP Channel producer. Next is the consumer, the development of the web application that runs in the browser.

Create a BSP application and maintain the following code in index.htm:

Line 17 declares the Web Socket url for front and back communication:

In this way, the development of Web Socket consumers is also completed.

Summarize

This paper firstly introduces the inefficient solution for the browser in the traditional call center to grab the response from the server by polling, which leads to the application scenario of the Web Socket technology. Then, it introduces the pain points that traditional ABAP performance analysis tools need to explicitly turn on and off the trace mode, and proposes a new analysis tool based on Web Socket technology, which can greatly improve the daily work efficiency of programmers.