Skip to Content
0
Former Member
Jan 27, 2009 at 09:45 AM

LibRfc cuts MATL_DESC after 40 characters.

69 Views

Hello All!!

A detailed explanaton of the problem is below:

We call BAPI_MATERIAL_GET_DETAIL from a non-Unicode program using LibRfc32.

If MATL_DESC (the first field in structure BAPIMATDOA) contains only Western-language characters, everything is fine. LibRfc returns a string built from the correct number of bytes (MATL_DESC: 40 bytes, OLD_MAT_NO: 18 bytes, MATL_TYPE: 4 bytes, IND_SECTOR: 1 byte, and so on).

If MATL_DESC contains Chinese characters, LibRfc return a string with the same structure as in the first case and this is wrong due to the fact that even in non-Unicode programs Chinese characters consist of 2 bytes, one lead byte and one trail byte. In the extreme case for instance that a text consists of 40 chinese characters, MATL_DESC must be 80 byte in size.

LibRfc cuts fields MATL_DESC after exactly 40 byte, so a text containing 40 chinese characters is truncated after the first 20 Chinese characters.

You can see this happening in LibRfc32 trace files if the non-Unicode language is set to Chinese (Taiwan).

This is my analysis of two traces. The first one has an English description only. The second one has a mixed description Chinese + English.

000000 | 05000000 05000503 00000503 05140010 |................|

000010 | 2E7259EC 68555843 AFFA3173 385AFA2E |.rY.hUXC..1s8Z..|

000020 | 05140512 00000512 02010011 4D415445 |............MATE|

000030 | 5249414C 504C414E 54444154 41020102 |RIALPLANTDATA...|

000040 | 03000631 31302020 20020302 0100154D |...110 ......M|

000050 | 41544552 49414C56 414C5541 54494F4E |ATERIALVALUATION|

000060 | 44415441 02010203 00245600 00000000 |DATA.....$V.....|

000070 | 00000002 53800C00 00000000 00000000 |....S...........|

000080 | 00000C01 000C524D 42202043 4E590203 |......RMB CNY..|

000090 | 02010015 4D415445 5249414C 5F47454E |....MATERIAL_GEN|

0000a0 | 4552414C 5F444154 41020102 03019E20 |ERAL_DATA...... |

0000b0 | 43415254 4F4E204C 41422D49 5236392D |CARTON LAB-IR69-|

0000c0 | 30372848 3339392D 302D4330 30303129 |07(H399-0-C0001)|

0000d0 | 31352E32 4B475320 20202020 20202020 |15.2KGS |

0000e0 | 20202020 20202020 20524F48 20453430 | ROH E40|

0000f0 | 31313030 30362020 20202020 20202020 |110006 |

CARTON LAB-IR69-07(H399-0-C0001)15.2KGS

20434152544F4E204C41422D495236392D303728483339392D302D43303030312931352E324B4753 202020202020202020202020202020202020 524F4820453430

C A R T O N L A B - I R 6 9 - 0 7 ( H 3 9 9 - 0 - C 0 0 0 1 ) 1 5 . 2 K G S R O H E 4 0

MATL_DESC : 40 bytes

OLD_MAT_NO: 18 bytes (spaces)

MATL_TYPE: 4 bytes

IND_SECTOR: 1 byte

000000 | 05000000 05000503 00000503 05140010 |................|

000010 | E52D4DE7 5D07BC47 B22D7AFB 4AA3C62E |.-M.]..G.-z.J...|

000020 | 05140512 00000512 02010011 4D415445 |............MATE|

000030 | 5249414C 504C414E 54444154 41020102 |RIALPLANTDATA...|

000040 | 03000637 30352020 20020302 0100154D |...705 ......M|

000050 | 41544552 49414C56 414C5541 54494F4E |ATERIALVALUATION|

000060 | 44415441 02010203 00245300 00000000 |DATA.....$S.....|

000070 | 01084906 00000C00 00000000 00000000 |..I.............|

000080 | 00000C01 000C524D 42202043 4E590203 |......RMB CNY..|

000090 | 02010015 4D415445 5249414C 5F47454E |....MATERIAL_GEN|

0000a0 | 4552414C 5F444154 41020102 03019EA4 |ERAL_DATA.......|

0000b0 | A3F9D7BF FBA4F92D A4ADAAF7 A5F3BCD2 |.......-........|

0000c0 | A8E328A5 5DC3E429 20202020 20202020 |..(.]..) |

0000d0 | 20202020 20202020 20202020 20202020 | |

0000e0 | 20202020 20202020 20464552 54453130 | FERTE10|

0000f0 | 37303530 30312020 20202020 20202020 |705001 |

不銹鋼片-五金件模具(包邊) 䕆呒ㅅ㜰㔰〰‱u2020u2020u2020u2020

A4A3F9D7BFFBA4F9 2D A4ADAAF7A5F3BCD2A8E3 28 A55D C3E4 29202020202020202020202020202020 202020202020202020202020202020202020 46455254453130

不 銹 鋼 片 - 五 金 件 模 具 ( 包 邊 ) F E R T E 1 0

MATL_DESC : 40 bytes (8 + 1 + 10 + 1 + 4 + 1 + 15)

OLD_MAT_NO: 18 bytes (spaces)

MATL_TYPE: 4 bytes

IND_SECTOR: 1 byte

MATL_DESC : 40 bytes (8 + 1 + 10 + 1 + 4 + 1 + 15) this is a problem since

MATL_DESC = 14 characters plus 15 blanks = 29 characters. This means 11 blanks are missing!

LibRfc create BAPIMATDOA structure built from 40 + 18 + 4 + 1 + ... bytes

In case of Windows code pages with 2-byte characters (lead byte + trail byte) like Chinese, all string containing chinese characters must be longer according to the fact that Chinese characters are built from 2 bytes even in non-Unicode.

In this concreate example MATL_DESC must be built like this: 51 + 18 + 4 + 1 + ... bytes

LibRfc cuts MATL_DESC after 40 characters regardless of the language used.

Is there any way to get the entire 80bytes that we require?