Reorganization of Send Requests

Use

When an application sends documents using Business Communication Services (BCS), certain data is created that has to be deleted again at some point. The central object is known as the send request (class CL_BCS), which manages all the objects connected with the sending (such as the document, the recipient list, and the status information).

Activities

The most important setting is who is responsible for deleting the send request (and all the connected objects). This can be either the creating application or BCS.

Application ID

If the application decides that it wants to delete the send request itself, it must identify itself using a 4-character ID of its choice. The application ID makes it possible to find out who the "owner" of send requests is, and to address the reorganization specifically if tables are overflowing, for example. There are no plans to introduce Customizing for the application ID.

The application ID can be set using the method SET_OWNER_APP of the class CL_BCS.

Standard Settings

The standard setting for new send requests is that BCS is responsible for deletion.

Object Relationship

Applications can have BCS relate a created send request to their application object (BOR object) automatically. The existence of a relationship affects reorganization. Generally BCS only deletes send requests that do not have relationships. Deleting on the basis of an expiry date is an exception to this (see below).

The relationship between the application object and the send request is written using the method CREATE_LINK of the class CL_BCS.

Expiry Date

It is possible to have the send request deleted on a specific expiry date. BCS must have deletion responsibility if this option is to be used. When the expiry date is reached, a check is made as to whether the send operation is really complete. Only then is the send request deleted.

An expiry date can be set using the method SET_EXPIRES_ON of the class CL_BCS.

Example

This section gives some examples for the reorganization of send requests and the settings required.

Automatic Deletion After Successful Sending

The following settings are required if send requests are to be deleted directly after successful sending:

  • Responsibility for reorganization: BCS

  • No relationship between application object and send request

  • Expiry date initial

Automatic Deletion After a Fixed Expiry Date Is Reached

The following settings are required if the send request is to be deleted on a specific expiry date:

  • Responsibility for reorganization: BCS

  • The application can (but does not have to) have the send request related to its application object

  • Set expiry date as desired

Automatic Deletion at a Point in Time Determined Dynamically

The application wants BCS to delete the send request automatically. However, this is not to occur immediately but at later point in time, which depends dynamically on a particular event. Beforehand, the send request is to be displayable using generic object services in the context of the application document.

The following settings are required for this:

  • Responsibility for reorganization: BCS

  • Relationship between application object and send request

  • Expiry date initial

As soon as the event is reached, the application deletes the relationship to the send request. This meets the requirements for automatic deletion by BCS, and the send request would be deleted.

Deletion by the Application

If an application wants to delete the send request itself, it must make the following settings:

  • Responsibility for reorganization: Application, ID = xxxx

  • Expiry date initial

The application can have the send request related to its application object.

To delete the send request, the application has to call the method DELETE of the class CL_BCS for each instance.