Multiple Interface Determination

Hello everybody,
I am working on the following szenarion:
- one sender and sender interface (incoming IDOC).
- one receiver with two different receiver interfaces (outgoing BAPIs). For one of these interfaces there exit two different interface and message mappings. So, 1 incoming interface => 3 outgoing with 2 different interfaces
So in the interface determination I want to rout the message by use of XPath expression to use one of the two interface (no problem at all), but also to choose one of two interface mappings for the same interface. If I try this by creating three lines in the interface determination and using different XPaths, the last entered interface always is deleted automatically.
Thanks for your help.

Hi,
To do what you want you may have to use both Receiver Determination and Interface Determination. XPath expressions can be used in both places.
In Receiver Determination, you will have 2 receiver services. Then, in one of the receiver services, you will have 2 Interface Determinations. So, you will end up with something like the following:
Receiver service1: interface1
Receiver service2: interface1, interface2
Regards,
Bill

Similar Messages

Meaning of multiple interface determination

I'm still starting with XI and some doubts are appearing while I get deeper into it. My doubt here is what's the sense in configuring more than one inbound interface in interface determination.
As you specificy sender and receiver services, and interface, how does it makes sense? I mean, the specified interface is forcing implicitily the inbound interface, so it doesn't make sense to define two different inbound interfaces.
Unless of course you choose the same inbound interface more than once, with different interface mappings, but then, which one would be chosen for an actual communication?
Thanks in advance.
(Environment XI 7.0)

