cancel
Showing results for 
Search instead for 
Did you mean: 

Receiver RFC displays data as #

Former Member
0 Kudos

Hello Experts,

We have a scenario JMS ->PI->RFC.

PI is Unicode system with charecter size 2 where as R3 is a ECC 6 non unicode system with charecter size one.

I guess due to this the error occurs while data conversion and # is diplayed; as RFC destination has default setting i.e. "Ignore Error, Error Indicator: '#' = U+0023"

Please suggest how can I overcome this problem?

I have tried option for changing the encoding using XSLT as mentioned in :

But it was of no help.

Please suggest!

Kind Regards,

Abhijeet.

Accepted Solutions (1)

Accepted Solutions (1)

stefan_grube
Active Contributor
0 Kudos

When you have an RFC receiver channel, you do not maintain an SM59 destination, so you can ignore settings there.

Check which characters are wrong. You have to apply the correct logon language in the RFC channel. The logon language refers to a specific codepage in the ECC system.

For example: for japanese characters, you use logon language japanese.

Do not change the encoding of the XML. Make sure, that the target XML is UTF-8 and all characters in this XML are correct.

Former Member
0 Kudos

Hi Stefan,

Thanks for inputs. I have changed the encoding in XSLT back to UTF-8, set logon Language to "DA" as the input can contain Danish Characters.

But still it is same, I do get # on receiving side.

I tried to remove XSLT and assign the Constant (actual payload which is a XML again) using a dummy Message mapping and it works fine. Data is received well on receiver system. But as soon as i try to map actual contents from JMS I get this #.

Can it be due to XSLT mapping used?


<xsl:stylesheet version="1.0" xmlns:xsl="http://www.w3.org/1999/XSL/Transform">
<xsl:output method="xml" version="1.0" encoding="UTF-8" indent="yes"/>
<xsl:template match="/">
<ns1:HDK083_REFUS_RECVDOCU xmlns:ns1="urn:sap-com:document:sap:rfc:functions">
<P_SIGN_DOCUMENT>
<xsl:value-of select="/.../.../ReferenceAttributTekst" />
</P_SIGN_DOCUMENT>
<P_XML_DOCUMENT>
<xsl:copy-of select="." />
</P_XML_DOCUMENT>
</ns1:HDK083_REFUS_RECVDOCU>
</xsl:template>
</xsl:stylesheet>

Also I tried to use Message mapping to replace the XSLT, but as the input coming in payload is a XML, when I assign it to string field it says


com.sap.aii.mappingtool.tf3.IllegalInstanceException: Cannot produce target element /ns1:HDK083_REFUS_RECVDOCU/P_XML_DOCUMENT. Check xml instance is valid for source xsd and target-field mapping fulfills requirements of target xsd 

Also i tried to use new feature of PI 7.1 "Return as XML" where we can assign a complete XML to single field, but still it fails in mapping with exception


SAP:Code area="MAPPING">EXCEPTION_DURING_EXECUTE</SAP:Code> 
  <SAP:P1>com/sap/xi/tf/_MM_Test_</SAP:P1> 
  <SAP:P2>com.sap.aii.mappingtool.tf7.IllegalInstanceExcepti</SAP:P2> 
  <SAP:P3>on: Cannot create target element /ns1:HDK083_REFUS</SAP:P3> 
  <SAP:P4>_RECVDOCU. Values missing in queue context. Targe~</SAP:P4> 
  <SAP:AdditionalText /> 
  <SAP:Stack>Runtime exception occurred during application mapping com/sap/xi/tf/_MM_Test_; com.sap.aii.mappingtool.tf7.IllegalInstanceException: Cannot create target element /ns1:HDK083_REFUS_RECVDOCU. Values missing in queue context. Targe~</SAP:Stack> 
  <SAP:Retry>M</SAP:Retry> 

Can you suggest something to resolve this???

Kind Regards,

Abhijeet.

stefan_grube
Active Contributor
0 Kudos

What is the encoding of the incoming XML? Have you confirmed, that the danish characters are in the correct encoding according to the XML declaration?

Former Member
0 Kudos

Hi Stefan,

The encoding for incoming XML is UTF-16.

How can we change the encoding in PI? I have tried it before to change it via XSLT from UTF-8 to ISO... , it gets changed but then receiver adapter(RFC in my case) changes it back to UTF-8.

So now I have a sender system (JMS) using UTF16 -> PI using UTF8 -> Receiver SAP ECC 6.0 configured as non unicode.

How should i handle this encoding issues??

Kind Regards,

Abhijeet.

stefan_grube
Active Contributor
0 Kudos

Make sure that the characters in your incoming XML are UTF-16 characters.

