Oracle EBS R12.2 - Следует ли использовать синоним APPS при выборе данных из пользовательских таблиц в Oracle Формах / отчетах? - PullRequest
0 голосов
/ 19 февраля 2020

Я анализировал изменения, которые необходимо выполнить в пользовательском коде клиента перед обновлением с EBS 12.1 до 12.2, с акцентом на соответствие исправлений в режиме онлайн.

При запуске ADZDDB проверки стандартов базы данных в режиме онлайн исправлений 1012 * .sql ', раздел SECTION-26 перечисляет ряд пользовательских объектов базы данных, которые необходимо изменить. В этом разделе говорится, что «операторы Query / DML должны обращаться к таблицам через синоним таблицы APPS». Объекты базы данных, находящиеся в зарегистрированной пользовательской схеме (например, XXSCHEMA), должны быть изменены для выбора данных через синоним таблицы APPS. Я понимаю это, и у нас есть план для устранения этих нарушений.

Теперь при запуске GS CC проверяет наличие пользовательских форм Oracle и сообщает о том же нарушении, но они указывают только на стандартные схемы EBS, т. Е. INV.table_name, которые нам нужно будет изменить в APPS. table_name. Выходные данные GS CC не отображают каких-либо нарушений в отношении зарегистрированных пользовательских схем в формах и отчетах, т.е. доступ к таблице через нашу XXSCHEMA не указан в результатах GS CC.

Мы сомневаемся, что формы и отчеты Oracle могли бы выбирать данные из пользовательских таблиц (зарегистрированных схем) напрямую, то есть XXSCHEMA.table_name без использования синонима APPS, поскольку это не указано в результатах GS CC. ,

Может кто-нибудь посоветовать, пожалуйста?

С уважением, Тиа go

1 Ответ

0 голосов
/ 19 февраля 2020

EBS 12.2 является просто продолжением стандарта, согласно которому пользовательские формы и отчеты должны ссылаться на объекты, принадлежащие APPS *

Хорошей практикой является исправление форм и отчетов, которые не указывают на отредактированное представление APPS вместо указания на таблицу EBS (например, apps.per_all_people_f вместо hr.per_all_people_f или apps.custom_table1 вместо xxschema.custom_table1).

Поскольку формы и отчеты будут выполняться с использованием APPS с контекстом конечного пользователя, рекомендуется, чтобы один из них не квалифицировал редакцию представления (например, просто используйте per_all_people_f). Ссылки на зарегистрированные схемы, которые являются пользовательскими, также должны следовать этой практике.

Почему?

- Oracle Безопасность EBS основана на APPS. Когда конечные пользователи входят в EBS, устанавливается контекст сеанса, который определяет доступ пользователя.

Oracle исторически утверждал, что настройки должны использовать объекты, принадлежащие APPS, потому что настройка (например, форма или отчет) будет использовать контекст пользователя во время выполнения для создания наборов результатов, которые соответствуют привилегиям конечного пользователя.

- С EBS 12.2, выталкивающей оперативное исправление и его многочисленные компоненты, Oracle заставляет нас продолжать использовать этот APPS centri c подход (как правило, это отредактированные представления, принадлежащие APPS). Отказ от использования отредактированного представления APPS может привести к ошибочным результатам.

Можно запросить ваши выпуски:

SELECT level,
de.edition_name,
de.parent_edition_name,
de.usable
FROM dba_editions de
START WITH de.edition_name = 'ORA$BASE'
CONNECT BY PRIOR de.edition_name = de.parent_edition_name
ORDER BY de.edition_name

Имейте в виду, что не ссылаясь на отредактированное представление APPS отсеянной или пользовательской таблицы. может привести к увеличению числа записей назад (искажая функционирование форм и отчетов).

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

...