Interface (un)determination

Hi gurus,
I have a straight-forward scenario, where SAP sends proxy with interface INT_OUT, and a non-SAP system receives it via SOAP with interface INT_IN.
I noticed the problem when I saw in SXMB_MONI that PI thinks it is from INT_OUT to INT_OUT. It does not show it as from INT_OUT to INT_IN. More awkward, adapter engine thinks it is from INT_IN to INT_OUT. Restarting / clearing the caches did not help.
When I do the testing from Directory, the determination is correct. Also, when I look at the trace in SXMB_MONI, the interface is determined correclty. BUT,when it comes to the pipeline step Call Adapter, the sender and receiver interfaces swith places, INT_IN becomes the sender and INT_OUT becames the receiver. This is the same in the "Response" pipeline step, which is the last step.
I have checked the Integration & Adapter Engine caches from RWB and they are correct.
What is responsibility of "Call Adapter" pipeline step in IE? And what can be the reason of this overall faulty behavior?
Thanks in advance.
Regards,
Gökhan

Delete your config objects and create them again...
Hope u know that the outbound/inbound perspective changes when ur using the Config wizard..
For e.g. when u start the wizard...u will be asked to provide the outbound interface ...mention the sender and for the inbound interface provide the receiver...
we usually speak of outbound and inbound based on external system whereas in Pi config ..it is with repect to the Pi system...
regards,
Arvind R

Similar Messages

Unable to find the Message Interface Receiver Determination

Hi Everyone,
I am unable to find the Message Interface Receiver Determination in the SAP BASIS 7.0 --> http://sap.com/xi/XI/System. in IR.
I am using P.I 7.0 SP 15
Could anyone let me know what could be the problem.
Regards,
Varun

Hi Sridhar,
I cant find the Message Interface Receiver Determination in IR under the standard SWCV SAP BASIS 7.0 and under the namespace http://sap.com/xi/XI/System. in IR.This Message Interface will be useful while configuring in enhanced Receiver Determination.
http://help.sap.com/saphelp_nw2004s/helpdata/EN/84/e8763c997fda50e10000000a11405a/frameset.htm
Regards,
Varun

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 & 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 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
enhanced interface determination
/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

ENHANCED INTERFACE AND RECEIVER DETERMINATION

1)what is the use of enhanced interface determination and enhanced receiver determination and in scenarios we will use them and in what conditions ,and what differentiates it from standard interface/reciever determination?

1. Standard receiver determination to specify the receivers of the message (and optionally routing conditions) manually.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
1.2You 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).
Enhanced receiver determination to have a mapping program determine the receivers of the message dynamically at runtimeInstead 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.
2.Standard Interface Determination :You can specify to which inbound interface 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.
2.1 n 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 receiver determination try this link also
http://help.sap.com/saphelp_nw70/helpdata/en/43/a5f2066340332de10000000a11466f/frameset.htm
Regards,
Mandeep Virk
*Reward if Helpful*

IDOC - BPM - IDOC Error --no sender or receiver interface definition found

I have an integration scenario, IDOC - BPM - IDOC. SAP will send ACC_GL_POSTING IDOC to XI, a BPM will start and then the BPM will send an IDOC to another SAP system.
I have read instructions on weblogs:
/people/pooja.pandey/blog/2005/07/27/idocs-multiple-types-collection-in-bpm
/people/krishna.moorthyp/blog/2005/06/09/walkthrough-with-bpm
The scenario has been successfully tested in the Test Configuration Tool. However, when I try send IDOC from the source, I received the message below in the trace.
<Trace level="1" type="B" name="CL_XMS_PLSRV_CALL_BPE-ENTER_PLSRV">
<Trace level="3" type="T">Processing mode is</Trace>
<Trace level="3" type="T">created BPE proxy for message B45CB0079DFA814BAD22CD1ED64CA6AB</Trace>
<Trace level="1" type="B" name="interface activity determination">
<Trace level="1" type="T">Version 000</Trace>
<Trace level="1" type="T">Message status 000</Trace>
<Trace level="1" type="T">Interface action INIT</Trace>
<Trace level="1" type="T">(must be INIT for a new determination)</Trace>
<Trace level="1" type="T">start CHECK_INTERFACE</Trace>
<Trace level="1" type="T">--start sender interface action determination</Trace>
<Trace level="1" type="T">select interface ACC_GL_POSTING.ACC_GL_POSTING01*</Trace>
<Trace level="1" type="T">select interface namespace urn:sap-com:document:sap:idoc:messages</Trace>
<Trace level="1" type="T">no interface found</Trace>
<Trace level="1" type="T">--start receiver interface action determination</Trace>
<Trace level="1" type="T">Loop 0000000001</Trace>
<Trace level="1" type="T">select interface ACC_GL_POSTING_abs*</Trace>
<Trace level="1" type="T">select interface namespace http://summaryFinancial.sap.dominofoods.com</Trace>
<Trace level="1" type="T">no interface found</Trace>
<Trace level="1" type="T">--no sender or receiver interface definition found</Trace>
<Trace level="1" type="T">Hence set action to DEL</Trace>
<Trace level="1" type="T">end CHECK_INTERFACE</Trace>
<Trace level="1" type="T">Set interface action DEL into MAST</Trace>
</Trace>
<Trace level="1" type="B" name="CL_IDX_IDOC_RESOURCE-GETBLOBDATA" />
<Trace level="3" type="T">inserted message into pipeline PE_ADAPTER</Trace>
<Trace level="1" type="Timestamp">2007-04-30T18:32:30Z EST qRFC raised on XBQO$PE_WS91000003</Trace>
</Trace>
Thanks,
Sergio

