Хочу задать вопрос APEX-общественности

Для одного проекта я сделал решения не совсем типовой задачи - применил отдельный сервер с APEX-ом в качестве proxy для доступа к контенту "рабочей базы" (РБ).
То есть буквально все что нужно для UI APEX-приложения лежит вне РБ. Ну и разумеется http-рендеринг тоже не напрягает РБ.
Но как то так получается что я нынче слегка удаляюсь от темы APEX-а, но может вдруг кому-то еще будет интересно.

https://apex.oracle.com/pls/apex/f?p=34134
Для входа даже логин/пароль вводить не нужно - есть кнопочка гостевого входа.
Там в описаниях и хелп-страницах есть побольше подробностей

Если общественности будет интересно, то я напрягусь и выложу в какой-нибудь паблик ресурс коды и описание
?
Не пропадать же добру

1. "Ядро" в виде пакетов для трансфера данных через dblink и основных UI-обьектов было написано для оплаченной работы в 2017
Но я уже сменил работу
2. Пример из Oracle-ой "песочницы" был написан в качестве портфолио для хэдхантера.
В расчете на одного очень солидного работадателя.
Но его (работодателя) это не заинтересовало.

Вот это последнее сильно печалит. Не конкретный работодатель, а отношение к APEX-у.
Вот и этот раздел форума SQL.ru пик популярности прошел где-то на версии 4.2

APEX очень крут по возможностям. Samples конечно хорошо, но это 20% от возможностей APEX-а.
Мне кажется, корпорация Oracle могла бы больше сделать для продвижения APEX-а.
Наверное им не до этого. Они счас выкладываются на Oracle-Cloud - пытаются тягаться с Amazon и Google

Oracle.com - хорошо что есть, но на нём предельно жлобский лимит на CLOB/BLOB-пространства,
необходимого для трансфера CLOB/XML данных. Так что регулярно будут "выпадать" сообщения о невозможности расширить таблицы
Ну и гранты там на минимуме
Вот список приложений , который можно увидеть в "нормальном" состоянии APEX-сервера

APEX написан на APEX-е - кто бы мог подумать :)

Хорошо. Сделаю.
Постараюсь к концу мая или + еще неделя

Просто сначала длинные выходные включая "Зенит-Чемпион"
Потом вдруг аврал, который все еще продолжается.

---------------

APEX нужен не ниже 18.1 - у версий ниже есть траблы с jquery
Обнаружилось по работе с Tree в режиме master-detail
Значит Oracle для Apex.Proxy нужен не ниже 11. У меня в основном Oracle11XE на VM WinXP
Все как-то нет повода попробовать Oracle18XE 64-bit на линуксе.

Для "рабочего" сервера APEX вообще не нужен
Столкнулся уже не раз с тем, что многие не сразу понимают этот простой факт.
Реально многие DBА-ники сразу записывают тебя во врага только за предложение что то поставить на рабочий
и работающий сервер с большими и ценными данными. В лучшем случае предлагают вместе провести ночь за
откатыванием из бэкапа.

На бизнес-сервере нужно
- отдельная схема , в которой ставится пара пакетов и пара таблиц
- наборы грантов для владельца этой схемы для доступа к обьектам
бизнес-приложения в режиме динамических скриптов запросов от имени владельца схемы
причем грантование через роль не катит, только непосредственно на юзера
- отдельный юзер для доступа ТОЛЬКО к таблицам и пакетам указанной схемы
- dblink от APEX.Proxy на этого юзера - так чтобы гранты владельца схемы
недоступны этому юзеру и запросы через открытытй dblink ничего не получат

Для бизнес-сервера ключевые критерии - regexp и DBMS_XMLGEN.
Т.е. не ниже 10-ки, но кажется в 10-ке были какие-то нюансы с DBMS_XMLGEN,
но их можно парировать в коде.

Вспомнил

Вспомнил
В 10-ке нет оператора continue
и приходится в некоторых циклах юзать GOTO в конец LOOP-а

irbis_alВ толк не возьму..это какое то подобие Oracle EM?
(Надеюсь знаете,что это такое...типа web console для базы..правда там ещё функций администрирования и аудита вагон и тележка)
OEM это инструмент DBA - не более и не менее. Какой-либо прикладной функционал туда не пристроить.
Причем инструмент довольно старый и не самый лучший. С Zabbix-ом не тягаться

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

