Dissecting SAP DIAG Protocol – Server Side Processing

In the previous post, I’ve already explained that the DIAG packet consists of three parts called dp, th and data.

Let’s examine again the the first DIAG packet that is sent by SAP GUI client to SAP R/3 server by respective parts :

dp part (length = 200 dec = 0xC8 hex) :

th part (length = 8 dec = 0x8 hex) :

data part (length = 54 dec = 0x36 hex) – the top row is offset information :

Here I will describe how this DIAG packet get processed on the server.

If you perform the list out of active tasks in the SAP R/3 server, you will find more than one active disp+work.exe. One of the disp+work.exe acts as the dispatcher, and the other is the worker processes, depending on the request type in DIAG packet.

The communication or synchronization solution between the dispatcher and worker is using the event object.

The dp part is first received at DpRGetLogin, but the task of this routine is just to initialize the th and data packet, then it is moved to shared memory to be processed by corresponding worker process.

The first dp part from SAP GUI is actually not used, but transformed using DpRTmPrepReq into a proper login request :

Here is the dump of the above dp part (taken from dev_disp log file) :

-IN– sender_id REMOTE_TERMINAL tid 1 wp_ca_blk 0 wp_id -1
-IN– action SEND_TO_WP uid 2 appc_ca_blk -1 type DIA
-IN– new_stat NO_CHANGE mode 0 len 62 rq_id 11
-IN– req_info LOGIN GRAPHIC_TM

You can refer to my previous post to locate the exact offset positions for the above dump data.

Next, the request is pushed into the queue by DpRqPutIntoQueue.

The routine DpRqServiceQueue that servicing the queue, perform checks to the integrity of request before passed to DpRqNormalHandle. Here the request is used to initialize _wp_adm shared structure. For request data (i.e. dp part), the dispatcher and worker process communicates using the _wp_adm structure.

As for the payload which consists of th and data part remains the same. After the queue information is done, the dispatcher then signals one of the event object to activate the assigned worker process.

On worker process side, after being signaled by dispatcher, it enters the ThRqAccept routine, which calls ThCheckReqInfo. The dispatched request (dp part) is accessed via _wp_adm shared structure using wp_id as its index, and the th and data part is accessed via a call to DpCaGetWpPtr.

At this point, the worker process has the dp part information in the wp_adm structure, and returned pointer from DpCaGetWpPtr for th and data part.

Returned pointer (i.e. pointer to th and data stream) of is moved to fields of ztta structure (via zttaptr variable). Because there is no documentation regarding this fields information, I can only stated that memory address of th and data stream is recorded at offset 0x4 and for information of its length is moved to offset 0x0A.

Using the two undocumented fields of ztta structure, the data part (excluding the th part) is then moved to MsgInputBuffer and MsgInputBufferLength respectively. It is by using this two variables that the first incoming data is processed by DiagSetGuiConnectData for processing the data part.

But first, let’s see how the server process the th part.

Offset 0x1 and 0x4 of th part is the login overhead data. This fields is dependent on request info from wp_adm structure. For example, when req_info is 0x09 (a combination of LOGIN and GRAPHIC_TM), overhead is set to INI state. this is evident from the log information generated by ThCheckReqInfo routine :

LOGIN: set INI in Overhead

The LOGIN request info is obtained from the field inside wp_tm structure.

Here is several important values for offset 0x1 and 0x4 for th part together with it’s definition for overhead :

0x10 and 0x00 INI for LOGIN request
0x02 and 0x00 EOC for LOGOFF request
0x01 and 0x00 EOS for CANCELMODE Request

Let’s move on to the data part.

When the trace flag has sufficient level, the dump of data part is executed by DiagTraceStream with typical log string at dev_w* trace file as follows (the asterisk denotes the wp_id, starting from zero) :

D APPL ST_USER CONNECT len 12
D
D APPL ST_USER SUPPORTDATA len 32

From this routine, we know that the first byte of data (0x10) is the record type called APPL, and the first DIAG packet from SAP GUI contains connect and support bit data records. So it has two records.

For first record, byte at offset 0x01 (value = 0x04) is interpreted as ST_USER, byte at offset 0x02 (value = 0x02) is CONNECT. Offset 0x03 apparently unused. The length of data record is at offset location 0x04 (value = 0x0C). The length count is not including the first five bytes, it’s just for the data record only.

For second record, byte at offset 0x01 (value = 0x04) is interpreted as ST_USER, byte at offset 0x02 (value = 0x0B) is SUPPORTDATA. The length of this record is 0x20 (32 dec).

We can see that the data part structure is relatively simple and each detail data communication session can be monitored using trace flags and the dev_w* log file in SAP R/3 server.

Using this design, the data part can have as many records as required, and also can process any data with variable lengths.

Advertisements

Leave a Reply

Fill in your details below or click an icon to log in:

WordPress.com Logo

You are commenting using your WordPress.com account. Log Out / Change )

Twitter picture

You are commenting using your Twitter account. Log Out / Change )

Facebook photo

You are commenting using your Facebook account. Log Out / Change )

Google+ photo

You are commenting using your Google+ account. Log Out / Change )

Connecting to %s


%d bloggers like this: