Я работаю с Oracle EBS более 18 лет, пройдя через полную эволюцию от 11i до R12. На протяжении этой долгой карьеры разработка пользовательских отчетов всегда была ключевой обязанностью, которую невозможно обойти. Вокруг этой работы год за годом возникали определенные проблемы, которые так и не были решены фундаментально.
Я работаю с Oracle EBS более 18 лет, пройдя через полную эволюцию от 11i до R12. На протяжении этой долгой карьеры разработка пользовательских отчетов всегда была ключевой обязанностью, которую невозможно обойти. Вокруг этой работы год за годом возникали определенные проблемы, которые так и не были решены фундаментально.
Эта статья не преследует цель рассказать историю. Она просто стремится честно задокументировать проблемы, которые я наблюдал и испытывал на протяжении многих лет, а также попытки, которые я предпринимал для их решения. Надеюсь, она послужит ориентиром для коллег, сталкивающихся с аналогичными вызовами.
В экосистеме EBS существует фиксированный набор процедур между завершением написания SQL и моментом, когда отчет становится доступным для выполнения конечными пользователями. Этот процесс является разумным и необходимым в рамках архитектуры EBS — он обеспечивает безопасность, изоляцию множества организаций, проверку параметров и планирование запросов. Однако с точки зрения эффективности разработки его стоимость действительно высока.
В частности, после завершения написания и тестирования SQL разработчики должны последовательно выполнить следующие операции:
Эти шаги не включают сложную бизнес-логику — это чисто конфигурационные задачи. Но для простого, возможно, разового отчета стартовые затраты этого процесса чрезмерно высоки. Отчет, написание SQL для которого занимает всего 20 минут, часто требует более часа для прохождения всего процесса, причем большая часть времени тратится на навигацию по меню, заполнение полей и ожидание ответов страниц.
Что еще более важно, если отчет требует корректировки SQL-логики или определений параметров после тестирования, значительная часть вышеуказанных шагов должна быть повторена. Это представляет собой существенное узкое место для сценариев разработки, требующих быстрой итерации.
Это проблема, которую я считаю ключевой и наиболее влияющей на пользовательский опыт.
Родной формат вывода параллельных программ EBS — это текстовый файл (обычно .out или .txt). Будь то отчет .rdf, разработанный с помощью Report Builder, или вывод хранимой процедуры PL/SQL, то, что в конечном итоге доставляется пользователям, по сути, является текстом фиксированной ширины или разделенным разделителями.
Однако то, что нужно бизнес-пользователям в их повседневной работе, почти без исключения, — это файлы данных в формате Excel. Это создает давно существующий "промежуточный этап": пользователи должны скопировать и вставить содержимое текстового файла в Excel, а затем использовать функцию "Текст по столбцам" для разделения его на несколько столбцов.
Этот этап связан с несколькими конкретными техническими проблемами:
Во-первых, проблемы ширины полей. Разработчики отчетов должны предварительно задать ширину отображения для каждого выходного поля. Если фактическая длина данных поля превышает эту заданную ширину (например, поля свободного текста, такие как описания товаров или имена поставщиков), EBS обрабатывает это путем автоматического переноса строки, вставляя символ переноса строки в текстовый файл. Этот перенос строки выглядит нормально в текстовом просмотрщике — содержимое просто отображается на новой строке. Но когда пользователи копируют весь текст в Excel и выполняют разделение по столбцам, Excel распознает этот перенос строки как терминатор строки, что приводит к неправильному разделению одной записи на две или более строк. Выравнивание столбцов всех последующих записей полностью нарушается. Пользователи должны вручную находить и исправлять эти ошибки или перенастроить ширину полей отчета и повторно отправить запрос.
Во-вторых, проблемы кодировки символов. Формат кодировки по умолчанию текстового файла часто не соответствует кодировке Excel по умолчанию для открытия файлов. Это особенно проблематично при обработке многобайтовых символов, таких как китайский или японский, что часто приводит к нечитаемому тексту. Пользователи должны вручную выбирать правильную кодировку при открытии текстового файла или указывать формат кодировки при импорте в Excel. Для нетехнических бизнес-пользователей это дополнительное и ненужное бремя.
В-третьих, обработка форматов чисел и дат. Числа и даты, экспортируемые в текстовые файлы, обычно находятся в формате обычного текста. После вставки в Excel пользователи должны вручную устанавливать форматы ячеек, прежде чем смогут выполнять такие вычисления, как суммирование или усреднение. Когда задействованы разделители тысяч, десятичная точность или форматы отображения дат, требуются дополнительные шаги ручной настройки.
В-четвертых, эффективность обработки больших объемов данных. Когда отчет возвращает большой объем данных (например, более 10 000 строк), операция копирования-вставки и ручного разделения столбцов сама по себе становится очень трудоемкой. Кроме того, производительность Excel при вставке больших объемов текста не всегда стабильна, что часто приводит к зависаниям или отсутствию ответа.
Эти проблемы широко распространены как в стандартных отчетах EBS, так и в пользовательских отчетах. Строго говоря, это не "ошибка" — это дизайнерское решение из эпохи создания EBS, когда текстовый вывод был основным методом кросс-платформенного обмена данными. Но в сегодняшней бизнес-среде это дизайнерское решение серьезно оторвано от реальных сценариев использования пользователей.
Бизнес-подразделения часто генерируют непериодические потребности в анализе данных в своей повседневной деятельности. Например:
Характеристики таких требований: относительно понятная SQL-логика, ограниченный объем данных, высокие требования к своевременности и высокая вероятность однократного использования без повторения.
В рамках стандартного пути разработки EBS даже разовый отчет должен пройти полный процесс регистрации — от определения исполняемого файла до его подключения к группе запросов. Это означает, что разработчики должны повторять конфигурационные задачи, не связанные с бизнес-логикой, каждый раз при реагировании на такие разовые запросы.
Другой распространенный обходной путь — разработчики выполняют SQL напрямую в инструментах баз данных (таких как PL/SQL Developer или Toad), копируют результаты и отправляют их пользователям в Excel. Этот подход обходит процесс регистрации EBS и значительно быстрее, но он также обходит контроль доступа к множеству организаций и проверку прав данных EBS, создавая потенциальные риски безопасности данных. Он также не может использовать параллельный менеджер для унифицированного планирования и ведения журналов.
Описанные выше проблемы не являются новыми. Фактически, в сообществе пользователей EBS и среди практиков эти трудности давно являются открытым секретом. Однако на протяжении многих лет отраслевые решения в основном сосредоточивались на следующих подходах, все с ограниченной эффективностью:
Ни один из этих подходов не меняет фундаментально модель разработки отчетов EBS. Разработчики по-прежнему должны вкладывать усилия как на уровне написания SQL, так и на уровне настройки системы, а пользователи по-прежнему должны тратить дополнительное время как на получение, так и на очистку данных.
Основываясь на вышеуказанных проблемах, я попытался создать независимый инструментальный уровень отчетности, названный SQLVantage. Его позиционирование — не замена параллельного менеджера EBS, а скорее дополнительный уровень быстрого реагирования, охватывающий следующие сценарии:
Центральная философия дизайна этого инструмента: устранить самую трудоемкую, но не связанную с бизнес-логикой процедурную работу в разработке отчетов EBS, позволяя разработчикам сосредоточиться непосредственно на двух ключевых элементах — SQL и конфигурации параметров.
Конкретный подход заключается в следующем:
Со стороны разработки разработчикам нужно только заполнить имя отчета, написать SQL-запрос и определить параметры запроса (имя параметра, тип данных, отображаемая метка, значение по умолчанию) в инструменте. После сохранения отчет становится немедленно доступным. Не требуется определять исполняемый файл, регистрировать параллельную программу, настраивать наборы значений или подключать группы запросов. Весь процесс настройки может быть завершен в течение 3-5 минут.
С точки зрения безопасности данных инструмент повторно использует механизм аутентификации пользователей EBS, гарантируя, что только пользователи с соответствующими ответственностями EBS могут получать доступ к отчетам и запускать их. Логика контроля доступа к множеству организаций (MOAC), задействованная в SQL-запросах, остается в самих SQL-запросах и контролируется разработчиками в соответствии с реальными бизнес-требованиями.
С точки зрения формата вывода инструмент напрямую генерирует Excel-файлы в формате .xlsx. Каждое поле результата запроса соответствует одному столбцу Excel, а каждая строка данных соответствует одной строке Excel. Ширина полей автоматически адаптируется к содержимому, и длинные тексты не вызывают переносов строк, которые могли бы повредить данные. Числа, даты и другие типы данных сохраняют свои исходные атрибуты типов при экспорте, позволяя пользователям сортировать, фильтровать и выполнять вычисления сразу после открытия Excel-файла.
С точки зрения расширяемости помимо Excel, инструмент также поддерживает вывод в формате JSON, облегчая интеграцию с внешними платформами данных или BI-системами.
После периода внутреннего использования этот инструмент действительно принес улучшения эффективности в следующих областях:
В то же время я должен указать на ограничения этого инструмента:
В течение 18 лет EBS была корпоративной платформой приложений, фундаментальная архитектурная стабильность и строгость которой не вызывают сомнений. Но именно из-за этой стабильности некоторые дизайнерские решения, которые были разумными в свое время, выглядят медлительными и громоздкими в сегодняшних сценариях использования.
Стоимость процесса разработки отчетов, текстовый формат вывода, путь реагирования на разовые потребности — эти проблемы возникли не только сегодня. Просто в сегодняшней среде их стоимость стала более очевидной. Бизнес-ритмы ускоряются, требования предприятий к реагированию на данные растут, а инструменты и процессы, которые мы используем, застряли в ушедшей эпохе.
SQLVantage — это попытка, которую я предпринял на основе этих проблем. Это не столько инновация, сколько упрощение и реорганизация существующих процессов. Если эта статья найдет отклик у некоторых коллег или предоставит справочный взгляд для тех, кто размышляет над аналогичными проблемами, она достигнет своей цели.
Пиша это, я не намерен представлять это как "историю успеха". Это просто человек, которого неоднократно беспокоили конкретные проблемы в конкретных рабочих сценариях, пытающийся улучшить эти проблемы по-своему. Как далеко может зайти этот путь, еще предстоит проверить на практике. Но по крайней мере, направление верное — позволить разработчикам вернуться к самому SQL, позволить пользователям вернуться к самим данным и позволить инструменту обрабатывать ненужные вещи между ними.