Oracle APEX: Убить Билла

Как удалить вручную сессию APEX, если известен её ID? Всё довольно просто.

Для начала подумаем, где должна использоваться возможность удаления сессии. Правильно, там где пользователь завершает сеанс в приложении - смотрим на ссылку LOGOUT_URL:

http://localhost:8888/apex/wwv_flow_custom_auth_std.logout?p_this_flow=4000&p_next_flow_page_sess=4550:8:8297564516445573

Нужное нам находится в wwv_flow_custom_auth_std.logout. Давайте глянем ещё на процесс, который выполняется при принудительном удалении сессий администратором экземпляра APEX. Заходим в Administration->Application Express Internal Administration, переходим на Manage Instance->Session State->Purge Session, by age. Это страница 66 приложения 4050. Посмотрим, что за процессы выполняются при обработке этой страницы:

set long 5000
select process_source 
  from apex_application_page_proc 
 where application_id = 4050 and page_id = 66;

PROCESS_SOURCE
--------------------------------------------------------------------------------
wwv_flow_cache.purge_oldest_sessions (
p_num_sessions_to_purge     => :P66_MAX_SESSIONS,
p_purge_sess_older_then_hrs => :P66_AGE * 24);

Ещё одна наводка - пакет wwv_flow_cache с множеством процедур purge_%.

Произведя ритуал Unwrap над этими пакетами, можно увидеть, что удаляется сессия APEX с идентификатором :p_id довольно просто:

delete apex_040000.wwv_flow_sessions$ where id = :p_id;

Всё, остальные изыски из этих процедур вроде подсчёта удалённых сессий, переноса их в wwv_flow_purged_sessions$ и изменения значения в печеньке на -1 нам не нужны.

Убить Билла сессию APEX - проще простого. Была бы лицензия на убийство в виде соответствующей привилегии на таблицу apex_040000.wwv_flow_sessions$...
Читать далее

PL/SQL Challenge: Now with APEX flavor!

Сегодня на PL/SQL Challenge появилась первая викторина по APEX. Надеюсь, многие захотят поучаствовать: для проверки знаний, из интереса, ради призов и чтобы узнать что-то новое.

Удачи!
Читать далее

Oracle APEX 4.0: Небольшой пример плохой реализации

Сегодня я хотел бы упомянуть о том, как не надо разрабатывать. И в качестве примера у нас будет... APEX 4.0 Application Builder. Думаю, все разработчики приложений, использующие эту среду, видели страницу атрибутов элемента, динамического действия или региона. Например, выбираем у элемента Display As=Select List - и появляется регион List of Values с соответствующими настройками. В общем, ту страницу, на которой в зависимости от типа объекта атрибуты и регионы прячутся и показываются в зависимости от выбранных значений.

Отличная цель: оживить и разгрузить страницу, убирая неподходящие поля с глаз долой.

Плохая реализация: при загрузке страницы показываются все элементы страницы, а уже потом Dynamic Actions прячут ненужное, запускаясь после полной загрузки страницы. Это здорово, что у динамических действий есть возможность запуска при загрузке страницы (флажок Fire On Page Load). Но когда пользователь видит мельтешащие поля, которые только что были, а потом куда-то пропали - это ужасно. И с эстетической точки зрения, и с точки зрения здравого смысла. Зачем показывать, а потом тут же (а иногда - и не тут, если страница загружается медленно) скрывать часть интерфейса? Лучше не показывать её вообще.

Как стоило сделать: воспользоваться возможностью указать соответствующий CSS-стиль в свойствах региона, элемента и в их шаблонах. Скрыть всё то, что показывается динамически в зависимости от каких-либо условий.

display: none;

Не отмечать Fire On Page Load у действий, которые что-либо скрывают. (Потому что они сохраняют старое значение свойства display и потом используют его при показе элемента.) Отмечать Fire On Page Load у действий, которые что-либо показывают. Как итог, на странице появятся вначале все обязательные настройки, а потом отобразится все доступные для изменения настройки.

Предложенный мной способ более трудоёмкий и требует больше времени от разработчика приложения. Но и приложение не будет "моргать" элементами интерфейса перед пользователем при каждой загрузке страницы. Мне кажется, это того стоит.

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

Oracle APEX: Collections Debug 2

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

create or replace procedure copy_apex_session_env 
  ( p_session_id apex_workspace_sessions.apex_session_id%type
  , p_app_id apex_applications.application_id%type )
as
  l_session apex_workspace_sessions%rowtype;
  l_app_id apex_applications.application_id%type;
begin
  begin
    select * into l_session
      from apex_workspace_sessions s 
     where apex_session_id = p_session_id;
  exception
    when no_data_found then
      raise_application_error(-20001, 'Invalid Session ID!');
  end;
  
  begin
    select application_id into l_app_id
      from apex_applications
     where application_id = p_app_id
       and workspace_id = l_session.workspace_id;
  exception
    when no_data_found then
      raise_application_error(-20002, 'Invalid Application ID!');
  end;  
  
  apex_custom_auth.set_session_id(p_session_id => l_session.apex_session_id);
  apex_custom_auth.set_user(l_session.user_name);
  wwv_flow_api.set_security_group_id(l_session.workspace_id);
  apex_application.g_flow_id := l_app_id;
end copy_apex_session_env;
/

Она должна создаваться в схеме разбора приложения (без этого не сработает wwv_flow_api.set_security_group_id). Теперь, чтобы увидеть данные соответствующей коллекции, достаточно вызвать процедуру и выполнить запрос:

exec copy_apex_session_env(p_session_id => &session_id, p_app_id => &app_id);

select * from apex_collections where collection_name = 'YOUR_COLLECTION_NAME';

Читать далее

Oracle APEX: Collections Debug

Самый простой, хоть и не очень честный способ отладки при работе с коллекциями APEX - смотреть в таблицы wwv_flow_collections$ и wwv_flow_collection_members$ схемы, в которую установлен APEX. Если, конечно, есть соответствующие права, и известны приложение (FLOW_ID) и сессия (SESSION_ID), работающие с коллекцией.
Читать далее

Пара фраз о JSON

Вначале - о проблеме. Сколько раз сталкиваюсь, что JSON-парсер в Firefox вдруг по какой-то причине спотыкается на казалось бы правильной JSON-строке. Решение довольно простое - завернуть эту строку в обычные скобки:

  var result = JSON.parse("("+json_string+")");

Теперь - о довольно удобном средстве работы с JSON из PL/SQL. Вам хочется организовать эту работу так?

declare
  l_json json := json();
begin
  l_json.put('name', 'Taras');
  l_json.put('sons', json_list('["Mykola", "Vasyl"]'));
  htp.p(l_result.to_char);
end;
/

Тогда обратите своё внимание на проект PL/JSON. Думаю, он облегчит Вам жизнь - особенно, если Вы не поленитесь просмотреть короткие уроки.
Читать далее

Oracle APEX: Медвежья услуга при копировании страницы

С прискорбием вынужден сообщить, что как минимум в версиях 3.2.1 и 4.0.1 я наткнулся на неприятный баг. При копировании страницы автоматически заменяются имена старых элементов: PMXXX заменяется на PNXXX, где M и N - номера оригинальной страницы и копии, соответственно. Проблема в том, что стоило бы заменять PM_XXX.

Для примера: у нас есть страница 5, которая где-то - в переходах, в значении элемента, в процессах - ссылается на элемент P52_X страницы 52. Теперь мы решили скопировать страницу 5 с новым номером 60. После копирования новая страница будет ссылаться на несуществующий элемент P602_X: было 52, стало 602.

Вот такая неприятная штука.
Читать далее