Zusätzlich zu den Standard QPPD Folgeprozessen können ein oder mehrere individuelle Folgeprozesse (Kundenprozesse) angelegt werden. Die dafür notwendigen Einstellungen sind in Kundenindividuelle Folgeprozesse (H) beschrieben.
ABAP-Klasse
Zunächst wird eine ABAP-Klasse erstellt, welche das Interface /SCT/QP_IF_FUP implementiert. Innerhalb dieser neu erstellten Klasse, muss über die Methode PROCESS das gewünschte Coding für den Folgeprozess implementiert werden.
In der Signatur gibt es lediglich einen Import-Parameter IS_FUP_DATA, welcher die folgenden Daten aus dem QPPD Standard zur Verfügung stellt:
FUP
Name des Folgeprozesses
TIMESTAMP
Zeitstempel, wann das Speichern im QPPD ausgelöst wurde
NODE
Information über den Knoten, für welchen dieser Folgeprozess gestartet wurde
STATUS
Status zum Knoten, für welchen dieser Folgeprozess gestartet wurde
DB_DATA
Alle aktuellen / neuen Daten des Knotens
DB_DATA_DEL
Alle gelöschten Daten
DB_DATA_ADD
Alle hinzugefügten Daten
DB_DATA_MOD
Alle geänderten Daten
DB_DATA_OLD
Daten des Objekts vor dem Speichern
EDIDC
Im Falle einer IDOC-Verarbeitung steht hier der Kontrollsatz des IDOCs
EDIDD
Im Falle einer IDOC-Verarbeitung stehen hier die IDOC-Daten
MSGTYPE
Im Falle einer Verarbeitung von Änderungszeigern steht hier der Nachrichtentyp
TARGET_SYSTEM
Im Falle einer IDOC-Verarbeitung steht hier das Empfangssystem
RAWSTRING
Dieses Feld kann für eine Datenübertragung eines beliebigen Objekts benutzt werden
COMMIT
Dieses Feld zeigt an, ob nach dem Ausführen des FUPs ein COMMIT WORK AND WAIT vom QPPD ausgeführt wird.
Das folgende Bild veranschaulicht die verfügbaren Felder:
Die Felder DB_DATA, DB_DATA_ADD, DB_DATA_MOD, DB_DATA_DEL sowie DB_DATA_OLD werden in Abhängigkeit von der Einstellung im Feld "DB-Daten" wie folgt versorgt:
"Keine"
Die Felder DB_DATA* werden nicht versorgt
Aktuelle
Das Feld DB_DATA wird versorgt.
Aktuelle+Alte
Die Felder DB_DATA und DB_DATA_OLD werden versorgt.
Aktuelle+Alte+Differenzen
Alle Felder DB_DATA, DB_DATA_OLD sowie DB_DATA_ADD, DB_DATA_MOD, DB_DATA_DEL werden versorgt.
Differenzen
Die Felder DB_DATA_ADD, DB_DATA_MOD, DB_DATA_DEL werden versorgt.
Individuell
Alle Felder DB_DATA, DB_DATA_OLD sowie DB_DATA_ADD, DB_DATA_MOD, DB_DATA_DEL werden versorgt.
Zusätzlich wird die Interface-Methode /SCT/QP_IF_FUP→DO_FILTER aufgerufen, womit die Daten weiter eingeschränkt werden können.
Name der Queue
Im Fall einer qRFC- oder bgRFC-Verarbeitung muss eine Queue zur Verarbeitung des Folgeprozesses erstellt werden. Per Standard SAP muss eine Queue immer einen Namen haben, der höchstens 30 Zeichen hat. Der Standard QPPD generiert einen Queuenamen gemäß dem Customizing wie folgt:
Der erste Teil des Namens ist das Präfix, welches im Customizing eingestellt ist:
Der zweite Teil des Namens wird aus den Daten abgeleitet, welche mit dem FUP verarbeitet werden sollen.
Falls ein Knoten verarbeitet wird, besteht der zweite Teil des Namens aus der Konkatenation von Vorschriftenummer und Vorschriftenversion verbunden mit einem Unterstrich. Falls die Vorschriftennummer nicht gefüllt ist, wird die GUID stattdessen genommen.
Falls es sich um eine IDOC-Verarbeitung handelt, besteht der zweite Teil des Namens aus der Konkatenation von Vorschriftenummer und Vorschriftenversion verbunden mit einem Unterstrich, welche aus dem HEADER-Segment ermittelt werden. Falls die Vorschriftennummer nicht gefüllt ist, wird die GUID stattdessen genommen. Falls das HEADER-Segment nicht existiert, wird stattdessen die Dokumentennummer des IDOCs genommen.
Falls es sich um eine Verarbeitung mit einem Nachrichtentypen handelt, besteht der zweite Teil des Namend lediglich aus dem Nachrichtentypen.
Dieser generierte Name kann über das die Methode DO_CHANGE_QUEUE_NAME im Interface /SCT/QP_IF_FUP redefiniert werden.