PI 7.3 Idoc Receiver Control Record does not match IDocXML root tag

[mike_radcliff]

Hi,

We are currently trying to get an File to IDOC scenario to work in PI7.3, EHP1 . We are set up as a JAVA Single Stack and using the IDOC_AAE adapter. We can receive IDOCS into PI 7.3 from our SAPECC Development system, but cannot successful send an Idoc to the ECC system.

The message we get is:

Transmitting the message to endpoint <local> using connection File_http://sap.com/xi/XI/System failed, due to: com.sap.engine.interfaces.messaging.api.exception.MessagingException: com.sap.conn.idoc.IDocParseException: (7) IDOC_ERROR_PARSE_FAILURE: IDoc type "ORDERS05" within the control record does not match IDocXML root tag <ZSPLORD5>:
state=READING_ENDTAG, charPosition=402, lineNumber=1, columnNumber=403

We are using a Stylesheet for mapping to the ORDERS05 Idoc. The Idoc has been extended/modified in SAPECC, so the CIMTYPE is "ZSPLORD5".

The Extended Idoc was Imported in from our DEV system, and it appears correct under Imported Objects.

The Name of the IDOC is "ORDERS.ORDERS05.ZSPLORD5", some of the layout is as follows:

Name                 Category            Type

ZSPLORD5           Element

   IDOC                 Element           ORDERS.ORDERS05.ZSPLORD5

       BEGIN           attribute           xsd:string

   EDI_DC40          Element           EDI_DC40.ORDERS.ORDERS05.ZSPLORD5

       SEGMENT     attribute           xsd:string

       TABNAME     element           xsd:string

other control record fields, then the data fields

The Stylesheet writes out the following when i use a test tool.

We do not populate the Control record because we need that determined at Runtime by the system.

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

<ZSPLORD5>

<IDOC BEGIN="1">

<E1EDK01 SEGMENT="1">

<BSTZD>7</BSTZD>

<VSART>TR</VSART>

<RECIPNT_NO>0000000171</RECIPNT_NO>

<LIFSK>01</LIFSK>

</E1EDK01>

<E1EDK14 SEGMENT="1">

<QUALF>012</QUALF>

<ORGID>ZSO</ORGID>

</E1EDK14>

<E1EDKA1 SEGMENT="1">

<PARVW>WE</PARVW>

<PARTN>0000000171</PARTN>

</E1EDKA1>

<E1EDK02 SEGMENT="1">

<QUALF>001</QUALF>

<BELNR>01710149</BELNR>

</E1EDK02>

<E1EDP01 SEGMENT="1">

<PSTYP>0</PSTYP>

<MENGE>9</MENGE>

<ROUTE>CUST</ROUTE>

<ZE1EDPB SEGMENT="1">

<ZZSOCRE_DT>20080918</ZZSOCRE_DT>

</ZE1EDPB>

<E1EDP19 SEGMENT="1">

<QUALF>003</QUALF>

<IDTNR>400044917188</IDTNR>

</E1EDP19>

</E1EDP01>

</IDOC>

</ZSPLORD5>

Our Communication Channel is set up to be a receiver, with adapter type IDoc_AAE, SAP BASIS 7.31, Transport Protocol is tRFC, Message Protocol is Idoc XML, Adapter Engine is Central Adapter Engine. RFC Client Parameters is Default(Recommended) , Destination is XI_IDOC_DEFAULT_DESTINATION. Interface Version is "Interface Version 4.0 or above", SAP Release is 701 (the receiving ECC system is still 701) and Queue Processing is checked on. Optional Metadata Parameters does NOT have the External Metadata Required box checked. Under Advanced, the Status is Active, Control Record in IDoc XML is "Not Mandatory" and the other check boxes to override the control record fields are all turned OFF/Unchecked.

My Business System has the Adapter-Specific Identifier set to our ECC System. The Logical System, System ID and Client are all set properly.

Any ideas on why I am getting this error?

In the PI 7.3 Java Single stack, I cannot find the Idoc Metadata (IDX2 transaction on a Dual Stack system).

Any ideas on how to see the Metadata on a Java Single stack system?

Regards,

Mike

[marksmyth · Accepted solution]

Hello Mike,

A fix is currently being prepared for this error. Please check note #1736292 Idoc_error_parse_failure Java IDoc_AAE. When the fix has been released, you will be able to access the note. It could take a week or more for the fix to be released.

The error was due to a missing IDoc type in the IDoc XML's tag <IDOCTYP>. If the <IDOCTYP> contains an empty value then during the parsing of the IDoc xml you will encounter the parse error.

Regards

Mark

[mike_radcliff · Accepted solution]

Hello Mark,

Thanks for the response.

