BPMs are memory intensive and resource consuming in SAP PI. In this blog, I would describe about a scenario, where, we can skip BPM for generating multiple type of Idocs from a single source message in PI 7.0. We will be using simple receiver determination and conditional interface determination.
Suppose we have got a file to Idoc scenario. The source file contains the data which could result in generating multiple types of Idocs for receiver SAP system. We are already aware of the the fact that multimapping would not work in this case as IDoc adapter would not support generating multiple types of IDocs via a single message.
We have a source file which has structure as mentioned below –
Header (occurrence = 1)
Item (occurrence = 1 to unbounded)
Trailer. (occurrence = 1)
Source File
Segment Item carries the application data which to be mapped into two types Idoc (order create or order change) depending on a field (Item-Identifier).
To simplify the case, let us assume that one Item record would create one Idoc.
- Order create Idoc ( ORDERS.ORDERS05) if Item-Identifier = CRE
- Order change Idoc ( ORDCHG.ORDERS05) if Item-Identifier = CHG
We have already created two different interface mappings for order change and order create mentioned as below -
- ThirdPartyFileStructure_OB_To_ ORDERS_ORDERS05 (contains graphical mapping ThirdPartyFileStructure_To_ ORDERS_ORDERS05)
- ThirdPartyFileStructure_OB_To_ ORDCHG_ORDERS05 (contains graphical mapping ThirdPartyFileStructure_To_ ORDCHG_ORDERS05)
We will have a receiver determination from third party to SAP ECC system. There will be a single receiver determination since there is only one message interface.
But there will be 2 interface determination (for order create and order change)
Conditional Interface Determination for ORDERS create (Source message will be routed to this interface mapping even if there is a single occurrence of 'CRE')
Conditional Interface Determination for ORDERS change (Source message will be routed to this interface mapping even if there is a single occurrence of 'CHG')
Finally interface determination will look like
Then we have two message mappings for Order create and order change
Order Create mapping (ThirdPartyFileStructure_To_ORDERS_ORDERS05)
Order Change mapping (ThirdPartyFileStructure_To_ORDCHG_ORDERS05)
We have created parent node (IDOC) based on Item-Identifier here. IDoc fields need to be mapped accordingly as per the mapping rule.
Please note that we have changed the occurrence of Idoc xsd (0 to unbounded). And then we are creating relevant ORDERS and ORDCHG Idoc.
Trigger the source file having 4 records (Two with Item-Identifier = CRE, Two with Item-Identifier = CHG).
<?xml version="1.0" encoding="UTF-8"?>
<ThirdPartyFileStructure_MT >
<Header>
<FileType/>
<Date/>
<NumberOfRecords/>
</Header>
<Records>
<MaterialNumber>M1</MaterialNumber>
<MaterialType>T1</MaterialType>
<PlantCode>2222</PlantCode>
<BatchCode>BAT_1</BatchCode>
<Quantity>10</Quantity>
<Identifier>CRE</Identifier>
</Records>
<Records>
<MaterialNumber>M1</MaterialNumber>
<MaterialType>T1</MaterialType>
<PlantCode>2222</PlantCode>
<BatchCode>BAT_1</BatchCode>
<Quantity>10</Quantity>
<Identifier>CRE</Identifier>
</Records>
<Records>
<MaterialNumber>M1</MaterialNumber>
<MaterialType>T1</MaterialType>
<PlantCode>2222</PlantCode>
<BatchCode>BAT_1</BatchCode>
<Quantity>10</Quantity>
<Identifier>CHG</Identifier>
</Records>
<Records>
<MaterialNumber>M1</MaterialNumber>
<MaterialType>T1</MaterialType>
<PlantCode>2222</PlantCode>
<BatchCode>BAT_1</BatchCode>
<Quantity>10</Quantity>
<Identifier>CHG</Identifier>
</Records>
<ThirdPartyFileStructure_MT>
Message would look like below in SXMB_MONI
These two sub messages will show two IDocs for ORDERS (Order create) and two IDoc for ORDCHG (Order change).
Order Create IDocs -
Order change IDocs -
Additional Points -
1) We can insert XSLT mapping before order create and order change mappings to remove the unwanted records. For order create mapping, we can filter those records having Item-Identifier = CRE only and then in next mapping (graphical mapping) we can have only those records which will create ORDERS.ORDERS05 IDoc only. Same can be done for Order change mapping.
2) In case, Item-Identifier has to be populated via an RFC call before the main logic, we can break this interface into two flows. The first flow can be used to populate Item-Identifier via RFC call, generate an intermediate file. Then this intermediate file can be processed again as mentioned above. Although this is a workaround but it would definitely save a BPM for the this kind of requirement.