Меню

Практические рекомендации по поиску источников данных - таблиц БД

Консультантам, при подготовке Технического задания программисту, необходимо указывать объекты (таблицы) в базе данных SAP, которые будут использоваться как источники данных. Методике определения этих источников посвящена настоящая статья.

Александр Неловкин, ведущий инженер-программист отдела разработки программного обеспечения центра компетенции SAP филиала «Управление «Укргазтехсвязь» ДК «Укртрансгаз». Опыт внедрения и сопровождения систем SAP – более 14 лет. Богатый опыт по консультированию и подготовке разработчиков для SAP систем. Более десятка проектов внедрения и модернизации системы SAP. Навыки и опыт работы со всем инструментарием SAP ABAP Workbench практически во всех модулях системы.

Обязательным элементом Технического задания (ТЗ) на разработку является указание источников данных. Под источником данных здесь подразумевается таблица Базы данных (БД), в которой хранится информация.

Типичная, ныне активно используемая, методика поиска источника данных для полей экрана выглядит так:

  1. Запускается транзакция.
  2. Открывается нужный экран.
  3. Курсор ставится на интересующее поле и вызывается Справка (нажимается F1)
  4. В окне справки нажимается кнопка Техническая информация ( )
  5. Значения полей Имя таблицы и Имя поля в открывшемся окне и считают источником данных.

Проблема, собственно, заключается в том, что в ряде случаев в поле Имя таблицы содержится имя структуры ABAP-словаря, а не имя таблицы. Структуры ABAP являются описанием составных типов данных и не имеют (в отличие от таблиц словаря) отображения в Базе данных (БД). Следовательно, сделать запрос к структуре и получить данные из БД невозможно.

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

Для примера, попытаемся определить таблицу-источник данных для поля Группа закупок в Заказе на поставку. Поле это находится на закладке ОргДанные транзакции ME22N (Изменение заказа на поставку), см. Рисунок 1.

Рисунок 1

Используя вышеописанную типичную методику, определяем, что для данного поля в Имя таблицы содержится «MEPO1222» и в Имя поля содержится «EKGRP», см. Рисунок 2.

Рисунок 2

MEPO1222 – это имя структуры. Она не может быть источником данных. Значит, будем определять, из какой таблицы берутся данные для поля Группа закупок

Для определения предлагается использовать SQL-трассировку. Основная идея заключается в том, чтобы оттрассировать обращение транзакции к БД и, проанализировав, к каким таблицам было обращение, определить, где хранятся интересующие нас данные.

Задача осложняется тем, что, как правило, трейс-лист получается довольно большой и приходится анализировать большой объем данных.

Задачу можно значительно облегчить, прибегнув к небольшой уловке. Если интересующее нас поле открыто для редактирования, то можно изменить его значение, и оттрассировав процедуру сохранения, искать в трейс-листе только операторы обновления таблиц (которых будет на порядок меньше, чем операторов считывания таблиц).

Вернёмся к нашему примеру. Нам понадобится два открытых режима. В первом режиме запускаем транзакцию ME22N и переходим на закладку ОргДанные (см. Рисунок 1).

Во втором режиме запускаем транзакцию ST05 - Трассировка SQL (см. Рисунок 3)

Рисунок 3

Нажимаем кнопку Activate Trace и возвращаемся в окно первого режима (см. Рисунок 1). В окне первого режима изменяем значение поля Группа закупок. В нашем примере изменим значение «011» на «012» (выбор значений совершенно случайный). После этого нажимаем кнопку Сохранить (

Если хотите прочитать статью полностью и оставить свои комментарии присоединяйтесь к sapland

У вас уже есть учетная запись?

Войти

Обсуждения Количество комментариев7

Комментарий от  

Марина Делинская

  |  14 июня 2012, 17:55

Спасибо большое! Очень полезная статья

Комментарий от  

Михаил Сидорочкин

  |  25 июня 2012, 10:53

Спасибо большое! Очень полезная статья

Гораздо быстрее можно найти используя Debugger Scripting. В случае его использования мы сравниваем значение переменной (структуры) и находим место где оно изменилось (в программе ей присваивается значение структуры - MEPO1222_pbo), далее по стеку выясняем откуда она заполняется. Написав один раз скрипт, мы избавим себя от необходимости анализа  большого трейса.

Комментарий от  

Михаил Сидорочкин

  |  25 июня 2012, 11:09

Гораздо быстрее можно найти используя Debugger Scripting. В случае его использования мы сравниваем значение переменной (структуры) и находим место где оно изменилось (в программе ей присваивается значение структуры - MEPO1222_pbo), далее по стеку выясняем откуда она заполняется. Написав один раз скрипт, мы избавим себя от необходимости анализа  большого трейса.

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

Комментарий от  

Александр Дублин

  |  29 июня 2012, 11:31

Гораздо быстрее можно найти используя Debugger Scripting. В случае его использования мы сравниваем значение переменной (структуры) и находим место где оно изменилось (в программе ей присваивается значение структуры - MEPO1222_pbo), далее по стеку выясняем откуда она заполняется. Написав один раз скрипт, мы избавим себя от необходимости анализа  большого трейса.

Михаил.
 
Если Вы можете написать статью-рекомендацию по поиску таблиц - источников данных с помощью Debugger Scripting, то мы с удовольствием её опубликуем.
 
С уважением, Александр Дублин.

Комментарий от  

Юрий Сычов

  |  21 сентября 2012, 06:05

Михаил.
 
Если Вы можете написать статью-рекомендацию по поиску таблиц - источников данных с помощью Debugger Scripting, то мы с удовольствием её опубликуем.
 
С уважением, Александр Дублин.

Пока статей на русском нет, можно здесь почитать
 
scn.sap.com/people/stephen.pfeiffer

Комментарий от  

Александр Неловкин

  |  25 сентября 2012, 09:30

Гораздо быстрее можно найти используя Debugger Scripting. В случае его использования мы сравниваем значение переменной (структуры) и находим место где оно изменилось (в программе ей присваивается значение структуры - MEPO1222_pbo), далее по стеку выясняем откуда она заполняется. Написав один раз скрипт, мы избавим себя от необходимости анализа  большого трейса.

Возможно и быстрее. Только далеко не везде стоит 7 версия, начиная с которой появился Debugger Scripting. Описанный же мной способ универсален и работает даже с версии 3.0 (это самая ранняя версия с которой мне приходилось работать), и, вполне возможно, с более ранними  :)

Комментарий от  

Мурат Бидов

  |  14 августа 2013, 17:02

Отличная статья! Помогло на практике)