cancel
Showing results for 
Search instead for 
Did you mean: 

Special Characters are getting added after RFC call

EkanshCapgemini
Active Contributor
0 Kudos

Hi,

We are calling an RFC in Get_EntitySet method of a Gateway service. In the table 't_output' of that RFC, we have a 'description' field of char50 which is initially blank and gets populated after RFC execution.

But after RFC call in gateway, this field is getting populated with preceding string "   \u0000\u0000\u0000\f\u0000\u0000ఀ"(as found in http response, find the debugger values in screenshot) then the actual values. I have tried executing the FM separately but there it was returning correctly (without this special character string).

Why is this happening and how to resolve it?

Accepted Solutions (1)

Accepted Solutions (1)

AshwinDutt
Active Contributor
0 Kudos

Hello Ekansh,

This is due to the data type mismatch.

Make sure that the structure or the table in which you are capturing the response from the RFC is same. I mean both have the same data types and the order of the fields as well.

for example lets say RFC is returning  a table having fields A , B , C and has the corresponding type as Decimal with length 7 decimal 3 , CHAR of length 10 , INT4 length 10.

when you capture this RFC response i mean the table in which you are capturing should have the table with same data types and order of the fields. i.e., table with fields A , B , C having types as Decimal with length 7 decimal 3 , CHAR of length 10 , INT4 length 10 correspondingly.

Fields like Quantity should be defined with correct length and precision.


This issue will be resolved if you make sure the above things are in place.


Regards,

Ashwin

EkanshCapgemini
Active Contributor
0 Kudos

Hi Ashwin,

The datatype and the order of the fields, both are same here. The datatype of 'Description' field is CHAR50 in RFC return table structure and in my table 't_output' as well.

AshwinDutt
Active Contributor
0 Kudos

Hello Ekansh,

Can you please share the screen shots of RFC table structure and your local table structure in which you are capturing the response of RFC ?

I have faced this issues and issue was with the type mismatch.

I don't see any other reason in GW for the data to be get corrupted except data type mismatch

Regards,

Ashwin

EkanshCapgemini
Active Contributor
0 Kudos

Hi ashwin,

This is the structure in RFC (showing after scroll to focus on Description).

And below is the snapshot for GW, in which I am capturing the result:

AshwinDutt
Active Contributor
0 Kudos

Hello Ekansh,

Thanks for your effort in sharing things Ekansh

I could find that RFC response table has got field ' CHARG '. Have a look at the below image.

But your GW structure has no field called ' CHARG ' . Have a look at the below image.

It is being missed out in your GW local structure.

Kindly add this field i.e., CHARG between OMEG and VAL_STOCK. Response will be fine this time

Regards,

Ashwin

EkanshCapgemini
Active Contributor
0 Kudos

Hi ashwin,

I regenerated the runtime artifacts, now it added the required fields.

Now its working fine.

Thanks for your efforts & help.

Answers (2)

Answers (2)

AshwinDutt
Active Contributor
0 Kudos

Hello Ekansh,

Like Chandra said problem might be with Unicode and Non_Unicode communication type as well.

You can check in SM59 about the RFC destination and Unicode details.

But i really suspect it is with data type mismatch.

If data types are correct then we need to look regarding unicode or non-unicode communication type.

Regards,

Ashwin

ChandraMahajan
Active Contributor
0 Kudos

Hi,

May be this thread discussion will help you to resolve problem

Regards,

Chandra

EkanshCapgemini
Active Contributor
0 Kudos

Hi Chandrashekhar,

I am unable to get the correct answer in that discussion URL.

In my case if I execute this FM in the destination system itself, it is giving correct data. But if I execute this through my gateway system, it is adding those characters.

ChandraMahajan
Active Contributor
0 Kudos

Hi,

may be then you can write extra logic to remove special characters in DPC_EXT class method before exporting data to response.

Regards,

Chandra

EkanshCapgemini
Active Contributor
0 Kudos

that I can write but what is the cause of this thing?

ChandraMahajan
Active Contributor
0 Kudos

Hi,

I guess the reason could be unicode and nonunicode system.

you can also refer this thread

I am not sure if this might be the reason.

Regards,

Chandra