Проблема

Недавно столкнулся с интересной задачей. Работающая интеграция использовала таблицу контрагентов для создания заявок, где хранилась связь склада и контрагента (у компании несколько юридических лиц).

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

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

В интеграции использовалась таблица XXT_BAIKAL_ADDRESS, в которой хранились данные с адресами складов, ФИАС коды, ремарки, контактные данные с привязкой к LOCATION_GID (ID склада в системе Oracle Transportation Management) для формирования JSON структуры заявки на перевозку.

Решение: использование VIEW с условием

Найденное нами решение оказалось достаточно удобным и простым — создать представление (VIEW), которое автоматически выбирает нужную таблицу в зависимости от текущей даты:

CREATE OR REPLACE VIEW xxt_baikal_address_current AS
SELECT * FROM xxt_baikal_address
WHERE sysdate < COALESCE((select START_DATE_ACTIVE 
                 from FND_LOOKUP_VALUES_VL@PROD_APPS
                 where lookup_type = 'XXTSC_LEGAL_SUCCESSOR'
                 and description = 'Слияние Юрлиц'),sysdate-1)
UNION ALL
SELECT * FROM xxt_baikal_address_copy
WHERE sysdate >= (select START_DATE_ACTIVE 
                  from FND_LOOKUP_VALUES_VL
                  where lookup_type = 'XXT_LEGAL_SUCCESSOR'
                  and description = 'Слияние Юрлиц');

COALESCE применил в качестве "страховки", на случай, если значение будет по какой-то причине отсутствовать, то тогда вью вернет только данные xxt_baikal_address.

Как это работает

  1. До даты изменения: представление возвращает данные из оригинальной таблицы xxt_baikal_address
  2. После даты изменения: представление автоматически переключается на новую таблицу xxt_baikal_address_copy
  3. Дата переключения: хранится в справочной таблице FND_LOOKUP_VALUES_VL, что позволяет легко её изменить без модификации кода

Внедрение решения

В нашем коде было необходимо сделать всего одно изменение — заменить обращения к таблице xxt_baikal_address на xxt_baikal_address_current.

Альтернативный вариант — можно было сделать синоним с именем оригинальной таблицы:

  1. Переименовать существующую таблицу в xxt_baikal_address_old
  2. Назвать новую таблицу xxt_baikal_address_new
  3. Создать VIEW с именем xxt_baikal_address

В этом случае вообще не потребовалось бы изменений в коде процедур.

Преимущества подхода

  1. Минимальное изменение кода — меняется только имя таблицы или создается синоним
  2. Автоматическое переключение — после наступления даты система сама начинает использовать новые данные
  3. Гибкость — дату переключения можно изменить в справочнике без необходимости изменения кода
  4. Отсутствие простоя — решение внедряется без остановки системы
  5. Прозрачность — в коде VIEW явно видно условие и логика переключения

Заключение

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

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