RFC between Non Uniocde Ariba and Uniocde ERP2004 system

[Former Member]

We have a Uniocde ERP2004 system, and we have some interfaces between that and Ariba, which has non Uniocde SAP RFC adaptors.

In the Ariba we are specifyin ghte Logon language as 'E', but when Ariba is callin SAP, we are getting RFC_CONVERSION_ERROR

Conversion error "ab_rfcImplode" from character set 4102 to character set 1100

When executing a remote function call a conversion error occurred. This

occurred when receiving or sending the data. The conversion error can

only appear, when the data is transferred from a Unicode system to a

non-Unicode system.

---

Any suggetsions?

[Former Member · Accepted solution]

Hi Matt,

there is a note dealing with this issue 722193, which basically tells to create an RFC destination ( not to be used ) for the Non uniocde client. But I guess it is applicable only for SAP Non Unicode systems,

Please confirm.

[Former Member · Accepted solution]

Hi Manish,

That's a pretty good question. I had thought about something like that when I was asking you how you connected (SM59 or not). It is probably worth a try in a DEV or sandbox. However, I do not work in support. You may consider opening a message with SAP.

I am confused about how it will ultimately work out, anyway. Basically, you have multi-codepage requirements for a non-Unicode interface...again, support may be able to provide a better answer...

Best Regards,

Matt

[Former Member · Accepted solution]

Hi Manish / Everyone,

I think the key to remember is that Ariba is passing Unicode characters to Tibco. Tibco's SAPAdapter is converting from UTF8 to Latin1 as that is the default SAPAdapter locale for the SAP Adapter. It currently works where Ariba is passing Japanese (UTF8 in Ariba) to SAP using the adapter locale of ibm-943 - which maps to code page 8000.

We have been directed to try the SAPAdapter locale of UTF8 - but this may not be a valid value for this version of Tibco...

Thanks,

Jeramy

[Former Member · Accepted solution]

Hi Jeramy,

Fair enough explanation, as I am no expert in Ariba or Tibco. What you are saying, I believe, is that both Ariba and SAP are Unicode, but the adapter in-between (provided by Tibco) is single codepage. I am at a loss, then, to how this can be configured to handle the requirements of characters from multiple codepages...Manish mentions that he needs Japanese, Korean, Chinese...

Perhaps I am just ignorant, though. I say pass it through XI or get rid of Ariba...just my two cents...

Best Regards,

Matt

[Former Member · Accepted solution]

Hi Matt,

Your answers actually provided us to look into all these options.

Right now Ariba has several SAP adaptors connected to SAP MDMP, each with its locale ( JA, KO, ZF, EN etc ). So this way Ariba passes the different langauge txns to the correspondign SAP Tibco Adaptor , and SAP MDMP receives the correct data.

Where I am at a loss is if its work with SAP MDMP for all these languages, why it should have issues with SAP Unicode. After all it is passign the data with same locale settings to Unicode SAP too. Unless there is something we need to do in SAP somewhere.

SAP Support aksed to update the RFC library, but we are on the latest one.

[Former Member]

Hi,

We are having the same problem. We have multiple partitions in our single ARIBA instance. Each partition uses its own SAP Adapter. For us the error occurs when we run the General Ledger pull. Where it becomes tricky is that it fails only for some partitions, in SAP terms for some company code. Is there something at the company code level in SAP beside the language that would cause that to happen? We have 2 English partitions. One is failing, one is not. Both uses the same adapter config (however 2 separate adapters running), the same SAP user, same SAP connection info and TIBCO sheet.

By the way, ARIBA SAP objects are not unicode compliant and needs to be check with the tcode UCCHECK and modified.

This is very confusing.

Cheers.

Mike

Message was edited by:

Michael Moulin

[Former Member]

Hello,

We solved our problem. It was cause by characters that exist in unicode but not in Latin. RFC was chocking on them when it usually replace them with "#".

