авторефераты диссертаций БЕСПЛАТНАЯ БИБЛИОТЕКА РОССИИ

КОНФЕРЕНЦИИ, КНИГИ, ПОСОБИЯ, НАУЧНЫЕ ИЗДАНИЯ

<< ГЛАВНАЯ
АГРОИНЖЕНЕРИЯ
АСТРОНОМИЯ
БЕЗОПАСНОСТЬ
БИОЛОГИЯ
ЗЕМЛЯ
ИНФОРМАТИКА
ИСКУССТВОВЕДЕНИЕ
ИСТОРИЯ
КУЛЬТУРОЛОГИЯ
МАШИНОСТРОЕНИЕ
МЕДИЦИНА
МЕТАЛЛУРГИЯ
МЕХАНИКА
ПЕДАГОГИКА
ПОЛИТИКА
ПРИБОРОСТРОЕНИЕ
ПРОДОВОЛЬСТВИЕ
ПСИХОЛОГИЯ
РАДИОТЕХНИКА
СЕЛЬСКОЕ ХОЗЯЙСТВО
СОЦИОЛОГИЯ
СТРОИТЕЛЬСТВО
ТЕХНИЧЕСКИЕ НАУКИ
ТРАНСПОРТ
ФАРМАЦЕВТИКА
ФИЗИКА
ФИЗИОЛОГИЯ
ФИЛОЛОГИЯ
ФИЛОСОФИЯ
ХИМИЯ
ЭКОНОМИКА
ЭЛЕКТРОТЕХНИКА
ЭНЕРГЕТИКА
ЮРИСПРУДЕНЦИЯ
ЯЗЫКОЗНАНИЕ
РАЗНОЕ
КОНТАКТЫ


Pages:     | 1 | 2 || 4 | 5 |

«УДК 002.52(075.8) ББК 32.973.202я73 МИНОБРНАУКИ РОССИИ ...»

-- [ Страница 3 ] --

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

- Базовые – их результаты должны быть использованы при перерасчете этого вида расчета;

- Вытесняющие –вытесняют этот вид расчета по периоду действия;

- Ведущие –изменение их результатов должно приводить к необходимости перерасчета этого вида расчета.

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

В этом случае для премии следует указать базовым видом расчета оклад, а ведущими – оклад и невыход, поскольку изменение результата расчета невыхода приведет к изменению результата оклада, что, в свою очередь, должно привести к изменению результата премии (рис. 5.4).

Рис. 5.4. Взаимное влияние видов расчетов Таким образом, существует возможность указать один из двух видов зависимости от базы: Зависимость по периоду действия и Зависимость по периоду регистрации. Оба вида этой зависимости подробно рассмотрены ниже в разделе Регистр расчета.

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

Например, вид расчета Алименты может зависеть по базовому периоду от таких видов расчета, как Оклад, ТарифДневной, ДоплатаПерсональная и т.д. (рис. 5.5,а). А вид расчета Оклад может вытесняться видами расчета Невыход, ОтсутствиеПоБолезни и др. (рис. 5.5,б).

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

Итак, каждый план видов расчета определяет отдельную структуру данных, где пользователь в режиме «1С:Предприятие» может создавать неограниченное число элементов (видов расчета). Созданные виды расчета пользователь впоследствии может изменять и удалять из базы данных. Кроме этого в режиме конфигурирования в плане видов расчета можно создать неограниченное количество предопределенных видов расчета. Эти виды расчета также будут доступны для использования в режиме «1С:Предприятие», но со следующими ограничениями:

предопределенный вид расчета не может быть удален в режиме «1С:Предприятие»;

в режиме «1С:Предприятие» не могут быть удалены и изменены некоторые свойства предопределенного вида расчета, заданные в режиме конфигурирования.

Об этих свойствах будет подробнее сказано ниже.

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

Рис. 5.6. Структура плана видов расчета Например, план видов расчета ОсновныеНачисленияОрганизаций может выглядеть, как показано на рис. 5.7. Догадайтесь, какие виды расчета на этом рисунке – предопределенные.

Рис. 5.7. План видов расчета ОсновныеНачисленияОрганизаций Формы плана видов расчета Для того чтобы пользователь мог просматривать и изменять данные, содержащиеся в плане видов расчета, система поддерживает несколько форм его представления. Система может автоматически генерировать все нужные формы;

наряду с этим разработчик имеет возможность создать собственные формы, которые система будет использовать вместо форм по умолчанию (рис. 5.8).

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

Для просмотра и изменения данных отдельных видов расчета используется форма вида расчета. Как правило, она представляет данные в удобном для восприятия и редактирования виде (рис. 5.9).

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

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

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

Как и другие регистры, регистр расчета имеет ресурсы, в которых хранит числовые данные;

имеет измерения, в разрезе которых можно получать значения ресурсов регистра;

имеет реквизиты, которые характеризуют каждую запись регистра расчета.

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

Периодичность регистра расчета может быть определена одним из следующих значений:

День;

Месяц;

Квартал;

Год.

Периодичность регистра расчета определяет промежуток времени, к которому будет относиться каждая запись регистра. Если указана периодичность День, то каждая запись регистра будет относиться к какому-либо дню;

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

