sm30: установить соответствующий заголовок столбца

ProgramBox

sm30: установить соответствующий заголовок столбца

Post author:admin
Запись опубликована:26 мая, 2023
Post category:Вопросы по программированию

#abap

Вопрос:

Я создал таблицу в SAP через se11, затем использовал генератор обслуживания таблицы.

Теперь я редактирую таблицу через sm30 :

Второй и третий столбцы: оба имеют заголовок «Feldname».

Вызывается первый столбец «Feldname» COLUMN_NAME , и его элементом данных является «Fieldname».
Вызывается второй столбец «Feldname» AUTH_FIELD , и его элементом данных является «XUFIELD».

Я хотел бы видеть имена столбцов, которые я дал столбцам в se16 (COLUMN_NAME, AUTH_FIELD) в заголовке.

Как запретить генератору обслуживания таблицы указывать другие имена в заголовках?

1. Короткие тексты для элемента данных XUFIELD явно неверны, и об этом следует сообщить SAP в сообщении OSS (инцидент). Второе, видите ли вы технические названия или функциональные в SE16 , зависит от ваших настроек.

2. @Jagger, как ты думаешь, почему «Feldname» (по-немецки «Имя поля») «явно неверно» для AUTH_FIELD / XUFIELD?

3. Что ж, для поля «Berechtigungsfeld» название «Feldname» в качестве краткого и среднего описания, очевидно, неверно.

4. @Jagger правильно сказать, что имя поля авторизации («Berechtigungsfeld») является именем поля («Feldname»), просто вы считаете это неточным. Но тогда есть миллионы неточных текстов, удачи, чтобы его изменила служба поддержки SAP Примечание: SM30 использует «средний текст», который ограничен 20 символами, но они специально ограничили его 15 символами, поэтому в лучшем случае SAP может изменить его на «Имя поля авторизации» (или, если они увеличат длину, им следует просмотреть все dynpro, чтобы убедиться, что места достаточно). Я на 99% уверен, что они его не изменят.

Ответ №1:

Вариант 1 — использовать пользовательские элементы данных:

Вместо использования элементов данных Fieldname и XUFIELD вы можете создавать свои пользовательские элементы данных и присваивать им тот заголовок, который вы хотели бы.

(Вам придется заново настроить обслуживание таблицы)

Вариант 2 — экран редактирования

При создании обслуживания таблицы вы указали функциональную группу и номер экрана.

Перейдите в SE80 -> Функциональные группы -> <function_group_supplied> -> экраны -> <screen_supplied> . Затем отредактируйте его по своему усмотрению.

Примечание: Изменение сгенерированного объекта считается рискованным. Ваши индивидуальные изменения могут быть перезаписаны при будущей регенерации.

1. Создание новых пользовательских элементов данных кажется очень распространенным явлением в sap / abap. Я добавил новую тему в свой пост в блоге: github.com/guettli/why-i-like-django-and-sap/blob/master /…

2. Для варианта 2 вы можете указать, что вы повторно создаете диалоговое окно, за исключением экранов. При регенерации существуют другие опции. Трудность заключается в том, что невозможно узнать, что было настроено в диалоговом окне, поэтому высок риск потери пользовательских изменений в будущем.

3. Спасибо @SandraRossi. Я отредактировал заметку. Надеюсь, теперь это более точно.

Ответ №2:

Добавьте пользовательские элементы данных с подходящими описаниями. Пусть новые элементы данных ссылаются на исходные (соответственно. домены), чтобы избежать необходимости все изобретать заново.

Описания элементов данных могут быть переведены.
Вы можете установить разные описания для разной длины, например «Поле» для узкого столбца длиной 10 и «Название поля» для широкой метки длиной 30.
Повторное создание экрана обслуживания не приведет к случайному удалению измененных описаний.

1. Теперь я знаю, почему в SAP так много пользовательских элементов данных. Вам это нравится? Будет ли SAP делать это таким же образом снова, если бы они могли начать с нуля?

2. На самом деле мы все еще делаем это. После R / 3 мы создали SAP Business By Design с каталогом типов данных объемом около 17 000 страниц . В настоящее время в S / 4 у нас есть представления CDS и элементы управления smart UI, которые по-прежнему используют множество элементов данных. В последнее время с облачной платформой SAP их количество уменьшается из-за архитектуры микросервисов. На самом деле идея заключалась в том, чтобы иметь уникальные домены (описания технических типов данных) с несколькими элементами данных (спецификации использования) сверху. Нравится ли это лично мне? Нет.

3. видите ли вы альтернативные способы решения этой проблемы? Я ежедневно использую Python / Django / PostgreSQL, и мне нравится этот набор инструментов. SAP для меня в новинку, и некоторые вещи выглядят чрезмерно сложными. Это замедляет ежедневную разработку и снижает удовольствие. Отсутствие удовольствия приводит к медленному прогрессу (мое личное мнение)

4. Технологии ABAP DynPro, которая управляет экранами обслуживания таблиц, более 30 лет, и за последние 20 с лишним лет она не совершенствовалась. Вполне естественно, что он не соответствует самой современной платформе веб-приложений. Если вам не нужна красота, она все равно может предоставить вам довольно быстрый способ ввода данных. В противном случае рассмотрите возможность создания веб-приложения CDS OData Fiori / UI5 поверх вашей таблицы. Если это слишком сложно, рассмотрите возможность создания конечной точки REST, которая читает / записывает таблицу, и создайте поверх нее пользовательский веб-интерфейс.

5. Да, они выглядят некрасиво, но меня не волнует красота. Мне просто нужны соответствующие заголовки. Мне нравится SAP-RFC. Работает нормально. Но, AFAIK, существует проблема с лицензией, называемая «Косвенный доступ»