Автоматизация документооборота АО Система управления. Часть 2

Страницы: 1 2 3

2. Проектная часть

2.1 Разработка проекта автоматизации
2.1.1 Этапы жизненного цикла проекта автоматизации

Совокупность всех последовательных стадий и этапов, включающих в себя как принятие решения о создании ИС, так и о приостановлении ее использования, называется жизненным циклом информационной системы [3].
В практической деятельность существует ряд стандартов, которые характеризуют ЖЦ:
– стандарт ГОСТ 34.601–90, который предназначен для автоматизированных систем, применяемых в разных областях деятельности, например, управление, исследование и т.п., в том числе и их сочетания, которые создаются в учреждениях. Создание автоматизированной системы предполагает определенные стадии и этапы, которые устанавливаются стандартом [5]:
– стандарт ISO 12207 используется как в рамках приобретения систем, различных программных продуктов и оказания тех или иных услуг, так и при работе с программными продуктами (их поставке, разработке, использовании и сопровождении) и программными компонентами программно-аппаратных средств на базе того или иного учреждения и за ее пределами;
– стандарт ISO 15288 способствует бесперебойной работе процессов, которые закладываются в основу жизненного цикла всех систем, разработанных человеком. Жизненный цикл такого типа включает в себя различные концепции идей, которые даже охватывают мысль о прекращение эксплуатации системы. Он играет роль в обеспечении процессов, связанных с приобретением и поставкой системы.
– RUP (Rational Unified Process – рациональный унифицированный процесс) является методологией разработки ПО, созданием и распространением которой занимается корпорация Rational Software (www.rational.com/ rup_info/). Она описывает упорядоченный подход к распределению задач и обязанностей в организации–разработчике.
Поскольку методика Rational Unified Process (RUP), на наш взгляд, является самой подходящей, то она будет использована в процессе описания этапов жизненного цикла. RUP основан на таких принципах, как:
– бесперебойное (до тех пор, пока проект не закончится) устранение основных рисков и ранняя идентификация;
– акцент на выполнение тех требований, что устанавливают заказчики к программе (осуществление анализа и создание модели прецедентов);
– ожидание каких-либо корректировок в требованиях, решениях проекта и осуществлении в период разработки;
– компонентная архитектура, реализация и тестирование которой происходит на начальных стадиях развития проекта;
– поддержание качества в ходе реализации всего проекта;
– реализация проекта в дружной команде, где архитекторы занимают главные позиции.
Согласно данному стандарту, можно выделить ряд последовательных этапов жизненного цикла систем информационного типа:
1. Начало (Inception)
На этом этапе:
– создаются видение и границы проекта;
– дается экономическое обоснование;
– разрабатываются основополагающие требования, ограничения и ключевая функциональность продукта;
– создается базовая версия модели прецедентов;
– происходит оценка всех возможных рисков.
При завершении начальной стадии оценивается достижение вехи целей жизненного цикла, которое предполагает соглашение заинтересованных сторон о продолжении проекта.
2. Проектирование (Elaboration)
На данном этапе осуществляется аналитическая деятельность, анализу подвергаются построение исполняемой архитектуры и предметная область. Можно выделить ряд составляющих компонентов:
– процесс документирования требований (в том числе и подробное описание для многих прецедентов);
– спроектированную, реализованную и оттестированную исполняемую архитектуру;
– обновленное экономическое обоснование и более точные оценки сроков и стоимости;
– сниженные основные риски.
Успешное выполнение фазы проектирования означает достижение вехи архитектуры жизненного цикла.
3. Построение (Construction)
Данный этап подразумевает реализацию функциональности продукта в большей части по сравнению с другими этапами. Первый внешний релиз системы и веха начальной функциональной готовности являются завершающими этапами в рамках фазы Построение.
4. Внедрение (Transition)
На данном этапе происходит окончательная подготовка продукта, осуществляется процесс его передачи заказчику. В рамках Внедрения реализуется программа бета-тестирования, происходят обучающие мероприятия пользователей и определяется качество готового продукта. Фаза Внедрения может повторяться в том случае, если качество продукции не оправдает ожиданий пользователей или не будет соответствовать критериям, которые были установлены на этапе Начала. Достижение вехи готового продукта и прохождение полного цикла разработки говорит об выполнении всех установленных ранее целей [13].
Первой стадией этапа внедрения будет реорганизация информационной инфраструктуры для обеспечения технической возможности развертывания разработанной нами информационной системы. Затем будут осуществлены мероприятия по подготовке специалистов, являющихся ответственными лицами на уровне ЦО банка и его филиалов. Суть ее состоит в том, чтобы они понимали принцип работы общей концепции функционирования системы, планируемой к внедрению, а также карт использования ресурсов.
Кроме того, обучение необходимо провести и для тех специалистов, которые будут заниматься вопросами, связанными с непосредственным внедрением информационной системы, поддержкой всех сопутствующих процессов. Так, функции по внедрению ИС будут возложены на инженеров ИТ-отделов (каждый будет осуществлять деятельность на вверенном ему объекте), а, в свою очередь, специалисты по информационной системе банка будут осуществлять функции, связанные с информационной поддержкой. Проверку функционирования внедрений ИС проводят операторы банка совместно с ИТ–отделом. Данный заключительный этап включает в себя проверку взаимодействия всех существующих логических модулей информационной системы и составление документации по мероприятиям, включающим в себя внедрение и тестирование информационной системы.

