Является ли текущее приложение рабочим или тестовым

[sukhanchik]

Добрый день всем!
Столкнулся с небольшой, но часто возникающей задачей при работе с АХ. Наверняка многие для себя решали этот вопрос, тем не менее - хотел бы поинтересоваться - кто и как решал, т.к. с ходу на форуме не нашел обсуждения этого вопроса.
Если у кого есть какие-то решения - пишите - интересно узнать - кто и как решал поставленную задачу.

Задача: В компании имеется несколько экземпляров АХ, в которых один рабочий, а остальные - копии (тестовая, разработческая или иная какая). Хочется, чтобы на нерабочих экземплярах АХ по умолчанию не работало часть функциональности. Например,
1. Не рассылалась почта реальным пользователям
2. Папка хранения прикрепленных документов не ссылалась на рабочую папку
3. Если в системе реализована интеграция с внешними системами - то стояла бы "заглушка" на попытку "залезть" во внешнюю систему
и т.д.

Обычно, копии экземпляров АХ получаются путем копирования приложения и БД (до АХ 2012). Соответственно - все параметры, прописанные в БД по умолчанию сохраняются и не перебиваются. А после восстановления бекапа - редко кто вспоминает о необходимости выполнения изменения данных, чтобы работа на копии не приносило вред рабочим данным / пользователям.

Исходя из этого - я видел следующие решения исходной задачи:
1. Создание скрипта, который необходимо запускать при восстановлении копии. Скрипт перебивает все ссылки и связи с внешними данными.
Плюс: Отличный вариант, если иметь гарантию того, что скрипт обработает все необходимы места в системе. Не нужно модифицировать соответствующие места в системе.
Минус: За ним нужно "ухаживать", т.е. следить за актуальностью и писать. Если скрипт не содержит в себе всех мест для обработки - то его польза лишь частичная.
Реализация: X++ или T-SQL.
2. Прописывание названия рабочей БД (АОСа) в параметры (или даже программный код). В коде, где делается отправка почты / интеграция с внешними системами / прикрепление документов / и т.д. пишется сравнение текущего названия БД (АОС) с прописанным в параметрах.
Плюс: Программный код умеет сам определять - где база рабочая, а где - копия.
Минус: Переименование рабочей базы предполагает соответствующее изменение в параметрах / программном коде, о котором нужно помнить. Также нужно ссылку на этот параметр прописывать в каждом необходимом месте кода.
Реализация: Название текущей БД в Х++:

new SQLSystem().loginDatabase()

Можно также запоминать название / порт текущего АОСа. Для этого есть методы

Session::getAOSInstance()

и

Session::getAOSPort()

.
3. Начиная с АХ2009 появилась замечательная табличка SysServerConfig (\Администрирование\Настройка\Конфигурация сервера). Именно там выбирается - какой АОС будет выступать в роли пакетной обработки. Однако главный плюс этой таблички состоит в том, что новые записи в ней создаются автоматически ядром системы при старте АОСа. Причем при создании - в поле "Имя экземпляра АОS" прописывается идентификатор нового АОСа. Т.о. добавление в эту табличку нового поля-флажка IsWork может позволить отметить галочкой рабочий АОС, после чего любое восстановление копии БД - гарантированно создаст свое название АОСа и т.о. по умолчанию текущий АОС копии БД не будет ссылаться на рабочую базу (я исхожу из того, что вряд ли кто подменяет БД в настройках АОСа, а скорее создает отдельный АОС на каждую копию системы). Ну а дальше - по аналогии с галкой "Сервер обработки пакетных заданий" - при необходимости галку IsWork можно поставить у любого / нескольких АОСов.
Плюс: Программный код умеет сам определять - где база рабочая, а где - копия. Нет необходимости держать отдельный параметр в отдельной табличке (если не считать флажок IsWork за параметр).
Минус: Как и в п.2 - нужно ссылку на этот параметр прописывать в каждом необходимом месте кода.
Реализация: В табличку SysServerConfig необходимо добавить флажок (NoYes) IsWork. На классе Global создать метод isCurrentAOSIsWork, возвращающий истину в случае, если АОС является рабочим. Соответственно - вызов данного метода вставляется во все необходимые места в коде:

