Generating different types of IDocs from a single source message without BPM

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.

1. Order create Idoc ( ORDERS.ORDERS05) if Item-Identifier = CRE
2. Order change Idoc ( ORDCHG.ORDERS05) if Item-Identifier = CHG

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’)

Finally interface determination will look like

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>

These two sub messages will show two IDocs for ORDERS (Order create) and two IDoc for ORDCHG (Order change).

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.