2.1.2 Ожидаемые риски на этапах жизненного цикла и их описание

Важно подчеркнуть, что любой вид деятельности подразумевает под собой определенные риски, поэтому процесс жизненного цикла разрабатываемой информационной системы не является исключением. Конечно, проще на начальном этапе провести выявление и анализ рисков, чем потом проводить мероприятия по устранению их последствий. Поэтому будет логичным выделить для каждого этапа жизненного цикла нашей информационной системы ряд основных рисков и меры по их предупреждению.
Для первой стадии характерны такие риски, как риск нарушения методологии ведения проекта и риск персонала со стороны заказчика и исполнителя. Среди основных факторов риска персонала со стороны заказчика и исполнителя можно выделить следующий:
– привлечение к проекту неопытных бизнес–аналитиков и ИТ– консультантов;
– включение в команду работы над проектом со стороны заказчика случайных сотрудников, а не ключевых участников бизнес–процессов, подлежащих автоматизации;
– ошибочные выводы, сделанные на основе анализа данных, неверная интерпретация данных, прошедших обработку;
– отсутствие у руководства предприятия единой целостной стратегии в области информационных технологий;
– непонимание руководством основных целей задач проекта;
– стремление скрыть реальные результаты работы того или иного сотрудника со стороны заказчика;
– некомпетентность сотрудников в рамках выполняемой работы;
– неправильный подбор персонала в рабочую группу над проектом;
– отсутствие мотивации и заинтересованности у функциональных менеджеров проекта;
– не налаженная система коммуникаций между участниками рабочей группы;
– негативное отношение персонала к проекту;
– необдуманный план ведения работ [7].
Все это может привести к плачевному результату, во избежание чего, можно противопоставить следующее:
– активное вовлечение высшего руководства в проект, активное взаимодействие с ним в ходе проекта и своевременное принятие решений;
– активное участие в проекте ведущих специалистов заказчика, ответственных за исполнение основных процессов;
– четко сформулированные цели и критерии успеха внедренческого проекта;
– участие профессиональных консультантов со стороны заказчика, а также сотрудников предметных подразделений со стороны исполнителя;
– проработка общей стратегии автоматизации предприятия;
– четкое разъяснение целей, материальное стимулирование, пропаганда позитивного примера среди участников на время реализации проекта;
– организация рабочих мест и процедур взаимодействия таким образом, чтобы члены проектной команды могли постоянно и беспрепятственно общаться друг с другом;
– стабильный состав рабочий группы в течение всего проекта;
– отбор людей в проектную команду по принципу их личной заинтересованности в успехе внедрения.
Необдуманное описание и утверждение документации, которая включает в себя информацию об интересах сторон и состоянии проекта, является основополагающим фактором появления риска нарушения методологии ведения проекта. Для предотвращения данного риска можно предпринять следующие меры:
– распределение прав и обязанностей для каждого участника в отдельности;
– наличие профессиональных консультантов как участников;
– проведение обучающих мероприятий с рабочей группой и ключевыми пользователями заранее;
– проведение разъяснительных работ непосредственно для персонала заказчика;
– согласование со всеми заинтересованными участниками проекта технических условий;
– любые изменения должны быть в обязательном порядке утверждены;
– техническое задание, которое не содержит избыточных характеристик, предполагает утверждение;
– участники группы проекта со стороны заказчика обладают компетентностью.