As a general comment, there is a parameter in parameter.table in the ARIBA config that control the -setlocale option of the adapter. It's in Messaging.Channels.Tibco. It's called SAPAdapterLocale. You can have something like SAPAdapterLocale = { NT = UTF8 } or { NT = UTF-16BE }.

The thing that solved our problem is to replace the librfc32.dll we got with our adapter for a newer version taken from the sapjco. Now, the special unicode characters are replaced with "#" and do not make the transaction to crash in SAP.

Cheers,

Mike.

[Former Member]

Hi,

1) Manish mentions that he is using SAP RFC adaptors for the RFC connection. So the RFC libraries should be correct.

2) In data transfer between non-Unicode and Unicode systems, the data conversion <i>always</i> occurs on the Unicode system.

So, despite the fact that 'E' is specified as the logon language in Ariba, there are also settings in SM59 of the ERP Unicode system that must be set correctly for the conversion to work properly. This error -- ab_rfcImplode -- appears in Note 814707 which then points to Note 647495 to make the proper settings.

Hope this helps.

Best Regards,

Matt

[Former Member]

Thanks Matt.

The scenario is

1- Ariba calling SAP to post POs in SAP, and SAP returns the PO# back. This works but the Asian characters are getting converted to Junk

2 - Ariba calling SAP for the master data info ( vendors, materials etc ). So Ariba establish an RFC connection with SAP, and SAP RFC returns the data back. There we are getting the conversion error in the short dump. There is no setting for ariba in SM59 and SAP itslef is not calling Ariba.

SO we are at a loss, why this RFC connection betwen Ariba and SAP is not working where it is supposed to work, and SAP should be converting the data based on the current login code page.

[Former Member]

Hi Manish,

For 1, even though communication between systems can be properly established, a receiving system can only store characters in the codepage of its system. Does the Ariba system have a codepage with Asian characters? I think it probably doesn't and that is why you are seeing junk. It gets converted correctly, but Ariba has no way to handle it. See my post where I have explained it a bit more.

For 2, please help me understand. How are you establishing a RFC connection without any entries in SM59?

Best Regards,

Matt

[Former Member]

Hi Matt,

1- Yep, that is our guess so far, as we are using sandbox right now, so Ariba guys are working on verifying it,

2- There is no entry in SM59 for Ariba, as SAP is not establishing any connection to Ariba. Ariba is calling SAP using a RFC connection. that RFC comes to SAP, and SAP returns the values in the same RFC call. thats where we are getting the short dump.

[Former Member]

Hi Manish,

Here are the rules for the determination of RFC Communication Code Page:

External Program is non-Unicode (Single Code Page):

RFC determines communication code page and converts between this code page and Unicode

-- <b>Default code page</b>

--- <b>Environment parameter SAP_CODEPAGE</b>

-

---

<i>Example in UNIX: setenv SAP_CODEPAGE 8000</i>

--- <b>RFC API RfcSetSystemCodepage</b>

-- <b>Expicit code page</b>

--- <b>RfcOpenEx at connection time</b>

-

---

<i>Example: RfcOpenEx (“… CODEPAGE=8000 …”,…)</i>

--- <b>RfcSetCodepage at runtime</b>

-

---

<i>Example: RfcSetCodepage (handle, “8000”);</i>

[Former Member]

Hi Matt,

yep, I attended your session in Las Vegas, so I sort of rememeber these things.

The issue here is Ariba RFC Adaptor, which is connecting to SAP.

Typical settign there is

adr3 -system:repourl tibcr://sapvar:service=AribaTibco8DEV:daemon=tcp:7703:subject=com.tibco.repo.instance_discovery.request -system:configurl /tibco/private/adapter/SAPAdapter40/SAInboundRFC.japan -setlocale ibm-943

The setlocale determines which codepage to use. Here it is using ibm-943 for Japanese, I guess it should correclty correspond to 8000, as the same command used to work in our MDMP system.

