Process fragment mapping defines which process fragment definitions are used to instantiate the system event types. It can be controlled by any number of conditions (condition XML element) linked to one another by AND rules.
The rules for the structure of process fragment mapping in the XML mapping file are specified in the following extract from the file eventmapping.dtd:
Example of conditional process fragment generation (file extract):
<?xml version="1.0" encoding="ISO-8859-1"?>
<!DOCTYPE eventmapping SYSTEM "eventmapping.dtd">
<eventmapping>
<processfragmentmapping>
<processfragment graphid="FRG_ORD_CREATED">
<condition eventattributetype="AUFTR_TYP">
<value>C</value>
</condition>
<condition eventattributetype="MAT_NR" logicaloperator="in">
<value>123456</value>
<value>56789</value>
<value>78901</value>
</condition>
</processfragment>
...
</processfragmentmapping>
<attributemapping>
...
</attributemapping>
</eventmapping>
The FRG_ORD_CREATED process fragment is created if the following two conditions are met:
A process fragment definition must not contain a condition. In this case, the same specified fragment definition is used for each imported system event. The objects in the instanced fragment are specified in the subsequent attribute mapping.
Definition of a process fragment group
Process fragment definitions can be summarized into groups. This results in the following advantages:
The two process fragment definitions below are contained in an XML mapping file:
<processfragment graphid="AUFTRAG_ANLEGEN">
<condition eventattributetype="AUFTR_TYP">
<value>C</value>
</condition>
<condition eventattributetype="CHARGEN_PFL" logicaloperator="neq">
<value>X</value>
</condition>
</processfragment>
<processfragment graphid="CHPLICHT_AUFTRAG_ANLEGEN">
<condition eventattributetype="AUFTR_TYP">
<value>C</value>
</condition>
<condition eventattributetype="CHARGEN_PFL">
<value>X</value>
</condition>
</processfragment>
The first process fragment AUFTRAG_ANLEGEN is created for a system event of the Order document type (attribute value of AUFTR_TYP is C), which is not subject to management in batches (attribute value of CHARGEN_PFL does not equal X).
The second process fragment CHPFLICH_AUFTRAG_ANLEGEN is created for a system event of the Order document subject to management in batches type (attribute value of AUFTR_TYP is C and attribute value of CHARGEN_PFL is X).
The two process fragments shown can be summarized in a process fragment group:
<processfragmentgroup>
<condition eventattributetype="AUFTR_TYP">
<value>C</value>
</condition>
<processfragment graphid="AUFTRAG_ANLEGEN">
<condition eventattributetype="CHARGEN_PFL" logicaloperator="neq">
<value>X</value>
</condition>
</processfragment>
<processfragment graphid="CHPLICHT_AUFTRAG_ANLEGEN">
<condition eventattributetype="CHARGEN_PFL">
<value>X</value>
</condition>
</processfragment>
</processfragmentgroup>
Summary into a process fragment group means that only one check is made as to whether the AUFTR_TYP source system attribute has the value C when importing. If this is not the case, neither of the two process fragments in the process fragment group is instantiated.
Use process fragment groups to improve the clarity of process fragment mapping definitions and the performance of the import process.
Suppress output of warnings
If you do not want to import certain system events in your customizing and if you have not defined any process mapping for these system events you can suppress the error message to be expected when importing. To do this, you need to specify conditions in the ignoreevent XML element, which suppress the output of an error message relating to particular fragments when these cannot be imported.
For system events specified with ignoreevent mapping, error message output is suppressed only if the system event cannot be imported. This means that when you import system events having both process fragment mapping and ignoreevent mapping, these system events are imported.
Example
You want to import process fragments if the EKKO_BSTYP system event attribute exists and the MSEG_SHKZG system event attribute has the value S for "Post goods receipt" or H for "Cancel goods receipt". Other values of the MSEG_SHKZG attribute result in a warning being output.
If the EKKO_BSTYP system event attribute does not exist, no process fragments are imported and no warning is output.
The following process mapping meets the above requirements:
...
<processfragmentgroup>
<!-- Import goods receipts with MM predecessor documents only
-->
<condition eventattributetype="EKKO-BSTYP" logicaloperator="exists"/>
<processfragment graphid="GWEOF">
<!-- Post goods receipt
-->
<condition eventattributetype="MSEG-SHKZG" logicaloperator="eq">
<value>S</value>
</condition>
</processfragment>
<processfragment graphid="GWSOF">
<!-- Cancel goods receipt
-->
<condition eventattributetype="MSEG-SHKZG" logicaloperator="eq">
<value>H</value>
</condition>
</processfragment>
</processfragmentgroup>
<ignoreevent>
<!-- Do not output warning if no MM predecessor document exists
because these system events are not to be imported
-->
<condition eventattributetype="EKKO-BSTYP" logicaloperator="notexists"/>
</ignoreevent>
...