2.1.3 Организационно-правовые и программно-аппаратные средства обеспечения информационной безопасности и защиты информации

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

Таблица 2.1

Разграничение прав пользователей

 

Защита от внешних угроз (безопасность каналов, протоколы, аутентификация, шифрование, безопасная пересылку ключей и т.д.) обеспечивается отделом ИТ.

 

Информационное обеспечение задачи

2.2.1    Характеристика нормативно–справочной, входной и оперативной информации

 

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

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

Всю информацию о заказах и их характеристиках можно найти в справочнике под названием «Заказы», который заполняется последовательно в два этапа:

− первичная информация: она заполняется в момент составления проекта и включает в себя такие сведения, как информацию о заказчике; объеме работ (указывается в квадратных метрах); номере материала, необходимого для изготовления деталей; дате, на момент которой должно быть полностью завершено выполнение заказа;

− вторичная информация предназначается для работы функции отображения статуса и прогресса выполнения заказа по партиям. К вторичной информации относятся: общий количественный состав партий деталей и количество партий, которые уже выполнены, из общего количества и статус заказа (после добавления общего количественного состава партий со значениями «0» и «В очереди» данные поля заполняются автоматически).

2.2.2 Характеристика результатной информации

 

Массив данных, где видна вся запрашиваемая информация за конкретный временной отрезок по товарообороту на предприятии является обработанной информацией, которая подвергается запросу пользователем системы «Оптовая торговля». С помощью такой информации представляется возможным за любой временной период выводить товарные, приходные и расходные накладные, в процессе продажи товара осуществлять выписку счета и гарантийных талонов.

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

Формирование экранной формы и выходного документа на носителе бумажного типа относится к одному из основных требований, которое предъявляется к программному комплексу «Оптовая торговля». Отчеты за конкретный временной период по приходным и расходным накладным относятся к выходной информации. Изначально они представляются в электронном формате, но каждый пользователь имеет возможность вывести их на бумажный носитель (таблица 2.2).

Таблица 2.2

«Отчеты»

В представленной выше таблице мы видим, что для формирования отчетов характерна периодичность.

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

Система управления базами данных (СУБД) – это совокупность программных и лингвистических средств общего или специального назначения, обеспечивающих управление созданием и использованием баз данных [24].

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

2.3    Программное обеспечение задачи

• Сценарий диалога

 

Дерево функций – функциональное отражение реализации целей автоматизированной системы. Разработка дерева функции позволяет выделить отдельные сценарии диалога [14]:

1. Сценарий «Работа со справочниками».
2. Сценарий «Работа с учетом товара».
3. Сценарий «Работа с оказанием услуг».
4. Сценарий «Работа с отчетами».

Работа со справочниками

Прежде, чем приступить к работе со справочниками, нужно выполнить следующие действия:

1. Выбрать пункт главного меню «Справочники».
2. Определиться с названием справочника, в котором будут произведены какие-либо изменения.
3. Выбрать действие, которое будет произведено над записями таблицы справочника:

– добавление записи;

– редактирование;

– удаление записи;

– навигация по справочнику.

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

Работа с учетом товара

С помощью главного меню «Учет товаров» пользователь имеет возможность:

– создать приходную накладную;

– открыть или внести коррективы в те накладные, что были созданы ранее;

– осуществить быстрый и удобный просмотр накладных с помощью установки интервала дат;

– осуществить быстрый поиск накладной, использовав ту дату, в которую он был создан.

Работа с отчетами

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

– выбрать пункт главного меню «Отчеты»;

– определить тип отчета, необходимый для формирования;

– установить параметры даты отчета;

– нажать кнопку «Сформировать».

