Standard Vs Extended Interface Determination

Can someone tell me what is the difference between extended and standard interface determination

Extended receiver determination is used when you want to decide which receiver's to send the message to based on the content of the input message or some other condition at runtime.
Here, first you define mapping to figure out the receivers of the msg and then you call this mapping in your receiver determination. the "receiver" message type which is present in sap basis -->... XI/system namespance i think.
The whole idea behind enhanced receiver determination is that during normal receiver determination the pipe line step for receiver determination is executed before the mapping step this resulted in a limitation in XI that you could not change your receivers based on the mesg content at runtime.
Now, in enhanced receiver determination XI will first execute this receiver determination mapping and figure out the receivers at runtime and then call the individual mappings.
Cheer's

Similar Messages

Extended Receiver & Extended Interface Determination

Hi Experts,
Can any tell me what is Extended Receiver & Extended Interface Determination.
And the Difference between Standard Receiver & Standard Interface Determination.
were to use Extended Receiver & Extended Interface Determination.
Thanks in advance
Shakif

Hi,
Standard Receiver Determination Features
Specifying Receivers
You can specify receiver parties and receiver services. To specify the receiver in more detail, you have the following options:
●     Select the receiver from the Integration Directory
●     Specify a constant value for the receiver
●     Determine the receiver dynamically from the message content
To enter the necessary details, use the following:
●     The party editor for specifying the receiver party
●     The service editor for specifying the receiver service
To call the relevant editor, in the Display/Edit Receiver Determination editor in the Configured Receivers frame, call the Input Help ( ) in either the Party or Service column.
Defining Conditions
You also have the option of specifying the conditions to be applied when forwarding a message to the receiver(s) in a receiver determination.
Generally, a condition relates to the contents of a message; if a specified condition is fulfilled for a particular payload element (the corresponding element has a certain value, for example), then the message is forwarded to the specified receiver(s).
●     If you want to specify a new condition for forwarding the message to a receiver, in the table in the Display/Edit Receiver Determination editor in the Configured Receivers frame, choose Insert New Condition () and call the condition editor by using the input help ().
●     If you want to specify a new condition for forwarding the message to multiple receivers, in the table in the Display/Edit Receiver Determination editor in the Configured Receivers frame, choose Insert Line After Selection ( ) and call the condition editor by using the input help ().
In the condition editor, you can select an element from the message payload and specify a value with which the value of this element is to be compared at runtime.
Enhanced Receiver Determination
Use
You use an enhanced receiver determination to have a mapping program determine the receivers of the message dynamically at runtime. Instead of creating the receivers in the receiver determination manually, you assign a mapping to the receiver determination and this returns a list of receivers at runtime.
A typical usage case is if you do not yet know the names of the receivers at configuration time. In this case, you can define a mapping program, for example, which reads a list of receivers from a table or from the payload of the message at runtime.
You can of course formulate conditions in a standard receiver determination that relate to the content of the message. However, you have to specify the names of the receivers (to which the message is sent under the formulated condition) explicitly in the receiver determination. If you create an enhanced receiver determination, you do not have to specify receiver names at this stage.
Integration
During the definition of the interface mapping, you assign the abstract message interface ReceiverDetermination as the target interface. The message interface ReceiverDetermination is in the Integration Repository in the software component SAP BASIS (namespace http://sap.com/xi/XI/System).
The message interface uses the message type Receivers and the data type Receivers. The data type Receivers describes a list of receivers and has the following structure:
The following instance of the data type Receivers contains two receivers. The first receiver comprises a party and service and is identified by a DUNS number; the second receiver comprises a service without a party.
<Receivers>
<Receiver>
    <Party agency=016 scheme=DUNS>123456789</Party>
    <Service>MyService</Service>
</Receiver>
<Receiver>
    <Party agency=http://sap.com/xi/XI scheme=XIParty></Party>
    <Service>ABC_200</Service>
</Receiver>
</Receivers>
You can specify party and service for each receiver.
Activities
       1.      Integration Repository: Define the interface mapping. Assign the message interface ReceiverDetermination as the target interface (see above).
       2.      Integration Repository: Define the message mapping or mapping program that is to determine the receivers at runtime. Assign the message mapping or mapping program to the interface mapping.
       3.      Integration Directory: Define an (enhanced) receiver determination.
○     Enter the outbound interface of the interface mapping from step 1 in the key of the receiver determination as the outbound interface.
○     Assign the interface mapping created in step 1 to the receiver determination.
Standard Interface Determination
Use
You can specify to which inbound interfaces at the receiver the message is to be sent at runtime. You also have the option of specifying a mapping and (when multiple inbound interfaces are defined) a condition for each inbound interface.
Note the following fundamental cases when assigning multiple inbound interfaces:
Multiple Different Inbound Interfaces
Imagine you enter the following interface assignment.
Inbound Interface
Condition
Interface Mapping
IF_1
M_1
IF_2
M_2
After the interface determination is evaluated, this results in two messages with the same payload at runtime. A different mapping (either M1 or M_2) is executed for both messages and then they are forwarded to the two interfaces (either IF_1 or IF_2) at the receiver.
Multiple Identical Inbound Interfaces with Conditions
Imagine you enter the following interface assignment.
Inbound Interface
Condition
Interface Mapping
IF_1
B_1
M_1
IF_1
B_2
M_2
In this case, the conditions are evaluated during the interface determination step. If condition B_1 is true, then mapping M_1 is executed; if condition B_2 is true, then mapping M_2 is executed. The message is forwarded to the same inbound interface at the receiver in both cases. Unlike in the case described above, this does not result in multiple messages with the same payload because only one condition can ever be true at runtime.
Features
You enter the assignment between the outbound interface and the inbound interface(s) in a table. Each table line represents exactly one assignment between the outbound interface and an inbound interface. To insert or delete lines, choose Insert One Line After Selection () or Delete Selected Line ().
Enhanced (Mapping-Based) Interface Determination
Use
In an enhanced interface determination you do not enter the inbound interfaces manually, but instead 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 do so, call 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,
Phani
Reward points if Helpful

Extended Interface determination

I have a outbound scenario
R/3 (PO from different vendors)--> Mapping A(or)Mapping B(or)Mapping C-->multiple Partners
when a puchase order comes to XI it should be able to recognise either of the mappingsA,B orC.
Can i use extended Interface determination in this case giving the vendor number(unique) so that the appropriate mapping is selected.
-Sudhansu

Hi Sudhanshu,
As Mark says, YOu can use extended interface determination when you use multi mapping and no need to define BPM for the same.
But for your requirement, under Standard Interface determination , Give multiple Interface mapping and give Xpath conditions for Vendor number for every Mapping.
Let us know if you require more clarifications.
Best Regards,
Divyesh

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

Extended Receiver Determinatipon and Interface Determination?

Hi,
Where exactly (In which business cases) we can implement or required Extended Receiver Determination and Interface Determination?
Thanks,
Naidu.

Hi,
There are only two modes standard and Extended, Enhanced receiver determinatrion is Extended receiver determination only.
Enhanced(Extended) receiver determination -->
Whenever list of receivers is determined dynamically at runtime, using a message mapping then it is called enhanced.
Enhanced Interface Determination--> It is when you want the target interfaces to be defined dynamically based on the multimapping, that is called enhanced interface determination.
Refre SAP help for more detail
http://help.sap.com/saphelp_nw04s/helpdata/en/42/ed364cf8593eebe10000000a1553f7/frameset.htm
Thanks!
Edited by: Sudhir Tiwari on Dec 5, 2008 6:34 AM

Interface Mapping not listing in the Extended Reciever Determination

Hi,
The Interface Mapping is not shown in my Extended receiver determination. I have created and activated the IM & MM using the MT - Receivers within the SAP Basis.
Regards
Unni

Hi,
You can only choose the Interface mapping for the Enhanced recevier determination in the extended tab of Receiver determination. & I dont see the Interface mapping in the select list.
Where do I have to check for the proper outbound message???
Regards

Extended receiver and enhanced interface determination

Hi,
Can somebody list me the business cases when we use the extended receiver and enhanced interface determination.In which scenarios we have to use them?
Where we can use these features and whom they can replace?
Regards,
Anoop

Hi Anoop
have alook at thses URl's also
http://help.sap.com/saphelp_nw04/helpdata/en/43/01322a7af25285e10000000a1553f7/frameset.htm
:Dynamic file and variable substitution
Similarly Extended Receiver determination is used to determine the receiver at runtime.
Refer my reply:Re: Condition In Receiver Determination Not Working
enhancement in ID
Enhanced Receiver Determination:
You use an enhanced receiver determination to have a mapping program determine the receivers of the message dynamically at runtime. Instead of creating the receivers in the receiver determination manually, you assign a mapping to the receiver determination and this returns a list of receivers at runtime.
http://help.sap.com/saphelp_nw04/helpdata/en/43/a5f2066340332de10000000a11466f/content.htm
Enhanced (Mapping-Based) Interface Determination
In an enhanced interface determination you do not enter the inbound interfaces manually, but instead 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.
http://help.sap.com/saphelp_nw04/helpdata/en/42/ed364cf8593eebe10000000a1553f7/frameset.htm
<b>enhanced interface determination</b>
/people/robin.schroeder/blog/2006/11/15/using-dynamic-receiver-determination-with-sync-interface
/people/venkataramanan.parameswaran/blog/2006/03/17/illustration-of-enhanced-receiver-determination--sp16
List of receivers can be dyamically determined and assigned at runtime using enhanced receiver determination .
http://help.sap.com/saphelp_nw04/helpdata/en/43/a5f2066340332de10000000a11466f/content.htm
Thanks
Pls reward if useful

Extended Receiver Determination problem

Hi,
I am making use of extended receiver determination to send 1 source to multiple target systems. When I was testing so that the interface would just send to 1 target system while still making use of the extended receiver determination, I got the following error CO_TXT_OUTBINDING_NOT_FOUND and "No receiver agreement found". The red flag error occurs during Technical Routing and when I checked the details SOAP Header -> Main, I found that the following:
Sender Service: ServiceA (correct)
Sender Interface: InterfaceA (correct)
Sender namespace: NamespaceA (correct)
Receiver Service: ServiceB (correct)
Receiver Interface: InterfaceA (wrong)
Receiver namespace: InterfaceA (wrong)
It seems that extended receiver determination was able to successfully determine the receiver service but fail in determining the correct receiver interface and receiver namespace. Does anybody know why this happen and how to correct the problem?
Some investigation that I already done:
1.) I temporarily changed the extended receiver determination to a standard receiver determination and specifying the 1 target system explicity without changing any other object in both IR and ID as well as using the same test file. The result is that this worked and the file was sent succefully to my intended target system. This tells me that the problem might either be in the extended receiver determination or in the message mapping or message interface Receivers. Also, this means that all the other objects in ID for this interface is configured correctly.
2.) I tried hard coding the target system as a constant in the message mapping for the Receivers message type and still make use of the extended receiver determination and I got the same problem mentioned above.
3.) I tried deleting the receiver determination, activating the changes, re-create the object and activate it and I still got the problem
4.) I tried checking sxi_cache and everything is up to date and correct
Any suggestions is highly appreciated.

