cancel
Showing results for 
Search instead for 
Did you mean: 

Sending back proxy inbound validation

Former Member
0 Kudos

Hi experts,

We have with one requirement here which I'm not sure if this is possible to attend. We have a SOAP x Proxy scenario, and when we sent a message with some invalid information (like one field which should have 3 characters, but are being sent with 5) and Proxy infrastructure are rejecting the message with the below error:

<?xml version="1.0" encoding="UTF-8" standalone="yes" ?>

- <!--  Inbound Message

  -->

- <SAP:Error xmlns:SAP="http://sap.com/xi/XI/Message/30" xmlns:SOAP="http://schemas.xmlsoap.org/soap/envelope/" SOAP:mustUnderstand="1">

  <SAP:Category>XIServer</SAP:Category>

  <SAP:Code area="INTERNAL">INCORRECT_PAYLOAD_DATA</SAP:Code>

  <SAP:P1 />

  <SAP:P2 />

  <SAP:P3 />

  <SAP:P4 />

  <SAP:AdditionalText />

  <SAP:Stack>Erro no processamento do payload de mensagem. Ocorreu um erro na deserialização em o programa ST /1SAI/SAS576C0498218C0ACE08E3. O comprimento de &quot;IP210000000000&quot; excede o comprimento máximo &quot;12&quot; permitido com tt:maxLength.</SAP:Stack>

  <SAP:Retry>M</SAP:Retry>

  </SAP:Error>

What we want to do is to catch the SAP:Stack message and return back to the client system. Is that possible?

I know that the best way to do that is using the message validation of SAP PI, but as its very difficult to maintain (xsd needs to be copied to file system), we're thinking here if we can propagate this SAP:Stack message to the client.

I really appreciate any help. Thanks.

Accepted Solutions (0)

Answers (3)

Answers (3)

ambrish_mishra
Active Contributor
0 Kudos

Hi Raphael,

Message validation in PI would again result in failure which is not an ideal design.

Coming back to your question, it is possible to configure a fault message and propagate the error message back to the sending system.

Having said that, ideally its a question of going back to design and checking that source field length should not be greater than target field length. If yes, there should be rules implemented at sender or in PI to trim the length for such fields.

Hope it helps.

Ambrish

former_member223322
Active Participant
0 Kudos

You can try using the fault message config. Refer the thread below.

http://scn.sap.com/thread/1495458

~Srini

Former Member
0 Kudos

Hello Raphael,

in case you haven't guessed, the answer is "no". Anyway, what would your client system do with this? Would they understand the meaning? Maybe it is technically possible, but not easier than placing an XSD on your file system and validating in PI. The location is not obvious to find, but I'm sure you can find an organisational solution to that (i.e. documenting it).

If this kind of error happens frequently you might want to block those messages before entering your systems, anyway.

Regards,

Jörg

Former Member
0 Kudos

Raphael, I couldn't have said it better than Jorg but in addition to that...

It's poor design to try and manage it this way (i.e. trying to route the stack back to the consumer). Ideally, this should be managed by the consumer - that's the reason you provide them with a WSDL. If they are still not adhering to the contract then stop it with validation in PI so that it doesn't have to use up any more system (and monitoring people) resources than is necessary...

The most important part, this fault stack isn't actually a full trace of all potential issues that the SOAP request could contain - it's the first one that was encountered. So it checks in sequence & triggers the deserialization error (i.e. field1 --> error, then field --> error etc.). So you could have the consumer resending a faulty message as many times as there are faulty fields. Again, additional overhead where it's really not needed...

Regards, Trevor