A Few Words About the RSCONN01 Program

Sending emails to users from an SAP system is a common practice widely used by many customers/clients. Emails can be sent from regular ABAP programs as well as from process chains, which is nothing new to most of us. I’d like to look at a real-world situation where knowledge of the RSCONN01 program, along with some other settings/mechanisms, might help you avoid unpleasant situations.

No one explains this better than the official documentation from the vendor — and I’m not going to try.

See: SAPconnect (BC-SRV-COM)

A typical SAP system landscape in a company usually looks like this:

• Development system
• Q/A (Testing) system
• Production system

In the production system, a background job is scheduled for the RSCONN01 program, which is responsible for sending emails from the queue to recipients.

As mentioned earlier, the source of these emails can be running process chains or ABAP programs that include the option to generate email messages. Emails are first placed in the queue (transaction SOST).

Then, the RSCONN01 program sends the emails from the queue to the recipients.

See Send Processes

Quite often, functional consultants need a separate system with productive master data for testing. Ideally, this would be the Q/A system. However, it's also common to copy the production system to a separate one (let’s call it Q/A-1) and provide it to consultants for further use.

The catch here is that all running process chains and scheduled email-sending programs are also copied into Q/A-1. Suppose you leave everything as is and begin testing. All scheduled jobs and active process chains will quietly do their job — sending notifications to users from Q/A-1. The same will continue to happen in the production system, potentially leading to growing dissatisfaction from — well, you know who. As experience shows, this kind of situation is entirely realistic.

To avoid it, you must ensure that in the Q/A-1 system:

• SMTP settings are reset
• The background job for RSCONN01 is canceled

To disable the SMTP server, go to transaction SCOT and set the values for Mail Host and Mail Port to something like none.

With this configuration, emails created in process chains or other programs will still land in the queue (transaction SOST), but won’t be sent. You can cancel the background job using transaction SM37.

The background job for RSCONN01 might be successfully disabled, but the SMTP server settings might still remain. You might assume that emails will just stay in the queue and won’t be sent. However, here’s the hidden danger: ABAP programs scheduled to run in the background that explicitly call RSCONN01 in their source code.

If you don’t stop their scheduled execution, these programs will add emails to the queue and immediately send them (everything in the queue will be sent). For the same reason, pay attention to the use of the SET_SEND_IMMEDIATELY method from the CL_BCS class, which might be present in your ABAP code.

If the SMTP settings are cleared, nothing disastrous will happen. Still, it’s best to check all these possible scenarios immediately after completing a system copy.

To check where RSCONN01 is being called from, use transaction SE38 and the Where-Used List option.