Например, если в регистр расчета с периодичностью месяц записать данные, где ПериодРегистрации задан как 08.14.2004, то регистр сохранит эти данные со значением поля ПериодРегистрации 01.04.2004 (рис. 5.10,а). Если в этой же ситуации периодичность регистра будет год, сохраненное значение периода регистрации будет 01.01.2004 (рис. 5..10,б.).

а) б) Рис. 5.10. Запись данных из документа в регистр расчета с разной периодичностью Следующей важной особенностью регистра расчета является возможность использования механизма вытеснения одних записей другими по периоду действия. При этом для каждой записи регистр расчета формирует фактический период действия, который является в общем случае совокупностью нескольких периодов, расположенных внутри периода действия (рис. 5..11).

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

Таблица 5.1.

Таблица регистра расчета … Начало периода действия Конец периода действия Вид расчета … … … … … … … 01.04.2004 00:00:00 31.04.2004 23:59:59 ссылка на Оклад … … … … … … Таблица 5.2.

Таблица фактического периода действия … Начало периода действия Конец периода действия … … … … … … 01.04.2004 00:00:00 31.04.2004 23:59:59 … … … … … После добавления в регистр записи вида расчета Невыход, который вытесняет вид расчета Оклад по периоду действия, записи о начислении по окладу примут следующий вид (табл. 5.3, 5.4).

Таблица 5.3.

Таблица регистра расчета … Начало периода действия Конец периода действия Вид расчета …… … … … … 01.04.2004 00:00:00 31.04.2004 23:59:59 ссылка на Оклад … …… … … … … 04.04.2004 00:00:00 10.04.2004 23:59:59 ссылка на Невыход … … … … … … Таблица 5.4.

Таблица фактического периода действия … Начало периода действия Конец периода действия … … … … … … 01.04.2004 00:00:00 03.04.2004 23:59:59 … … 11.04.2004 00:00:00 31.04.2004 23:59:59 … … … … … Другим механизмом, который поддерживает регистр расчета, является зависимость записей по базовому периоду. Этот механизм позволяет основывать расчет зависимых (вторичных) записей регистра на данных, полученных в результате расчета первичных записей. Регистр расчета может поддерживать два вида зависимости от базы: зависимость по периоду действия и зависимость по периоду регистрации.

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

Например, в начале апреля производится расчет зарплаты за март. Премия за март должна быть начислена исходя из оплаты по окладу за март. В этом случае, как правило, используется зависимость по периоду действия (рис. 5.12).

Рис. 5.12. Зависимость по периоду действия Следует сделать два замечания к приведенному рисунку.

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

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

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

В качестве примера можно привести расчет штрафов при начислении зарплаты за март.

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

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

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

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

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

Формы регистра расчета Для того, чтобы пользователь мог просматривать данные, содержащиеся в регистре расчета, система поддерживает форму представления регистра расчета – форму списка. Она позволяет выполнять сортировку и отбор отображаемой информации по нескольким критериям (рис. 5.14):

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

Функциональные возможности регистра расчета Основными функциональными возможностями, которые предоставляет регистр расчета разработчику, являются:

- выбор записей в заданном интервале по заданным критериям;

- выбор записей по регистратору;

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

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

- получение данных о записях, подлежащих перерасчету;

- чтение, изменение и запись набора записей в регистр.

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

Диаграмма Ганта представляет собой диаграмму интервалов на шкале времени (рис.

5.15) и отражает использование объектами (точками) ресурсов (серий).

Рис. 5.15. Пример представления фактического периода действия записей расчета с помощью диаграммы Ганта Диаграмма отображает значение для каждой пары точка-серия. В нашем случае отображения фактического периода действия записей регистра расчетов точками диаграммы являются сотрудники, а сериями – виды расчетов. Таким образом, для каждого сотрудника существует некоторое значение диаграммы по каждой из серий, то есть по каждому из видов расчета.

Платформа 1С:Предприятие содержит элемент управления, позволяющий создавать диаграммы Ганта. Значение диаграммы Ганта представляет собой специальный объект, который автоматически формируется системой на основании того, какие точки и какие серии определены для данной диаграммы. Этот объект является совокупностью (коллекцией) интервалов, то есть может содержать не один, а несколько интервалов, которые соответствуют паре серия-точка (создаваемый по умолчанию объект ЗначениеДиаграммыГанта не содержит ни одного интервала). Разработчик может получить значение диаграммы, указав интересующую его точку и серию, и затем добавить в коллекцию необходимое количество интервалов.

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

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

Литература: [1, 6, 14].

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

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

Кроме этого, должна существовать возможность ограничить пользователей в выполнении тех или иных действий с объектами базы данных. Например, кладовщик может создавать и изменять приходные накладные, поскольку он отвечает за учет материалов на предприятии. Мастеру может понадобиться просматривать приходные накладные для того, чтобы знать, какие материалы и когда были получены. Однако мастер не должен иметь возможности вносить какие-либо изменения в приходные накладные.

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

В этой лекции рассмотрим механизмы и средства администрирования корпоративной ИС на примере администрирования систем на платформе 1С:Предприятие 8 по материалам сайта фирмы 1С и руководства [13].

Основные средства администрирования системы 1С:Предприятие реализованы в составе конфигуратора. Однако есть ряд механизмов и утилит, которые не входят в состав конфигуратора, хотя также имеют отношение к администрированию системы 1С:Предприятие. Наиболее важные механизмы и инструменты, входящие в состав средств администрирования 1С:Предприятия представлены на рис. 6.1.

