cancel
Showing results for 
Search instead for 
Did you mean: 

RFC to XML-RFC Parsing issue in RFC Adapter as Sender

Former Member
0 Kudos

Hi all,

I tried to use RFC adapter as a sender. The scenario I am trying to achieve is R3 -> RFC Adapter Sender --> BPM --> RFC Adapter Receiver --> SAP Auto-ID system.

The reason to use two RFC adapter and BPM is to log the request message if the RFC call fails. Everything works as expected, except the RFC Adapter Sender.

The RFC I am calling has an input table. The input data I use works fine if I call it via SE37 or remotely from another SAP system. However, if I call it via RFC adapter, when XI parses the data into RFC-XML format, the input data is all messed up.

DATA: BEGIN OF ID_STR,

ID_VERSION(8) TYPE C,

ID(96) TYPE C,

ELEMENT_NAME(50) TYPE C,

ELEMENT_VALUE(128) TYPE C,

END OF ID_STR.

DATA: it_id LIKE TABLE OF ID_STR,

ls_id LIKE ID_STR.

ls_id-ID_VERSION = 'EPC_1.30'.

ls_id-ID = '30340242206DC3C00000000A'.

ls_id-element_name = 'BATCH_ID'.

ls_id-element_value = 'BATCH001'.

APPEND ls_id TO it_id.

CALL FUNCTION '/AIN/UI_MOBILE_MSG_SEND'

IN BACKGROUND TASK

DESTINATION 'RFC_UPDATEAII'

EXPORTING

IV_BUSINESS_PROCESS = '09'

IV_COMMAND = 'DO'

IV_ACTION_TYPE = 'APL2'

IV_PRT_ID = '31140242200000000F000000'

IV_DEVGRP_EXTID = 'MOBILE'

TABLES

IT_ID = it_id

.

commit work.

And the parsed RFC-XML message is:

-


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

<rfc:_-AIN_-UI_MOBILE_MSG_SEND

xmlns:rfc="urn:sap-com:document:sap:rfc:functions">

<IV_ACTION_TYPE>APL2</IV_ACTION_TYPE>

<IV_BTD_EXTID />

<IV_BTD_TYPE />

<IV_BUSINESS_PROCESS>09</IV_BUSINESS_PROCESS>

<IV_COMMAND>DO</IV_COMMAND>

<IV_DEVGRP_EXTID>MOBILE</IV_DEVGRP_EXTID>

<IV_LOC_EXTID />

<IV_LOC_TYPE />

<IV_PRT_ID>31140242200000000F000000</IV_PRT_ID>

<IV_PRT_ID_VERSION />

<IV_REASON_CODE />

<IV_UNAME/>

<ET_RETURN />

<IT_ID>

<item>

<ID_VERSION>EPC_1.30</ID_VERSION>

<ID>206DC3C00000000A BATCH_ID</ID>

<ELEMENT_NAME />

<ELEMENT_VALUE />

</item>

</IT_ID>

</rfc:_-AIN_-UI_MOBILE_MSG_SEND>

-


You can see the data in the table is all wrong, it should be:

<IT_ID>

<item>

<ID_VERSION>EPC_1.30</ID_VERSION>

<ID>30340242206DC3C00000000A</ID>

<ELEMENT_NAME>BATCH_ID</ELEMENT_NAME>

<ELEMENT_VALUE>BATCH001</ELEMENT_VALUE>

</item>

</IT_ID>

The calling system is a 4.6C non-unicode system, and the destination system is a unicode system (this does not matter since the first part of the integration is between R3 and XI). There is no config found on R3 side to specify non-unicode because it is a rather old system. In XI RFC Adapter config, I checked non-unicode checkbox (I also tested it with this unchecked, but still the same issue).

Have any of you seen this problem and how you resolve it?

Thanks a lot for your help!

Regards,

Hart

Accepted Solutions (0)

Answers (1)

Answers (1)

MichalKrawczyk
Active Contributor
0 Kudos

Hi Hart

long time no seen - hope you remember me

>The reason to use two RFC adapter and BPM is to log the request message if the RFC call fails

there is an easy way (guess max 3-4 hours) to solve all of your issues

and get rid of a BPM

use IDOC - XI - ABAP Proxy

then you will have IDOC and ABAP Proxy that always log the message on both ends (and you can restart ABAP proxies easily in AII - and every AII supports ABAP proxies) + you get rid of a BPM as it's not necessary as far as I understand (as it's asyn communication right?)