Rajeev,
The source system in the receiver determination is connected to R3. Other IDOCs are coming across the XI system.
Below is some trace information in the Receiver Determination.
<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="2" type="T">...valid Receiver w/o Condition: - IP_GeneralLedger</Trace>
<Trace level="2" type="T">No Receiver found behaviour: 0</Trace>
<Trace level="2" type="T">Number of Receivers:1</Trace>
<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) IP_GeneralLedger ACC_GL_POSTING_abs</Trace>
<Trace level="2" type="T">...valid InbIf without Condition: ACC_GL_POSTING_abs</Trace>
<Trace level="2" type="T">Number of receiving Interfaces:1</Trace>
Thanks,
Sergio

PI 7.1 - condition during receiver determination

Hi,
I am trying to do the receiver determination condition in the condition editor of integration directory but XPATH or context objects of my interface (corresponding to my software component version) do not appear in the window for maintaining the condition.
I had no difficulty when following the same process during 7.0 or earlier versions but it seems to be issue in PI 7.1.
Anyone else also faced a similar situation or is there any extra step I need to ensure before going for receiver determination (standard not enhanced)?
Your help would be appreciated.
Cheers.

My scenario is:
Source system -> PI (ccBPM) -> Target system
Now I have number of ccBPMs and there would be one picked up based on the payload from source system interface. For this my configuration objects are as follows:
Sender agreement with (source comm component and source system outbound interface)
Receiver determination - at this stage I want to figure out which ccBPM should get executed and hence condition based on payload
interface determination - goes to receiver step of ccBPM with message type same as outbound interface from source system
I have another receiver determination, interface determination for target system interfaces from ccBPM and then receiver agreement.
But in this overall scenario key part is first receiver determination step where ccBPM as receiver is to be determined.
I checked up all my objects again to find out any missing gap from my understanding. But I am not able to get the interface (source system interface) in the condition editor. I tried maintaining the XPATH manually but it ends in error during execution suggesting that receiver could not be determined.
Any more suggestions please?

Interface mapping Object _Doesn't exist in RuntimeCache_Error_SXMB_MONI

Hi EXperts ,
Issue in XI --Dev System
I have an simple IDOC (DESADV.DELVRY03) ->Flat File Scenario . Mapping is done as per the Line of Business requirements .
I have tested mapping and I get the response as expected.
We released the IDOC (Outbound Processing ) in SAP R/3 , but I get the mapping error in SXMB_MONI.
Error:
SAP:Category>XIServer</SAP:Category>
<SAP:Code area="MAPPING">NO_MAPPINGPROGRAM_FOUND</SAP:Code>
<SAP:P1>Object ID 61CFAE955F1A345ABEA3081C92818052 Software Component C31B3EB0F7B811DFC3F3ECDD0AE005A3</SAP:P1>
<SAP:P2 />
<SAP:P3 />
<SAP:P4 />
<SAP:AdditionalText />
<SAP:ApplicationFaultMessage namespace="" />
<SAP:Stack>Interface mapping Object ID 61CFAE955F1A345ABEA3081C92818052 Software Component C31B3EB0F7B811DFC3F3ECDD0AE005A3 does not exist in runtime cache</SAP:Stack>
Activtaed the Interfcae mapping and refeshed the configurtaion Object : Interface , Receiver Determination.Noticed that we have error in Cache Notifictaion --Design Part . The Configuration --Cache update is fine.
I have raised the Ticket to resolve this error.
But as this was high proirity task to be delivered,how can i try fixing this issue myself . I have tried couple of times, creating new interface mapping , activating , referring new interface mapping in : Interface , Reciever Determination but nothing fix this issue.
Please provide me inputs.
Thanks,
Vara