Рис. 6.1. Механизмы и инструменты, входящие в состав средств администрирования 1С:Предприятия 6.1. Аутентификация Система 1С:Предприятие обеспечивает одновременную работу нескольких пользователей с одним прикладным решением. Для разграничения прав доступа пользователей к данным информационной базы, в системе ведется список пользователей, допущенных к работе с данным прикладным решением.

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

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

- аутентификация средствами 1С:Предприятия;

- аутентификация средствами Windows.

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

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

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

Если для пользователя не указан ни один из видов аутентификации, - такому пользователю доступ к прикладному решению закрыт.

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

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

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

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

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

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

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

а) б) Рис. 6.3. Учебная версия не допускает аутентификацию Windows и не позволяет задавать пароли пользователям 6.2. Система прав доступа Система прав доступа позволяет описывать наборы прав, соответствующие должностям пользователей или виду деятельности. Структура прав определяется конкретным прикладным решением.

Кроме этого, для объектов, хранящихся в базе данных (справочники, документы, регистры и т.д.) могут быть определены права доступа к отдельным полям и записям.

Например, пользователь может оперировать документами (накладными, счетами и т.д.) определенных контрагентов и не иметь доступа к аналогичным документам других контрагентов.

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

Рис. 6.4. Роли в учебной версии Роль определяет, какие действия, над какими объектами метаданных может выполнять пользователь, выступающий в этой роли:

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

Ограничение доступа к данным на уровне записей и полей Среди действий над объектами, хранящимися в базе данных (справочниками, документами и т.д.), есть действия, отвечающие за чтение или изменение информации, хранящейся в базе данных. К таким действиям относятся:

- чтение - получение записей или их фрагментов из таблицы базы данных;

- добавление - добавление новых записей без изменения существующих;

- изменение - изменение существующих записей;

- удаление - удаление некоторых записей без внесения изменений в оставшиеся.

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

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

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

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

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

Рис. 6.5. Интерфейсы в учебной версии Редактор интерфейсов содержит два окна. В верхнем окне отображается список панелей, входящих в состав интерфейса (это могут быть как командные панели, так и панели инструментов). В нижнем окне отображается содержимое выбранной панели. Командные меню и панели инструментов имеют схожую структуру: они содержат набор элементов, которые могут образовывать иерархические структуры:

Редактор позволяет добавлять и удалять панели интерфейса, управлять порядком из отображения на экране:

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

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

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

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

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

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

Рис. 6.7. Журнал регистрации 1С:Предприятие Журнал регистрации доступен как в режиме 1С:Предприятие, так и в режиме Конфигуратор. В режиме 1С:Предприятие по щелчку мыши в полях Данные и Представление данных можно перейти к тому объекту прикладного решения, который указан в записи журнала регистрации.

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

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

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

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

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

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

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

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

При загрузке и выгрузке информационной базы система открывает стандартный диалог выбора файла.

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

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

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

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

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

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

- ограничение времени тестирования и исправления;

- сохранение параметров тестирования между этапами;

- продолжение прерванного ранее тестирования и исправления;

- поддержка тестирования и исправления порциями в командной строке запуска.

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

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

Как правило, роли создаются отдельно для каждого вида деятельности, и каждому пользователю системы ставится в соответствие одна или несколько ролей.

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

- если хотя бы в одной роли есть разрешение, то доступ будет открыт;

- если во всех ролях разрешение отсутствует, то доступ будет закрыт.

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

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

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

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

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

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

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

В лабораторной работе №4 мы создадим в разрабатываемой системе две подсистемы и в будем использовать их для назначения прав пользователей.

Литература: [6, 14, 20-21].

Лекция 7. Интеграция корпоративных ИС, реализация обмена данными в корпоративных ИС 7.1. Взаимосвязь информационных подсистем предприятия Каким образом связаны информационные системы внутри предприятия? Обычный путь для российской компании средних размеров - начинать внедрение информационных технологий с автоматизации работы бухгалтерии, отдела кадров и документооборота.

Данные этих систем наиболее формализованы, процессы легко автоматизируются. Широко распространенные пакеты "1C: Бухгалтерия", "Босс: Кадровик", "LanDocs", "LanStaff", "Salary" и др. позволяют наращивать себя любыми приложениями и, таким образом, интегрировать их в общую информационную систему предприятия. Рис. 7.1 показывает, каким образом модули информационной системы компании связаны друг с другом. Модуль TPS обслуживает основные производственные и вспомогательные процессы, и обычно это главный источник для других информационных модулей. ESS - главный получатель данных и внутренних систем из внешней среды.

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

Связи между DSS и совокупностью TPS, KWS, MIS намеренно показаны неопределенными. Иногда DSS тесно связана с другими подсистемами. Но это только в том случае, если предприятие отличается высокой степенью автоматизации всех процессов.

Обычно подсистема DSS изолирована от основных производственных информационных систем и использует их данные и информационные потоки для работы своих аналитических систем.

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

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

В настоящее время при формировании информационной инфраструктуры предприятия, при проектировании и реализации КИС все чаще применяется сервис-ориентированная архитектура (Service-Oriented Architecture - SOA). Это такая архитектура ИС, в которой система строится из набора гетерогенных слабосвязанных компонентов (сервисов). SOA понимается как парадигма организации и использования распределенного множества функций, которые могут контролироваться различными владельцами. Базовыми понятиями в такой архитектуре являются "информационная услуга" и "композитное приложение".

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

