Построениенадежных решений на базе DocsVision 4.5

Построениенадежных решений на базе DocsVision 4.5

Методические рекомендации

17.05.2011

Copyright© DocsVision 2011

Содержание

1 Введение. 3

2 Настроечные решения. 4

2.1 База данных. 4

2.2 Сервер приложений. 4

2.3 Поиск, представления. 5

2.4 Делопроизводство. 5

2.5 Workflow. 6

2.6 Конструктор решений. 6

3 Программные решения. 7

3.1 Схемы карточек и база данных. 7

3.2 Разработка клиентских компонентов. 7

3.3 Расширения. 7

3.4 Конструктор решений. 8

3.5 Workflow. 8

2  Введение

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

Приведенные в документе рекомендации в полном объеме применимы к актуальной версии системы DocsVision4.5, и ограниченно применимы к более ранним версиям (4.0 – 4.3).

Для понимания и использования приведенных рекомендаций, требуются следующие навыки:

·  Для настроечных решений - знание основ установки, администрирования, и настройки DocsVision (в объеме курсов DV902, DV903);

·  Для программных решений - знание основ разработки на платформе DocsVision (в объеме курсовDV907, DV908).

3  Настроечные решения

3.1  Базаданных

1.  Для обеспечения отказоустойчивости базы данных необходимо использовать кластеризацию SQLServer. Подробные сведения: http://msdn. microsoft. com/en-us/library/ms179410.aspx, а также методические рекомендации DocsVisionпо организации отказоустойчивых и производительных кластеров (документ будет опубликован в течение 2-го квартала 2011 года)

2.  Выполнять регулярное профилактическое обслуживание (в том числе резервное копирование) базы данных (подробные сведения в документе “Рекомендации по обслуживанию DocsVision 4.5”)

3.  Не пытаться удалять объекты из базы данных, не посоветовавшись с вендором (служба консалтинга или служба технической поддержки). При таком удалении может оказаться, что не все объекты удалены, что приводит к захламлению базы и возможным ошибкам при обновлении на новые версии.

4.  В случае если обновление базы по каким-то причинам прервалось, после выявления причины проблемы лучше провести его сначала, восстановив базу из бэкапа – а не пытаться продолжить обновление на той же базе.

5.  Если же довести обновление базы до конца не получилось, но “все вроде бы работает”, то рекомендуется организовать регулярный мониторинг базы данных. В случае увеличения размера какой-нибудь таблицы, проверять, должны ли на этой таблице быть  внешние ключи с каскадным удалением. Возможно, эти ключи были потеряны при неудачном обновлении базы.

3.2  Серверприложений

1.  Для обеспечения отказоустойчивости сервера приложений необходимо использовать NLB-кластеризациюWindows. Подробные сведения: http://technet. /ru-ru/library/bb633031.aspx, а также методические рекомендации DocsVisionпо организации отказоустойчивых и производительных кластеров(документ будет опубликован в течение 2-го квартала 2011 года). Внимание: возможностьNLB-кластеризации должна поддерживаться в используемой лицензии (DocsVisionConcurrentServers).

2.  Из предлагаемых сервером транспортов, самым универсальным и надежным (но при этом самым медленным) является HTTP+SOAP. Рекомендуется использовать его, если возникают частые сбои, связанные с транспортным уровнем (ошибки вида “не удалось разобрать SOAP-сообщение полученное от сервера”).

3.  Если не используются протоколы NamedPipe, WCFTCPили WCFNamedpipe, то сервис DocsVisionStorageServer, реализующий подключение по этим протоколам, рекомендуется принудительно отключить (disabled).

4.  Если используется IIS-версия сервера приложений (доступ через протоколы HTTP+SOAP, HTTP+Binary, WCFHTTP) –то рекомендуется настроить периодическую перезагрузку(recycling) пула приложений в IIS (рис. 1).В качестве критериев перезагрузки можно указать регулярный временной промежуток (Regulartimeintervals или Specifictime) – например, каждые сутки в 2 часа ночи; или объем занятой оперативной памяти (Virtualmemoryusage + Privatememoryusage) – например, при достижении 3Гб занятой памяти. Перезагрузка пула приложений возможна во время интенсивного использования сервера, и не приведет к отключению работающих пользователей.

Рисунок 1: перезагрузка пула приложений в IIS

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

3.3  Поиск, представления

1.  Избегать ситуации, когда большое количество пользователей могут потенциально выполнять большое количество сложных поисковых запросов одновременно. Например, большого количества виртуальных папок с отчетами. В этом случае целесообразно выгружать отчет на портал раз в день бизнес-процессом, чтобы пользователи могли ознакомиться с уже подготовленной статической информацией, и не нагружали при этом сервер. Другой пример: использование Личного помощника. Рекомендуется настроить Помощника таким образом, чтобы запросы у разных пользователей выполнялись в разное время, а не одновременно.

3.4  Делопроизводство

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

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

3.5  Workflow

1.  Минимизировать сложность бизнес-процессов – чем проще процесс, тем меньше возможностей для возникновения ошибки. Сложный процесс лучше разбить на небольшиеподпроцессы.

2.  Использовать вехи в функциях БП для контроля прохождения БП различных этапов

3.  По возможности, не использовать шлюз к почте в режиме работы через MSExchange(MAPI), т. к. данный протокол является менее надежным. Вместо этого рекомендуется использовать ExchangeWebServices (для Exchange 2007 и 2010).

4.  Не изменять настройки сервиса WF, без крайней необходимости. Рекомендуется использовать следующие настройки:

