Wrong character set in RFC Response.

[Former Member]

Hi all,

interesting little problem - in calling an ERP system via the RFC Adapater, I am expecting English text in a string field, however,I end up getting a series of, I assume, Chinese characters. I don't know why, it has nothing to do with a language text look up as I am explicity forcing a return of 'Call Made!' to one of the the string fields all apart of my debugging.

So the question is - where can I go to find out what the default character set is for the PI system.

Thanks.

[stefan_grube · Accepted solution]

Standard for PI is UTF-8

Check logon language of RFC adapter channel. It should be EN.

[Former Member · Accepted solution]

Thanks Stefan,

the front end codepage is character set is UTF-8 and the RFC user, in fact all users, are logging on with langauge of 'EN'. It seems to be just this particular field. Another field for example is Material Description, and that is coming through as english and is readable, however, this other field as populated by an RFC Call, regardless of whether I set delibrately via code eg;

ev_sortf = 'Call Made!'.

or let it populate from a select statement comes through in a different character set. When I look at the field configuration and the WSDL, it is set as type STRING in both the data type and in the RFC definition, and I cannot see anything that stands out as not to use the English character set.

[stefan_grube · Accepted solution]

If this is just one field, I assume that you aded the field later in the RFC structure. So the RFC meta data in the RFC adapter cache might be outdated.

Deactivate and activate the channel, that should help.

[Former Member · Accepted solution]

Perfect!! Thanks Stefan and your assumption was right - to test the interface I did change the RFC signature from a SORTP type to STRING.

Now why is this important? If the RFC Channel is already established and activated, and then a lookup is developed why would a subsequant modification to the ERP sige require a re-activation of the channel? Surprisingly, I did delete/re-import the RFC thinking this might resolve the problem, but it didn't.

[stefan_grube · Accepted solution]

> Now why is this important? If the RFC Channel is already established and activated, and then a lookup is developed why would a subsequant modification to the ERP sige require a re-activation of the channel?

The RFC stores the RFC meta data in the cache, after you activate the channel. This helps to improve performance.

The chache is independent from ESR, so it does not help to upload the RFC metadata there.

[Former Member · Accepted solution]

Hmm ok. Still don't quite understand the sequence of events of how the error would result. I'll just ensure that any changes I make to an RFC lookup that I'll deactivate/activate any associated RFC Channels.

Thanks again.

[jorgehuedo · Accepted solution]

Hi experts,

We are having a similar situation than Jason.

We have imported RFCs that have changed and is incoming to PI the messages with incorrect characters, the data disordered...

We have reimported the RFCs, deactivate/activate RFC channels, but we continue with the error.

Any other ideas?