Сервис обычно характеризуется следующими свойствами:

- возможность многократного применения;

- услуга может быть определена одним или несколькими технологически независимыми интерфейсами;

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

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

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

- создать систему корпоративных композитных приложений, основанных на системе корпоративных Web-сервисов;

- организовать интеграцию приложений, бизнес-процессов, с автоматизацией бизнес процессов, включая Human Workflow;

- использовать различные транспортные протоколы и стандарты форматирования сообщений, средства обеспечения безопасности, надежной и своевременной доставки сообщений;

- существенно повысить скорость разработки прикладных приложений и снизить затраты на эти цели.

Благодаря упрощению среды управления и взаимодействия снижается потребность в кодировании новых программ;

повторное использование сервисов сокращает затраты времени на разработку;

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

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

Обязательным условием построения и внедрения архитектуры системы на основе SOA является использование единой инфраструктуры описания сервисов (репозитория сервисов), разрешенных протоколов доступа и обмена сообщениями, форматов сообщений.

Упомянутая инфраструктура образует так называемую интеграционную шину (ИШ) (Enterprise Service Bus - ESB), являющуюся одним из центральных компонентов системы.

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

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

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

По данным Gartner Group ("Predicts 2007: SOA Advances", 17 ноября 2006 года): "К году SOA станет господствующей архитектурой построения ИТ-систем, что приведет к окончанию 40-летней эры господства архитектуры монолитных приложений".

Рис. 7.2. Структура построения ESB и компоненты концепции SOA Изменение и совершенствование бизнес-процессов в компаниях занимает годы. По данным Gartner Group, 80% ИТ-бюджета - это расходы на сопровождение систем, из них 35% - затраты на интеграцию приложений, 60% стоимости внедрения корпоративной ИС составляют расходы на интеграцию, 50% ИТ-бюджета потрачено на обеспечение интерфейсов систем. Использование SOA-архитектуры позволяет эффективно организовать оперативную адаптацию ИТ-систем под требования бизнеса, что дает стратегическое преимущество компании, заключающееся в:

- повышении скорости адаптации бизнеса к быстро меняющимся требованиям рынка (Agility);

- расширении взаимодействия гетерогенных корпоративных информационных систем при сохранении сделанных в них инвестиций;

- сокращении расходов на ИТ-системы на основе повторного использования их функциональных компонентов;

- повышении производительности труда клиентов, партнеров и сотрудников (на основе архитектуры Web 2.0).

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

- Основные бизнес-цели внедрения SOA-решений состоят в ликвидации:

- фрагментированности и дублирования данных;

- дублирования реализаций бизнес-функций, процедур, процессов;

- негибкой архитектуры.

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

- обеспечивать преемственность инвестиций в IT, сохранение существующих информационных систем и их совместное эффективное использование для повышения ROI от IT-вложений;

- обеспечивать реализацию различных типов интеграции:

o пользовательская интеграция (User Integration) - обеспечение взаимодействия информационной системы с конкретным персонифицированным пользователем;

o интеграция приложений (Application Connectivity) - обеспечение взаимодействия приложений;

o интеграция процессов (Process Integration) - интеграция процессов в соответствии с бизнес-логикой деятельности предприятия;

o информационная интеграция (Information Integration) - интеграция с целью обеспечения доступности информации и данных;

o интеграция новых приложений (Build to Integrate) - интеграция новых приложений и сервисов в существующие информационные системы.

- обеспечивать поэтапность внедрения вновь созданных и миграции существующих информационных систем;

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

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

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

Рост рынка продуктов для SOA-решений - 100% в год. В 2006 году ожидалось [2], что в 2007 году SOA будет использована как основа создания 50% новых приложений, критичных для бизнеса и бизнес-процессов;

а к 2010 году этот показатель вырастет до 80%. Более 80% приложений, введенных в промышленное использование в 2006 году, будут частично или полностью перепроектированы к 2010 году, чтобы быть использованными в построении композитных приложений в SOA- архитектуре;

к 2010 году более 80% всех программных инфраструктурных продуктов будут включать корпоративную шину сервисов или требовать ее использования. Среди исполнительных директоров компаний 54% считали, что в период до 2010 года в числе главных стратегических преимуществ компаний новые модели ведения бизнеса имеют большее значение, чем выпуск новых продуктов и услуг. По данным Forrester ("The State of SOA in Financial Services", январь 2006), "Подавляющее большинство финансовых компаний будут использовать SOA к концу 2008 г. В общем, 50% европейских финансовых компаний или уже используют SOA или находятся на последней стадии его внедрения".

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

- создавать, обрабатывать и обмениваться данными различных форматов;

- осуществлять доступ ко всем объектам системы 1С:Предприятие 8, реализующим ее функциональные возможности;

- поддерживать различные протоколы обмена;

- поддерживать стандарты взаимодействия с другими подсистемами;

- разрабатывать собственные интернет-решения.

Рассмотрим кратко эти средства.

7.3.1. Механизмы обмена данными Механизмы обмена данными позволяют реализовать территориально распределенные информационные системы, обменивающиеся данным в off-line режиме, без постоянного соединения. С помощью этих механизмов можно осуществлять интеграцию не только между различными информационными базами 1С:Предприятия, но и строить сложные гетерогенные информационные системы, включающие, наряду с решениями на платформе 1С:Предприятие, еще и внешние приложения.

