Skip to Content

It was interesting when a fellow colleague came to me with what he deemed ‘weird happenings’ in the Development PI box (PI 7.11 SP08).

Here was a straightforward scenario. We pull a file, set it as an attachment and send it over an email. A mail package was used to form the Mail and the content of the email while a Java module did the trick of having both the content and attachment as part of the mail (for those who think it is not possible to have a meaningful email body with a properly named email attachment file, check out this comprehensive blog from madhav poosarla)

Everything was in place as it was supposed to be in place. But then it began to happen.

Every first time the scenario ran, it ended up in a mapping exception;

contentpro_16Aug2012_1.JPG

But what made it weird was that if you restarted the error message manually or it got restarted via the automatic restart, the scenario turned successful.

contentpro_16Aug2012_2.JPG

Now the mapping that created the mail package was definitely failing. But what could be the reason?

It was a simple mapping with all its input fields being constants and a couple of fields being parametrized to make it configurable. There was no way the mapping had issues. Obviously there couldn’t be an issues since on the restart of the same message without making any changes, the mapping ran successfully and thus the scenario execution being completed end to end.

It was then something totally crazy and unrelated came to my mind.

Earlier I had happened to read this Tips and Tricks blog from William Li . I wondered if a similar trick would help.

Even though we were not using ICO but the normal configuration scenario, we first tried with removing the SWCV reference from the Sender agreement.

contentpro_16Aug2012_3.JPG

Well, that didnt change any of the result.

Next we tried to remove the SWCV reference in the Receiver Determination;

contentpro_16Aug2012_4.JPG

Guess what, it worked. No more “Content not allowed in prolog” error. Every single time the scenario ran, it worked.

Now how and why does it work? Well, frankly, I got no clue. What do you think folks? Is the SWCV enforcing something during the runtime? If so then why does a restart of the error message end up successfully executing the message?


To report this post you need to login first.

16 Comments

You must be Logged on to comment or reply to a post.

  1. Praveen Gujjeti

    Really strange!!!! Thanks Shabarish for sharing this info. But one question, did you get a chance to compare complete traces (SOAP header) for mapping failure with the one which is success (after restart). This might give a clue what is wrong.

    – Praveen Gujjeti

    (0) 
  2. Baskar Gopalakrishnan

    Thanks for sharing this info. Yes, this is strange. We know that this error message shows if there is an invalid xml syntax in the message which is parsed by XML Parsers.

    >But what made it weird was that if you restarted the error message manually or it got restarted via the automatic restart, the scenario turned successful.

    Can you verify whether the message goes through xml validation step during manual restart?

    (0) 
  3. Stefan Grube

    PI tries to figure out the operation of the service interface.

    The operation is determined by the root tag name of the XML message. If there is no XML, you get an error message.

    Instead of doing the steps as you described, you can also set the service interface type to “xi 3.0 compatible” That means an interface cannot have several operations, so it need not be determined.

    I recoomend using “xi 3.0 compatible” service interface for any interface with one operation only, especially for any non-XMLmessage.

    (0) 
      1. Stefan Grube

        When you remove the SWCV from receiver determination, the operation will not be determined from payload, as the service interface cannot be interpreted.

        I do not know, how SAP PI determines the correct operation mapping, when it cannot determine the operation from message payload. This is not documented anywhere.

        (0) 
    1. nunu agarwal

      Hi Stefan

      can you pls explain your statement  a little more”That means an interface cannot have several operations, so it need not be determined”

      thanks

      (0) 
  4. Prabhu Veerasamy

    Hi Shabarish,

    I got the exact error as this and removed the SWCV from the sender agreement and receiver determination. Now i get the below error.

    The following variables cannot be resolved by any variable data source: “name”. Please check the spelling of each value’s prefix.<br>

    Message processing failed. Cause: com.sap.engine.interfaces.messaging.api.exception.MessagingException: Unable to clone File Adapter receiver channel for parallel processing


    Could you kindly help me with this?

    (0) 
  5. Rosa Maicon

    did not work for me…I am still getting the same error after remove the SWCV in Sender Agreement and Receiver Determination.

    Any idea how to fix? I am using PI 7.3

    (0) 
    1. Vikrant Singh

      I believe it happened as the XML was malformed had few extra invalid characters in front of the <?xml?> tag. I corrected the xml and the error disappeared.

      (0) 
  6. Sanjay Raskar

    Hi Vijay,

    I am getting same error. I have scenario to Get PDF file from FTP and dump Into SAP, where in FTP there are 3 folder and that 3 PDF file need to dumped in same receiver(SAP directory are diff) corresponding directory in AL11. I have created UDF to change directory but in mapping only this error is coming

    Runtime exception occurred during application mapping com/sap/xi/tf/_MM_File_to_File_; com.sap.aii.utilxi.misc.api.BaseRuntimeException:Content is not allowed in prolog“.

    I have done changes as per your suggestions and also checked many posts from SDN but no success, Can you please suggest more hints.

    Thanks in Advance.

    (0) 
  7. P R

    Hi Shabharish,

    I’m also facing the same problem what u have posted,and the remedy u said also i did.but facing the same problem.

    can anyone suggest the solution?

    Thanks,

    Prasad.

    (0) 

Leave a Reply