Elbert,
I you are doing only standard receiver determination only and using certain condition you are sending to different targets. If yes check this url:
/people/prasadbabu.nemalikanti3/blog/2006/09/20/receiver-determination-based-on-the-payload-of-input-dataextended-xpathcontext-object
Can you please put the payload after message mapping and the xpath condition you mentioned. or if you are doing enhanced receiver determination please check this:
Re: Error in enhanced receiver determination
---Satish
Edited by: Satish Reddy on Jun 23, 2009 9:08 AM

Extended receiver determination and Dynamic attributes

Hello,
is it possible to access dynamic attributes within an extended receiver determination? Can I modify / set dynamic attributes of an XI message within an UDF in the extended receiver determination mapping?
In detail: In my scenario I want to use an extended rec. determination, make a lookup in a DB inside the determination in order to define the receiver, and based on the lookup result I want to add some information as dynamic attributes to the XI message, which then can be accessed in the interface determination as conditions.
Thanks,
Chris

Hi,
In my scenario I want to use an extended rec. determination, make a lookup in a DB inside the determination in order to define the receiver, and based on the lookup result I want to add some information as dynamic attributes to the XI message, which then can be accessed in the interface determination as conditions - See you can do a DB lookup in a msg mapping........but by the time you have reached msg mapping your receiver determination will be done......so your receiver is already decided............Extended recever determination is for dynamically choosing a recever based on source msg's data.........
Regards,
Rajeev Gupta