Платформа обеспечивает работу двух механизмов обмена данными:

- Механизм распределенных информационных баз Этот механизм предназначен для обмена данными только с идентичными конфигурациями 1С:Предприятия 8 и жестко регламентирует структуру создаваемой системы. Он является аналогом компоненты «Управление распределенными информационными базами», существующей в технологической платформе 1С:Предприятия 7.7, однако существенно превосходит этот механизм по гибкости настройки и разнообразию поддерживаемых схем обмена.

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

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

В состав средств платформы, используемых для построения схем обмена данными, входят:

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

- Средства XML-сериализации. Средства XML-сериализации служат для представления данных 1С:Предприятия 8 различных типов в виде последовательности данных XML, и наоборот.

- Средства чтения/записи XML-документов Средства чтения и записи XML документов позволяют работать с данными формата XML на «базовом» уровне, без привязки к объектам 1С:Предприятия 8.

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


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

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

7.3.2. Работа с XML-документами Работа с XML-документами доступна непосредственно из встроенного языка системы 1С:Предприятие 8.

Имеется возможность:

- последовательно читать и записывать xml-документы:

o преобразовывать из строки, полученной из текста элемента или значения атрибута XML, в значение в соответствии с указанным типом;

o получать строковое представление значения для помещения в текст элемента или значение атрибута XML;

o получить тип данных XML, соответствующий переданному в качестве параметра типу;

o производить проверку возможности чтения из XML значения указанного типа;

o производить проверку соответствия схеме XML при чтении XML o производить запись значения в формате XML;

o возвращать тип, соответствующий типу данных XML.

- использовать модель объектного доступа к данным xml-документов (ДокументDOM), соответствующую следующим стандартам:

o DOM Level 2;

o XPath (DOM Level 3);

o DOM Load and Save (DOM Level 3).

- использовать объектную модель схемы XML (СхемаXML).

Используя внешнее соединение и механизмы работы с XML можно организовывать интеграцию с прикладными системами по принятым в этих системах форматам. Для этого применяются механизмы XSL-преобразования. Например, для такой интеграции можно использовать BizTalk сервер компании Microsoft (рис. 7.4).

Рис. 7.4. Использование BizTalk сервера компании Microsoft для интеграции ИС Платформа 1С предоставляет средства для работы с XML-документами в бинарном формате Fast Infoset. Технология Fast Infoset использует альтернативный синтаксис отображения XML-данных. Это обеспечивает меньший объем файлов и более высокую скорость обработки, чем скорость обработки данных, записанных в обычном XML-формате.

Файл, записанный в формате fast infoset, имеет расширение.fi или.finf.

7.3.3. Web-сервисы Web-сервисы - это один из важных механизмов платформы, используемых для интеграции с другими информационными системами. Он является средством поддержки упоминавшейся выше SOA (Service-Oriented Architecture) - сервис-ориентированной архитектуры, которая является современным стандартом интеграции приложений и информационных систем.

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

Она позволяет реализовывать слабо связные программные компоненты с тем, чтобы максимально повысить их повторную используемость.

Сервис-ориентированная архитектура интенсивно развивается и поддерживается крупными вендорами. Она строится на базе сервисов, автономных или управляемых извне.

Предпочтительным способом их реализации являются веб-сервисы. Они независимы от платформы, автономны и поддерживаются повсеместно.

Прикладное решение 1С:Предприятия 8 может являться как поставщиком веб сервисов, так и потребителем веб-сервисов, опубликованных другими поставщиками.

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

Рис. 7.5. 1С:Предприятие как поставщик веб-сервисов В качестве потребителей могут выступать системы, использующие произвольные аппаратные и программные платформы. Технология веб-сервисов является платформенно независимой.

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

Рис. 7.6. 1С:Предприятие как потребитель веб-сервисов Техническая реализация web-сервисов Если прикладное решение 1С является поставщиком веб-сервиса то и в файловом, и в клиент-серверном варианте работы взаимодействие между прикладным решением и потребителями веб-сервиса осуществляется через веб-сервер, с помощью модуля расширения веб-сервера (рис. 7.7, а).

а) б) Рис. 7.7. 1С:Предприятие в роли поставщика (а) и потребителя (б) Web-сервиса При этом, когда потребитель обращается к web-сервису прикладного решения, выполняется модуль web-сервиса. Этот модуль содержится в конфигурации и в нем располагаются процедуры, выполняемые при вызове тех или иных операций web-сервиса.

В случае клиент-серверного варианта работы этот модуль будет исполняться в кластере серверов 1С:предприятие. В случае файлового варианта работы - в модуле расширения веб-сервера.

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

7.3.4. Web-расширение Web-расширение - это один из компонентов платформы. Оно поставляется в составе отдельного продукта - 1С:Предприятие 8. Web-расширение 1. Этот компонент позволяет встраивать доступ к данным 1С:Предприятия в существующие Web-сайты и Web-приложения, а так же создавать готовые Web-приложения, использующие информационную базу 1С:Предприятия 8.