I don't think you answered my question. I'm talking about configuration of two inbound interfaces in a single interface determination object.
In this image you can see one of my interface determinations:
[picture|http://img26.imageshack.us/my.php?image=interfacedet1ju7.jpg]
Sender service and sender interface are set and can't be modified, just as receiver service. This configuration is making mandatory that in the "configured interfaces" section, the inbound interface is BAPI_MATERIAL_GETALL, because that is the output message type of MI_OUT_S_0422_BAPI_MATERIAL_GETALL.
So what's the sense of adding a new line in the "configured interfaces" section?
It would only make sense using BAPI_MATERIAL_GETALL as inbound interface (is mandatory as I wrote before), and specify a different interface mapping. However, in that case, which one of those two would be used in runtime?
(Please answer directly to my questions and not just a general paragrafh. Otherwise I don't think we will get a successful communication. If what I write can't be understood please ask me.)
Thanks.

Error when trying multiple inbound interface determination for IDOC

Hi !
I have this scenario: File -> XI -> IDOC.
For each source file, I need to send multiple idoc packages, all to the same business system, but each package should be the result of different interface mappings.
All mappings have same source and target message types...e.g. source: MT_MyFile, target: CREMAS04.
To avoid creating a generic mapping program, we need to duplicate the current mapping program, make it handle the new case, and then add it as second interface mapping in Interface Determination, with same inbound interface, but different interface mapping, without conditions. All interface mapping should execute.
We are receving this error:
<SAP:Code area="IF_DETERMINATION">CX_ID_PLSRV</SAP:Code>
<SAP:P1>Inbound interface was found more than once (for same sender and receiver) for outbound interface urn:xxxxx/xxxx:.MI_xx_xxxxxxxx_xxx_xx</SAP:P1>
<SAP:Stack>Error when determining the inbound interface: Inbound interface was found more than once (for same sender and receiver) for outbound interface urn:xxxxx/xxxx:.MI_xx_xxxxxxxx_xxx_xx Inbound interface was found more than once (for same sender and receiver) for outbound interface urn:xxxxx/xxxx:.MI_xx_xxxxxxxx_xxx_xx</SAP:Stack>
Any clues?
Regards,
Matias.

Hi Satish !
Thanks.
I need to send different IDOCs to SAME business system.
In Interface determination I need this:
Inbound Interface -
Condition -
Interface Mapping
IF_1 no condition M_1
IF_1 no condition M_2
I need to send BOTH IDOC packages to same business system.
But it keeps throwing the posted error.
Regards,
Matias.

Problem in Interface determination for multiple MM

Hi experts,
i designed an IDOC to Jdbc scenario.
The particular thing is that I have TWO message mappings to apply for the same source and same target.
Hence, I have in my directory two scenarios with :
- same Reveicer Determination
- same Interface Determination
- differents Receiver agreements (i have two Communication Channels)
In my interface determination, I have configured a standard Interface determination with my two interface mappings to apply.
My problem is when I send an idoc, the result should be for my two interfaces differents payloads to inject to the database, but I get the same payload for both interfaces with the same namespace...it looks like it only use one Interface mapping instead of both...
It is driving me crazy...
Any help would be greatly appreciated
Kind regards,
Jamal

Hi,
i have the same receiver.
I do have two interface mappings in my interface determination. The problem is that it uses the same for both interface.
If I use enhanced ID, i can only specify one Interface mapping.
What I want :
- sender A - Message mapping 1 - receiver A
- and also sender A - Message mapping 2 - receiver A
when the idoc is sent.
what I have right now (though my configuration seems to be right) :
- sender A - Message mapping 1 - receiver A
- and also sender A - Message mapping 1- receiver A
Thanks a lots,
Jamal

Outbound interface determination in file adapter?

In my scenario files with different schemas can be send to XI from the same directory using the file adapter (so each file has a different interface that must be mapped etc.).
I cannot add multiple interfaces to the file adapter in sender agreement and determine the outbound interface by some condition. Interface must not be "*".
I thought about creating multiple file adapters (all listening to the same directory) and sender agreements. Each adapter is listenig to specific file type only (e.g. *.yxz, *.abc). So before putting the files to the input directory the file extension must be changed so that only the right adapter reads the file and XI gets the right interface.
Is there abetter way to do this???

These blogs will be usefull i guess..
/people/krishna.moorthyp/blog/2005/06/09/walkthrough-with-bpm
/people/arpit.seth/blog/2005/06/27/rfc-scenario-using-bpm--starter-kit
https://www.sdn.sap.com/irj/sdn/weblogs?blog=/pub/wlg/1403 [original link is broken] [original link is broken] [original link is broken]
/people/sriram.vasudevan3/blog/2005/01/11/demonstrating-use-of-synchronous-asynchronous-bridge-to-integrate-synchronous-and-asynchronous-systems-using-ccbpm-in-sap-xi
/people/ravikumar.allampallam/blog/2005/02/17/bridging-the-sync-async-bridge-with-fork-xi
/people/sravya.talanki2/blog/2005/08/24/do-you-like-to-understand-147correlation148-in-xi
/people/daniel.graversen/blog/2006/09/07/using-a-bpm-to-collect-messages-for-a-set-interval-of-time
Reward points if usefull........

When we will go for Ectended Interface Determination

extended interface determination example give me any one...
Regards,
Vinay

Enhanced (Mapping-Based) Interface Determination
Use
In an enhanced interface determination, you do not enter the inbound interfaces manually, but first select a multi-mapping. You get the inbound interfaces from the target interfaces of the multi-mapping. The inbound interfaces are determined at runtime during the mapping step.
You typically use an enhanced interface determination if the source message has an element with occurrence 0 ... unbounded (for multiple items of a data record) and you want multiple messages (for the individual items) to be generated at runtime.
For example, you want to split an overall booking for a trip comprising connecting flights into individual booking orders (for each leg of the trip).
You cannot realize this usage case with a standard interface determination (without using an integration process). A standard interface determination does allow you to specify multiple (N) inbound interfaces (with different mapping). In this case, N messages with the same payload and different receiver interfaces are generated from the source message before the mapping step; these are then transformed differently depending on the receiver interface. Therefore it is conceivable to write the mappings in such a way that the first mapping from the source message generates a message that only contains the first item, the second mapping generates a messages that only contains the second item, and so on. However, this no longer works if the number of items can vary with each new source message.
You can use an enhanced interface determination to configure a mapping-based message split for this usage case. You assign the interface determination a multi-mapping that has a target interface with an element with occurrence 0...unbounded. At runtime, the individual messages (for the individual items) are calculated in the mapping step. First, the individual messages are grouped into a bulk message. Then, the bulk message is transferred to the Adapter Engine. The Adapter Engine then splits the bulk message up into the individual messages (see figure).
Procedure at Runtime During Message Split
Note that both the bulk message and all individual messages each have a message header with a receiver interface (see figure).
Receiver Interfaces of Bulk Messages and Individual Messages
The header of the individual messages contains the relevant receiver interface. It is based on the definition of the multi-mapping. Note that the receiver interfaces of the individual messages may be different. The receiver interface of the bulk message is always InterfaceCollection (namespace http://sap.com/xi/XI/System).
If the message split only results in one message, the original message structure remains the same. In this case, a bulk message containing just one individual message is not created.
You can also assign a multi-mapping with multiple different target interfaces to an enhanced interface determination (1:n transformation). Each target interface can contain elements with occurrence 0 ... unbounded.
Messages cannot be sent by using different Adapter Engines in a mapping-based message split. This affects configuration thus: All receiver agreements that have a receiver interface from the mapping entered in the key must only be assigned communication channels with the following adapter types:
-          RFC adapter
-          SAP Business Connector adapter
-          File/FTP adapter
-          JDBC adapter
-          JMS adapter
-          SOAP adapter
-          Marketplace adapter
-          Mail adapter
-          RNIF adapter
-          CIDX adapter
The adapters also have to all run on the same Adapter Engine.
Adapters developed by partners also support a mapping-based message split if they run on the same Adapter Engine.
Attachments from the original message are not appended to the messages resulting from the message split.
Activities
To execute a mapping-based message split, perform the following steps:
       1.      Integration Repository: Define the multi-mapping (see Developing Multi-Mappings for Message Splits).
       2.      Integration Directory: Define the interface determination.
Note the following:
○     The outbound interface of the multi-mapping must be entered as the sender interface in the key of the interface determination.
○     The interface determination type must be set to Enhanced.
○     Select the multi-mapping you defined previously from the Integration Repository.
To select the interface mapping, use the input help ( ).
The target interfaces of the interface mapping are displayed in the Inbound Interfaces frame.
The number of messages (for an inbound interface) created in the mapping step is displayed in the Occurrence column.
regards,
Raj

Condition Based Interface Determination in ICO (AAE) - PI 7.1 EHP1

Hi Friends,
We have PI 7.1 EHP1 - SP 04.
In our scenario, we have 1 outbound interface and 2 inbound interface. Based on condition, it needs to select the first inbound interface or second inbound interface.
In the normal configuration, we are able to select. (By click + icon and add condition in the Receiver Interfaces in Interface Determination Step)
When we create configuration using ICO (Integrated Configuration), there is no option in "Receiver Interfaces" Tab to add two inbound interfaces with condition.
Could you please clarify how do we do this in ICO?
Kind regards,
Jegathees P.

IMHO, condition based interface determination is not possible in ICO.
Use Multiple inbound service interfaces... You can handle in design level .. ESR level.
Check the Abhishek's blog... This might be helpful.
http://www.sdn.sap.com/irj/scn/go/portal/prtroot/docs/library/uuid/90dcc6f4-0829-2d10-b0b2-c892473f1571?quicklink=index&overridelayout=true
Note: Since in your case you need two receiver agreements, you cannot handle through ICO. The above link might be helpful to do multimapping without BPM.
Edited by: Baskar Gopal on Apr 26, 2011 9:53 AM

Complex interface determination fails for 0-N mappings

We have a mapping question for the following scenario in PI 7.1: One message needs to be mapped into two target structures, it comes from the same sender and goes to same receiver. We need to call two different BAPI in the same SAP end system simultaneously.
This is set up in one interface determination (same sender & receiver) where we use two different operation mappings with different receiver interface names. If the mapping have multiplicity 1, everything works fine and the message gets mapped to both receiver interfaces simultaneously. But, when the multiplicity of the mappings is 0-N (split mapping), then we get error message during interface determination phase:
Error when determining the inbound interface: Inbound interface found several times (for same sender and receiver) for the outbound interface http://sending/namespace.sndInterfaceName
How can we set up our scenario with two 0-N mappings without getting error message? One option would be combining two mappings in one, but this can not work in our case because of the high complexity.
Any comments appreciated. Thanks, Sanjay.
Edited by: Sanjay Gupta on Oct 21, 2010 10:50 PM

Thanks for taking the time to look into this. See my comments below.
1. Are you using multi mapping? Source Message type 1 and Traget message types 2 (added from messages tab in the mapping)
We have two mappings, both create only a single output type, however, they are split mappings, meaning the mapping result message multiplicity is 0-N. So the answer is NO, this are no multi mappings
2. At any time, can both the target messages be created or are they mutually exclusive?
both targets will always be created, they are NOT mutually exclusive
3. With in each message type that gets generated on the target side, is the occurance 1..1 or 1..unbounded?
Don't fully get the question, but I assume you ask if the mapping is defined as a 1:1 or 1..N mapping. The latter is true.
4. Is there any condition in the interface determination?
Answer is No.
5. How many operation mappings did you design.
We have two operation mappings, each containing a different mapping to the different receiver interface type.
Being said that, the ideal way should be, You need to create only one message mapping by adding multiple message types on the target side. I fully understand and agree with this statement, but due to the complexity of the mapping we need to separate it out into two mappings.
It is confusing, that the described scenario works if the multiplicity of the mapping objects used is 1, but as soon as the multiplicity is 0-N (when using a split mapping instead), we start getting the error message.

Interface Determination causing issue in Receiver Determination

Hi
I am having an issue with interface and receiver determination as follows:
- Inbound message may be sent to two receivers.
- Message gets sent to first receiver, fails during interface determination. There are multiple inbound interfaces found based on a set of XPATH conditions. This creates an error 'Inbound interface found more than once for outbound interface '. That is itself is not the issue.
- Issue is that the message is stopped from going to the other receiver even if there are no issues in the interface determination for that receiver.
Is there a way to resolve this? Appreciate any help. Thx, Duncan

Again, thanks for the replies.
MONI for RD
- <Trace level="1" type="B" name="CL_XMS_MAIN-CALL_PLSRV_LOCAL">
- <Trace level="1" type="B" name="CL_RD_PLSRV-ENTER_PLSRV">
<Trace level="1" type="T">R E C E I V E R - D E T E R M I N A T I O N</Trace>
<Trace level="1" type="T">Cache Content is up to date</Trace>
<Trace level="2" type="T">Start without given receiver</Trace>
<Trace level="2" type="T">Classic Receiver Determination via Rules.</Trace>
<Trace level="2" type="T">Check conditions for rule line no. 1</Trace>
<Trace level="3" type="T">...create rule engine</Trace>
<Trace level="3" type="T">...call rule engine for Condition %CL_SAI_SWF_RULE_ENGINE.MSG_GET(MSG=&_MSG&;NSP=&_NSM&;XPATH="/p2:despatchAdvice")% EX and %CL_SAI_SWF_RULE_ENGINE.MSG_GET(MSG=&_MSG&;NSP=&_NSM&;XPATH="/p2:despatchAdvice/deliveryNote/referenceIdentification")% CE COSTCENTRE or %CL_SAI_SWF_RULE_ENGINE.MSG_GET(MSG=&_MSG&;NSP=&_NSM&;XPATH="/p2:despatchAdvice")% EX and %CL_SAI_SWF_RULE_ENGINE.MSG_GET(MSG=&_MSG&;NSP=&_NSM&;XPATH="/p2:despatchAdvice/deliveryNote/referenceIdentification")% CE INTERPLANT or %CL_SAI_SWF_RULE_ENGINE.MSG_GET(MSG=&_MSG&;NSP=&_NSM&;XPATH="/p2:despatchAdvice")% EX and %CL_SAI_SWF_RULE_ENGINE.MSG_GET(MSG=&_MSG&;NSP=&_NSM&;XPATH="/p2:despatchAdvice/deliveryNote/referenceIdentification")% CE INTERPLANT_ONESTEP or %CL_SAI_SWF_RULE_ENGINE.MSG_GET(MSG=&_MSG&;NSP=&_NSM&;XPATH="/p2:despatchAdvice")% EX and %CL_SAI_SWF_RULE_ENGINE.MSG_GET(MSG=&_MSG&;NSP=&_NSM&;XPATH="/p2:despatchAdvice/deliveryNote/referenceIdentification")% CE INTRAPLANT or %CL_SAI_SWF_RULE_ENGINE.MSG_GET(MSG=&_MSG&;NSP=&_NSM&;XPATH="/p2:despatchAdvice")% EX and %CL_SAI_SWF_RULE_ENGINE.MSG_GET(MSG=&_MSG&;NSP=&_NSM&;XPATH="/p2:despatchAdvice/deliveryNote/referenceIdentification")% CE INTRAPLANT_ONESTEP or %CL_SAI_SWF_RULE_ENGINE.MSG_GET(MSG=&_MSG&;NSP=&_NSM&;XPATH="/p2:receivingAdvice")% EX or %CL_SAI_SWF_RULE_ENGINE.MSG_GET(MSG=&_MSG&;NSP=&_NSM&;XPATH="/p2:inventoryActivityOrInventoryStatus")% EX</Trace>
<Trace level="2" type="T">......extracting (new) for Extractor: XP /p2:despatchAdvice</Trace>
<Trace level="2" type="T">......extracting values found: 0</Trace>
<Trace level="2" type="T">......extracting (new) for Extractor: XP /p2:receivingAdvice</Trace>
<Trace level="2" type="T">......extracting values found: 1</Trace>
<Trace level="2" type="T">...valid Receiver with Condition: - GLR430</Trace>
<Trace level="2" type="T">Check conditions for rule line no. 2</Trace>
<Trace level="3" type="T">...call rule engine for Condition %CL_SAI_SWF_RULE_ENGINE.MSG_GET(MSG=&_MSG&;NSP=&_NSM&;XPATH="/p2:despatchAdvice")% EX and %CL_SAI_SWF_RULE_ENGINE.MSG_GET(MSG=&_MSG&;NSP=&_NSM&;XPATH="/p2:despatchAdvice/deliveryNote/referenceIdentification")% NE COSTCENTRE and %CL_SAI_SWF_RULE_ENGINE.MSG_GET(MSG=&_MSG&;NSP=&_NSM&;XPATH="/p2:despatchAdvice/deliveryNote/referenceIdentification")% NE INTERPLANT and %CL_SAI_SWF_RULE_ENGINE.MSG_GET(MSG=&_MSG&;NSP=&_NSM&;XPATH="/p2:despatchAdvice/deliveryNote/referenceIdentification")% NE INTERPLANT_ONESTEP and %CL_SAI_SWF_RULE_ENGINE.MSG_GET(MSG=&_MSG&;NSP=&_NSM&;XPATH="/p2:despatchAdvice/deliveryNote/referenceIdentification")% NE INTRAPLANT and %CL_SAI_SWF_RULE_ENGINE.MSG_GET(MSG=&_MSG&;NSP=&_NSM&;XPATH="/p2:despatchAdvice/deliveryNote/referenceIdentification")% NE INTRAPLANT_ONESTEP</Trace>
<Trace level="2" type="T">...invalid Receiver: P_3PL_XML_ME_ODTH - despatchAdviceToE1EDT20</Trace>
<Trace level="2" type="T">Check conditions for rule line no. 3</Trace>
<Trace level="2" type="T">...valid Receiver w/o Condition: P_3PL_XML_ME_ODTH - S_HTTP</Trace>
<Trace level="2" type="T">No Receiver found behaviour: 0</Trace>
<Trace level="2" type="T">Number of Receivers:2</Trace>
</Trace>
</Trace>
</Trace>
Here, you see that both receivers are found.
MONI for ID
<Trace level="1" type="B" name="PLSRV_INTERFACE_DETERMINATION" />
- 
<Trace level="1" type="Timestamp">2007-02-26T20:06:49Z CET Start of pipeline service processing PLSRVID= PLSRV_INTERFACE_DETERMINATION</Trace>
- <Trace level="1" type="B" name="CL_XMS_MAIN-CALL_PLSRV">
<Trace level="3" type="T">Calling pipeline service: PLSRV_INTERFACE_DETERMINATION</Trace>
<Trace level="3" type="T">Reading Pipeline-Service specification...</Trace>
<Trace level="3" type="T" />
<Trace level="3" type="T">Pipeline service specification (table SXMSPLSRV)</Trace>
<Trace level="3" type="T">PLSRVID = PLSRV_INTERFACE_DETERMINATION</Trace>
<Trace level="3" type="T">PLSRVTYPE =</Trace>
<Trace level="3" type="T">ADRESSMOD = LOCAL</Trace>
<Trace level="3" type="T">P_CLASS = CL_ID_PLSRV</Trace>
<Trace level="3" type="T">P_IFNAME = IF_XMS_PLSRV</Trace>
<Trace level="3" type="T">P_METHOD = ENTER_PLSRV</Trace>
<Trace level="3" type="T">FL_LOG =</Trace>
<Trace level="3" type="T">FL_DUMMY = 0</Trace>
<Trace level="3" type="T" />
<Trace level="1" type="B" name="CL_XMS_MAIN-CALL_PLSRV_LOCAL" />
- 
- <Trace level="1" type="B" name="CL_ID_PLSRV-ENTER_PLSRV">
<Trace level="1" type="T">I N T E R F A C E - D E T E R M I N A T I O N</Trace>
<Trace level="1" type="T">Cache Content is up to date</Trace>
<Trace level="2" type="T">Check conditions for (Inb: Party Srvc If) GLR430 WMMBXY.WMMBID01</Trace>
<Trace level="3" type="T">...create rule engine</Trace>
<Trace level="3" type="T">...call rule engine for Condition%CL_SAI_SWF_RULE_ENGINE.MSG_GET(MSG=&_MSG&;NSP=&_NSM&;XPATH="/p1:inventoryActivityOrInventoryStatus/inventoryDocumentType")% CE INVENTORY_STATUS</Trace>
<Trace level="2" type="T">......extracting (new) for Extractor: XP /p1:inventoryActivityOrInventoryStatus/inventoryDocumentType</Trace>
<Trace level="2" type="T">......extracting values found: 0</Trace>
<Trace level="2" type="T">...invalid InbIf: WMMBXY.WMMBID01</Trace>
<Trace level="2" type="T">Check conditions for (Inb: Party Srvc If) GLR430 WMMBXY.WMMBID01</Trace>
<Trace level="3" type="T">...call rule engine for Condition%CL_SAI_SWF_RULE_ENGINE.MSG_GET(MSG=&_MSG&;NSP=&_NSM&;XPATH="/p1:inventoryActivityOrInventoryStatus/inventoryDocumentType")% CE INVENTORY_ACTIVITY</Trace>
<Trace level="2" type="T">......extracting (new) for Extractor: XP /p1:inventoryActivityOrInventoryStatus/inventoryDocumentType</Trace>
<Trace level="2" type="T">......extracting values found: 0</Trace>
<Trace level="2" type="T">...invalid InbIf: WMMBXY.WMMBID01</Trace>
<Trace level="2" type="T">Check conditions for (Inb: Party Srvc If) GLR430 WMMBXY.WMMBID01</Trace>
<Trace level="3" type="T">...call rule engine for Condition%CL_SAI_SWF_RULE_ENGINE.MSG_GET(MSG=&_MSG&;NSP=&_NSM&;XPATH="/p2:receivingAdvice/receivingAdviceItemContainmentLineItem/purchaseOrder/documentReference/uniqueCreatorIdentification")% EX</Trace>
<Trace level="2" type="T">......extracting (new) for Extractor: XP /p2:receivingAdvice/receivingAdviceItemContainmentLineItem/purchaseOrder/documentReference/uniqueCreatorIdentification</Trace>
<Trace level="2" type="T">......extracting values found: 2</Trace>
<Trace level="2" type="T">...valid InbIf with Condition: WMMBXY.WMMBID01</Trace>
<Trace level="2" type="T">Check conditions for (Inb: Party Srvc If) GLR430 WMMBXY.WMMBID01</Trace>
<Trace level="3" type="T">...call rule engine for Condition%CL_SAI_SWF_RULE_ENGINE.MSG_GET(MSG=&_MSG&;NSP=&_NSM&;XPATH="/p2:receivingAdvice/carrier/additionalPartyIdentification/additionalPartyIdentificationValue")% CE SHUTTLE</Trace>
<Trace level="2" type="T">......extracting (new) for Extractor: XP /p2:receivingAdvice/carrier/additionalPartyIdentification/additionalPartyIdentificationValue</Trace>
<Trace level="2" type="T">......extracting values found: 1</Trace>
<Trace level="2" type="T">...valid InbIf with Condition: WMMBXY.WMMBID01</Trace>
</Trace>
</Trace>
- <Trace level="1" type="B" name="CL_XMS_MAIN-WRITE_MESSAGE_LOG_TO_PERSIST">
<Trace level="3" type="T">Persisting message after plsrv call</Trace>
<Trace level="3" type="T">Message-Version = 002</Trace>
<Trace level="3" type="T">Message version 002</Trace>
<Trace level="3" type="T">Pipeline CENTRAL</Trace>
</Trace>
<Trace level="3" type="System_Error">Error exception return from pipeline processing!</Trace>
<Trace level="1" type="B" name="CL_XMS_MAIN-WRITE_MESSAGE_TO_PERSIST" />
- 
<Trace level="3" type="T">Persisting message Status = 014</Trace>
<Trace level="3" type="T">Message version 003</Trace>
<Trace level="3" type="T">Pipeline CENTRAL</Trace>
</SAP:Trace>
Here, you see that the ID runs for the first receiver. It hits an error because two conditions on the ID for the first receiver are satisfied. However, it then stops rather than allow the processing for the other receiver to continue.
Any ideas? Thx, Duncan

No interface objects found in interface determination

Hi Experts,
              i am configuring the multiple idoc to flat file.
             for this, i am not using the bpm.
            i refer the following blog.
           https://www.sdn.sap.com/irj/sdn/weblogs?blog=/pub/wlg/4443. [original link is broken] [original link is broken] [original link is broken]
       According to this blog, we can make the scenario as file to file. xi will pick the idoc-xml file.
    for this, could you please let me know the source data type?
   i exported standard idoc and made occurances as unbounded and import to name space.
   for the imported external defination, i creared the message interface as outbound and used as sender interface.
i made the mapping between external deficnation to flat file structure.
my IR part is ok.
i have problem with ID.
when i configure the interface determination, i found it as no interface objects found.

Hi,
Normally we dont require to create DT , MT MI incase we are using IDOC.
But in your case you imported the idoc and exported it to ur desktop and changed the Occurance of that IDOC.
Then again you imported that as External Def.
This case you need to create the MI for this IDOC, why because we dont have the option to select the External def directly with out creating the MI at the time of creation of Interface mapping.
But in case of IDOC means we have the provision to select the IDOC derectly at the time of Interface mappimg
Regards
Seshagiri

Condition based Interface determination

Hi ,
Environment : PI 7.1.
Scenario : File to Proxy.
In this scenario , We have a single file interface which reads a file and routes the data to two different inbound interfaces.
Steps followed to do this -
>>Defined two inbound interfaces interface1 & interface2.
>>Both interfaces are pointed to same ECC system.
>>Read the file using a single sender file communication channel.
>>Define receiver ECC in the receiver determination.
>> Define interface determination based on a value of a field in the file structure(source structure). Used XPATH to define this content based routing and selected operation mapping specific to the interface.
1 sender agreement
1 receiver determination ( not using enhaced receiver determination because we have only one receiver)
1 interface determination which has two receiving interfaces based on XPATH condition ( maintain order runtime is checked)
2 Receiver agreements.
2 Communication channels.
For example if you have 10 lines in a file , out of which if 5 lines has a value related to interface 1 & 5 lines has a value related to interface 2. It should push the data into two different proxies as configured.
We are facing a problem in this scenario -
There is no consistency in the logic. Some times it runs interface 1 & some time it executes interface 2.
based on condition 1 it routes the data to interface 1 successfully but the structure is not getting created for interface 2 so it is giving an error stating the interface 2 structure is not available.
In SXMB_MONI the branching steps show two subnodes but if you see the log it shows that in subnode 1 the sender is sender interface & the receiver is interface 1 based on the filter condition. If you see the log for subnode 2 then it shows the sender is sender & the receiver as interface 2 below that it shows another entry which shows the reciver interface is interface2.
Please evaluate and let us know if the approach we are following works or not. If there is any limitations please let us know how to achive this.
Regards,
Reddy

Hi,
Your design is correct but here you missed one point. Here the message is send either to receiver1 or receiver2 depending on the condition but not both. As this does not result in multiple messages with the same payload because only one condition can ever be true at runtime. For more details see the below link
http://help.sap.com/saphelp_nw04/helpdata/en/46/8015de950e6be3e10000000a155369/frameset.htm
If you want to create multiple message then you need do 1:n mapping :
http://www.sdn.sap.com/irj/scn/weblogs;jsessionid=(J2EE3417700)ID2056393550DB10021342992851308291End?blog=/pub/wlg/2927
Shweta.

Interface determination condition

Hi Experts,
I am working on File to IDoc scenario, where I want to send IDocu2019s based on source data, in flat file if order number exists then I have to send MATMAS idoc , if order number does not exists then I want send DEBMAS.
I developed 2 mapping programs and checking condition in Interface determination to check order number exists or not.
i wrote below conditions in Interface determination and not working for multiple Orders
MT_Invoice /Order/OrderNum EX u2013 to check order number exists or not.
MT_Invoice /Order[not(OrderNum)] EXu2014to check order number not exists
My Source Structure after file content conversion looks like below
<Order> 1..unbounded
 <CustomerID>
 <MaterialID>
 <OrderNum>
</Order>
Regards,
JAM

Hello,
The Interface determination condition will not filter the payload data. It can only determination whether a particular condition is true or false.
If any valid condition occurs, complete payload will be passed to the respective Interface and mapping will be executed accordingly.
Currently in your case I guess both conditions are getting satisfied for multiple records in payload.
I think you need to implement the filtering logic in message mapping using the concept of multi- mapping.
Refer blog: /people/jin.shin/blog/2006/02/07/multi-mapping-without-bpm--yes-it146s-possible
The mapping will contain 2 target structures with occurance 1...unbounded i.e. Matmas and Debmas for your scenario.
You need to apply filter logic on header nodes in the mapping.
Or you need to process single records in the payload.
-Rahul

Single SOAP receiver adapter for multiple interfaces

Hi,
I have to send multiple interfaces like Vendor, Customer, Material to one receiver.
I want to configure only one communication channel (receiver SOAP adapter) to send all these interfaces. Is this possible?
Currently I am provided with different URLs from the receiver system as below.
http://host:port/Services/Vendor.wsdl
http://host:port/Services/customer.wsdl
http://host:port/ServicesMaterial.wsdl
I will be having 3 Sender agreement, 3 receiver determination, 3 interface determination and 3 Receiver agreement.
I want only one SOAP reciever adapter which goes inside all the above 3 Receiver agreement.
So When I give the target url as http://host:port/Services, the messages fail.
But When I specify the full targert url in the adapter as http://host:port/Services/Vendor.wsdl then it works.
Which means I would have to create as many communication channel as interfaces.
Is there a work around for this?

hi kantheri,
For this, we have to fill the TargetURL and the SOAPAction in Receiver Communication channel dynamically.
So, we need to write UDF in Message Mappings using DynamicConfiguration to fill the TargetURL and the SOAPAction Dynamically.
DynamicConfigurationKey keyURL = DynamicConfigurationKey.create("http://sap.com/xi/XI/System/SOAP","THeaderSOAPACTION");
DynamicConfigurationKey targetURL=DynamicConfigurationKey.create("http://sap.com/xi/XI/System/SOAP","TServerLocation");
// access dynamic configuration
DynamicConfiguration conf = (DynamicConfiguration) container
.getTransformationParameters()
.get(StreamTransformationConstants.DYNAMIC_CONFIGURATION);
conf.put(keyURL,"Soap action");
conf.put(targetURL,"target url");
return "";
In this UDF, we are filling the TargetURL in u201CTServerLocationu201D message attribute and SOAPAction in u201CTHeaderSOAPActionu201D message attribute.
So, whenever we execute this corresponding operation these values will be filled in receiver communication channel at runtime.
TargetURL- Give some dummy URL or http://
SOAPAction - *
regards,
ganesh.

BPM using multiple interface

Hi All,
i have a sceanrio where i have one sender idoc and multiple(5) soap receivers.so i have five interface that have same sender idoc and different soap receiver.Soap is syncronous and sending us the response of that message.
So we have to create a scenario as IDOCSoapRequestSoapResponse---File for each interface
I know it requires BPM to fullfill the condition of multiple interface.Please suggest the BPM design to achive the scenario.
Regards
Laxmi Bhushan

hi Laxmi Bhushan Jha ,
IDOCSoapRequestSoapResponse---File for each interface
As per my knowledge that is poosiable and simple with SOAP Lookup in ESR Mapping
for Soap Lookup:
Webservice Calls From a User Defined Function.
and coming to id:
in receiver determination , we need to define multiple recievers
in interface determiination, we define multiple operation mappings.
thanks,

Single IDOC to Multiple Interface Mapping

We have a requirement in our project where one masterdata IDOC will be sent from a SAP MDM box and will be transformed to a target IDOC and be sent to an SAP SNC box. However, the scenario is that depending on the contents of the IDOC, there can be multiple IDOCs that need to be created. For example, the single MDM IDOC has V1, V2 and V3 values then the IDOCS that should be sent to the SAP SNC box should be three.
The IT head of the customer decided against using Enhanced Interface Determination (since the problem can be easily solved using a 1:n mapping) due to the complexity especially when the solution is rolled out to other regions as each region has it's own logic (currently, the other implementation has only 1:1 mapping so there is no problem). I had developed a 1:n mapping but the resulting map is too big and very complex.
What I tried to do is to create separate mappings for each scenario that an IDOC needs to be generated out of the values from the received IDOC in XI and then define rules in the Interface Determination. Problem is that XI throws an error stating that multiple interfaces are found. So I cannot use Interface Determination to trigger creation of multiple IDOCS of the same type with different values from a single IDOC sent by the same SAP box.
Question is, is there any way to solve this requirement without using Enhanced Receiver Determination. I was thinking of BPM but not really sure how to do it.
Thanks in advance!
Best Regards,
Rommel Mendoza
Hewlett Packard Asia-Pacific, Ltd.

Thanks a lot for that.
For example, We have this input Message:
<ZMATMA>
<IDOC>
 <E1MARAM>
 <E1MARMM>
 <MEINH>IT</MEINH>
 </E1MARMM>
 <E1MARMM>
 <MEINH>CS</MEINH>
 </E1MARMM>
 <E1MARMM>
 <MEINH>SW</MEINH>
 </E1MARMM>
 </E1MARAM>
</IDOC>
</ZMATMA>
then there should be an output of:
<SAVEMULTIPLE204>
<IDOC>
 <BUOM>IT</BUOM>
</IDOC>
</SAVEMULTIPLE204>
<SAVEMULTIPLE204>
<IDOC>
 <BUOM>CS</BUOM>
</IDOC>
</SAVEMULTIPLE204>
<SAVEMULTIPLE204>
<IDOC>
 <BUOM>SW</BUOM>
</IDOC>
</SAVEMULTIPLE204>
The logic is when the MEINH field of the ZMATMA02 IDOC has the values: IT, CS and SW, create one IDOC for each.
Thanks in advance!
Edited by: Rommel Mendoza on Nov 6, 2008 7:30 PM

Multiple Interface Determination

Similar Messages

Maybe you are looking for