Enhanced Interface Determination in PI 7.1

Hi All,
My scenerio will work as follows
The changes in the process order will triggered by the client system .I will get the already converted XML file.I have used the file adapter in the sender side to pick the file.At the receiver side I am using the 3 custom BAPIs.I have used 3 message interface instead of multi-mapping as the inbound interfaces.
The Logic is like that:
If the Process order status is = 1 then call BAPI 1,if it 2 then call BAPI 2 & call BAPI 3.
Please tell me the following
1.Is there Enhanced Interface Detrmination option available in PI 7.1?If so then can I mention or call 2 BAPIs in one condition over there?Do I need to write ABAP condition?
2.Is Enhanced interface Determination possible when I have used 3 inbound interfaces instead of multi-mapping?
3.From my point of view I need the following in my scenerio
- 3 message mappings(Graphical Mappings),
- 3 interface mappings,
- 1 sender agreement,
- 1 receiver determination,
-1 interface determination(with 2 conditions in it),
-3 receiver agreements.
Am I right?
4.How many sender and receiver agreements do I need?
5.Do I need to go for Enhanced receiver determination?
Thanks in advance.

the same status node in the source file on which I will impose check will call the selective inbound interface based on the
status node.Is it?If so,then do I need to mention anything other than the check condition in XPATH e.g.do I need to mention any
mapping program or inbound interface (though I dont thing so but I am still confused) ?
Yes, apart from specifying the condition in the Condition Editor you also should mention the corresponding Inbound Service Interface and Interface Mapping (if any).
Condition will only cause the execution of that particular line and wont automatically call the mapping/ interface (unless these are specified in the Interface Determination).
Is XPATH the alternative option in condition editor which can be skipped though I would surely like to go through it as
much as possible?
XPATH is the easiest option to specify a condition....other option includes the use of a Context Object.
So as of now think that you cannot skip XPATH (for this particular requirement).
Once you become an expert in using a XPATH (which you can in a days period) you can try out for Context Objects.
Regarding Test Case:
There is no standard template for this.....i would suggest check with peers in your company.....many a times companies have their own templates for test cases alongwith the possible cases....then referring to those test cases you can build the cases for your scenario. Avoid a direct copy of the test cases.....many wont be relevant for your case.
Regards,
Abhishek.

