Show TOC

 Buffering Types of Correspondence Requests

Definition

The various buffering types reflect the type of management of correspondence requests during processing in the correspondence tool. There is an implementation for each buffering type.

Use

By choosing the appropriate buffering type, you can improve performance and influence the functions for generating correspondence at the time when you integrate the correspondence tool in your application.

Structure

The correspondence tool supports three buffering types:

  • No buffering

    The correspondence requests are not buffered. All changes to correspondence requests are made directly on the database.

  • Local buffering

    All changes to correspondence requests are made directly on the database. The header of the correspondence request is also buffered. The content of the buffer is deleted when an LUW is confirmed or rejected (ABAP commands COMMIT WORK or ROLLBACK WORK).

    Caution Caution

    Local buffering still exists because it was used in the past, but it should not be used for new development.

    End of the caution.

  • Buffer model with instance management

    All parts of correspondence requests are buffered. The header and history can be changed as often as you wish. However, all other parts can only be created.

    The buffer model offers a local and a global buffer. When you create or change a correspondence request, this takes place in the local buffer. For existing correspondence requests that you want to change, they first have to be made available from the global buffer or from the database.

    Confirming causes the correspondence requests to be transferred from the local buffer to the global buffer. Rejecting can cause a correspondence request to be made invalid, if there are errors in the local buffer. There is one exception: setting of the output date when outputting already confirmed correspondence requests directly in the global buffer. Therefore, after already confirmed correspondence requests were output, confirmation of the buffer is no longer necessary.

    When an LUW is confirmed (ABAP command COMMIT WORK), the contents of the global buffer are written to the database. The content of the buffer is deleted when an LUW is confirmed or rejected (ABAP commands COMMIT WORK or ROLLBACK WORK). To determine these events, the system uses the LUW handler. The application can also use the LUW handler if you want to synchronize the buffer of the application with this buffer. If database changes are to be executed in the update task and an object is changed multiple times in an LUW, the only means of ensuring this occurs without errors is to use the buffer model.

Integration

When you integrate the correspondence tool, the following scenarios are possible within an LUW:

  • Only one action is executed for each correspondence request.

    For one business object, one or more correspondence requests are created, or existing correspondence requests are output. Since only one change operation is executed on the database for each correspondence request, no buffering should take place.

  • Multiple actions are executed for each correspondence request.

    For one business object, one or more correspondence requests are created and immediately output. Since several change operations are executed on the database for each correspondence request, the buffering model should be used. First, all correspondence requests must be created. If processing of the business object was successful, the correspondence requests must be confirmed . If not, they have to be rejected . After that, the system can output all correspondence requests that were transferred to the global buffer after being confirmed. With the completion of the LUW, the contents of the global buffer are output to the database. Following that, the buffer is deleted.

  • One or more actions are executed for each correspondence activity in a mass run.

    During processing of business objects, you want correspondence requests to be created in a mass run, and, if required, output.

    To improve performance, the worklist is often assigned to packages, and the objects of a package are processed within an LUW. In this case, use the buffer model. This is the only way to ensure that correspondence requests of objects that were already successfully processed are not lost. Using the buffer model also ensures that it is possible to fully reset correspondence requests for incorrect objects. This means that each time a business object is processed, the correspondence requests created for this object have to be either confirmed or rejected. Once all the objects of a package have been processed, the correspondence requests stored in the global buffer can be output, if you wish. With the completion of the LUW, the contents of the global buffer are output to the database. Following that, the buffer is deleted.

For more information on the buffering type, see data element CORR_BUFFER_MODE. The domain for this data element contains these fixed values for the buffering type:

Fixed Values of Domain CORR_BUFFER_MODE for Buffering Types

Active Buffering Type, Otherwise Without Buffering

X

Active Buffering Type, Otherwise Local Buffer

B

Active Buffering Type, Otherwise Buffer Model with Instance Management

Normally you enter the buffering type in the relevant functions using the I_BUFFER_MODE parameter. However, the names of the parameter of the following function modules are different due to circumstances in the past.

Function Modules with Different Parameter Names for Buffering Type

FKK_WRITE_CORR

Creating correspondence requests

I_WRITE_TO_BUFFER

FKKCORR_PRINT_DFKKCOH_SET

Output correspondence requests

I_USE_BUFFER_AND_NOT_SELECTION

Each call of the function initializes the buffer management that implements the buffering type. This means that the buffer management of all buffering types can be initialized. The first call of a function that changes the content of the buffer or of the database sets the corresponding buffer management to active, thereby specifying the buffering type that is active until the completion of the LUW. After that point, the system uses only the active buffer management for the function, regardless of the selected buffering type for the function. In this way, the system ensures that no inconsistencies can arise between the various buffer managements; however, you do have to look ahead and choose a suitable buffering type when you call the function.

If necessary, you can specify the active buffering type by calling the static method GET_BUFFER_MODE of class CL_FKK_CORR_PERSISTENCE.

By calling the GET_BUFFER_HANDLER_INTERFACE static method of the CL_FKK_CORR_PERSISTENCE class, you can make a reference available on the IF_FKK_CORR_BUFFER_HANDLER interface of the active buffer management or the buffer management based on the buffer type. The IF_FKK_CORR_BUFFER_HANDLER interface provides the necessary methods for confirming (method CONFIRM_LOCAL_CORR_REQUESTS) and rejecting (method RESET_LOCAL_CORR_REQUESTS) correspondence requests.

Using the SET_SORT_BY_SENDCONTROL method, you can, if buffer management is active, have the system sort the correspondence requests in the global buffer by the SENDCONTROL field that is available in the header, and make them available for output in this way. This minimizes the number of spool requests generated when the correspondence requests are output. Once this indicator is set, you cannot remove it in the LUW. The indicator remains set within the current LUW. You can reset in the next LUW, if necessary.

Example

Only one action is executed for each correspondence request

You want to create a single account statement for a contract in the form of a correspondence request. The applicable correspondence requests are output during processing at the end of the day. Normally this is a case of an event-controlled business transaction.

Multiple actions are executed for each correspondence request

For a certain contract, you want to create a single account statement as a document and send it to the customer. Therefore you create a correspondence request and have it output immediately. Normally this is a case of an event-controlled business transaction.

One or more actions are executed for each correspondence activity in a mass run

For a large number of contracts, you want to create correspondence requests in a mass run, and possibly output them. Normally this is a case of a business transaction that recurs each period.