I still have a question on this. Per Michal's suggestion, I tested it WITH the IDOCTYP tag populated in the payload and it still failed.

Where does this empty value happen?

I populated it in the payload. Did it drop the value before sending it on and fail to move it through?

Do you know if that is the issue?

If so, wouldn't this happen with everyone's Outbound Idoc's?

Or do I have some other flag/field/service set up incorrectly??

Thanks again for your time,

Mike

[mike_radcliff · Accepted solution]

Hello Mark,

Thanks for the Note Number. I have been watching patiently for it to be released.

Do you know if the issue is for every JAVA Stack idoc receiver?

I populated the IDOCTYP in the test I did for Michal and it still gave the same error, so it was not blank in my test.

Does that mean that with the release 7.3, ehp1 Java Stack Idoc adapter will not work for ANY idocs as a Receiver? If it does work, then I am missing something when I did the test for Michal.

Thanks again for your help.

Mike

[marksmyth · Accepted solution]

Hi Mike,

Sorry, I don't know much more about how the error occurs etc. As I understand it the fixes for this have already been released although we are still waiting for the note to be released. The fixes are available in the following patches:

XI ADAPTER FRAMEWORK 7.31 SP003 4

XI ADAPTER FRAMEWORK 7.31 SP004 1

XI ADAPTER FRAMEWORK 7.31 SP005 0

Try deploying whichever patch corresponds to your current SP release and this should resolve the error for you.

Regards

Mark

[mike_radcliff · Accepted solution]

Hi Mark,

We successfully applied note 1736292.

We were still getting errors. So we then set the persistance property on the JavaIdocAdapter Resource Adapter to be false. We then saved it and the IDOCS successfully were sent to the ECC system.

We then set the persistance property back to true, and we are now getting the following errors.

IDoc: Sender Party:   Sender Service: BS_CORP_POS_STORE_D  Receiver Party:   Receiver Service: BS_CORP_SAPECC_DV2_150  Communication Channel: BS_CORP_SAPECC_IDoc_Receiver

IDoc: SQLException before sending : com.sap.sql.log.OpenSQLException: Failed to set the parameter 12 of the statement >>INSERT INTO XI_IDOC_OUT_MSG ( IDOC_NUMBER , XI_MSG_NO , REF_NUMBER , ORIGINAL_IDOC_NO , IN_TIME , MESSAGING_TYPE , IDOC_TYPE , CIM_TYPE , SEND_PORT , SEND_PRTNR_NO , SEND_PRTNR_TYPE , CLIENT , STATUS , CONTROL_RECORD , CHANNEL_ID , ACK_NEEDED , ACK_RECEIVED , ARCHIVE ) values ( ?,?,?,?,?,?,?,?,?,?,?,?,?,?,?,?,?,? ) <<: Cannot assign an empty string to a parameter with JDBC type

>>VARCHAR<<

IDoc: Error before sending : Exception com.sap.aii.af.idoc.exception.IDOCAdapterException

IDoc: Error while processing the received messagecom.sap.aii.af.lib.mp.module.ModuleException

MP: exception caught with cause com.sap.aii.af.idoc.exception.IDOCAdapterException

Exception caught by adapter framework: Failed to set the parameter 12 of the statement >>INSERT INTO XI_IDOC_OUT_MSG ( IDOC_NUMBER , XI_MSG_NO , REF_NUMBER , ORIGINAL_IDOC_NO , IN_TIME , MESSAGING_TYPE , IDOC_TYPE , CIM_TYPE , SEND_PORT , SEND_PRTNR_NO , SEND_PRTNR_TYPE , CLIENT , STATUS , CONTROL_RECORD , CHANNEL_ID , ACK_NEEDED , ACK_RECEIVED , ARCHIVE ) values ( ?,?,?,?,?,?,?,?,?,?,?,?,?,?,?,?,?,? ) <<: Cannot assign an empty string to a parameter with JDBC type >>VARCHAR<<

Transmitting the message to endpoint <local> using connection File_http://sap.com/xi/XI/System failed, due to: com.sap.aii.af.idoc.exception.IDOCAdapterException

Message status set to WAIT

Any ideas why it does not want the persistance to be set on (true)?

We would like to monitor and the value must be set to true, according to documentation that I have read.

Are we missing some other flag,setting, whatever?

Thanks again for the help on this.

Mike

[mike_radcliff · Accepted solution]

A patch was released by SAP this week to fix this problem after I opened an OSS Message.

SAPXIAF04 

SP-level#04, Patch-level #9

That fixed the issue with the Insert statement.

The note containing this fix is: 1688780 IDoc AAE Adapter fails to insert empty strings in database

Thanks,

Mike

[Former Member]

Hello ,

