Основные подходы к интегрированию программных модулей кратко

Обновлено: 02.07.2024

Методические указания по выполнению практических работ по МДК 02.01 Технология разработки программного обеспечения разработаны в соответствии с рабочей программой ПМ.02. Осуществление интеграции программных модулей по специальности 09.02.07 Информационные системы и программирование.

Методические указания по выполнению практических по МДК 02.02 Инструментальные средства разработки программного обеспечения работ разработаны в соответствии с рабочей программой ПМ.02. Осуществление интеграции программных модулей по специальности 09.02.07 Информационные системы и программирование.

Методические указания по выполнению практических и лабораторных работ по МДК 02.03 Математическое моделирование разработаны в соответствии с рабочей программой ПМ.02. Осуществление интеграции программных модулей по специальности 09.02.07 Информационные системы и программирование.

ВложениеРазмер
pm.02_mdk_02.01.pdf 1.29 МБ
pm.02_mdk_02.02.pdf 685.81 КБ
pm.02_mdk_02.03.pdf 2.94 МБ

Предварительный просмотр:

Предварительный просмотр:

Предварительный просмотр:

По теме: методические разработки, презентации и конспекты

Программа профессионального модуля "Участие в интеграции программных модулей"

Программа производственной практики разработана на основе Федерального государственного образовательного стандарта по специальности среднего профессионального образования 230115 Программирование в ком.


Рабочая программа ПМ 03. "Участие в интеграции программных модулей"

Рабочая программа профессионального модуля – является частью примерной основной профессиональной образовательной программы в соответствии с ФГОС по специальности СПО 230115 Программирование в компьюте.


Рабочая программа по ПМ.03 Участие в интеграции программных модулей для специальности 09.02.03 Программирование в компьютерных системах

Рабочая программа по ПМ.03 Участие в интеграции программных модулей для специальности 09.02.03 Программирование в компьютерных системах. Для ваиативной части добавлена дополнительная компетенция ПК.3.


РАБОЧАЯ ПРОГРАММА по профессиональному модулю ПМ.03 Участие в интеграции программных модулей

РАБОЧАЯ ПРОГРАММА по профессиональному модулю ПМ.03 Участие в интеграции программных модулей.

МЕТОДИЧЕСКИЕ РЕКОМЕНДАЦИИ ПО ВЫПОЛНЕНИЮ КУРСОВОЙ РАБОТЫ по профессиональному модулю ПМ.03 Участие в интеграции программных модулей
Методические указания к выполнению лабораторных и практических работ по ПМ.03. УЧАСТИЕ В ИНТЕГРАЦИИ ПРОГРАММНЫХ МОДУЛЕЙ


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

Параметрический поток – набор данных, необходимых для настройки пакета при необходимых условиях.

ППП делится на два крупных класса:

· пакеты генерирующего типа;

· пакеты интерпретирующего типа.

У пакетов генерирующего типа отсутствует параметрический поток и присутствует информационный поток. При генерации пакета получается новая программа.

У пакетов интерпретирующего типа имеем информационный и параметрический потоки. Новых программ не получаем.

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

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

Параметрический поток функциональных систем включает:

· параметры, характеризующие входную информацию (количество показателей, документов);

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

· параметры, характеризующие систему запросов;

· параметры, характеризующие конфигурацию системы.

Информационный поток – значения входных документов (машинных, бумажных).

Все ППП делятся на два класса: пакеты общесистемного назначения, пакеты функционального назначения.

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

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

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

· разработка ТЗ на автоматизацию данного ППП;

· осуществление выбора ППП в соответствии с ТЗ;

· уточнение требований к функциональным и обеспечивающим частям системы в соответствии с выбранным ППП;

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

· разработка параметрического потока данных;

· отладка программного обеспечения на информационных потоках;

· разработка и доработка документации по данному пакету в соответствии с требованиями заказчика;

· разработка руководства пользователя для данного объекта управления.

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

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

· подготовка информационного потока для ввода;

· разработка самого программного модуля на конкретном языке;

· описание программы и подготовка эксплуатационных документов (руководство пользователя).

Изложение основных подходов к интегрированию программных модулей.

Основные подходы к интегрированию программных модулей

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

Интеграция на уровне данных

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


Рисунок - 14. Традиционная схема интеграции данных

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

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

