Sap bw mail sending monitoring policy

SAP BWEmailSendMonitoringPolicy

In the past, when an email was submitted to the BW mail queue, we thought we had finished our work. In fact, we are not, and we are always confused, because emails may be wrong, dragged, waited, or stuck, and all the children may make mistakes, but we don't know why.

Our plan is to include email sending in a controllable range, so we can know whether there are any errors, whether there are any emails, and whether there is any waiting.

During the planning, we have implemented the following steps:

1. Monitor the waiting status of the email system

2. If there is a waiting status, the system can automatically trigger the mail sending action.

3. Monitor abnormal emails in the Mail System

4. If an abnormal email exists, it can automatically trigger the resend action.

Through the Data Log Analysis of the mail system, we find the corresponding relationship. The mail system will temporarily store the currently waiting emails in the sost table. In the table that stores the basic information of the emails in the Union Sood, we soon achieved the first step. Create the following attempt:

Tables:

Sood

Sosc

Join conditions:

Sood mandt = sosc mandt

Sood objtp = sosc objtp

Sood objyr = sosc objyr

Sood objno = sosc objno

View fields:

Sood objno

Sood objnam

Sood objdes

Sood crdat

Sood crtim

Sood objsnd

Sood sddat

Sood sdtim

Sosc entry_date

Sosc entry_time

Sosc sndpri

Sosc status

Sosc new_status

Then we can try to get the current email waiting status through the query.

We know that you can manually send a waiting email, but our goal is to enable the system to do it automatically, so we found the corresponding report: rsconn01 (as for how to findProgramThrough SDN and debug ). There must be a waiting email, and we need to monitor the email, so let the program trigger the mail sending action. In this way, we solved the second problem.

The third step is relatively simple, because determining whether a log is incorrect is nothing more than determining the log status information. However, the problem is that the status number we have obtained covers all the situations. Therefore, the log status numbers shown in history are stupid, but we have to say we have done it.

The implementation in Step 4 is also found through the debug program, function: so_send_process_requeue. Here, you may be wondering why you don't need the second step. The reason is that the program in step 2 will only resend the emails that are currently in the waiting state, and once the email is abnormal, the mail system will kick these emails to the non-waiting state, therefore, the program that appears in step 2 won't be able to touch this abnormal email, so it cannot be used for sending. This function stores emails that need to be resold through a table, so what we need to do is to re-store the email information.

The format of the internal table is as follows: [bold is required]

Objtp

Objyr

 

Objno

 

Fortp

 

Foryr

 

Forno

 

Rectp

ADR

 

Recyr

 

Recno

 

Msgtps

Repeat_cnt

Wait_date

 

Wait_time

New_status

Sndreq

 

Immediatly

You can use the Sood and soos tables to fill in all the information in the internal table, then the re-import queue operation is completed, of course, only the re-import queue action is completed, so you still need to perform the second step (whether to set immediatly to X, you can immediately send and test, but Xiao Fang repeatedly told me not to light all rabbits, remember ).

Through the above introduction, it is estimated that BW's mail monitoring will be under your control.