If your JMS server is Websphere, you have to figure out, what is the correct CCSID for UTF-16

In principle you need not change the encoding, but if you use graphical mapping it will change to UTF-8.

Do not try to change the encoding to something else!

When you check the payload in SXMB_MONI, is it correct?

Former Member
0 Kudos

Hi Stefan,

If your JMS server is Websphere, you have to figure out, what is the correct CCSID for UTF-16 

Yes, JMS server is WebsphereMQ.

In principle you need not change the encoding, but if you use graphical mapping it will change to UTF-8.

No, I am not using Graphical mapping at any point, Just XSLT for data transformation and a Java mapping will be used for signature verification (currently not included in scenario). But I can see that if i change encoding in XSLT, PI (probably RFC adapter) was changing the encoding back to UTF-8. Something strange.

Do not try to change the encoding to something else! 

Ok, I am not doing it any more.

When you check the payload in SXMB_MONI, is it correct?

Yes, the payload looks exactly as required in Moni as well as in RWB -> CC monitoring for RFC adapter. So at all points in PI can see that the data is correct.

I also tried to divert this output to a test MQ Q. And then tried to validate the output using XML spy or other editors, it was ok.

But only this ECC system cant process it, and displays #.

On the other hand if i remove XSLT and map the same payload as a constant using graphical mapping, it is received well by ECC system.

Not sure how to deal with it.

Kind regards,

Abhijeet.

stefan_grube
Active Contributor
0 Kudos

I do not see anything wrong in your XSLT.

I am sorry, I have no idea, why this does not work for you.

I have not worked with UTF-16 so far.

Former Member
0 Kudos

Hi Stefan,

Thanks for the help so far!

Kind Regads,

Abhijeet.

Former Member
0 Kudos

Hello Experts,

I have found that the problem is due to a kind of strange limitation we are facing on ECC system. The ECC system when receives "<" and ">" in the payload it cannot process them and thus displays "#" indicating Character Conversion error.

I have tried sending

"& lt;" and "& gt;" or "& #60;" "& #62;" 

instead of "<" and ">", it works fine with these replacement and data can be received as well as interpretted as expected in ECC.

Now I need to replace all "<" and ">" in my payload (string XML) with

"& lt;" and "& gt;" or "& #60;" "& #62;" 

. I tried using some of the common techniques suggested for charecter replacement. But since "<" is a special character they didnt work. I think i need some special escape character mechanism to accomplish this task in XSLT.

Any help will be really appreciable.

Regards,

Abhijeet.

Answers (1)

Answers (1)

Former Member
0 Kudos

make the R3 system as unicode system - select unicode option in rfc.

Also check the RFC destionation pointing to R3 from XI - check the unicode option there too.

chirag

Edited by: Chirag Gohil on Jul 8, 2010 5:47 PM

Former Member
0 Kudos

Hi Chirag,

Thanks Chirag for quick response. For some reason all the options on "MDMP & Unicode" tab are grayed out with default option selected.

I have requested basis team to help me with this. Hope to get it working with this change. Is there anything else I can check on?

Where can I check for encoding type used by ECC system (UTF8. ISO....)???

Kind Regards,

Abhijeet.

Former Member
0 Kudos

Hi Chirag,

But for receiver RFC scenario we do not need any RFC destination on PI system to point on R3?????

Kind Regards,

Abhijeet.

Edited by: Abhijeet Ambekar on Jul 8, 2010 5:59 PM

Former Member
0 Kudos

make sure that ur both systems should be unicode system so that i will accept the unicode characters.

just try to select MDMP - unicode and try to send the data again. let me know the outcome of the same.

chirag

Edited by: Chirag Gohil on Jul 9, 2010 11:38 AM

stefan_grube
Active Contributor
0 Kudos
make sure that ur both systems should be unicode system so that i will accept the unicode characters.

what crazy idea to change a non-unicode system on the fly to unicode.

It is no problem at all to connect PI to non-unicode systems.

Former Member
0 Kudos

Hi Stefan,

It is no problem at all to connect PI to non-unicode systems.- I agree with u.

But I have also faced the same problem earliar with the character set and after setting the R3 system to unicode system which has resolved the problem.

chirag

stefan_grube
Active Contributor
0 Kudos
But I have also faced the same problem earliar with the character set and after setting the R3 system to unicode system which has resolved the problem.

I think you mean: You set the unicode flag in SM59 destination.

This is correct for sender RFC adapter.

Former Member
0 Kudos

ur understanding is correct-

chirag

stefan_grube
Active Contributor
0 Kudos

>

> ur understanding is correct-

> chirag

OK, then I have misunderstood you. Sorry for my reply.