maybe you can go this way and IDOCs always work...

good luck,

Regards,

Michal Krawczyk

http://mypigenie.com XI/PI FAQ

Former Member
0 Kudos

Hi Michal,

Nice to hear from you again! Hope everything's been well. And also Merry Christmas!

There are some other factors that we need to take this approach. First of all, the RFC we are using is a standard RFC. Secondly, on R3 side, we have a config table that controls the mode of the RFC call. If it is synchronous, the call goes directly into Aii without using XI; and if we expect performance issue and want to call it asynchronously, the call goes via XI using RFC adapter.

The problem I am having is the same as the thread , but I do not have a way to specify non-unicode in my RFC destination.

Any idea why RFC adapter could not parse the data correctly?

Thanks,

Hart

MichalKrawczyk
Active Contributor
0 Kudos

hi,

>Any idea why RFC adapter could not parse the data correctly?

in case you didn't try it yet you can reset RFC adapter metadata

on XI

from SAP OSS note - Note 730870 - FAQ XI 3.0/ PI 7.0/ PI 7.1 RFC Adapter

quote:

"The caches for all communication channels are cleared when the J2EE Engine is restarted, the RfcAdapter J2EE Service 'SAP XI Adapter: RFC' is restarted or a dependend J2EE Service is restarted ('SAP XI AF CPA Cache', 'SAP XI AF Messaging'). "

but this is the only thing I can think of 😕

>and if we expect performance issue and want to call it asynchronously, the call goes via XI using RFC adapter.

but still in asyn case you don't have this RFC on XI so you can just call Z module with the same RFC signature (copy of original) and inside fill in the IDOC - this will at least allow you to get rid of this BPM

Regards,

Michal Krawczyk

http://mypigenie.com XI/PI FAQ

Former Member
0 Kudos

Thanks a lot, Michal!

The cache refresh did not help.

The reason of not going to idoc approach as you suggested is that since the RFC we are using is a standard AII function, the customer does not want to make a lot of dev. the BPM is already in place, and everything is working except this RFC adapter piece.

I just want to see whether there is a problem (known or unknown) with the RFC adapter, or there is something I did wrong.

Have you seen this problem before?

Hart

Former Member
0 Kudos

Hi Hart,

Have you checked the Non Unicode flag in the RFC Destination which you would have created in sm59 transaction? If not check it and try.

Thanks

Amit

Former Member
0 Kudos

Hi Amit,

As I mentioned earlier, since the calling system is a 4.6C system (rather old basis), I do not see any flag for unicode in SM59.

Thanks!

Hart

Former Member
0 Kudos

Hi guys,

Got a reply from SAP. In Note 730870 Q27 says no mix of non-unicode and unicode together. I guess this is the problem.

Does anyone have a work-around besides the approach Michal suggested (IDOC)? I would prefer to have as little as possible impact on the calling system.

Thanks!

Hart

Former Member
0 Kudos

Hi Michal,

The problem is that the real life is not as easy as getting things done :-).

My approach only needs some config on R3 and then some XI objects, and it works if the systems are all unicode. It is so close...

Your approach gets rid of the BPM which is nice, but it requires to create idocs, abap proxies (no big deal though from development of view), but it needs much more work later for the customer to maintain.

I think for now, I would create a custom RFC on 4.6C system to have the exact signature as the Aii RFC (so that XI can download the metadata using 4.6C system), and then use straight mapping in XI to map this custom RFC in to the aii standard. Only an additional RFC is required. All the other pieces will remain the same. When 4.6C is upgraded to ECC which is unicode-enabled, they have the option to call directly via XI RFC adapter.

What do you think?

Best regards,

Hart

prateek
Active Contributor
0 Kudos

Not very sure about the solution but could you check tcode uccheck in R/3 to identify the statements not supported by unicode systems.

Regards,

Prateek

Former Member
0 Kudos

What RFC Adapter does not support, according to the note, is that when a RFC metadata is in a unicode system, but you try to use RFC adapter to call it from a non-unicode system, or vise versa. XI does not matter in this case (it is always unicode anyway).

In my scenario, I have the standard RFC in aii (unicode), XI downloads its metadata, and R3 (4.6C non-unicode) is trying to use that metadata to call the RFC. It did not work because of the unicode & non-unicode mix.

If I create a custom RFC using the exact signature, I can download the metadata from 4.6C itself, and use a straight XI mapping to map the custom RFC into the aii standard one.