После построения отчета пользователь должен решить:

– распечатать и сохранить данный вариант отчета;

– сохранить и не распечатывать данный вариант отчета;

– распечатать и удалить данный вариант отчета;

– не печатать и удалить вариант отчета;

– изменить форму отчета;

– перейти в другой тип отчета;

– выйти из этого режима работы.

Функциональная декомпозиция, а именно разделение всей системы на подсистемы и их детальное описание проводится после того, как была описана контекстная диаграмма. Поэтому на рисунке 2.1 каждый фрагмент системы представлен в виде отдельной диаграммы декомпозиции.

 

Рисунок 2.1 – Первый уровень декомпозиции

 

Весь процесс деятельности магазина делится на:

– консультация и продажа;

– прием и оформление заказов;

– сотрудничество с клиентами;

– контроль оплаты и отгрузка товара.

На рисунке 2.2 можно увидеть декомпозицию первого функционального блока, включающего в себя консультацию и продажу.

Рисунок 2.2 – Декомпозиция – консультация и продажа

 

Далее была произведена декомпозиция функционального блока – прием и оформление заказов (рисунок 2.3).

Рисунок 2.3 – Декомпозиция функционального блока – прием и оформление заказов.

Далее была произведена декомпозиция функционального блока – сотрудничество с клиентами (рисунок 2.4).

Рисунок 2.4 – Сотрудничество с клиентами

Затем декомпозировался последний блок диаграммы – контроль оплаты и отгрузка товара (рисунок 2.5).

Рисунок 2.5 – Контроль оплаты и отгрузка товара

Итак, процесс декомпозиции бизнес-процессов на предприятии АО «Системы управления» позволяет выявить структуру будущей базы данных.

2.3.2    Характеристика базы данных

 

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

Поддержка большого количества типов таблиц (у пользователей есть выбор между MyISAM – полнотекстовый поиск и InnoDB – транзакции на уровне отдельных записей) делает СУБД MySQL более гибкой. Важно отметить, что вместе с СУБД MySQL осуществляется поставка специальных типов таблиц EXAMPLE, которые показывают принципы разработки типов таблиц нового образца. СУБД MySQL регулярно пополняется новыми типами таблиц, что происходит за счет открытой архитектуры и GPL–лицензирования.

На рисунке 2.6 можно познакомиться со схемой базы данных ИС, проектирование которой осуществляется нами.

 

 

Рисунок 2.6 – Схема базы данных

2.3.3    Структурная схема пакета (дерево вызова программных модулей)

Система состоит из пользовательской и административной частей. Структура пользовательской части представлена на рисунке 2.7:

 

Рисунок 2.7 ­ Структурная схема пользовательской части пакета

 

На рисунке 2.8 представлена структура административной части ИС:

 

Рисунок 2.8 – Структурная схема административной части пакета

 

2.4 Испытание разработанного решения

2.4.1 Описание программных модулей

 

Конфигурации системы PAYDOX

Конфигурации системы – это сформированные или предустановленные варианты функционирования системы для разных типов функциональности или разных категорий пользователей. Необходимый функционал, предназначенный для разных видов приложений или пользовательских ролей, формируется за счет применения функциональности конфигураций.

Таблица 2.3

Конфигурации системы «PayDox»

 

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

В переменной VAR_PossibleApplicationTypes настроечного файла PayDox\TEXTANSI.txt указывается список тех конфигураций, что доступны, а, в свою очередь, в переменной VAR_ApplicationType – конфигурации, установка которых происходит по умолчанию.

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

Рисунок 2.9 – Выбор конфигурации

 

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

К документу можно приложить любое количество файлов. Документ может включать в себя файл образа документа. Примером может стать осуществление сканирования такого изображения, которое уже утверждено и содержит все обязательные составляющие (печать, подпись) или видео-, звуковые файлы. Для автоматического получения из системы на ПК пользователя того или иного документа, выполненного в MS Word и содержащего данные, которые находились в карточке документа, может быть настроен файл образца документа в формате MS Word. Это возможно для всей документации вышеописанной категории. В документ MS Word, который вызывается пользователем с web-сервера, данные из карточки вставляются автоматически «на лету». Данный документ предназначен для печати и может быть подписан. Система предусматривает загрузку файла образа документа, поскольку может появиться необходимость в хранении образа подписанного бумажного документа непосредственно в системе.