Presently I am facing error when sending Idocs having extension , where the error says that there is a mismatch between IDocXML root tag and Idoctype in EDIDC .

For the errors of this sort , I came across the Note 1801511 which is not apt for us as we are on Higher Version .

Could you please help me on this .The necessary details are as below .

System details

PI Version : PO /PI 7.4 Single Stack

Service Pack:08

Release: NW731EXT_13_REL

Component Info :- XI AF Component : SP 8

Transformed Data with Proper IDocType/CIM Type/Message Type

Error :

state=READING_ENDTAG, charPosition=248, lineNumber=1, columnNumber=249" class="urTxtStd urTxtColor" style="WHITE-SPACE: normal" ti="0" lsdata="{0:'Error before sending due to idoc parsing error: (7) IDOC_ERROR_PARSE_FAILURE: IDoc type MATMAS05 within the EDI_DC40 control record segment does not match the IDocXML root tag :\nstate=READING_ENDTAG, charPosition=248, lineNumber=1, columnNumber=249',8:true}" ct="TV" bMarkedAsFocussed="true" bResetTabIndex="true"Error before sending due to idoc parsing error: (7) IDOC_ERROR_PARSE_FAILURE: IDoc type MATMAS05 within the EDI_DC40 control record segment does not match the IDocXML root tag <ZMATMASEXT>:
state=READING_ENDTAG, charPosition=248, lineNumber=1, columnNumber=249

Thanks & Regards,

Malini

[MichalKrawczyk]

Hi,

do you see the IDOC created in PI ?

http://wiki.sdn.sap.com/wiki/display/TechTSG/(PI)+No+IDoc+messages+displayed+in+IDoc+Monitor+after+a...

can you see the correctly populated EDIDC40 ?

if not can you try populating the EDIDC40 yourself (for a test) with CIMTYP - your extension

and check if it's working like that ?

Regards,

Michal Krawczyk

[mike_radcliff]

Hi Michal,

Our JavaIdocAdapter has the persistance set to true. I just rechecked it to validate.

I added the following control record information to the stylesheet

<EDI_DC40>

<xsl:attribute name="SEGMENT"><xsl:text>1</xsl:text></xsl:attribute>

<TABNAM>EDI_DC40</TABNAM>

<MANDT>010</MANDT>

<IDOCTYP>ORDERS05</IDOCTYP>

<MESTYP>ORDERS</MESTYP>

<CIMTYPE>ZSPLORD5</CIMTYPE>

<SNDPOR>SAPDV2</SNDPOR>

<SNDPRT>LS</SNDPRT>

<SNDPRN>DV2CL0150</SNDPRN>

<RCVPOR>SAPXID</RCVPOR>

<RCVPRT>LS</RCVPRT>

<RCVPRN>XIPOSDV2</RCVPRN>

</EDI_DC40>

And then did the test again.

The same message came up, but with different column numbers.

Transmitting the message to endpoint <local> using connection File_http://sap.com/xi/XI/System failed, due to: com.sap.engine.interfaces.messaging.api.exception.MessagingException: com.sap.conn.idoc.IDocParseException: (7) IDOC_ERROR_PARSE_FAILURE: IDoc type "ORDERS05" within the control record does not match IDocXML root tag <ZSPLORD5>:
state=READING_ENDTAG, charPosition=367, lineNumber=1, columnNumber=368

I then changed the communication channel advanced tab as follows and did the test again.

I made the control record Mandatory(Recommended), and clicked on the 3 checkboxes below that.

Here are the results of that test.

Transmitting the message to endpoint <local> using connection File_http://sap.com/xi/XI/System failed, due to: com.sap.engine.interfaces.messaging.api.exception.MessagingException: com.sap.conn.idoc.IDocParseException: (7) IDOC_ERROR_PARSE_FAILURE: IDoc type "ORDERS05" within the control record does not match IDocXML root tag <ZSPLORD5>:
state=READING_ENDTAG, charPosition=351, lineNumber=1, columnNumber=352

Interesting thing is, I cannot find the IDOC information in the payload. The payload shows my input, but NOT the outbound payload. When I check this process in our old PI 7.0 system, the messages show the IDOC payload.

I have the ORDERS05 IDOC type and the ORDERS05 CIMTYPE ZSPLORD5 Idocs showing up in the Metadata of the IDOC Monitor, but no messages show up in the Message Monitor area when I do the tests.

Again, thanks for the help with this problem/issue.

Mike

[mike_radcliff]

Hi Michal,

One added note on this. We did some checking on the IDoc Monitor, and it DOES show us the Inbound messages that were done last week. Outbound is the direction we are having trouble with. Inbound Idocs are working fine.

Thank you.

Mike