Решено Как Обработать Запросы К Документам, Перенесенным В Архивную Базу

  • Автор темы Автор темы anna
  • Дата начала Дата начала
A

anna

Добрый день, коллеги!
Подскажите, пожалуйста, как сделать автоматический редирект в архивную базу, если запрашивается удаленный документ. Клиент - Notes.
 
По ссылке из письма? -> почти никак.

Мы как-то делали так:
Переносили документ в архив, но не удаляли его из основной базы, а меняли ему форму.
В этой форме делали на событиях открытия - перенаправление в архивную базу.
В результате по ссылке из письма открывался документ в архиве.
 
$$ReturnDocumentDeleted - для веба же только, в клиенте разве работает?
И опять же, имея механизм обычных ссылок в письмах - ничего мы не знаем.
Эти запросы обрабатываются ядром, может быть их можно перехватить на событии Database postopen, но не уверен.
 
Эти запросы обрабатываются ядром, может быть их можно перехватить на событии Database postopen, но не уверен.
Нажмите, чтобы раскрыть...
Database postopen при открытии по ссылке не срабатает.
 
Domino-Designer
И даже знаю как, так как руку приложил)
rinsk сказал(а):
Все ссылки только через proxy базу - не? :)
Нажмите, чтобы раскрыть...
Нет, там хотспот в письмо вставляется, затем идет код на открытии.
Через CAPI идет определение удален документ или нет доступа, затем сообщение или переадресация.
Но там ПЯ всех пользователей изменен, есть куча библиотек в ящике + вьюхи.
 
savl сказал(а):
Domino-Designer
И даже знаю как, так как руку приложил)

Нет, там хотспот в письмо вставляется, затем идет код на открытии.
Через CAPI идет определение удален документ или нет доступа, затем сообщение или переадресация.
...
Нажмите, чтобы раскрыть...
Нууу... в хотспот много чего можно положить)
А таки да - в плане гибкости такая "интеллектуальная" ссылка выигрывает...
 
rinsk
Ну там много чего и было)
Определение базы по внутреннему справочнику с перебором реплик по серверам.
Получение документа по UNID через CAPI.
Сообщение/переадресация.
Хотспот был картинкой ссылки, так что для пользователей совсем прозрачно было.
Текст хотспота лежал в настройке, в глобальной базе.

Тут основной минус, что такая "интеллектуальная" система подразумевает доработку ПЯ пользователей, так как такой объем кода запихнуть в один хотспот просто тяжело. DXL может свалиться на обработке.
 
Пасиба, вопрос решен путем, описанным savl в первом комментарии.
 
anna сказал(а):
Пасиба, вопрос решен путем, описанным savl в первом комментарии.
Нажмите, чтобы раскрыть...
Путь подходит для модулей с не сильно большим числом документов. Если у вас в модуле в месяц создается 500к+ документов, то вы рискуете словить ошибку ID Table. Максимальное количество доков которое мы смогли создать в базе до появления проблемы (килобайтные логи) ~17кк документов, реальные базы лучше держать не более 2-3кк
 
Leoric сказал(а):
Максимальное количество доков которое мы смогли создать в базе до появления проблемы (килобайтные логи) ~17кк документов, реальные базы лучше держать не более 2-3кк
Нажмите, чтобы раскрыть...
это на какой ОДС?
 
~17кк это сколько? что-то я не понимаю, в чем вы измеряете.
 
Интересна ситуация с ODS52. Вроде там изменения\исправления делали направленные на поддержку больших объемов. 17kk как то маловато...
 
@rinsk, а кроме больших объемов еще что-то есть? Инфы мало нашел, только про объемы свыше 2х Гб
Сейчас пробежался по своим базам, большинство 43, редкие 51.
Разница в версии клиента и сервера имеет значение?
[DOUBLEPOST=1424155908,1424155857][/DOUBLEPOST]Предлагают переходить, но везде только из-за объемов вложений. Для меня это сомнительно, но все же... Почту бы перевели.
 
Глухо - так ничего и не нарыл - http://forum.codeby.net/lofiversion/index.php?t52495.html
На моей памяти конкретно про 43 и 51 то же не было инфы о кол-ве доков в базе.
ODS52 поддерживается с 9.0.1.
А почтовые - их обязательно надо переводить на 51 и соотв. на DAOS. I/O существенно ниже, не говоря уж об экономии места.
 
Для ответа нужно войти/зарегистрироваться
Мы в соцсетях:

Обучение наступательной кибербезопасности в игровой форме. Начать игру!

Верх Низ