Если проект "свой собственный" и вся база вам доступна безраздельно - конечно же ставьте APEX напрямую и мой вариант не обязателен.
Но...
С помощью APEX.Proxy я смогу подключаться к нескольким рабочим базам - не одномоментно, но по револьверному принципу.
Как то была задумана, начата, но так и не реализована идея "витрины" для сбора и предьявления руководству оперативной
бизнес-статистики с нескольких серверов "в одном окне"

Использовать конструкции вида
select * from table@dblink
терпимо, пока таблиц и view - три-четыре не более

В APEX18 Oracle сделал облегчение - в определении отчетов
я могу задать имя remote_base (т.е. фактически dblink)
из специального набора shared-компонент
И APEX сам выполнит ваш запрос на указанной базе так что
писать в запросах суффиксы не обязательно

В моем проиложении запросы и скрипты
- хранятся как clob обьекты в спец.таблице
- именно как clob передаются на сторону "рабочего" сервера
- из запросов СРАЗУ же делается xml-курсор (DBMS_XMLGEN)
и полученый XML возвращается на APEX для отображения и обработки
- со скриптами посложнее - на extern стороне юзается оператор запуска
execute immediate v_clob ...
но в любом случае возвращается XML

rgnik,

Сорри, речь идет не о dblink а о "REST Enabled SQL Reference"

Вот тут подробнее
https://docs.oracle.com/database/apex-18.1/HTMDB/rest-enabled-sql-updating-components.htm

Впрочем, сам не пробовал

Итак, выкладываю обещанное
Яндекс-диск
https://yadi.sk/d/wifbvQeQDuvSzA

в нем
1) WinXPXE.rar - 1.5 ГБ
виртуальная машина под VMWare Workstation версии не ниже 11
здесь полностью развернутый вариант
Oracle11XE+Apex18.1+Демо-приложение

2) WinXPXE2.rar - 1.4 ГБ
аналогичная VM - имитатор внешней базы для APEXProxy

3) InstallByScript.zip -760 kB
набор скриптов для инсталяции с помощью SQLPlus
а также все обьекты приложения - DDL, HTML, img и пр.

4) APEXProxy_Install.pdf - 420 kB
Описание вариантов и процесса инсталяции

5) APEXProxy_Describe.pdf - 610 kB
Описание приложения

6) APEXProxy_2developer.pdf - 300 kB
немного деталей для программистов

У кого из желающих получится (или не получится) развернуть сабж, стукните
просто интересно - все ли я предусмотрел

Хм... Тихо.
Ладно - сам продолжу.

Может быть люди из Oracle сюда заходят.
Насколько мне известно, развитие cloud-технологий привело к существенному сокращению закупок классических per-server лицензий по всему миру.
Амазоновские облака интенсивно заполняются PostgreSQL и NOSQL базами, в том числе за счет миграций с Oracle.

Дарю бизнес идею.
Создать в облаке оракловый мега-супер-сервер, but with advanced sharing/quoting structure.
А девелоперам приложений предоставить вот примерно такой же как мой сабж доступ из частных локальных или облачных XE-APEX-proxy серверов. Только на решении проблем развертывания и конфигурирования будет экономия (правда за счет devops-ов).
Кроме того (очень важно!), заготовить sample-pattern-ы максимально пригодные для прототипирования, а то эти сэмплы на dept/emp из 80-х реально раздражают.
Паттерны должны соотвествовать званию "best practics" - включать мелкие финты и крупные комбинации от гуру APEX-а вроде Denes Kubicek, Ted Struik etc.
В качестве примера - понятие "конфигурация 1С"

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

Быстро слепить полностью работоспособное приложение на APEX-е по готовым паттернам - реально за 2-3 недели.

Нынче development-frameworks стали мелькать как шмоточные коллекции - полгода и уже новый более модный фасон забивает старые. Часто не успев созреть до реальной эффективности.
Oracle DataBase - практически последний "оплот стабильности" и самый стабильный источник мани-хани персонально для меня.

Нашлось время и желание.
Сделал VMWare виртуалку под 64 разрядный линукс -CentOS7x64+Oracle18cXE+APEX18.2

Как оказалось, в Oracle18cXE имеется 2 instance баз данных - root и так называемая plugable, предназначенная для контейнерного подключения/развертывания . Соответствующие имена сервисов
- XE и XEPDB1. И это оказалось очень кстати для развертывания приложения APEX.Proxy.
APEX установлен на XEPDB1, а XE используется как "внешняя рабочая" БД - из XEDB1 "протянут" дблинк на XE.
так что для демонстрации работы с dblink-Ом хватило одной VM.