// VSUH, Возвращает истину, если текущий аос является рабочим 05.02.2013
static server boolean isCurrentAOSIsWork()
{
    SysClientSessions clientSessions;
    SysServerSessions serverSessions;
    SysServerConfig   serverConfig;

    int      serverId;
    ServerId serverIdConfig;
    str      serverName;
    int      pos;
    int      aosIDLen;
   ;

    select ServerId from clientSessions where clientSessions.SessionId == sessionid();
    serverId = clientSessions.ServerId;

    new SkipAOSValidationPermission().assert();
    serverSessions.skipAosValidation(true);
    select AOSId, Instance_Name, Status from serverSessions where serverSessions.ServerId == serverId;
    if (serverSessions.Status != 0)
    {
        aosIDLen = strlen(serverSessions.aosId);  // Код взят с SysServerConfig.delete()
        pos = strfind(serverSessions.aosId, '@', 1, aosIDLen );
        serverName = substr(serverSessions.aosId, 1, pos-1);
        serverIdConfig = serverSessions.Instance_Name + '@' + serverName;
        select firstonly IsWork from serverConfig
            where serverConfig.ServerId == serverIdConfig;
    }
    return serverConfig.IsWork;
}

Кто еще каким способом решал исходную поставленную задачу и как часто ее требовалось решать?

[lvan]

А как тестировать отправку писем тогда?
Если делать всё правильно, то надо тупо клонировать систему в изолированную виртуалку и тестировать там. И никаких настроек не нужно будет.

[dn]

Цитата:

Сообщение от sukhanchik

Задача: В компании имеется несколько экземпляров АХ, в которых один рабочий, а остальные - копии (тестовая, разработческая или иная какая). Хочется, чтобы на нерабочих экземплярах АХ по умолчанию не работало часть функциональности. Например,
1. Не рассылалась почта реальным пользователям
2. Папка хранения прикрепленных документов не ссылалась на рабочую папку
3. Если в системе реализована интеграция с внешними системами - то стояла бы "заглушка" на попытку "залезть" во внешнюю систему
и т.д.

1. В параметры почты добавлен флаг "Отключить". На тестовой базе устанавливаем после обновления данных. Если требуется протестировать почту - временно включаем.
3. Тестовые настройки по интеграции сохраняем стандартным экспортом данных. После обновления данных в тесте - загружаем эти настройки вместо рабочих.

Кроме того сделан конф. ключ "Для тестирования", который должен быть включен на тесте, но выключен на рабочей. Часть логики завязана на него.

[dn]

Цитата:

Сообщение от sukhanchik

А после восстановления бекапа - редко кто вспоминает о необходимости выполнения изменения данных, чтобы работа на копии не приносило вред рабочим данным / пользователям.

Напишите регламент по обновлению данных на тесте.

[sukhanchik]

Цитата:

Сообщение от lvan

Если делать всё правильно, то надо тупо клонировать систему в изолированную виртуалку и тестировать там. И никаких настроек не нужно будет.

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

Цитата:

Сообщение от dn

1. В параметры почты добавлен флаг "Отключить". На тестовой базе устанавливаем после обновления данных. Если требуется протестировать почту - временно включаем.
3. Тестовые настройки по интеграции сохраняем стандартным экспортом данных. После обновления данных в тесте - загружаем эти настройки вместо рабочих.

Ну это да, если не забывать.

Цитата:

Сообщение от dn

Кроме того сделан конф. ключ "Для тестирования", который должен быть включен на тесте, но выключен на рабочей. Часть логики завязана на него.

Интересная мысль. Спасибо.

Цитата:

Сообщение от dn

Напишите регламент по обновлению данных на тесте.

Мой вопрос больше академический. Хотелось просто выяснить - как эту задачу решают. Регламент - это всегда хорошо. По сути - регламент = скрипту в моем вопросе. Я совершенно согласен с таким подходом. Хорошо, когда есть возможность решать чего-то административными мерами. Поэтому и написал - что в жизни встречал 3 варианта, в т.ч. скрипт = регламент, однако чаще попадались на жизненном пути компании, в которых такой регламент не внедрен, однако частично - задача решена "программистким" путем.

Вот собственно поэтому и решил поинтересоваться для расширения кругозора - кто как решает данную задачу и часто ли возникает данная задача.

[Logger]

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

[oip]

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

[sukhanchik]

Цитата:

Сообщение от Logger

Хорошим тоном было бы перебивать в тестовом приложении все названия контрагентов, договоров, и.т.п.

Цитата:

Сообщение от oip

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

Интересно, а как это все отражается на реальных данных? Названия контрагентов /договоров живут далеко не в одной таблице. А если эти названия еще и в коде (например, клиента) присутствуют - то замучаешься перебивать. А глобальное изменение данных - несет в себе риск некачественного тестирования.
Хотя логика в перебивке есть.