Now after converting to Unicode, we receive junk chars in SAP for Japanese char, and when SAP sends response back to Ariba in the RFC call ( please see that it is ariba which is initiating the connection , so no sm59 entry in SAP ), we get RFC_CONVERSION_FIELD.

Actually in teh response back even if it converts the unconvertible data to '#### ' that should be fine, but it is short dumping.

WE tried removing the setlocale command in Ariba adaptor connection setting, with language as J, but nothing seems to work.

[Former Member]

to add to my message above, Ariba plainly said that their SAP Adaptor is Non Unicode, and they will not support anything on that for us.

Message was edited by: Manish Garg

[Former Member]

Hi Manish,

What is the SAP_CODEPAGE setting at the OS level?

Best Regards,

Matt

[Former Member]

Hi Matt,

it is iso_8859_1 .

Thansk for taking time to look into this thread.

Manish

[Former Member]

Hi Manish,

Pretty interesting problem...

I am no expert on Ariba, but I can at least make an educated guess here...

You are passing Japanese characters in this connection, correct? So...

Your value for SAP_CODEPAGE is iso_8859_1. This corresponds to Latin-1. I believe the SAP (Unicode) system is attempting to determine its communication codepage settings from this value (it ignores/does not use the Ariba value)

"<i>We receive junk chars in SAP for Japanese char</i>"...this would be correct, since the SAP system is using a Latin-1 setting for the conversion. It does not recognize the Japanese characters and thus converts them to junk.

"<i>When SAP sends response back to Ariba in the RFC call ...we get RFC_CONVERSION_FIELD</i>"...this, too, would be correct as the SAP system is attempting to convert Japanese to Latin-1 (4102->1100) in the FM and it dumps.

At this point I would try changing the setting of SAP_CODEPAGE to the Japanese value (iso-2022-jp ?). However, I am not positive that it will completely solve the problem, but it will at least give more information!

Best Regards,

Matt

[Former Member]

Thanks Matt; Our Unicode system is down right now as we are using it to make our normal Dev box. So I will try it on Monday again.

But I have some questions for now:

1- We have all the Asian languages apart from Latin-1 set. So even if setting the code page to Japanese would resolve the issue with Japanese chars, we would again get the same issue with Korean and Chinese.

2- I tried debugging the call ( using Debug program in SM50 ) in SAP. ( I was logged on in English ), the System language I see correclty as 'J'in the process, but how can I identify the code page there? there is no system variable ( SY- xxx ) for code page. But I guess as SY-LANGU was 'J' it should have 8000 as the code page there.

3- Same on #2, if there is something like SY-xxx for code page, would it help if I can set that to the correct code page at the beginning of the code.

4- Last option i was thinking if there is a way I can do the conversion myself, using the SAP function modules

TREX_TEXT_TO_UTF8 Converts text from current encoding to UTF-8

TREX_UTF8_TO_TEXT Converts text from UTF-8 to current encoding

These work foine for English, but for Japanese, and others do not.

Message was edited by: Manish Garg

[Former Member]

Hi Manish,

I do not know if you can do the conversion yourself...I am not a developer

I think the best way to debug this is to follow the troubleshooting steps in Note 814707.

Or, you could scrap Ariba ;-)...

Or, you could do as Barry suggested and pass it through XI...

Best Regardes,

Matt

[Former Member]

Yep, I am definitely looking to replace Ariba with SAP. But in the meantime I guess I have to deal with that junk.

ok, Let me try more on Monday.

[Former Member]

are you using any middleware to assist with the conversion?

We use SAP XI to convert between non-unicode and unicode systems.

[Former Member]

Hi Manish,

If you had interfaces btw SAP unicode and SAP non-unicode, RFC libraries would do convertion so everything would work fine. But since you are using Ariba, it non-unicode RFC libs may not be completely compatible with SAP RFC libs.

Regards,

Mike