cancel
Showing results for 
Search instead for 
Did you mean: 

PI XI to SFTP with XSD definitions and no namespace

Former Member
0 Kudos

Hello all,

I am working with the following scenario:

Sender: SAP ECC / R3 system

Receiver: external 3rd party

Interface type - asynchronous

Adapters - XI sender to SFTP receiver

Message type is an XSD definition created by me, and used in the interface definitions on inbound and outbound side. The xsd looks like this:

?xml version="1.0" encoding="utf-8" ? 
xs:schema xmlns:xs="http://www.w3.org/2001/XMLSchema"
   xs:element name="ReconciliationResponse"
      xs:complexType
         xs:sequence
            xs:element name="ReconciliationResponseDateTime" type="xs:string" /
            xs:element name="ReconciliationGUID" type="xs:string" /
            xs:element name="MissingDocuments"
               xs:complexType
                  xs:sequence
                     xs:element name="DocumentID" type="xs:string" minOccurs="0"  maxOccurs="unbounded" /
                  /xs:sequence
               /xs:complexType
            /xs:element
         /xs:sequence
      /xs:complexType
   /xs:element
/xs:schema

I created this xsd rather than using a data type & message type configuration because the receiver (3rd party) requires the XML in this format without any namespace reference. I had tried it that way first but the anonymizer bean didn't fully remove all of the namespace reference.

All the integration builder side configuration has been done via the config wizard and seems correct.

However, when I try to run the interface, it succeeds on the ECC sender side but fails when it gets to PI with error no standard agreement found. With a 'test configuration', I don't get much more, but it really seems to be failing on the interface determination:

Sender Agreement Not found

Trace level="1" type="B"SENDER AGREEMENT SIMULATION
/Trace... (5 lines) 

Receiver Determination: | NNN_041 | SI_InvoiceReconResponse_Out

Trace level="1" type="B"CL_RD_PLSRV-ENTER_PLSRV/Trace... (12 lines) 

Interface Determination Not found

Trace level="1" type="B"CL_ID_PLSRV-ENTER_PLSRV/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="1" type="T"...There is no Interface Determination configured for receiver party 3RDPARTY and receiver service ZBSER_3RDPARTY /Trace 
Trace level="2" type="T"Check conditions for (Inb: Party Srvc If) 3RDPARTY ZBSER_3RDPARTY SI_InvoiceReconResponse_Out /Trace 
Trace level="2" type="T"...valid InbIf without Condition: SI_InvoiceReconResponse_Out /Trace 
Trace level="2" type="T"Number of receiving Interfaces:1 /Trace 
Trace level="1" type="E"CL_ID_PLSRV-ENTER_PLSRV/Trace

Operation Mapping Not found

Trace level="1" type="B"CL_MAPPING_XMS_PLSRV3-ENTER_PLSRV/Trace 
Trace level="2" type="T"......attachment XI_Context not found /Trace 
Trace level="3" type="T"Mapping already defined in interface determination /Trace 
Trace level="1" type="T"No mapping configured /Trace 
Trace level="1" type="E"CL_MAPPING_XMS_PLSRV3-ENTER_PLSRV/Trace

Receiver Agreement Not found

Runtime error: Problem occurred in receiver agreement for sender -NNN_041 to receiver 3RDPARTY-ZBSER_3RDPARTY,urn:xxx.xx.xx:P2P.SI_InvoiceReconResponse_Out: No standard agreement found for , NNN_041, 3RDPARTY, ZBSER_3RDPARTY, urn:xxx.xx.xx:P2P, SI_InvoiceReconResponse_Out
 Trace level="1" type="B"CL_XMS_PLSRV_OUTBINDING-ENTER_PLSRV/Trace 
Trace level="2" type="T"O U T B O U N D - B I N D I N G /Trace 
Trace level="2" type="T" Cache Content is up to date /Trace 
Trace level="2" type="T"determine OUTBOUND BINDING for: /Trace 
Trace level="2" type="T"-NNN_041 /Trace 
Trace level="2" type="T"3RDPARTY-ZBSER_3RDPARTY /Trace 
Trace level="2" type="T"urn:xxx.xx.xx:P2P.SI_InvoiceReconResponse_Out /Trace 
Trace level="1" type="T"error with outbound binding. /Trace 
Trace level="1" type="T"No standard agreement found for , NNN_041, 3RDPARTY, 3RDPARTY, urn:xxx.xx.xx:P2P, SI_InvoiceReconResponse_Out /Trace 
Trace level="1" type="E"CL_XMS_PLSRV_OUTBINDING-ENTER_PLSRV/Trace