Обзор методов объектно-ориентированного анализа и проектирования приведен в разд. 6. В данном разделе рассмотрены методы структурного проектирования. Такие методы ориентированы на формирование структуры программного средства по функциональному признаку.

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


    1. упрощение разработки ПС;

    2. исключение чрезмерной детализации обработки данных;

    3. упрощение сопровождения ПС;

    4. облегчение чтения и понимания программ;

    5. облегчение работы с данными, имеющими сложную структуру.

    1. модульный подход требует большего времени работы центрального процессора (в среднем на 5 – 10 %) за счет времени обращения к модулям;

    2. модульность программы приводит к увеличению ее объема (в среднем на 5 – 10 %);

    3. модульность требует дополнительной работы программиста и определенных навыков проектирования ПС.

      1. методы нисходящего проектирования;

      2. методы расширения ядра;

      3. методы восходящего проектирования.

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

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

      Таблица 2.6 – Типы и силы связности модулей


      Связность

      Сила связности

      Функциональная
      10 (сильная связность)

      Последовательная
      9

      Коммуникативная
      7

      Процедурная
      5

      Временная
      3

      Логическая
      1

      Связность по совпадению
      0 (слабая связность)

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

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

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

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

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

      Модуль имеет связность по совпадению, если его операторы объединяются произвольным образом.

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

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

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

      В таблице 2.7 содержатся типы сцепления модулей и соответствующие им степени сцепления.
      Таблица 2.7 - Типы и степени сцепления модулей


      Сцепление
      Степень сцепления

      Независимое
      0

      По данным
      1 (слабое сцепление)

      По образцу
      3

      По общей области
      4

      По управлению
      5

      По внешним ссылкам
      7

      По кодам
      9 (сильное сцепление)

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

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

      Модули со сцеплением по данным не имеют общей области данных (общих глобальных переменных).

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

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

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

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

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

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

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

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


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

      2. принятие основных решений в алгоритме выносится на максимально высокий по иерархии уровень;

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

      1. экранные формы ввода и/или редактирования информации базы данных;

      2. отчеты;

      3. макросы;

      4. стандартные средства для обработки информации;

      5. меню для выбора функции обработки и др.

      Методы разработки при модульном программировании

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

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

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

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

      Синерги́я (греч. συνεργία — сотрудничество, содействие, помощь, соучастие, сообщничество; от греч. σύν — вместе, греч. ἔργον — дело, труд, работа, (воз)действие) — суммирующий эффект взаимодействия двух или более факторов, характеризующийся тем, что их действие существенно превосходит эффект каждого отдельного компонента в виде их простой суммы[1], эмерджентность.

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

      Мне постоянно приходится сталкиваться с одними и теми же проблемами и решениями многие из которых приходится пояснять в каждом новом проекте заказчикам, некоторые – программистам. А потому я считаю, что о процессе интеграции стоит поговорить подробно. В большинстве примеров я выбрал различные случаи интеграции 1С и CRM, так как сегодня именно этот вопрос, как показывает моя практика, наиболее актуален. Хотя данная статья подойдет при интеграции практически любого программного обеспечения. Итак начнем.

      Что такое интеграция?

      Википедия дает нам такое определение:

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

      Я считаю, что в данном случае Вики абсолютно права. И дополнить ее можно только одним определением:

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

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

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

      Например, если вы объединяете конфигурацию 1С: Торговля с 1С: Бухгалтерией, вам может потребоваться передать данные по всем продажам в бухгалтерию, а обратно получить сведения об оплате по этим продажам.

      1. Определяем, какой продукт является источником, какой – приемником.
      2. Сопоставляем объекты между источником и приемником.
      3. Выбираем протокол для интеграции
      4. Проводим постобработку данных (после переноса в одну из сторон)

      Важно: при интеграции различных программных решений нужно хорошо понимать их функционал.

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

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

      Выбираем источник и приемник

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

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

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

      Сопоставление объектов (данных)

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

      Например, практически в любой CRM контактное лицо и клиент – это одно и то же. С другой стороны в 1С контактное лицо может быть клиентом, партнером, поставщиком. И очень важно понимать, куда именно записывать данные этого контактного лица. Также важно сопоставлять все данные до того, как начнется работа непосредственно с кодом. Для этого прекрасно подойдут таблицы или блок-схемы.

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

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

      И здесь возникает проблема: требуются правила сопоставления.

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

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

      1. Обязательно оставляю клиенту подробно описанные правила сопоставления и пояснения, какие параметры и данные менять недопустимо.
      2. Предусматриваю варианты оповещения об ошибке. Т.е. не только фиксирую проблему в логе ошибок, но и оповещаю пользователя о сбое каким-то образом: при помощи SMS, письмом на email, всплывающими уведомлениями в 1С. А иногда всеми этими способами сразу.

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

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

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

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

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

      Обмен данными: писать самому или применять типовое решение?

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

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

      А потому при выборе между самостоятельным написанием обмена данными и типовым решением, которое не на 100% подходит для данной ситуации, лучше писать обмен самому.

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

      Метод подключения: REST API, SOAP или прямое подключение к базе приемника

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

      Вопросы клиентского доступа: почему не работает обмен?

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

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

      • Ограничение доступа по IP.
      • Ограничение прав пользователя.
      • Ограничение по количеству обращений к источнику или приемнику

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

      1С идентификаторы и ошибки, связанные с ними

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

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

      Еще одна проблема: нет возможности привязаться к уникальному идентификатору.

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

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

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

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

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

      Формат выгрузки

      Для обмена данными используются самые разные форматы. Это может быть JSON, XML, CSV, TXT, прямой доступ к базе и т.д. У меня в этом вопросе нет каких-то определенных предпочтений. Я считаю, что здесь нужно исходить из рациональных требований проекта.

      Постобработка

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

      • Оповещение менеджера о поступлении заказа, например, при помощи sms
      • Уведомление пользователей о поступлении новых заказов или другой актуальной информации по email
      • Звуковой сигнал и/или всплывающее окно в 1С с напоминанием о том, что появились новые запросы или заявки

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

      Например, это может быть уведомление клиента о том, что его заказ успешно прошел выгрузку и отправлен в обработку. И здесь также может быть использовано sms, электронное письмо или просто изменение статуса заказа в системе.

      Тестирование интеграции

      С моей точки зрения интеграция – это часть (иногда частный случай) внедрения программного обеспечения. И здесь, как и для любой другой работы по внедрению ПО, потребуется тестирование программистом, потом – лично консультантом, а также различные варианты тестирования вместе с пользователями. Об этом я подробно писал в статье Внедрение программного продукта. Особенности работы бизнес-консультанта. Часть III. Финальная.

      Отличие односторонней и двусторонней интеграции

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

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

      Читайте также: