Мы пишем инструмент на Java, который анализирует и преобразует код ABAP. Поэтому у нас нет намерения писать новый код ABAP, но наш инструмент должен обрабатывать все ABAP, даже устаревшие операторы. Кроме того, я не эксперт по ABAP.
У нас есть инструмент ABAP, который извлекает систему и записывает ее в XML. Эта программа не содержит логики, поэтому я считаю, что XML действительно соответствует системе.
Я смотрю на данные, полученные при чтении текстового пула. Последний читается READ TEXTPOOL
; если они существуют, атрибуты LANGU
, ID
, KEY
, ENTRY
и LENGTH
записываются в XML.
Теперь я вижу записи текстовых элементов в XML, которые, кажется, нарушают формат, как описано в документации по ключевым словам ABAP.
id = I, длина ключа не равна 3. В частности, ключи имеют вид 01100001, SH010001, SF010001
id = R, ключ присутствует. Пример: key = "027". Я даже вижу пример, где все атрибуты одинаковы, но ключ.
id = S, текстовый элемент не начинается ни с " "
(восемь пробелов), ни с "D "
(буква "D", за которой следуют семь пробелов)
длина текстового элемента превышает максимальную. Мы используем верхние пределы H = 255, I = 132, S = 38, R = 70, T = 70. (Здесь я не уверен, откуда взялись наши цифры)
При преобразовании текстовых записей мы проверяем существующие и не можем использовать слишком длинные существующие. Может кто уточнить?
Вы можете использовать имя программы READ TEXTPOOL для получения текстов, используемых в программах ABAP. Согласно Документация ABAP:
| ID | KEY | ENTRY |
| H | 001 through 004 | List header Column headers |
| I | ID of a text symbol | Text of the text symbol |
| R | - | Program title |
| S | Name of a parameter or selection criterion | Selection text |
| T | - | List header Title bar |
id = I, длина ключа не равна 3. В частности, ключи имеют вид 01100001, SH010001, SF010001 -> согласно приведенному выше определению это имя текстового символа, означает: ссылку на текст, используемый в программе (указывающий на текст). Так откуда у вас длина = 3? Не могу поддержать этого.
id = R, ключ присутствует. Пример: key = "027". Я даже вижу пример, где все атрибуты такие же, но ключ. -> normalle должно быть заголовком исполняемой программы ... который определенно может быть длиннее 3 цифр
id = S, текстовый элемент не начинается с "" (восемь пробелов) ни "D" (буква "D" с семью пробелами) -> некоторые из них могут быть автоматически сгенерированы в ABAP и, следовательно, иметь странные имена.
длина текстового элемента превышает максимальную. Мы используем верхние пределы H = 255, I = 132, S = 38, R = 70, T = 70. (Здесь я не уверен, где наши числа родом из) По сравнению с вашими проблемами. -> текстовые элементы содержат максимум 255 символов, вы можете видеть, что в abap STRUCTURE: TEXTPOOL есть одно поле: TEXTPOOLTX CHAR 255
Я думаю, что это были бы определения, которые нужно проверить:
ID Type TEXTPOOLID CHAR 1
KEY Type TEXTPOOLKY CHAR 8
ENTRY Type TEXTPOOLTX CHAR 255
LENGTH Type TEXTPOOLLN INT4 10
Надеюсь это поможет!
id = I, длина ключа не равна 3: это происходит из определения текстового символа в Документация ABAP. "Текстовый символ ведет себя как константа и может быть указан в позициях чтения с использованием имени text-idf. Здесь idf - трехсимвольный идентификатор текстового символа. Этот идентификатор может состоять из любых буквенно-цифровых символов плюс" _ ". текстовый символ берется из текущего загруженного текстового пула.
id = R, ключ присутствует: Здесь дело в том, что ключ есть вообще. В документе, который вы цитируете, ключ для id = R дается как '-', то есть без ключа.
id = S: Если вы правы, документация ABAP в этом случае не очень полезна.
есть так много способов изменить (или сделать что угодно) с SAP ... полагаться на документацию от официального SAP может быть не лучшей идеей. Вы когда-нибудь слышали о системных копиях? Думаю, это упростит вашу жизнь, чем вытащить весь SAP в XML и вернуть обратно ... просто идея. по крайней мере, проголосуйте за некоторые ответы, даже если вас это не устраивает. но документация имхо не надежна.
Я думаю, что приведенные вами объяснения действительны для недавно созданных текстовых пулов, но, возможно, при создании XML использовалась старая логика.
Более того, нет уверенности в том, что XML является точным изображением текстового пула, извлеченного READ TEXTPOOL, поэтому на него трудно ответить.
Было бы лучше, если бы вы выполнили READ TEXTPOOL сегодня, и если есть что-то странное, то, возможно, мы сможем исследовать.
Что касается существующего XML, просто примените обходной путь, чтобы получить правильные текстовые элементы:
Я почти уверен, что результаты, которые я вижу, появились недавно. Но в любом случае просто «игнорировать лишние строки» или «взять первые 3» - непростые варианты, потому что это изменило бы систему клиентов (мы воспроизводим наши результаты). По крайней мере, мы должны проверить и сообщить о наших изменениях. последнее, я собираю аргументы
Можете ли вы предоставить воспроизводимый пример таких ошибочных записей пула текста? Если это не может быть воспроизведено в исходном виде, используя просто READ TEXTPOOL в каком-либо отчете, более вероятно, что ваше преобразование XML содержит ошибки, например кто-то неправильно учел Unicode или другие преобразования кодовой страницы, поскольку все компоненты TEXTPOOL символьны.