Thanks to all of your for your support .
Yes as Udo said , I did reassign the Interface mapping in : Interface Determintaion / Reciever Determination and activated .
Buta s this isuse was in Development System , and I reliased that there was mismatch of Password entered for : PIAPPLUSER --pipeline user and Cache Error with SLD in Design . Configurtaion / SLD .
Raised ticket for Cache Error which got solved . Resetting password of PI service user also worked .
Release new IDOC in WE19(--outbound DESADV.DELVRY03) and it was successfully processed to File(xml).
Best Regards,
Varalakshmi

File-file,no interface found error

Hi, I am doing a simple file-file scenario testing. Following is the log from message monitor... Please let me know what other info you would need to help me the issue. Thank you
<Trace level="1" type="T">select interface MI_Motorola*</Trace>
<Trace level="1" type="T">select interface namespace http://www.motorola.com</Trace>
<Trace level="1" type="T">no interface found</Trace>
<Trace level="1" type="T">--start receiver interface action determination</Trace>
<Trace level="1" type="T">Loop 0000000001</Trace>
<Trace level="1" type="T">select interface MI_SSPRINT*</Trace>
<Trace level="1" type="T">select interface namespace http://www.sprint.com</Trace>
<Trace level="1" type="T">no interface found</Trace>
<Trace level="1" type="T">--no sender or receiver interface definition found</Trace>
<Trace level="1" type="T">Hence set action to DEL</Trace>
<Trace level="1" type="T">end CHECK_INTERFACE</Trace>

Hi Satish,
I just tested the scenario from ID. I have checked the log. Please find it below and let me know next step...
sender agreement not found
<Trace level="1" type="B">SENDER AGREEMENT SIMULATION</Trace> <Trace level="1" type="T">Simulating Adapter Engine...</Trace> <Trace level="1" type="T">Simply trying to loolup for the most specific Sender Agreement object</Trace> <Trace level="1" type="T">no objects found</Trace> <Trace level="1" type="T">Note that real results may differ</Trace>
I did double check sender agreement object which looks good.

No interface found

Hello,
I am trying to send file to idoc. I get the following error.
Trace level="3" type="T">Persisting message Status = 001</Trace>
<Trace level="3" type="T">Message version 000</Trace>
<Trace level="3" type="T">Pipeline CENTRAL</Trace>
<Trace level="1" type="T">--start sender interface action determination</Trace>
<Trace level="1" type="T">select interface MI_Material_Async_Out_9*</Trace>
<Trace level="1" type="T">select interface namespace http://dsouza.com</Trace>
<Trace level="1" type="T">no interface found</Trace>
<Trace level="1" type="T">--start receiver interface action determination</Trace>
<Trace level="1" type="T">Loop 0000000001</Trace>
<Trace level="1" type="T">select interface *</Trace>
<Trace level="1" type="T">select interface namespace</Trace>
<Trace level="1" type="T">no interface found</Trace>
<Trace level="1" type="T">--no sender or receiver interface definition found</Trace>
<Trace level="1" type="T">Hence set action to DEL</Trace>
- <Trace level="1" type="B" name="CL_XMS_MAIN-PERSIST_READ_MESSAGE">
<Trace level="3" type="T">Trace object available again now. OK.</Trace>
I have done the following.
1. CPA Cache refresh and all available cache refresh.
2. Test configuration - with payload and everything is green checked.
I have substantial time in searching sdn and unable to figure out the problem. Could you please help me.
Thank you.
William

Hi WILLIAM DSOUZA ,
In our production support we face same issue frequently, follow these steps which we follow to trace the error and solve that:-
1) In transaction SXMB_MONI in the very right of your message select your message then right click and copy all details of your message on a notepad
2) go to integration directory , click on the search button situated in the above left pan, then in the search window in the drop down meenu select interface determination, as you will select interface determination then in the bottom down window fillup the entries like sender service interface and receiver service and click on the button find
it will search your receiver determination click on the interface determination a new window will open, there you can find in the interface determination that is any condition? check that condition in your message payload and you will get the eroor
generally found errors in this case are as follows
a)when you will fill sender and receiver details in the receiver determination serach window then search comes with result that "No Interface found"
in that case you remove the receiver details and again search with only sender details then you will find what is the receiver service configured for this sender service. in case different receiver service is configured for this sender match it with your configured scenario
b) second error comes when you have given some condition on any tag for receiver determination and your payload is not satisfying that condition then it will give you no receiver error. then edit your payload and restart it again (for quality of service EO or EOIO)
Hope it may solve your problem
Thanks
Sandeep sharma
PS: if helpful reward points

RFC to BPM - Error in receiver interface