Рисунок 2.10 – Модель документа системы

 

2.4.2 Методы проведения испытаний

 

Методы проведения испытаний представим в виде таблицы 2.4.

Таблица 2.4

Описание проверки

 

 

2.4.3 Проведение проверочных испытаний и их результаты

 

Внедрение системы включает несколько этапов:

1. Установка выбранной системы на сервер.

Для того, чтобы работать в PayDox, применяется web-интерфейс, пользователи осуществляют свою деятельность посредством простого браузера (например, Mozilla Firefox), поэтому необходимость в установке ПО на рабочие места отсутствует.

2. Первоначальная настройка системы.

Первоначальная настройка предполагает комплекс следующих действий:

2.1.   Настройка контекстного поиска;

2.2.   Настройка связи с MsWord;

2.3.   Настройка автоматической рассылки e-mail;

2.4.   Настройка программного агента;

2.5.   Первоначальная настройка справочников системы:

Категории документов

— Пользователи

— Подразделения

— Должности

— Номенклатура дел

3. Доработка и адаптация системы под требования АО «Системы управления»
4. Обучение персонала.

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

В таблице 2.5 можно ознакомиться с календарным планом работ по внедрению СЭД PayDox.

Таблица 2.5

Календарный план работ по внедрению СЭД PayDox в АО «Системы управления»

Внедрение конфигураций СЭД PayDox в АО «Системы управления» следует произвести в следующем порядке:

«Документооборот»

«Ознакомление»

«Канцелярия»

«Контроллер»

«Бизнес-процессы»

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

Установка системы

Запустить установочный файл PayDoxSetup.

Прежде, чем начать установку, нужно удостовериться в том, что произведен запуск Internet Information Services. Если данная программа отсутствует на ПК, то нужно произвести ее установку, для чего использовать специальный инсталляционный диск Windows. Программа установки выдаст ошибку в том случае, если он не будет запущен.

Выделение отдельного IP-адреса необходимо для инсталляции PayDox. В данном случае нужно удостовериться в том, что функциональность ASP не отключена. После завершения установки систему можно запустить несколькими способами: кликнув на пиктограмму PayDox, которая появится на рабочем столе, или указав адрес web-узла PayDox, который находится в браузере и задается в процессе установки.

Первоначальная настройка системы paydox

2.1.   Настройка контекстного поиска

Служба индексирования Windows настраивается с целью работы полнотекстового контекстного поиска, который осуществляется по содержимому тех файлов документов, файлового архива, сообщений и бизнес-процессов, что были присоединены. Нужно убедиться в том, что служба индексирования не отключена. Далее в «создать каталог» Paydox и добавить в него папки Paydox\MessageFiles\, Paydox\DocFiles\ и Paydox\FileStorage\.

Рисунок 2.11 – Добавление в каталог Paydox папок Paydox\MessageFiles\, Paydox\DocFiles\ и Paydox\FileStorage\

Настройка полнотекстового поиска

В PayDox для полнотекстового поиска по файлам применяется Indexing Service.

Для функционирования полнотекстового поиска нужно выполнять ряд нижеописанных действий:

— включение автоматического старта Indexing Service должно происходить всегда после каждой загрузки операционной системы;

— создать новый каталог «PayDox» и расположение, сделать его частью Indexing Service;

— в каталог PayDox сервиса Indexing Service добавить ссылку на директорию, указанную в переменной Application(«PathDocFiles») в файле Global.asa с загруженными файлами системы;

— перезапустить Indexing Service;

— в файле Global.asa установить значение переменной Application («isfullindexsearch») = True.

 

2.2.       Настройка связи с ms word

Если применяется функциональность, основанная на том, что в процессе выдачи документов Word из карточки «на лету» в выведенный на ПК пользователя файл Word подставлять реквизиты карточки документа, то необходима настройка связи с MS Word. Для автоматического формирования стандартных документов, например, накладных или счетов-фактур, данная возможность оказывается очень полезной.