Interface mapping not visible in interface determination

Hi,
when i create Interface determination in ID i could see Message interface and i could not my Interface mapping in that.
It is saying no objects found.
when i select enhanced instead of standard i could see my Interface mapping
plz give some idea reg. this
Thanks

Hi,
Check if there is any Interface mapping available between the Outbound Message Interface name and Inbound Message Interface name which you are using in your Interface Determination. Check carefully.
Thanks
aMit

XPATH to determine node name in condition of Interface determination

Hi,
does anybody out there know whether one can use a condition such as "name(/p1:Envelop/p1:Body/*)" to retrieve the name of the first element underneath the Body structure which is usually the payload. In the example below. I'd like to retrieve "ns0:BAPI_USER_GET_DETAIL" or just "BAPI_USER_GET_DETAIL" which I would like to than compare in my "=" condition.
<?xml version="1.0" encoding="iso-8859-1"?>
<sap:Envelope xmlns:sap="urn:sap-com:document:sap" version="1.0">
<sap:Header xmlns:rfcprop="urn:sap-com:document:sap:rfc:properties">
    <saptr:From xmlns:saptr="urn:sap-com:document:sap:transport">BC1</saptr:From>
    <saptr:To xmlns:saptr="urn:sap-com:document:sap:transport">BC2</saptr:To>
</sap:Header>
<sap:Body>
     <ns0:BAPI_USER_GET_DETAIL xmlns:ns0="urn:sap-com:document:sap:rfc:functions">
      <CACHE_RESULTS/>
      <USERNAME>bauerd</USERNAME>
     </ns0:BAPI_USER_GET_DETAIL>
</sap:Body>
</sap:Envelope>
I have a client that once to migrate his SAP BC interfaces to PI without having to change the sending application which is a CICS mainframe application. The mainframe application invokes various BAPI's by just passing in a different payload into the above envelope. The payload is always the request structure for the BAPI. The message is send synchronously to SAP BC which than calls the BAPI and returns the response to the caller, again in form of the above envelope and as payload the BAPI response structure.
To convert this to PI I have to be able to initiate different interface mappings depending on what BAPI is requested. This is pretty straight forward as there are no special mapping transformation taking place in SAP BC for both the BAPI request and response. However I need to determine what interface mapping to call depending on BAPI requested by the CICS application.
As said the customer does not want to change the sending application. The only part we are allowed to change is the URL which changes from SAP BC to the SAP PI Plain HTTP sender adapter. The post will always use the same outbound message interface. Therefore I can't use SAP PI's standard receiver determination. Using this adapter I will also be able to get access to the whole message envelope as outlined above.
I already got all of this working nicely with the exception that I can't determine what BAPI is requested and therefore what interface mapping I have to trigger in my interface determination.
Has anybody used a condition as above and if so how should it look like in the condition editor. The one outlined above does not seem to work. However it is also not failing in PI.
Also I don't want to change my approach for doing this. However if it is not possible to retrieve the node name using the xpath statement (as outlined above) in the condtion editor than I will have to look for a different approach to resolve this problem. Any suggestions would than be more than welcome.
Many thanks in advance.
Dieter

If the structure is not too big, you can use:
//ns0:BAPI_USER_GET_DETAIL EX
otherwise take the full path:
/p1:Envelop/p1:Body/ns0:BAPI_USER_GET_DETAIL EX
The namespaces have to be declared.
Regards
Stefan

Interface mapping in Interface Determination??

Hi friends..
iam doing IDOC to File..
in message mapping ,i changed the occurance of IDOC to unbounded and did the same in interface mapping also..
but in intrerface determination i am not getting Interface mapping ,i tried Extended interface mapping also..
please suggest me..
thanks and regards
Ram

Hi,
MultiMapping will not work for IDoc's.You need to use Idoc packaging for this,
https://www.sdn.sap.com/irj/sdn/go/portal/prtroot/docs/library/uuid/877c0d53-0801-0010-3bb0-e38d5ecd352c
Is this what you have done?
Regards
Bhavesh

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

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

Standard Vs Extended Interface Determination

Similar Messages

Maybe you are looking for