Hi everybody,
I have created the scenario below.
i imported the ZStart_Job rfc from R/3
i created the MI_Start_Abs (abstract and async) - message type is same from ZStart_Job
i created the BPM_Job where the send interface is MI_Start_Abs.
i configured the sender and receiver agrameent, receiver and interface determination and others.
i actived everything.
When i execute the "call function ZStart_Job", the execution dosent return error in Message Monitoring, but appears one green flag with hit "Scheduled".
In XML body show the error below
<Trace level="1" type="T">--start receiver interface action determination</Trace>
<Trace level="1" type="T">Loop 0000000001</Trace>
<Trace level="1" type="T">select interface</Trace>
<Trace level="1" type="T">select interface namespace</Trace>
<Trace level="1" type="T">--no sender or receiver interface definition found</Trace>
<Trace level="1" type="T">Hence set action to DEL</Trace>
Can anybody help me?

Guys,
I used the Configuration Wizard for create configuration again.
But occurs the same error below
<Trace level="1" type="T">--start receiver interface action determination</Trace>
<Trace level="1" type="T">Loop 0000000001</Trace>
<Trace level="1" type="T">select interface</Trace>
<Trace level="1" type="T">select interface namespace</Trace>
<Trace level="1" type="T">--no sender or receiver interface definition found</Trace>
<Trace level="1" type="T">Hence set action to DEL</Trace>
PLEASE, can anybody helpe me?

Receiver determination based on target msg???

Hi All,
Is it possible to do a receiver determination based on some field present in target msg. I know I can do the same if the field is present in source msg with the condition editor in receiver determination. But this will not help my scenario. I need to find the receiver based on a field in target msg. Is it possible?? If so, can u pls explain it???
Thanks & Regards,
Jai Shankar.

Jai,
Am on Sp14 and have not had the chance to try it out.
but, I dont think you will need a extra Receiver Determination for the Enhanced Receiver Determination.
What I understood out of that blog was that the Interface mapping between Source Interface and Receiver Interface will determine the receiver. So, you fill in the reciver service field with the actual receiver and this value will be taken as the receiver.
The Receiver Interface will be taken from the SAP basis SWCV.
http://help.sap.com/saphelp_nw04/helpdata/en/43/a5f2066340332de10000000a11466f/frameset.htm
Regards,
Bhavesh
Regards,
Bhavesh

IDoc - IDoc interfacing with multiple mappings

Hi,
We want to use two different mappings for the same IDoc interface (based on a condition). So we use the ORDERS idoc for a sales scenario and also for a purchase scenario. The sending service is the same for both ORDERS messages, lets call it service SEND. Furthermore, for both ORDERS messages, the receiving service is also the same lets call it RECV.
The problem is that we want to use a different mapping for the ORDERS sales scenario as for the ORDERS purchase scenario. The sending and receiving interface in both cases is the same.
The receiver determination and interface/mapping determination is a problem in this case.
One way to solve this is to use a party, but in the configuration of the party you can only use the same sending logical system name ONCE. So party A cannot have the same logical system name (SEND) as party B (SEND) for scheme ALE#LS.
Another way would be to use different services, one for the first scenario and mapping and one for the second. Again the problem is that you need to enter adapter settings for both services (RECV1 and RECV2), but a logical system name can only be used in ONE service. If you want to assgin it to a second service, this is not allowed.
Does anybody have a solution for this?
thanks !

Hi Alexander,
why don't you try doing it in one BPM?
something like this:
one sender
one receiver
2 mapping programs
Receive step -> Swich Step - if PO go to Transformation step one (mapping 1), else go to Transformation step two (mapping for the SO) - Send Step?
you can base you swith step on E1EDK14 segment qualifier = 013
(As far as I remamber only Purches orders have it)
but check it:)
BTW
if you use the Swith Step you probably want to use a Transformation step before the Swith step (mapping from ORDERS to dummy message with one TAG - indication if this is PO or SO based on content of the ORDERS) this way the swich step will work for sure
Regards,
michal
Message was edited by: Michal Krawczyk

Determining the Directories based on a condition to poll the file

Hi All,
I have One requirement, that i want to poll the file in the target directory based on the following condition.
1) If name1 = "ABC" the file should go to //xi/test/file1.xml
2) If name1= "XYZ" the file should go to //xi/develop/file2.xml
How can i Achieve this requirement.
Regards
Bopanna

How many Message Interfaces have to create
3 One sender one each for 2 receivers
howmany interface mappings have to create
2
howmany cc's have to create
3 - 1 sender 2 receiver
howmany Sender & Receiver agreements have to create
3 - 1 sender 2 receiver
howmany interface & Receiver determinations have to create
1 receiver determination
2 interface determination
Regards,
Prateek

Interface (un)determination

Similar Messages

Maybe you are looking for