Данный программный продукт расширяет сферу применения 1С:Предприятия 8. Он позволяет организовать доступ через веб-интерфейс к функциональности прикладных решений новых категорий пользователей, в том числе и тех, у которых на компьютерах не установлена платформа 1С:Предприятия. Это могут быть мобильные пользователи, сотрудники территориально удаленных подразделений, посетители интернет-магазинов и веб-порталов:

Web–расширение позволяет встраивать доступ к данным 1С:Предприятия в существующие веб-сайты и веб-приложения и создавать готовые веб-приложения, использующие информационную базу 1С:Предприятия 8.

Благодаря Web-расширению разработчик может быстро построить пользовательский веб-интерфейс, по стилю работы схожий с интерфейсом 1С:Предприятия 8, и легко адаптировать веб-приложение к изменениям прикладного решения.

Разработчик может создавать формы веб-приложения самостоятельно или использовать формы, автоматически генерируемые системой на основе структуры конфигурации 1С:Предприятия 8.

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

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

Для создания веб-приложения разработчику достаточно воспользоваться конструктором приложения. Далее разработчик может создавать формы для тех объектов конфигурации, к которым необходимо реализовать доступ через веб-интерфейс. Создание формы также полностью реализуется конструкторами. Полученные в результате формы могут интерактивно редактироваться. Разработчик может управлять составом элементов управления, связанных с данными информационной базы, и их свойствами аналогично тому, как это делается для форм пользовательского интерфейса 1С:Предприятия. При этом, как и в пользовательском интерфейсе 1С:Предприятия 8, система автоматически создает в процессе работы формы для тех объектов, для которых разработчик не создал их в явном виде.

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

Если же необходимо включить доступ к данным 1С:Предприятия в уже имеющиеся страницы, то можно использовать специализированные элементы управления, предоставляемые Web-расширением. Использование таких элементов управления позволит реализовать доступ к данным информационной базы без написания кода и предоставит пользователю весь необходимый сервис по работе с данными.

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

3. Организация доступа к данным 1С:Предприятия для решения других задач Кроме использования специализированных форм и элементов управления, механизмы Web-расширения могут использоваться и для решения других задач, связанных с получением доступа к данным 1С:Предприятия.

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


Кроме этого, механизмы доступа к данным Web-расширения могут использоваться и для решения интеграционных задач не связанных непосредственно с веб-доступом.

4. Организация программного доступа к 1С:Предприятию из других систем Предоставляемая Web-расширением технология создания веб-сервисов позволяет реализовать программный доступ к функциональности прикладных решений 1С:Предприятия практически из любых программных средств.

Использование веб-сервисов позволяет построить интеграционные решения на основе наиболее современных технологий. При этом 1С:Предприятие будет выступать в качестве одной из компонент интегрированного решения.

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

Структура Web-расширения Взаимодействие клиента с информационной базой 1С:Предприятия 8 при использовании Web-расширения выглядит следующим образом (рис. 7.8) [19].

Рис. 7.8.

Используя технологии веб-сервера (Microsoft.NET ) и механизмы 1С:Предприятия (внешнее соединение), Web-расширение предоставляет как пользовательский, так и программный интерфейс для манипулирования данными информационной базы 1С:Предириятия 8.

Это становится возможным благодаря тому, что Web-расширение имеет многоуровневую архитектуру, включающую в себя как базовые объекты (выполняющие только операции манипулирования данными), так и специализированные объекты, реализующие алгоритмы взаимодействия пользователя с данными информационной базы, аналогичные используемым в самой системе 1С:Предприятие 8.

На рис. 7.9 представлена схема работы Web-расширения.

Рис. 7.9. схема работы Web-расширения 1С:Предприятие Для доступа к информационным базам Web-расширение использует механизм внешнего соединения. Этот механизм является наиболее эффективным инструментом организации программного доступа к данным 1С:Предприятия 8. Web-расширение может сохранять открытые внешние соединения в пуле для их повторного использования, что позволяет экономить ресурсы веб-сервера и ускорять работу пользователей.

На базовом уровне работа с данными 1С:Предприятия 8. осуществляется при помощи набора объектов, реализующих технологию доступа к данным ADO.NET. Эти объекты позволяют не только получать данные, но и модифицировать их.

Получение данных возможно в двух режимах: режиме таблицы, реализующем технику объектного доступа к данным, и в режиме запроса, позволяющем полностью использовать возможности языка запросов 1С:Предприятия 8.

Модификация данных (добавление, изменение и удаление) выполняется только в режиме таблицы (т.е. в объектной технике).

Для создания пользовательского интерфейса и работы с данными на более высоком уровне используется ряд объектов, реализующих технологию ASP.NET.

Контрольные вопросы и задания 1. В чем заключается суть интеграции информационных ресурсов предприятия?

2. Что такое сервис-ориентированная архитектура ИС?

3. Каким образом формируется информационная услуга?

4. На базе каких элементов реализуются корпоративные композитные приложения?

5. Что такое Web-сервис и какую роль такой сервис играет в информационной инфраструктуре компании?

6. Какие основные механизмы использует для интеграции ИС платформа 1С?

7. В чем разница между механизмами web-сервисов и web-расширением Литература [3, 6, 14, 20].

Лекция 8. Внедрение корпоративных ИС. Методики внедрения.

8.1. Особенности выбора и внедрения корпоративной ИС Классические корпоративные ИС, в отличие от так называемого "коробочного" программного обеспечения, относятся к категории "тяжелых" программных продуктов, требующих достаточно длительной настройки, перед тем как начать ими пользоваться.

