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.

Similar Messages

  • 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

  • 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
    <b>IF_1</b>                     no condition                   <b>M_1</b>
    <b>IF_1</b>                     no condition                   <b>M_2</b>
    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

  • 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.

  • 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

  • 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.

  • Interface determination : How to populate an Operation Mapping parameter

    Hi experts,
    I'm creating an interface determination, I have an Operation Mapping in it. This operation mapping has an inbound parameter. When Configurating this parameter I can choose between putting a constant or getting the value from a "container". Does anybody knows where this container will be? Is it  possible to take the parameter from an export parameter from Integration Process(BPM)?
    My interface:
    BPM->IDOC
    Regards
    Gonzalo

    Hi Stefan,
    What I wanted is leaving the mapping outside the BPM, instead that I can leave it inside and the result will be the wanted. What you mean implies something similar.
    I'm going to explain why, from the process dessign point of view, I want to leave the mapping outside.
    1.-I send an IDOC from my ERP
    2.-This IDOCs starts a BPM who, in a synchronous way, makes some updates in a DB.
    3.- Functionally speaking this updates could return a 0 if OK or a -1 if NOK
    4.-The BPM have to return an ACK to the ERP.
    For constructing this ACK I need my original IDOC and the result of the updates (-1 or 0).
    -If I put the mapping inside the BPM it will work (and that will probably be the final solution).
    -But, for a better performance and dessign, I wanted to leave the mapping outside.
    -I also want to know if the container in the interface determination we talked before can be used or what it means. (So let me know if you find out something about)
    -The third reason is that I find interesting speak about this topics in the forum if you know what I mean :-D
    Regards
    Gonzalo

  • 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

  • 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 <b>not </b>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.
    <b>MONI for RD</b>
    - <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.
    <b>MONI for ID</b>
    <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

  • Use of Enhanced option in Interface Determination

    Hello All,
    I am stuck up with a problem, where I need your expertised help.
    The scenario is IDOC --> Files 
    what I mean by files is:  I have one sender (ecc system) and two receivers (ftp destinations using file adapters).  I created multi mappings (1:n); based on the content of the IDOC field, either Message Type1 or MessageType2 are populated in the message mapping.  Each MessageType belongs to separate receivers.  Message mapping working good when tested in the test tab.
    Now, coming to configuration side; I have created one interfaced determination with enhanced mode and gave the Message interface information, which populated both Message Interfaces below automatically.  Interface is failing with "No receiver Agreement for the sender receiver combinatio".  I checked all the cache refresh and also the receiver agreements.  I have both receiver agreeements defined, one of each receiver.  I guess something to do with Interface Determination definition. 
    Questions:
    1) In the interface determination, what receiver system we need to specify.  I have two receivers here; I don't see space to specify both when selected enhanced option.
    2) How do I specify receiver determination for this?
    Thanks for your help..RP

    I just looked into the error message deeply.  This is why it is errroring out.  any idea is a great help.
    In the Interface determination, I have * for the receiver.
    In the Receiver determination, I have both receivers defined. 
    In the bottom section of the Receiver Determination, It is showing both message interfaces for each receiver like below
    Receiver1
       MessageInterface1  --  Interface Mapping -- Receiver Agreement
       MessageInterface2  --  Interface Mapping -- Does Not Exist
    Receiver2
       MessageInterface1  --  Interface Mapping -- Does Not Exist
       MessageInterface2  --  Interface Mapping -- Receiver Agreement
    In the Moni, I see two child messages as they are supposed to, one for each receiver and and both failed.
    Both messages failed with the similar message statinng that 'No receiver agreement found for sender xx and receiver combination'.  This error is for the other message interface which does not beloing to that receiver (MI information also shown in the message). 
    Thanks for your help..

  • Receiver and Interface determination

    Hi,
    My senario is File to IDOC and mail.
    The condition here is the count of Idoc generated has to be sent as a mail and the mail has to  be sent only after the IDoc has been generated successfully.
    So i am using two receiver services one is for IDOC and other is for mail and  in one receiver determination I am refering TWO reciver Service without any condition.
    now  i have to use only one interface determination to maintain the order at runtime. so that the interface mapping for mail will be triggered only after the Idoc interfacemapping is successfull.
    but in receiver agreement  i am not able to refer the Receiver channel for Mail. because the receiver service is still poiting to the Idoc Serveice.
    Plz advice.

    Hi!
    I think the above requirement will also work by using a simple BPM. just try with below steps.
    Steps in BPM::
    1. Receive step to receive File from a third party by using File Sender CC.
    2. SEND ASYNCH step to send IDOC generated Structure data.
    3. Before going to next step please find any constant value which will be coming into IDOC from file that
        means for example if your IDOC cotnains any field like ORDER_Generated_By or 
        GENERATED_BY:: AMAR  name is same in all the data that is coming into IDOC remember that Field
        Name name and insert it in the swtich statement condition editor.
    4. Now Insert Switch Condition with 2 branches A & B,
         a) Branch A contains control statement and this branch executes only if the condition statisfies with
            If that IDOC Field lets say name XXXX is equal to constant value AMAR then raise/throws  an alert
            mail by uising Control Step.
        b) In Branch B also you ill be including Control Step but this control Step will says that  MAIL
            INDICATION  No IDOC is generated by using another control step.
    5) Remaining all other configurations like 2 receiver agreements and every thing aare same.
    6) But you need to confgure ALert configuration settings okay.
    You can also achive this by using without BPM.::
    In ID part:: you need to enter a condition in Receiver Determination with two receiver business systems and that condition will be once the IDOC field like XXXXX(generated_by is equal to some constant like AMAR ) then it needs to active the Mail Business System.
    but this would be little but confusion and but u can achive the above requirement by using simple BPM.
    Note:: Only diadvantage will be some performance issue will come if goes through BPM but it works
              very 100 systamatic way because you can review where exactly your Scenario strucks and also
              u can check whether your IDOC generated or not whether mail sent or not in the BPM WORK
               FLOW in the BUSINESS PROCESS ENGINE.
    Regards::
    Amar Srinivas Eli

  • 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.

Maybe you are looking for