a.  Максимальный объем ОЗУ не более 1 Gb. Если разрешить использовать больший объем, может возникнуть ситуация, когда при активной компиляции скриптов объем занятой памяти превысит 2Gb так быстро, что сервис не успеет освободить занятую память.

b.  Период поиска активных процессов не рекомендуется выполнять чаще чем 30 секунд, потому что поиск активных БП и формирование очереди процессов – весьма ресурсоемкая операция, и для снижения нагрузки на сервер и уменьшения вероятности блокировок ее желательно выполнять как можно реже.

c.  Размер пакета процессов не рекомендуется устанавливать больше 40, т. к. использование больших размеров пакетов увеличивает нагрузку на сервер ДВ, увеличивает конкурентность в базе и вероятность блокировок в SQL.

Подробные рекомендации о настройках Workflow в документе “Рекомендации по тонкой настройке и оптимизации Workflow”(документ будет опубликован в течение 2-го квартала 2011 года)

3.6  Конструкторрешений

1. При выполнении привязки свойства к полю карточки (карточка на полях) необходимо выбрать поле карточки с соответствующим типом. Например, если в карточке есть свойство "Целое число", то и привязывать его в схеме карточки нужно к полю соответствующего типа (Integer). Если это свойство "Сотрудник", то поле должно быть типа RefId и т. д...

2. При настройке ролевой модели стараться по возможности не добавлять больше трех уровней вложенности в условиях.

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

4  Программные решения

4.1  Схемыкарточек и базаданных

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

2.  При разработке собственных хранимых процедур, которые обрабатывают данные DocsVision (например, расширенных отчетов), лучше использовать относительно простые Sql-выражения, создавать необходимый пакет индексов. Иначе на промышленных нагрузках неоптимальности в процедурах приводят к повышенной нагрузке на диск БД и торможению (мертвым блокировкам) в параллельных операциях.

4.2  Разработкаклиентскихкомпонентов

1.  Использовать транзакции (механизм отложенных изменений), для того, чтобы данные не могли оказаться в противоречивом состоянии. Писать код так, чтобы при возникновении исключения данные пользователя не были бы повреждены.

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

3.  Отказаться от использования пустых обработчиков ошибок в любых местах. Так как “проглатывание” ошибки в промышленной эксплуатации может привести к непредсказуемым последствиям и невозможности диагностики.

4.  Стараться использовать объектную модель DocsVision (FolderCard, SavedView) для тех мест где она есть, вместо прямого обращения к данным (через объект CardData). В дальнейшем расположение данных в секциях и карточках может поменяться и обращение к секциям и строкам напрямую может потребовать переписывания кода при переходе на следующие версии ДВ.

5.  При кэшировании объектов API (CardData, RowData и т. д.), а особенно если использовать для этого статические переменные – необходимо внимательно следить за таким кэшем, не забывая его вовремя высвобождать. Но лучше в рамках жизненного цикла компонента применять собственные структуры и классы, описывающие те или данные указанных объектов.

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

7.  При разработке клиентских компонент следует экономить gdi ресурсы. Например, этого можно добиться, динамически подгружая редко используемые элементы управления, использующие большое количество gdi объектов.

4.3  Расширения

1.  При использовании служебных сессий DocsVision в коде серверных расширений желательно реализовать пул сессий. Иначе длительная операция в рамках служебной сессии приведет к блокировке параллельных операций, которые обрабатывает серверное расширение.

2.  Если в серверном расширении используется пул сессий, то стоит предусмотреть, что эти сессии могут быть принудительно завершены администратором – и потребуется их автоматическое восстановление. Так же обязательно нужен какой-либо механизм очистки этого пула, чтобы обновить закэшированные в сессиях данные.

3.  Избегать использования VB6-компонент в коде серверного расширения. Причина в том, что VB6-компоненты работают только в 32-битном процессе в STA-апартменте. Даже если настроить серверное приложение в 32-битный режим, то STA-компонента будет тормозить параллельное исполнение потоков  - все потоки будут блокироваться друг с другом при вызове кода из VB6-компоненты.

4.4  Конструкторрешений

1. В конструкторе решений есть возможность использования скриптов на языке или C#. При написании скриптов нужно придерживаться следующих рекомендаций:

a) Следует тщательно проверить все ли сборки, необходимые для выполнения скрипта, подключены, все ли директивы using объявлены для классов, которые вы используете.

b) Обязательно предусмотреть в методах обработчики ошибок try/catch, так код станет более надежным, а карточки при открытии не будут выдавать непонятные ошибки в случае неудачно написанных скриптов.

4.5  Workflow

1.  Не маскировать возникающие ошибки в блоке try\catch функции Сценарий.

2.  В собственных функциях\шлюзах\скриптах не порождать потоки, которые могут упасть с ошибкой или никогда не завершаться.

3.  В собственных функциях\шлюзах\скриптах не использовать STA компоненты и объекты потоконебезопасных классов, доступные одновременно для нескольких функций\скриптов

4.  Не писать скриптов, которые могут работать неопределенное время. Если время работы скрипта зависит от набора данных, поступавшего на вход (например – коллекции файлов), и размер этого набора данных неопределен и над каждым элементом этого набора данных совершается однотипная операция – то стоит выделать в скрипт эту отдельную операцию и организовать цикл силами самого БП, а не скрипта. Это несколько ухудшит производительность, но тогда работа скрипта не будет прервана системой WF при анализе работы функций на предмет возникновения зависания.