Ограничения на ресурсы 18XE очень даже щадящие - 2 Гб + 4 ядра.
На машине CoreI7+DDR4+SSD - APEX просто летает.


Адрес диска все тот же
https://yadi.sk/d/wifbvQeQDuvSzA


Продолжая нумерацию.

7) CentOS764.7z - 5 ГБ, в развернутом виде 17 ГБ
собственно образ VM

8) APEXProxy_VM_CentOS7.pdf - 860 кБ
Описание VM

irbis_al,
1) Я поклонник VMWare еще с 6-й версии
у меня в архивах полсотни образов еще с Win2000
не только мое мнение- VMWare круче VBox
но главное (естественно) - я привык к нему

2) существуют утилиты трансформации из VMWare в VBox
(и обратно); кому надо - сам сделает

3) SPLIT? об чем речь?
Резать на части виртуальный диск было необходимостью
во времена FAT32 (макс.раpмер файла - 2ГБ)
У меня там же по ссылке рядом лежат VM для WINXP - первоисточник всех
клонов был сделан лет 7-8 назад - во там как раз vmdk порезан на
куски по 2ГБ.
Сейчас такое ограничение излишне. По рекомендации VMWare (и это очевидно)
целостный виртуальный диск лучше чем резаный.
Собственно формат виртуального диска не я задавал - взял готовый на osboxes.org
Архивы VM можно делать "кусками" - WinRAR и 7Z умеют это делать

4) время жизни ссылки на yandex.disk - на всё воля Яндекса

irbis_al,
Сходил по ссылке
http://www.cis-pos.com/apex/f?p=116:43
Интересно и познавательно.
Хорошо бы в этом форуме где-нибудь закрепить страницу c вот такими ссылками

Но КИС "Классика" это все-таки десктоп приложение. Или я ошибаюсь?

Насчет граблей с 180-дневным лимитом default profile я знаю давно
В своей VM сразу же сделал unlimited


В принципе сабж-VM пригодна для "БД ORACLE общего назначения персонального пользования"
Как инструмент БД-девелопера под названием "песочница" (sandbox).
Единая пусть даже отдельная девелоперская БД как среда коллективной разработки
- очень условно. Если два разработчика одновременно работают пусть
и над разными, но взаимозависимыми обьектами - постоянная инвалидация
не даст нормально работать никому.
Если у каждого девелопера есть своя собственная "песочница" с подготовленным
клоном БД - каждый молча делает свою работу не мешая другим.
А если есть необходимость в программистских экспериментах с радикальным и необратимым
рефакторингом обьектов БД - без "песочницы" никак.
Если рефакторинг принят - уходит на коллективную дев-базу
Если нет - "песочница" откатывается на предыдущий архив
Пострадавших нет

irbis_al...Виртуальные машины обмениваются образом формата ova...
May be....
На вкус и цвет все фломастеры разные
Не вижу никакого особого кайфа в формате OVA/OVF для личного пользования
Нашел таки этот пункт меню у себя на Workstation - никогда им раньше не пользовался
Получил комплект ovf(не ova) файлов размером более 7 ГБ. И этот экспорт полностью проигнорил мои describe-подкаталоги
в которых я обычно описываю что там внутри VM - комплект софта, пароли, конфиги и прочая... А то ведь через полгода и не вспомнишь уже.
7Z делает архивирование всего что надо мне, а не стандарту OVA - менее 5Г и быстрее. 7ГБ в остатки моего яндекс-диска просто не влезли бы.

Перед рискованными манипуляциями с VM я делаю бэкап-архив в режиме "быстрый rar" (rar быстрее 7z)
- пусть на 20% менее плотно, зато всего минута-полторы. И восстанавливается из "бэкапа" с такой же скоростью.
Между прочим, APEX у меня "встал" полностью корректно только с 3-го раза - только когда я нашел в сети подсказку
на какую из 2-х баз сервера 18XE его нужно ставить. И каждая "кривая" инсталяция заканчивалась "убиванием" и восстановлением вот из такого бэкапа.
А убивать свое время на 10-15 минут восстановление из OVF - мне жалко.

Еще. Оригинал VM CentOS я брал на osboxes.org. Спасибо им - не так уж тривиально корректно поставить CentOS в минимально-оптимальной конфигурации. Там же лежит еще туча образов VM разных ОС - все в в виде зазипованных (7z) виртуальных дисков
либо в формате VMWare либо VBox. Почему-то этим парням (явно не новички) никто не растолковал про крутизну и универсальность OVA ?

