Вот тут достаточно понятно написано про гейтвей, его функционал и настройки.

http://docs.oracle.com/cd/B28359_01/appdev.111/b28424/adfns_web.htm#BGBBHAEC

Если всё настроено, то в итоге нужно будет обращаться к урлу формата

protocol://hostname[:port]/virt-path/[[!][schema.][package.]proc_name[?query_str]]

где [schema.][package.]proc_name - это наш самописный пакет с процедурой, которая и будет response генерить посредством PL/SQL

haXbatbankir1980Переписал эти web приложения на ExtJs c Ajax по demand процессам и всё летает, все довольны :)

А чем не угодил встроенный Jquery? EPG (embedded pl/sql gateway) почему не заменили на Apex Listener?

Не угодил тем, что он какой то обкастрированный. Потому что всё это тянется с DB сервера грубо говоря. Да и дизайнить в Apex достаточно сложновато, чуть не стандарт - так сразу приходится долго ковыряться. А стандарт достаточно убогий. Сразу полный ajax интерфейс не получишь.
Настройки кэширования разных файлов вообще непонятно как делается. Походу оно вообще не выдает хедэры для кэширования и всегда тянет все файлы (js, картинки и тп) с сервера.


Сначала работали с апач и mod_plsql, после недели-двух работы сервер начинал жутко тормозить и приходилось перезагружать apache.

Наш DBA как я понимаю после этого и перевел работу на Listener. Еженедельные затыки не наблюдаются, но скорость работы в целом не айс.
На настройки сервера не пенять, DBA у нас хороший :)

ДА и вообще, как говорится Кесарю - кесарево.
Не должна БД заниматься генерацией Web UI и клиентской логики работы.

Даже сами разработчики оракла такое пишут, правда чёт к своему продукту не активно применяют. Однобоко получается.

авторOverview of PL/SQL Web Applications

Typically, a Web application written in PL/SQL is a set of stored subprograms that interact with Web browsers through HTTP. A set of interlinked, dynamically generated HTML pages forms the user interface of a web application.

The program flow of a PL/SQL Web application is similar to that in a CGI PERL script. Developers often use CGI scripts to produce Web pages dynamically, but such scripts are often not optimal for accessing the database . Delivering Web content with PL/SQL stored subprograms provides the power and flexibility of database processing. For example, you can use DML, dynamic SQL, and cursors. You also eliminate the process overhead of forking a new CGI process to handle each HTTP request.


То что CGI скрипты не оптимальны для оперирования с БД - это они написали. А то, что в APEX они пытаются сделать инструмент для дизайнинга WEB приложений, а сам APEX практически на PL/SQL написан (утрирую конечно :) ) и как бы тоже не предназначен для этого - про это они не пишут :)

Так что мы просто разделили процессы.
WebUI делает ExtJS, а выдачу и обработку данных - процедуры доступные через APEX demand процессы.

У нас используется Listener сейчас.

Даже сам Apex Application Builder тормозит. Бывает картинки рендерит через 2-3 секунды после открытия страницы.

Например,
https://ora-crs-scan.ldc01.l:1443/i/eba/img/eba_launchpad.png

Blocking 3ms
Waiting 7,03 s
Receiving 0.500ms

Это не моё приложение, эта картинка тянется в аппбилдере апексовском.
И хром ее из кэша не берет, ибо респонс хедер картинки выглядит так



Как видите, ничего тут про кэш нет.

Так медленно не всегда открывается, бывает и быстро открывается.
Всё тоже самое с другими ресурсами, то быстро откроет, то несколько секунд открывает.


А вот пример запроса обычной страницы с одной таблицей.




В хроме показывает время

Blocking 8ms
Connecting 4ms
SSL 3 ms
Sending 0ms
Waiting 4,31 s
Receiving 3ms

На странице отражается 1 таблица на основе селекта.
Хочу заметить, что селект этот накрученный с использованием функций в пакете. Для выборки нужных данных простой селект не сделать. Думаю именно из-за этого и тормоза. Но как еще тогда выборку отразить? Полностью рисовать таблицу через htp.p в процедуре?

Но и время выполнения, если я правильно понял в дебаге, этого селекта как бы и незначительно.
0.00229 Execute Statement: SELECT decode(R.....

а вот что дальше происходит мне непонятно

0.00018 print column headings
4.95481 rows loop: 15 row(s)

Вот они 5 секунд и всплыли.
Что означает rows loop:15 row(s) ?



А вот доставка практически аналогичных данных, что в этой таблице отражается для ExtJs приложения.

Респонс недеры




время
Sending 0.997ms
Waiting 398 ms

В деманд процессе запускается процедура в пакете, которая делает выборку и формирует json формат.

При этом в Apex таблице 15 записей отражается на странице.
А в ExtJs грузится 50 записей этой же выборки на страницу.

Для себя мы вывод сделали в пользу ExtJS.
Время рассудит :)