2.3.   Настройка автоматической рассылки e-mail уведомлений e-mail

Клиент – функциональность PayDox, предназначенная для обеспечения возможности работы с PayDox через e-mail без использования web-браузера.

Установка SMTP Service необходима в том случае, если планируется применение функциональности PayDox по автоматической рассылке e-mail уведомлений.

Использование внешнего smtp-сервера для отправки e-mail уведомлений.

Для отправки e-mail уведомлений используется внешний SMTP-сервер вместо используемого по умолчанию Windows Default SMTP Virtual Server. Ваши значения для таких переменных, как («IsNotUseDefaultSMTPVirtualServer») = «Y» указываются в файле Global.asa с целью настройки на использование внешнего SMTP-сервера. Если указать значением пустую строку, то будет использоваться Windows Default SMTP Virtual Server

Application(«SMTPServer»)= «mail.seversta****l.com» — адрес внешнего SMTP-сервера(«SMTPServerPort») = 25 — используемый порт(«SMTPConnectionTimeout») = 30 — таймаут установки соединения в секундах(«SMTPAuthenticate») = 1 — механизм аутентификации, 1- Basic, 2- NTLM(«SendUserName») = «administrator» — логин (имя почтового ящика)(«SendPassWord») = » administrator » — пароль(«SMTPUseSSL») = False — использовать ли SSL.

 

2.4.       Настройка программного агента

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

В данном случае могут быть выполнены следующие действия:

— периодические документы создаются автоматически;

— уведомления, приходящие в PayDox e-mail, проверяются;

— e-mail уведомления о наступлении сроков исполнения или истечении сроков действия той или иной документации отправляются пользователям автоматически.

В файле PayDox\Agent\Agent.asp хранится код программного агента, там же можно найти вызовы всей периодически выполняемой в системе функциональности. Непосредственно с помощью этого файла можно произвести изменения периодичности вызова данной функциональности. В файле PayDox\Agent\Agent.vbs находится вызов самого агента, периодичность его запуска нуждается в настройке. Периодичность вызова функциональности с наименьшим периодом вызова не должна быть больше периодичности вызова агента.

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

Запуск скрипта PayDox\Agent\Agent.asp должен осуществляться под MS Internet Explorer, поскольку данный скрипт является ASP-кодом, который выполняется на сервере PayDox. Этот запуск и осуществляет модуль PayDox\Agent\Agent.vbs. Данный автоматический запуск модуля PayDox\Agent\Agent.vbs требует периодичности, его настройка осуществляется в Windows Task Scheduler. Итак, новая задача создается и добавляется в расписание Windows.

Для того, чтобы запустить MS Internet Explorer, вызывающий, в свою очередь, скрипт PayDox\Agent\Agent.asp необходим программный код.

Программный код модуля PayDox\Agent\Agent.vbs:

Option ExplicitError Resume NextIEIE = CreateObject(«InternetExplorer.Application»).Visible = False.Navigate(«http://PRM01SQL004-010/ Agent/Agent.asp»)While IE.Busy.Sleep 1000.QuitIE = Nothing

Программный код модуля PayDox\Agent\Agent.asp

Программный код модуля PayDox\Agent\Agent.asp содержит исполняемый код, предназначенный для периодического автоматического исполнения.

Код для проверки даты и времени предыдущего запуска агента:

If Application(«SendNotifications»)<>»» ThenDateDiff(«d», Application(«SendNotifications»), Now) >= 1 Then

‘Функция выполняется только если с момента последнего запуска прошло больше 1 дня

Call SendNotifications(«SendNotifications») = NowIfSendNotifications(«SendNotifications») = Now

End If

Данный код определяет, было ли что-то записано в переменную Application(«SendNotifications») ранее. Если нет, то он запускает процедуру рассылки e-mail уведомлений Call SendNotifications. Если да, то проверяет, прошел ли с момента предыдущего запуска 1 день, если да, то запускает процедуру рассылки e-mail уведомлений Call SendNotifications и сохраняет текущую дату и время в переменную Application(«SendNotifications») для проверки при последующем запуске агента.

Страницы: 1 2 3