Выбор КИС, приобретение и внедрение, как правило, требуют тщательного планирования в рамках длительного проекта с участием партнерской компании - поставщика или консультанта [21].

Поскольку КИС строятся по модульному принципу, заказчик часто (по крайней мере, на ранней стадии таких проектов) приобретает не полный спектр модулей, а ограниченный их комплект. В ходе внедрения проектная команда, как правило, в течение нескольких месяцев осуществляет настройку поставляемых модулей (рис. 8.1).

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

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

Если с приобретением малой, как правило "коробочной" системы проблем практически не бывает, то со средней системой - и тем более с крупной - всё обстоит гораздо сложнее.

Крупную информационную ERP-систему нельзя так просто купить, доставить, включить и пользоваться. Предприятие должно быть основательно подготовлено к внедрению такой системы. Внедрение ERP-системы сродни сложной хирургической операции - и там и здесь резать приходится "по живому", и там и здесь очень много зависит от тщательной подготовки, от умения профессионалов и даже от удачи [2]!

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

- высокая стоимость приобретаемого продукта (доходящая до нескольких миллионов долларов);

- большое разнообразие предлагаемых ERP-систем;

- длительность срока подготовки специалистов по внедряемому продукту;

- предпродажный цикл (от нескольких месяцев до нескольких лет);

- сам цикл внедрения (цикл внедрения ERP-системы даже на одной производственной площадке предприятия может длиться до нескольких лет).

Таблица 8.1.

Соотношение стоимостных оценок внедрения Внедрение, соотношение затрат и стоимостные оценки Локальные Малые Средние Крупные системы интегрированные интегрированные интегрированные системы системы системы Внедрение Простое, Поэтапное или Только Поэтапное, коробочный коробочный поэтапное. Более сложное. Более 9 вариант вариант. Более 4 6-9 месяцев 12 месяцев месяцев Функциональная Учетные Комплексный учет Комплексное управление: учет, полнота системы (по и управление управление, производство направлениям) финансами Соотношение затрат 1/ 0,5 / 2 1/ 1/ 1 1/ 2/ 1 1/ 1-5/ лицензия/ внедрение/ оборудование Ориентировочная 5-50 тыс. дол. 50-300 тыс. дол. 200-500 тыс. дол. 500 тыс. 1 млн.

стоимость дол.

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

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

В то же время ERP-система - это не только инструментарий для бизнеса, но и технология его ведения.

В правильном выборе ERP-системы должно быть в первую очередь заинтересовано руководство предприятия. Проект по внедрению ERP-системы должен рассматриваться руководством предприятия как стратегическая инвестиция.

Естественно, что любое предприятие предпочтет внедрить апробированную, надежную и приемлемую для него по цене ERP-систему. Вопрос заключается в том, какую систему имеет смысл внедрять - западную или отечественную? И здесь нельзя дать однозначный ответ.

В настоящее время российские системы демонстрируют хорошую динамику развития, однако западные системы пока все же богаче функционально. Особенностью западных систем является также то, что они разрабатываются (и дорабатываются) уже несколько десятков лет в соответствии с общемировыми принципами эффективного ведения бизнеса (без уклонения от уплаты налогов, ведения двойной бухгалтерии и др.). То есть в западных системах гораздо лучше реализована так называемая "правильная" ("цивилизованная") модель ведения бизнеса. Это преимущество является одновременно и их недостатком (применительно к российским условиям), так как западные ERP-системы хуже приспособлены к работе со сложными, нецелостными и нелогичными бизнес-моделями, которые в настоящее время более жизнеспособны в России. Недостатком западных систем является также их высокая стоимость, хотя некоторые российские программные системы по стоимости уже догоняют западные ERP-системы [2].

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

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

В первую очередь руководство предприятия должно понять, зачем предприятию нужна ERP-система. Еще до внедрения должны быть поставлены четкие и измеряемые цели, заданные в так называемой S.M.A.R.T. системе: цели должны быть конкретны (Specific), измеримы (Measurable), согласованы (Adjusted), релевантны (Relevant) и иметь определенные сроки исполнения (Time of Execution). Желательно, чтобы ответ на этот вопрос можно было формализовать и представить наглядно в цифрах и диаграммах (объем сэкономленных средств, более высокая оборачиваемость товаров, сокращение времени на работу с поставщиками и клиентами и др.). Обязательно должны быть сформулированы и утверждены руководством предприятия основные требования к ERP-системе:

- какие цели хозяйственной деятельности и задачи бизнеса в целом позволит реализовать приобретаемая и внедряемая система;

- какие функциональные области и типы производства она должна охватывать;

- какие процессы следует автоматизировать;

- какие отчеты готовить;

- какие программно-технические платформы использовать.

При этом очень важно четко определить текущие и перспективные потребности предприятия или организации. Нужно хорошо разобраться, что движет бизнесом, какие факторы критичны для успеха и что необходимо для развития компании. Требования должны быть оформлены в виде специального документа (Vision Scope), в котором определены и расписаны по приоритетам все желаемые характеристики ERP-системы.

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

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

Чрезвычайно важным моментом является и правильный выбор разработчика (или разработчика-внедренца, как это нередко еще бывает в России) ERP-системы, который должен не просто поставить свое ПО компании-клиенту, а стать ее долговременным партнером, обеспечивающим сопровождение и дальнейшее развитие системы.

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

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

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