The payloads on both ECC and PI for this look exactly the same.

I also have the reverse scenario of SFTP sender to XI receiver from this same 3rd party and use a similar XSD setup and that all works fine.

The message needs to look like this at the 3rd party receiving side:

?xml version="1.0" encoding="utf-8" ? 
 ReconciliationResponse
     ReconciliationResponseDateTime2012-01-18T09:18:36/ReconciliationResponseDateTime 
     ReconciliationGUID0af4d090-1215-4728-a178-8675g5f1450e/ReconciliationGUID 
     MissingDocuments
        DocumentID0100000158/DocumentID 
     /MissingDocuments
  /ReconciliationResponse

Any suggestions of how to send this message in the required format would be welcomed.

Best regards,

Christine

Accepted Solutions (1)

Accepted Solutions (1)

markangelo_dihiansan
Active Contributor
0 Kudos

Hello,

I created this xsd rather than using a data type & message type configuration because the receiver (3rd party) requires the XML in this format without any namespace reference. I had tried it that way first but the anonymizer bean didn't fully remove all of the namespace reference.

You can actually remove the XML namespace by deleting its entry in the message type as shown in this blog

Receiver Determination: | NNN_041 | SI_InvoiceReconResponse_Out

Trace level="1" type="B"CL_RD_PLSRV-ENTER_PLSRV/Trace... (12 lines)

In receiver determination, have you checked virtual receiver option(since you are using party)?How are you sending from ECC to PI, is it using the XI Adapter (no sender agreement required) or using SOAP Adapter using XI Protocol (this needs a sender agreement)?

Hope this helps,

Mark

Former Member
0 Kudos

Thanks to you both for your replies.

I have checked my spelling (actually the config wizard's spelling!) many times now. I can't spot any problems there.

As for whether my receiver agreement is generic enough, I'm not 100% sure - I used the config wizard and it created it. It has a sender communication component (our ECC system), and all the receiver fields are filled: communication party = 3rd party, communication component = 3rd party business system, interface = SI defined on the receiver side, namespace = SI namespace. Receiver comm channel = my SFTP receiver channel.

<You can actually remove the XML namespace by deleting its entry in the message type as shown in this blog>

I had already tried this but it does not completely remove all references as I need it to - it leaves just a little bit in there: <ReconciliationResponse xmlns="urn:xxx.xx.xx:P2P"> when I need it to be just <ReconciliationResponse>

<In receiver determination, have you checked virtual receiver option(since you are using party)?How are you sending from ECC to PI, is it using the XI Adapter (no sender agreement required) or using SOAP Adapter using XI Protocol (this needs a sender agreement)?>

I cannot see any option for virtual reciever in my receiver determination. I am sending ECC to PI via the XI Adapter (then from PI to the third party via SFTP).

Any other ideas would be welcome.

Former Member
0 Kudos

Hi Christine,

Is the sender interface name the same as the receiver interface name ?

If not, do you have an interface determination where the receiver interface is specified (even though it is without a mapping) ?

Horia

Former Member
0 Kudos

Hello Horia,

My sender interface name is not the same as my receiver interface name. I do have an interface determination, where the sender interface is defined (with the right name) and the receiver interface is also defined (with the right name). I also have an operational mapping in the interface determination which calls a R3_ABAP class to dynamically set the file name value on the receiver side.

However, both of the service interfaces have the same operation name, which was done in case that was causing my problem (it didn't help).

Christine

Former Member
0 Kudos

Hi Christine,

This is really strange. And I assume that if you look in sxi_monitor at the message and compare the information in there with the information in the interface determination then everything matches out (sender party, sender service, sender interface, sender interface namespace and the respective receiver info).

If that's also the case I would think it is a caching problem. What I would recommend is change the description for the interface determination and receiver agreement, activate them again and then check that the cache notifications went fine. You can see

that in the tools menu I think.

I hope this helps,

Horia

Answers (2)

Answers (2)

Former Member
0 Kudos

My thanks to those who replied and tried to help - I have awarded points to all.

The problem I was having has suddenly vanished on its own and this web service started working without errors this morning.

I can only guess that this was due to the fact that we just patched our PI system from 7.0 sp 4 to 7.0 sp 8. During this our PI system was built new from scratch. So it was either the patching, the rebuilt system or simply the complete cache refresh that fixed things.

I had read in other threads that this particular error can occur due to cache problems on PI.

Former Member
0 Kudos

Hi Christine,

Please check your scenario again. The error message could come from the missing interface determination or from the missing receiver agreement. Check that the spelling of the interface in the interface determination is the same as the one in the receiver agreement. Or that the receiver agreement is generic enough.