Storing Additional Application Data in Correspondence Containers

Use

You want to store additional data for creating correspondence in a correspondence container.

Prerequisites

You have made sure that the data for creating the correspondence is not already stored (or can be stored) in an object of the application and you only need to store the key for this object in the correspondence container. Note: Changing this application-specific object between the creation of a correspondence request and the delayed or repeated output of a correspondence request can lead to a change of the contents of the correspondence. If you do not want this to happen, then you have to take this into account in the application or store the data in a correspondence container. In this way, the creation of correspondence can have considerable influence on the design of the application.

Procedure

Assign additional data to two groups:

Data that is identical for all correspondence types of an application, such as the contract
Data that is specific to a correspondence type

You also have to decide if the data:

Is only needed for creating correspondence
Should make the selection of correspondence requests during the output of correspondence requests or of the correspondence history possible

Depending on which of these options you want, the correspondence tool provides three ways of storing additional data in a correspondence container:

Storing it in the data fields DATA1 to DATA4 in the correspondence header
Enhancing the database tables of the correspondence header and the correspondence history
Storing it in a data cluster

Application-specific enhancement of the header and the history

If you want to store information for all correspondence types of an application, and if this information should also offer a targeted access to the correspondence requests in the output report or a correspondence history, then you should enhance the header and/or the history.

When enhancing the header and history, you should be very careful and restrictive, since the field in the header and history can also affect other applications. Never add fields to these tables that are used only in one or very few correspondence types of an application. Once a field is added, you can no longer remove it after it has been transported.

In order to make quick access using the fields possible, you have to adjust the existing indexes of the database tables of the header and history. Describe your requirements in an SAP Note for the given application. Ultimately, only the customer can decide which indexes are created and how they are created.

Enhance the header (table DFKKCOH) and the history (table DFKKCOHI) using append. To ensure that no identical components are created due to the decentralized development of the applications, you have to follow this procedure:

In the display of database table DFKKCOH and/or DFKKCOHI in the ABAP Dictionary, choose Goto Append Structure from the menu.
In the dialog box that appears for the append, enter a name in the form <pre> _APP_DFKKCOH (I), where <pre> stands for the prefix of the application (such as CMS_APP_DFKKCOH), and a short description in the form <application> Append for DFKKCOH(I) .
In the menu, choose Edit Include Add and add an include with a suffix to the append. Make the following entries:

Structure <pre> _STR_DFKKCOH(I), where <pre> is the prefix of the application

Group No entry

Suffix <pre>, where <pre> is the prefix of the application

Entering a suffix ensures that identical components can be differentiated from each other. Do not add any components directly to the append. You must store all additional fields in the include structure.
Now create the structures that were added to the append, <pre> _STR_DFKKCOH or <pre> _STR_DFKKCOHI with the additional fields for the database tables DFKKCOH or DFKKCOHI. We recommend activating the created objects from the inside to the outside.

Correspondence-Type-Specific Use of Fields in Database Table DFKKCOH and of the Data Cluster

For storing correspondence-type-specific key information on objects of the application or other data, you can use the data fields DATA1 to DATA4 in the header of the correspondence container.

If you have to store additional data that is not needed for accessing correspondence requests, you can store it in a data cluster. However, since processing of the data cluster is demanding on both performance and memory, you should use it sparingly. You have to make the data in the cluster available to the correspondence tool in an internal table of type FKK_TAB_DFKKCODCLUST (or it is available in this form). For examples for the packing and unpacking of data, see function modules FKKCORR_EXP_CLUSTER and FKKCORR_EXP_DECLUSTER.

Since the import command during unpacking reacts to changes in the definition of data structures between the packing and unpacking of data, you have to take measures accordingly. It is useful to decouple the definition of the data of the cluster in the ABAP Dictionary from the definition of the corresponding data in the application. In this way, you can ensure that in the case of incompatible changes of the definition of the data in the application, different versions of the definition of the data can be made available in the cluster. The data clusters store version information with the data. This version information is made available for unpacking the data when the data cluster is read by the correspondence tool. The version information can be set at event 44012080 by the application.

Note Note

For this reason, it is helpful to output all correspondence requests before installing a support package or upgrading to a new release.

End of the note.

Result

You can transfer the additional data to the correspondence tool when generating a correspondence request. The correspondence tool stores this data in the correspondence container and makes it available again to the application when the correspondence request is output.