В ряде случаев предприятия ориентируются на системы, разработанные собственными отделами ИТ. Практика показывает, что ориентация на "самописные" системы позволяет получить ИС, наиболее подходящую для бизнеса компании, но ставит в итоге компанию в зависимость от собственных разработчиков. Редко такой самостоятельно разработанный программный продукт остается жизнеспособным достаточно долгое время, так как по нему обычно нет соответствующей полной и актуальной документации. Нельзя сказать, что он профессионально протестирован на этапах разработки и сдачи в эксплуатацию и надежно сопровождается (примером этому является хотя бы кондитерская фабрика имени Крупской в Санкт-Петербурге, которой пришлось спешно переходить с унаследованных систем на программный продукт "Парус" из-за ухода своих ведущих программистов [24]). Крупное предприятие может позволить себе инвестировать средства в разработку собственной (под свои конкретные потребности) КИС только при наличии следующих основных условий:

- на рынке нет готового программного продукта, удовлетворяющего предприятие по функциональности, стоимости и условиям сопровождения;

- на предприятии есть мощный ИТ-отдел с опытными аналитиками, менеджерами проектов и программистами;

- есть полная и грамотная постановка задачи;

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

- есть возможность реального сопровождения созданной системы собственными силами;

- возможность тиражирования разработанного ПО для дочерних (отраслевых) предприятий.

8.2. Основные принципы выбора ERP-системы При выборе ERP-системы необходимо обратить особое внимание на следующие основные моменты.

Имидж фирмы-разработчика, время ее работы на рынке, репутация самой системы и общее количество успешных внедрений. Однако солидность фирмы не является главным фактором выбора. Многие новички рынка (не обладающие ежегодными миллионными оборотами и тысячами клиентов) предлагают интересные решения, основанные на современных технологиях и по вполне разумной цене. Большое число внедрений может быть также заслугой маркетинга, а не действительным качеством системы. Известны по крайней мере несколько случаев, когда предприятия по несколько раз меняли свои ERP-системы, обладающие известными на российском рынке брэндами (причем, как западные, так и российские). Главной причиной замены этих систем являлась недостаточная функциональность систем, низкая скорость работы, малая масштабируемость1, плохое качество сопровождения при необходимости доработки систем и др.

Масштабируемость— в электронике и информатике означает способность системы, сети или процесса справляться с увеличением рабочей нагрузки (увеличивать свою производительность) при добавлении ресурсов (обычно аппаратных). Масштабируемость — важный аспект электронных систем, программных комплексов, систем баз данных, маршрутизаторов, сетей и т. п., если для них требуется возможность работать под большой нагрузкой. Система называется масштабируемой, если она способна увеличивать производительность пропорционально дополнительным ресурсам. Также под масштабируемостью понимается возможность наращивания дополнительных ресурсов без структурных изменений центрального узла системы. В системе с Число успешных внедрений в России. В первую очередь, имеются в виду комплексные внедрения. Важно также знать, есть ли внедрения на родственных отраслевых предприятиях и потребовалась ли там помощь внешних консультантов. Необходимо также посмотреть, как реально работает система хотя бы на одном-двух объектах, и пообщаться с ИТ-менеджерами и ее рядовыми пользователями, так как никакие маркетинговые материалы или даже статьи в специализированных изданиях не помогут составить более или менее полное представление о реальных возможностях системы - в некоторых случаях они даже вредны, так как рекламные издания могут сформировать неадекватное представление о ERP-системе у неподготовленного менеджера! Однако следует всегда помнить о том, что любая (даже чрезвычайно функционально богатая) ERP-система настраивается под потребности конкретного предприятия (а предприятий-близнецов даже в рамках одной отрасли просто не существует). В этом случае важно понять, способна ли фирма-разработчик в разумные сроки "дописать" поставляемую систему под функциональность, необходимую предприятию заказчику. Следует помнить, что в некоторых случаях затраты на доработку системы и ее последующее сопровождение могут превышать базовую стоимость.

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

За это время предприятие значительно меняется (его продукция, организационно-штатная структура, система управления, бизнес-процессы, роли и полномочия должностных лиц и др.). Информационно-аналитическая система, являющаяся основой управления предприятием, должна меняться вместе с производством. Она должна позволять легко менять АРМы и меню, формировать отчеты и справки, делать произвольные выборки информации в удобном представлении, менять технологию сопровождения бизнес-процессов и шаблоны отчетных форм путем параметрической настройки. Система должна легко настраиваться и интегрироваться в рамках ИИС предприятия с другим программным обеспечением (например, с корпоративным ПО расчета зарплаты или управления персоналом, ПО управления документооборотом, CAD/CAM/CAE-системами, PDM системами и др.). Важным моментом при этом является то, что все необходимые доработки системы должна делать фирма-разработчик, юридически отвечающая перед предприятием за качество своей работы.



Pages:     | 1 | 2 || 4 | 5 |
 





 
© 2013 www.libed.ru - «Бесплатная библиотека научно-практических конференций»

Материалы этого сайта размещены для ознакомления, все права принадлежат их авторам.
Если Вы не согласны с тем, что Ваш материал размещён на этом сайте, пожалуйста, напишите нам, мы в течении 1-2 рабочих дней удалим его.