Ёлки зеленые, а отредактировать сообщение нельзя чтоли? :)
куки страницу растянул...

Кстати, если непонятно в последнем абзаце про доставку данных,то это запрос данных с сервера для таблицы.
Запрос вот так выглядит


Remote Address:192.168.7.74:8085
Request URL: http://192.168.7.74:8085/apex/wwv_flow.show
Request Method:POST
Status Code:200 OK

Request Headers

Accept:*/*
Accept-Encoding:gzip,deflate,sdch
Accept-Language:ru-RU,ru;q=0.8,en-US;q=0.6,en;q=0.4
Connection:keep-alive
Content-Length:235
Content-Type:application/x-www-form-urlencoded; charset=UTF-8
Cookie:ORA_WWV_RAC_INSTANCE=1; O
Host:192.168.7.74:8085
Origin: http://192.168.7.74:8085
Referer: http://192.168.7.74:8085/dmds.html
User-Agent:Mozilla/5.0 (Windows NT 5.1) AppleWebKit/537.36 (KHTML, like Gecko) Chrome/34.0.1847.137 Safari/537.36
X-Requested-With:XMLHttpRequest
Form Dataview sourceview URL encoded
p_request:APPLICATION_PROCESS=GETDEMANDS
p_instance:8674961479752
p_flow_id:999
p_flow_step_id:3
p_arg_names:3_PNAME
p_arg_names:3_JSONDATA
p_arg_values:dmds.html
p_arg_values:{"page":1,"start":0,"limit":50}

Form Data

p_request:APPLICATION_PROCESS=GETDEMANDS
p_instance:8674961479752
p_flow_id:999
p_flow_step_id:3
p_arg_names:3_PNAME
p_arg_names:3_JSONDATA
p_arg_values:dmds.html
p_arg_values:{"page":1,"start":0,"limit":50}


Тут 192.168.7.74:8085 - это на моем компе крутится nginx
все ссылки содержащие "/apex/" он проксирует на https://ora-crs-scan.ldc01.l:1443

Так что получается, что запросы по урлу
https://ora-crs-scan.ldc01.l:1443/apex/wwv_flow.show
и не тормозят вовсе, а вот по
/apex/f?p... - тормозят.

Значит дело не в работе Listener или mod_plsql, т.к. это просто "приемопередатчики"...

kasikНо тут уже нужен проф. верстальщик, такак все будет на клиенте(если что то замороченное). И выйдет, что ты по сути превратишься в фронт-энд разработчика.

Что мы приобретаем и что теряем в данном расскладе?

PS: скорее всего получится много ручной работы, такак генерации старниц не будет как таковой, а описание их все будет на разработчике. И никакого декларативного подхода, если токо не считать такого подхода "вшитого" в сам фраемворк...

Верстальщик чего? Кода? HTML?

Я переписал одно из приложений на ExtJS всего за неделю (не с утра до вечера сидел, есть еще и основная работа) с учетом того, что это мой первый опыт разработки ExtJS и большинство времени ушло на изучение мануала по ExtJS и прикрутки ExtJS к APEX.

Чтобы создавать страницы на APEX тоже потребуется грамотный кодер. Будет много нюансов всплывать, если что посложнее надо будет делать. Сам ExtJs фреймворк достаточно прост для изучения, если есть опыт работы с ООП языками.

Если уж совсем нужно вывести только одну табличку без наворотов, то да, проще только апекс заюзать.

авторскорее всего получится много ручной работы, такак генерации старниц не будет как таковой

вот тут не соглашусь :)

взять хотя бы вот этот пример
http://docs.sencha.com/extjs/4.2.1/extjs-build/examples/grid/list-view.html

Отображение таблицы с подгруженными данными. Нет тут в коде ничего из HTML. Его фреймворк сам генерит.
Лезть в HTML придется разве что при необходимости нестандартных отражений стандартных элементов.

Верстальщик HTML тут точно не нужен :)

Конечно если сравнить формирование простой таблицы, вроде этого примера, то в апексе конечно быстрее реализовать.
А вот представьте, что теперь надо сделать кнопку добавить и добавлять в эту таблицу данные.
В ExtJS это делается по сути в несколько строк в текущий код. И никаких перезагрузок страницы при этом. Запись будет добавена на сервер при создании записи в таблице автоматически. При этом можно отработать и успешность/неуспешность отработки на сервере и в зависимости от этого сделать или коммит или режект записи на клиенте. Можно даже отправку на сервер сделать ручной. Добавлять в оффлайне записи, подключить коннект и всё "сбросить" на сервер. Всё это делается просто изменением пары параметров у объектов в коде. Точнее autoSync у объекта store вместо true поставить false. И добавить кнопку при нажатии на которую запустить store.sync(); - 3 строчки кода.

SvDevSvDevВ данном случае тормозит запрос и его надо отлаживать, к апексу это не имеет отношения.
Точнее может иметь, а может не иметь, тут надо смотреть.

например, если выставить тип столбца значения, на основе запроса
Display as Text (based on LOV, does not save state)
и поставить на него сортировку, понятно, что запрос будет дописан очень жестко с подзапросом, и может начать тормозить,
и такие опции лучше не использовать, лучше в source руками запрос дописать,

но там очень много приколов оптимизации запросов, которые к апексу вовсе отношения не имеют,
тут надо смотреть и отлаживать сам запрос.


Посмотрел этот тормозящий запрос в навигаторе. Если брать как есть, навигатор показывает выполнение 5 сек и отбирает при этом 83 записи из нескольки тысяч.

из селекта убрал все функции, составил только столбцы таблицы. Из условия where так же убрал одну функцию.
Теперь стало выполняться 1,5-2 секунды.
Все остальные условия отборки происходят по полям таблицы.

Условие муторное. Накладывается фильтр по полям, который задает пользователь в апексе.
Причем не не просто (field=:p1_field or :p1_field is null) и так по всем полям, а есть еще и фильтрация сразу по нескольким полям and и or (группа).

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

Ввиду того, что в деманд процессе при использовании ExtJS я выборку делаю на PL/SQL, то при необходимости я могу сам сгенерировать запрос с нужными условиями в where тем самым исключив ненужные обработки оптимизатором и т.п.

например.
мне нужно сделать выборку из таблицы select field1, field2 from t

и сделать фильтр по обоим полям.

Для апекса это возможно только в виде




В PL/SQL я делаю так




это простейший пример для понимания. На самом деле такой подход целесообразен когда where сложный.

Еще пример, у меня есть поле фильтра по значению в котором я хочу отобрать клиентов по коду или по наименованию или по ИНН. Быстрый поиск так сказать.

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

Еще пример.
Допустим есть у меня таблица со списком клиентов, у каждого клиента есть счета и каждый клиент имеет признак офиса обслуживания.
Мне нужно иметь возможность отфильтровать клиентов по офису или найти клиента со счетом (или счетами по маске, например).
счета у меня хранятся в отдельной таблице.
в Апекс мне всегда нужно иметь в условия отбора проверку наличия счета у клиента по маске и условие отбора по признаку офиса. Естественно в обоих условиях есть и проверка на нулевое значение.
Получается типа


Для ExtJS я просто сделаю проверку на пустое значение :p1_accmask и если оно пустое, то мой запрос будет выглядеть так


а если пустое поле :p1_office, то ничто мне не мешает вообще другой запрос сделать, например



или


В зависимости от того, чей план выполнения лучше.

SvDevbankir1980Например,
https://ora-crs-scan.ldc01.l:1443/i/eba/img/eba_launchpad.png

Blocking 3ms
Waiting 7,03 s
Receiving 0.500ms

Это не моё приложение, эта картинка тянется в аппбилдере апексовском.
И хром ее из кэша не берет, ибо респонс хедер картинки выглядит так

Как видите, ничего тут про кэш нет.

Почему это, а ETag чем не устраивает ?


Тем, что картинка отражается на странице через несколько секунд, а не сразу :)

Да, хром показывает что статус этого файла картинки Not Modified и в итоге берет ее из кэша.
Но делает это он только после получения ответа с этим самым тегом ETag. И получает он этот ответ через 7 секунд.
Да если бы и не было ETag, и файл модифицировался, не думаю, что 30 кБ этого файла тянулись бы с сервера более нескольких милисекунд. Так что что есть, что нет - особой разницы нет. Всё равно долго.

Конечно, я не спорю о возможностях Апекс при правильном подходе, но мне лично кажется, что пусть у меня сначала откроется страница с пустой таблицей моментально с надписью "Загрузка данных" и крутящимся колесом, а потом в течение 1-2-3 секунд там появятся данные, чем ждать пока вся страница отобразится в браузере через 1-2-3 секунды.
Просто иногда разбражает, думаешь что комп тормозит или инет отвалился или...

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

Как то так...

Я про это еще на 1-й странице написал :)

Мы и юзаем апекс чисто только ради аутентификации и сессионности. Ну и 3 глобальные переменные сессии - логин, имя пользователя и офис, чтобы при каждом коннекте не селектить из таблицы. Хотя по большому счету и без них можно. Их же можно и на клиенте хранить.

От Apex мы ни одного HTML тега не получаем и его ресурсами (css, js, картинки) вообще не пользуемся.

ресурс /f?p=... юзается только один раз для установления сессии.
Да и то сам Апекс нам его подкидывает - редирект на Home page при запросе урла аутентификации. В ней (хомпейдж) есть процесс After Footer, который нафиг всё, что нагенерил апекс скидывает и возвращает json формат в котором success=true (аутентификация успешна) instance_id (который идет в паре с кукис сессии и мы его в дальнейшем используем при ondemand процессах).
если логин неправильный, то апекс редиректит на страницу логона (101-я обычно), там тоже всё нафиг скидывается в afterfooter и возвращается success=false reason = authentification failed. Если таймаут сессии на сервере происходит, то апекс всегда и перекидывает на 101-ю и мы получаем сигнал отвала сессии и далее обрабатываем уже как нам нужно.
Например, у меня в одном месте сделано так, что если при отправке данных на обновление из таблицы возвращается такой сигнал, то у меня автоматом выскакивает окно ввода логина/пароля и после успешной аутентификации отправка данных повторяется и всё сохраняется. В итоге, если забил какие то данные в таблицу а сессия вдруг отвалилась, данные у меня не потеряются.

kasikСделайте что бы контент для таблицы подтягивался асинхронно с загрузкой самой страницы, то есть загрузится каркас страницы а контент уже после через ajax.

Ага, и получим траблы с пагинацией по этой таблице :) знаем, плавали :)

Michael Isaev
Однако, и на APEX написаны достаточно нагруженные приложения, например,


Oracle Learning Library (некоторое время назад Metalink был тоже на APEX)

Ссылки на приложения, написанные на APEX от Oracle

Топик "Сайты на APEX" с форума



Посмотрел.

Не нашел ни одного сайта, где работа идет с табличными цифровыми данными. В большинстве своем сайты-визитки, где даже динамическая подгрузка не нужна - достаточно и переход по урлу.
Основной контент - это текстовые данные, хранение которых наверняка организовано "в одной" таблице в виде html без необходимости выборки по 5-10 и более таблиц сразу да еще с миллионами записей да еще с вычислениями.

простой пример.

Нужно мне отобразить средние остатки по счетам клиентов за год. Запрос будет выполняться несколько секунд (о наличии хранилища данных с подготовленными данными не говорим, это уже другая тема). Будет ли это открываться страница несколько секунд или загружаться непосредственно таблица несколько секунд - это очень разные вещи и отношение к этому разное у пользователя. В случае с ExtJS пока грузятся данные в таблицу, я могу еще что то открыть или делать в этом же приложении не дожидаясь окончания загрузки. И делается это всё без танцев с бубном :)

Открытие одной страницы в бизнес приложении может равняться по затрачиваемым ресурсам открытию нескольких десятков таких вот сайтов-визиток одновременно. Активное использование Ajax распараллеливает процесс. Если мне необходимо загрузить информацию о клиенте с разных таблиц-источников (контакты, счета, документы и тп). То в случае с ExtJS у меня будет несколько запросов к БД и каждый будет выполняться в своем отдельном процессе, а в случае с АПЕКС, если опять же не прикручивать аякс, в одном последовательно.
Пока что интегрировать аякс в Апексе без танцев с бубном практически невозможно.
Чтобы мне сделать независмо подгрузку данных в разные таблицы, мне нужно сделать страницу с кодом, который будет подгружать регион динамически (необходимо писать при этом JavaScript и получить проблемы с пагинацией или плагины какие-нибудь) и сделать страницы с этими регионами. При этом грузится в результате запроса вся страница с этим регионом, а в итоге задействованы только данные региона, всё остальное отбрасывается, для ускорения процесса приходится еще и шаблон отдельный делать для таких страниц, с минимумом html, чтобы чисто только данные региона возвращались. Технология прям супер, ничего не скажешь.