Я буду делать так как мне удобнее и быстрее.

Michael Isaev..
Cкажем, спасибо ZhV за его работу.

Да ладно... донт меншин ит.

У меня есть простой интерес
Хочу и надеюсь что ORACLE&APEX не падет жертвой модных и местами сильно афероподобных
акций "импортозамещения", продвижения "свободных" RDBMS, "облачных вебфрэймов" ...
Я хорошо отношусь к PostgreSQL и поработал на нем немало.
Именно поэтому точно знаю, что ORACLE намного круче - мощнее и надежнее.

Когда я впервые занялся APEX-ом, я сразу же сделал себе "учебную" виртуалку под него.
Возможность лазить по ORACLE-серверу с SYS-грантами "куда хочу никого не спрашивая" и ничем не рискуя - очень ценно,познавательно и полезно для быстрого наращивания скилсов
Пусть желающие освоить APEX получат еще один инструмент.
Чем больше ораклоидов и апексоидов будет - тем лучше :)

Michael Isaev,

Ну надо же...
А я дня три гуглил и яндексил - и вот такого простого и прямого варианта не нашел.
А надо было только вместо "VM samples/examples" искать "Virtual Box Appliance"

Зато a нашел osboxes.org - сгодится на многие случаи.

И здесь на SQL.ru уже есть ссылки на это решение
от присутствующего в топика юзера irbis_al
https://www.sql.ru/forum/1226685/ishhu-vm-s-oracle11g-apex4-2-zhelatelno-pod-oracle-virtualbox

Спасибо, Michael Isaev , что "наткнулись и поделились"
Надо будет качнуть и глянуть.

iv_roman_vl,

1) Лицензия на "основную/рабочую" базу - ессно.
Предполагается, что она (база и лицензия) уже есть
APEX.Proxy - это бесплатные ORACLE 18XE и APEX
Я пока не нашел в лицензионных соглашениях на эти продукты ограничений на коммерческое использование
В отличие от вышеприведенных ссылок на "Virtual Box Appliance" -
там между прочим стоит "полноприводный" ORACLE, но есть явная оговорка - только для разработки и тестирования

Разумеется нельзя вставлять XE и APEX в прайс и брать за них деньги с клиента.
Впрочем, это касается и Linux-а

Между прочим, для 18XE установлен лимит - 2 процессора по 2 потока.
На процессорах от I7 - это очень много.
Ограничение по max обьему не критично - на то и прокси - не предназначен для хранения прикладных данных

2) статистики особой нет - было только одно внедрение (да и то скорее бета версия), но я там уже не работаю
Из накладных расходов "проксирования" - трафик xml-clob-ов.
Если не гонять гриды на тысячи строк - вполне умеренно.
Конечно, REST-сервисы за счет формата json покомпактнее будут, но, повторюсь, на обьемах до сотни кб это почти не заметно

В некотором смысле удивительно, что ORACLE сам до сих пор не догадался "запроксировать" APEX.
По настоящему загруженная база постоянно "молотит" длинные очереди запросов, держит огромные массивы кэшей и ролбэк логов...
Расход ресурсов огромный - рабочие сервера "греют атмосферу" не хуже майнинговых ферм.

И грузить эту же базу еще и HTML-рендерингом... Пиковые загрузки базы и работающих приложений во многом совпадают
Почему бы не избавить SQL-машины от сугубо стринговых JavaScript&HTML обработок

Michael IsaevЕсли кому интересно (сам наткнулся только сегодня):

Oracle обновил 6/20/2019 виртуалку...
Хорошая вешчь. Рекомендую взять пока дают

Усталый разработчикКоллега, всё никак не дойду до нормального обзора вашего решения, честное слово, не моя в том вина.
Да в общем то никто никуда не торопится https://www.sql.ru/forum/images/smoke.gif

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

Я уже поэкспериментировал насчет "запроксировать" APEX-ом PostgreSQL .
В принципе "удаленный вызов" с помощью ораклового пакета гетерогенных вызовов работает надежно


И очень помогает то, что в PostgreSQL вызов процедуры можно делать в виде запроса.
Постгрешная функция генерации cursor_to_xml(...) - очень похожа на DBMS_XMLGEN и работает очень быстро.
Есть "грабли", но "обходимые" - трансферить CLOB-ы и BLOB-ы туда и обратно insert-ами можно только чанками по 32к

Может быть неспеша доделаю - если не встретятся непроходимые грабли.
А потом буду думать что с этим можно сделать.