cancel
Showing results for 
Search instead for 
Did you mean: 

XML Validation and Sender ABAP Proxy

Former Member
0 Kudos

Hi,

I send a message from ECC 6.0 to PI 7.10 using an ABAP proxy.

I configured XML validation on the Integration Engine. This should validate the message that is send by ECC.

But when the message is sent in ECC the proxy adds a new namespace:

xmlns:prx="urn:sap.com:proxy:ECO:/1SAI/TAS1D17F6FED8FB7FDF31F2:701:2008/06/06"

This namespace is not in the XSD that I exported from PI and put in the filesystem for validation.

So the validation fails at this moment.

Does somebody have suggestions?

Ron

Accepted Solutions (0)

Answers (3)

Answers (3)

former_member181962
Active Contributor
0 Kudos

I don't think we can have xml validation for proxy scenarios.

Where did you chose the xml validation option? While creating which object?

Bascially, you generate the ABAp proxy based on the structure of the interface.So, all the imjporting and exporting parameters of the ABAp proxy class will be complying to the xsd definition. Hence it doesn't make any sense to validate the structure of the XML again.

More over, i just tried to use a XI adapter in a sender agreement.

I was not able to select any xml validation parameter.

Regards,

Ravi Kanth Talagana

Former Member
0 Kudos

Hi,

As far as I could find out enumerations and patterns are not checked in the proxy. So there is still a gap.

Ron

Former Member
0 Kudos

Ron,

I just openend one of client proxy scenarios and observed this as well. I am pretty sure, with PI 7.0 this was not happening.

Are you also seeing the the Message Header node with Sender/ Reciever part and Msg Guid parameters?

May be this is a new feature of PI 7.1, but I cant find any documentation on this.

Am interested on what is going to be your approach.

Thanks

Jai

former_member200962
Active Contributor
0 Kudos

Yes it is available from SAP PI7.1 and you can search with keywords XML Validation either on SDN or in help.

Regards,

Abhishek.

Former Member
0 Kudos

Hello Abhishek,

I am pretty much aware of the XSD validation feature of PI 7.1. Infact we are using it in almost all our scenarios.

I am(was) not aware of the new namespace and <Message header node> being added to the payload of proxy messages.

Thanks

former_member200962
Active Contributor
0 Kudos

ok....sorry for mis-understanding your post!

Former Member
0 Kudos

Hi

Because of this problem I'm thinking of validating the message in the Receiver Agreement in stead of Sender Agreement ...

Ron

Former Member
0 Kudos

>>I think it is very odd to have to change the message manually.

In fact, if you regenerate the proxy the GUID in the namespace changes ... so you have to do everythink all over again ....

not very nice.

Ron

Exactly!! Infact you need to modify it in every environment because the ECC system Id is part of the namespace.

Doesn't make much sense to me.

>>Because of this problem I'm thinking of validating the message in the Receiver Agreement in stead of Sender Agreement ...

That is an option although not the ideal solution.

Regards

Jai

former_member200962
Active Contributor
0 Kudos

Keep the structure same as you receive from source system....manually edit the XSD and add the namespace or other attributes as you can see in the source message.

For XMl validation to be done we have to mention it in Sender Agreement (for incoming message), for PROXY we dont create a Sender Channel and hence no Agreement.....where did you mentioned that the validation has to take place?

Regards,

Abhishek.

Former Member
0 Kudos

Hi Abishek,

It's correct that a Sender Agreement is not necessary for the interface to run without errors. But you still can create them. (when you generate a scenarion they are also created automatically). In the Sender Agreement I have chosen the Validition in the Integration Engine.

I think it is very odd to have to change the message manually.

In fact, if you regenerate the proxy the GUID in the namespace changes ... so you have to do everythink all over again ....

not very nice.

Ron