In addition to the standard QPPD follow-up processes, one or more individual follow-up processes (customer processes) can be created. The settings required for this are described in Creating Customer-Specific Follow-Up Processes (H).
ABAP class
First, an ABAP class is created that implements the interface /SCT/QP_IF_FUP. Within this newly created class, the required coding for the subsequent process must be implemented using the method PROCESS.
In the signature, there is only one import parameter IS_FUP_DATA, which provides the following data from the QPPD standard:
FUP
Name of the subsequent process
TIMESTAMP
Timestamp when saving was triggered in the QPPD
NODE
Information about the node for which this subsequent process was started.
STATUS
Status for the node for which this subsequent process was started.
DB_DATA
All current/new data of the node
DB_DATA_DEL
All deleted data
DB_DATA_ADD
All added data
DB_DATA_MOD
All changed data
DB_DATA_OLD
Data of the object before saving
EDIDC
In the case of IDOC processing, the control record of the IDOC is located here.
EDIDD
In the case of IDOC processing, the IDOC data is located here.
MSGTYPE
In the case of change pointer processing, the message type here is
TARGET_SYSTEM
In the case of IDOC processing, the receiving system is here
RAWSTRING
This field can be used for a data transfer of any object
COMMIT
This field indicates whether a COMMIT WORK AND WAIT is executed by the QPPD after the FUP is executed.
The following image illustrates the available fields:
The data in the DB_DATA_DEL, DB_DATA_ADD, and DB_DATA_MOD fields is only available if the value "Current+Old+Differences" is set in the "DB Data" field for the subsequent process.
The data in the DB_DATA_OLD field is only available if the value "Current+Old+Differences" or "Current+Old" is set in the "DB Data" field for the subsequent process.
The data in the DB_DATA field is only available if the value "Current+Old+Differences" or "Current+Old" or "Current" is set in the "DB Data" field for the subsequent process.
Name of the queue
In the case of qRFC or bgRFC processing, a queue must be created for processing the subsequent process. To do this, a name is generated by the QPPD as follows:
The first part of the name is the prefix that is set in Customizing:
The second part of the name is derived from the data to be processed with the FBD.
If a node is processed, the second part of the name consists of the concatenation of the specification number and specification version connected with an underscore. If the specification number is not filled, the GUID is taken instead.
If it is an IDOC processing, the second part of the name consists of the concatenation of the specification number and specification version connected with an underscore, which is determined from the HEADER segment. If the specification number is not filled, the GUID is used instead. If the HEADER segment does not exist, the document number of the IDOC is taken instead.
If the processing involves a message type, the second part of the name consists only of the message type.
This generated name can be redefined using the method DO_CHANGE_QUEUE_NAME in the interface /SCT/QP_IF_FUP.

