Руководство по интеграции это

1С-Битрикс: Управление сайтом 7.x

Руководство по интеграции. Быстрый старт.

Содержание

Введение

Руководство по интеграции предназначено для разработчиков веб-сайтов на основе программного продукта «1C-Битрикс: Управление сайтом». В документе подробно рассматривается процедура интеграции продукта в новый или уже существующий сайт. При составлении документа подразумевалось, что разработчик владеет базовыми технологиями для разработки веб-сайта, такими как HTML, CSS, PHP.

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

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

Если у вас возникнут дополнительные вопросы по работе с продуктом, то вы можете обратиться в службу

технической поддержки или на форумы компании «1С-Битрикс».

Создание и удаление сайта

Демонстрационная версия продукта представлена только одним сайтом. Его основная задача – ознакомление с возможностями продукта. Для более детального изучения процесса интеграции сайта с системой рекомендуется не изменять существующий, а создать новый сайт. И затем создать шаблон дизайна для вашего сайта. Управление сайтами системы выполняется в Административном разделе на странице Настройки > Настройки продукта > Сайты > Список сайтов (рис. 1.1).

Рис. 1.1. Список сайтов.

Процесс создания и удаления сайта подробно описан в учебном курсе

Администрирование системы.

Общие принципы интеграции

Система «1C-Битрикс: Управление сайтом» обладает большими возможностями по интеграции дизайна в сочетании с удобством выполнения этих работ. Использование шаблона с программным кодом обеспечивает необходимую гибкость при реализации интернет-проекта, позволяет реализовать как простые шаблоны, так и шаблоны с произвольной программной логикой и индивидуальным внешним видом.

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

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

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

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

Общий алгоритм действий по созданию полноценного шаблона следующий:

• Создание бланка шаблона в разделе Настройки > Настройки продукта > Сайты > Шаблоны сайтов;
• Добавление в бланк шаблона нарезанного HTML-варианта дизайна;
• Задание разделителя #WORK_AREA#;
• Замена HTML-кода на вызов соответствующих PHP-функций;
• Применение шаблона к сайту.

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

Удобство работы по созданию шаблона определяется:

• возможностью использования визуального HTML-редактора;
• поддержкой технологии Drag and Drop при работе с компонентами;
• возможностью быстрого доступа к редактированию компонентов и свойств объектов.

Шаблон сайта. Структура

Внешний вид сайта определяется шаблоном дизайна.

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

Структура дизайна сайта обычно состоит из трех основных частей (рис. 2.1):

• Верхняя часть дизайна (header).
• Рабочая область страницы, в которой размещаются информационные материалы сайта, компоненты или любой другой программный код (Work Area).
• Нижняя часть дизайна (footer).

Рис. 2.1. Основные части дизайна.

• Header — верхняя часть дизайна, заголовок. Включает в себя, как правило, верхнюю и левую часть дизайна со статической информацией (логотипом, лозунгом и так далее), верхним горизонтальным меню и левым меню (если они есть в дизайне). Может включать в себя информационные динамические материалы. Хранится в отдельном файле …/<идентификатор шаблона>/header.php.
• Work area — рабочая область страницы, в которой размещаются собственно информационные материалы сайта.
• Footer — нижняя часть дизайна со статической информацией (как правило: контактная информация, сведения об авторе и владельце сайта и так далее), нижним горизонтальным меню и правым меню (если они есть в дизайне). Может включать в себя информационные материалы. Хранится в отдельном файле …/<идентификатор шаблона>/footer.php.

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

Управление шаблонами дизайна осуществляется в Административном разделе на странице: Настройки > Настройки продукта > Сайты > Шаблоны сайтов. Форма, представленная на этой странице, позволяет просмотреть, отредактировать существующие шаблоны, а также добавить новые.

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

Рис. 2.2. Редактирование шаблона в визуальном режиме.

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

Возможность визуального редактирования шаблона определяется настройками Главного модуля (рис. 2.3).

Рис. 2.3. Настройки Главного модуля.

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

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

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

Каскадные стили, используемые в шаблоне, рекомендуется разделять на две таблицы стилей, хранящиеся в двух разных файлах. Оба файла находятся в директории /bitrix/templates/<идентификатор_шаблона>/. Один из файлов носит название styles.css и содержит стили для представления информационного содержания страницы на сайте. Содержимое этого файла отображается при редактировании шаблона на закладке Стили сайта. Во втором файле – с именем template_styles.css — описаны стили для отображения текстов в самом шаблоне дизайна. Содержимое этого файла отображается при редактировании шаблона на закладке Стили шаблона.

Все шаблоны хранятся в директории /bitrix/templates/. Набор файлов каждого шаблона находится в поддиректории, название которой соответствует идентификатору шаблона. В рассматриваемом нами примере шаблон размещается в каталоге: /bitrix/templates/books/.

• Примечание: При создании нового шаблона через интерфейс задается его имя, название, описание для показа в списке, код шаблона внешнего вида сайта, таблицы стилей и набор используемых включаемых компонентов и картинок. При сохранении шаблона автоматически создается поддиректория /bitrix/templates/<идентификатор_шаблона>.

Каждый шаблон имеет схожую структуру файлов и поддиректорий. Простейший шаблон может состоять всего из нескольких основных файлов: header.php, footer.php, styles.css, template_styles.css.

Все графические элементы, используемые в шаблоне, размещаются в директории /bitrix/templates/<идентификатор_шаблона>/images/.

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

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

Применение шаблонов к сайтам

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

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

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

Рис.2.4. Шаблоны и сайты.

Выбор и назначение шаблонов для каждого сайта выполняется в Административном разделе: Настройки > Настройки продукта > Сайты > Список сайтов.

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

Рис. 2.5. Настройка условий применения шаблонов.

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

• Корпоративный сайт (на главную страницу выведен каталог книг) будет использоваться в качестве основного шаблона сайта, так как для него не задано условие показа.
• Шаблон Прохождение курса обучения будет использован для страниц раздела /communication/learning/course/ на сайте.
• Шаблон Версия для печати будет использован, если адрес страницы содержит параметр print=Y. Например, ссылка на странице сайта http://www.site2.com/?print=Y позволит посетителю получить версию документа для печати.

• Внимание! Условие может содержать любой программный код на языке PHP, в том числе вызовы API-функций продукта. Для получения дополнительной информации смотрите документацию к продукту.
• Внимание! При настройке условий применения шаблонов обязательно указывайте индекс сортировки. Порядок применения шаблонов к сайту определяется в соответствии с указанной сортировкой. Если для страницы (раздела) может быть применено несколько шаблонов, то в итоге будет применен шаблон с большей сортировкой. Если индекс сортировки задан не будет, то может быть применен неверный шаблон.

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

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

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

Некоторые элементы дизайна в шаблоне представлены в виде программных компонентов. Это облегчает процесс создания и управления сайтом.

Вернемся к шаблону Корпоративный сайт и познакомимся с основными программными компонентами и включаемыми областями. На рисунке 2.6 выделены компоненты и включаемые области в данном шаблоне.

Рис. 2.6. Включаемые области в шаблоне.

В исходном HTML-коде проводятся замены выделенных областей на код вызова соответствующих компонентов системы «1С-Битрикс: Управление сайтом», которые обеспечивают показ различного рода информации: метаданных, заголовка страницы, подключение таблицы каскадных стилей, вывод административной панели, навигационная цепочка, меню сайта.

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

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

Рис. 2.7. Режим редактирования контента.

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

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

Управление параметрами включаемых областей, компонентов, редактирование стилей сайта и шаблона выполняется в режиме разработки и настройки сайта (закладка на административной панели, рис. 2.8).

Рис. 2.8. Режим разработки и настройки сайта.

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

Работа с компонентами

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

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

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

• Внимание! Изменять содержимое папки /bitrix/components/bitrix/ не рекомендуется! При выполнении обновлений эта папка перезаписывается и вы потеряете все изменения.

Пользовательские компоненты рекомендуется размещать в своей папке, например, /bitrix/components/my_folder/ либо в разделе /bitrix/components/.

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

Имена компонентов имеют вид «идентификатор1.идентификатор2….». Например, «catalog», «catalog.element», «catalog.section.list» и т.п. Рекомендуется строить имена иерархически, начиная с общего понятия и заканчивая конкретным назначением компонента. Например, компонент, показывающий список товаров данной группы, может называться «catalog.section».

Папка компонента 2.0 содержит следующие подпапки и файлы:

• подпапку templates, в которой расположены шаблоны вывода (отображения) компонента (может отсутствовать, если у компонента нет шаблонов вывода).
• файл component.php, который содержит логику (код) компонента. Этот файл должен всегда присутствовать в папке компонента.
• файл .parameters.php, который содержит описание входных параметров компонента для редактора. Если у компонента есть входные параметры, то этот файл должен присутствовать в папке компонента.
• папку images, в которой хранятся необходимые изображения.
• файл .description.php с названием, описанием компонента и его положением в дереве компонентов в редакторе и т.д.
• другие подпапки и файлы:

• help с файлами помощи по компоненту;
• lang с языковыми файлами.

Размещение компонента

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

• Удаление из оригинального html-кода участка, соответствующего функции компонента.
• Добавление вместо html-кода php—кода вызова компонента.
• Редактирование шаблона компонента и его файла стилей под дизайн сайта (при необходимости).

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

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

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

Рис. 3.1. Размещение компонента.

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

Управление содержимым компонента

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

Рис. 3.2. Меню команд кнопок для управления контентом.

Данные пункты меню также доступны в режиме разработки и настройки сайта (закладка Разработка). Они отделены от команд редактирования компонентов горизонтальной линией (рис. 3.3).

Рис. 3.3. Меню команд компонента.

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

Типовые команды:

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

Редактирование параметров компонента

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

• пункта Редактировать параметры компонента меню команд компонента (рис.3.4);

Рис. 3.4. Переход к редактированию параметров компонента.

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

• пункта с названием компонента меню кнопки Компоненты Административной панели (рис. 3.5).

Рис. 3.5. Переход к редактированию параметров компонента.

В обоих случаях открывается следующая форма настройки параметров компонента (рис. 3.6):

Рис. 3.6. Форма редактирования параметров компонента.

Копирование шаблона компонента

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

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

Рис. 3.7. Переход к копированию шаблона компонента.

В открывшейся форме укажите параметры копирования шаблона (рис. 3.8).

Рис. 3.8. Форма копирования шаблона компонента.

Шаблон компонента, скопированный в один из шаблонов сайта, называется пользовательским. Теперь его можно изменять под конкретные требования дизайна.

Редактирование шаблона компонента

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

• Обратите внимание! Не рекомендуется производить редактирование системных компонентов и их шаблонов, расположенных в папке /bitrix/components/bitrix/. Эта папка обновляется системой обновлений, поэтому все изменения, произведенные пользователем, будут потеряны.

Быстрый переход к редактированию шаблона компонента выполняется из публичного раздела в режиме разработки и настройки сайта (закладка Разработка). Для этого служит пункт Редактировать шаблон компонента меню команд кнопки управления компонентом (рис. 3.9).

Рис. 3.9. Переход к редактированию шаблона компонента.

Если данный пункт меню выбран для простого компонента, то откроется форма редактирования файла template.php (файл шаблона простого компонента, рис. 3.10).

Рис. 3.10. Редактирование шаблона простого компонента.

Если же пункт меню был выбран для комплексного компонента, то откроется форма редактирования файла имя_компонента.php (файл-шаблон, определяющий расположение подкомпонентов, рис. 3.11).

Рис. 3.11. Редактирование общего шаблона комплексного компонента.

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

Рис. 3.12. Переход к редактированию подкомпонента.

Редактирование CSS-файла шаблона компонента

Задание внешнего оформления компонента осуществляется с помощью редактирования файла стилей style.css. Для быстрого перехода к редактированию стилей шаблона компонента используйте команду Редактировать CSS-файл шаблона (рис. 3.13).

• Примечание: данная команда доступна в том случае, если для компонента применен пользовательский шаблон.

Рис. 3.13. Переход к редактированию файла стилей компонента.

Редактирование файла стилей осуществляется в соответствии с общими правилами CSS, система не накладывает на это никаких ограничений.

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

описание задания

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

Руководства по интеграции предоставляют:

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

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

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

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

Распространение и формализация

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

Первые пилотные интеграционные проекты появились в начале 2000-х годов. На практике были установлены различные профили реализации. В общей сложности существует более 100 проектов с сопоставимыми сферами деятельности, некоторые из которых также работают под другими названиями, например B. Активные спонсоры , помощники по интеграции , гиды по межкультурному общению , будущие гиды и многое другое. Даже если были попытки стандартизировать руководства по интеграции, в настоящее время не существует общенационального стандарта, регулирующего минимальные требования. Проекты в немецкоязычных странах иногда имеют разительные различия с точки зрения основных критериев, таких как задачи и области деятельности, квалификация инструкторов по интеграции, условия заказа, вступительные требования или вознаграждение. Тем не менее, существуют три инициативы штатов для руководств по интеграции, которые регулируют структуру руководств по интеграции в соответствующем федеральном штате; так с 2007 года в Нижней Саксонии и Гессене и с 2013 года в Берлине.

Гиды по интеграции также действуют в Австрии.

Финансирование и финансирование

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

Даже если время от времени высказывается критика о том, что задачи руководства по интеграции на самом деле являются задачами социального государства, которые также должны соответственно оплачиваться, большинство руководителей по интеграции действуют на добровольной основе . До 2014 года были также многочисленные проекты, которые финансируются за счет мер по интеграции на рынок труда ( финансируемым государством сектор занятости , один евро работа , ABM ). Однако гиды по интеграции (и районные матери) нанимаются в Берлине с 2013 года на основании государственного коллективного договора.

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

литература

• Боммс, Майкл / Колб, Хольгер (ред.) (2006): Руководства по интеграции для города и района Оснабрюк — Основы, оценка и перспективы проекта муниципальной модели . В: Материалы ИМИС. Выпуск 28/2006. URL: https://www.imis.uni-osnabrueck.de/fileadmin/4_Publikationen/PDFs/imis28.pdf Доступ: 23 ноября 2017 г.
• Боммес, Майкл / Севекер, Марина / Парал, Юдифь / Тембориус, Сабрина (2010): Оценка проекта Integrationslotsen в Нижней Саксонии — окончательный отчет . Оснабрюк: ИМИС.
• Геземанн, Франк (2015): Обзор пилотных проектов интеграции в Германии — концепции, области применения и финансирование. Берлин: комиссар Берлинского сената по вопросам интеграции и миграции. URL: http://www.desi-sozialforschung-berlin.de/uploads/Integrationslotsenprojekte-in-Deutschland-BF01.pdf Доступ: 23 ноября 2017 г.
• Huth, Susanne (2007): Руководства по интеграции — модели взаимодействия и интеграции — опыт и стратегии реализации . Франкфурт-на-Майне: социальные исследования INBAS. URL: https://www.inbas-sozialforschung.de/fileadmin/user_upload/Projektberichte/0709_INBAS-SF_Expertise_Integrationslotsen.pdf Доступ: 23 ноября 2017 г.
• Huth, Susanne / Pöhnl, Berit (2007): Обмен опытом и семинар по разработке стратегий реализации . Документация проекта: Руководства по интеграции — модели взаимодействия и интеграции. Франкфурт-на-Майне: социальные исследования INBAS. URL: https://www.inbas-sozialforschung.de/fileadmin/user_upload/Projektberichte/0710_INBAS-SF_Dokumentation_Integrationslotsen.pdf Доступ: 23 ноября 2017 г.
• Литц, Роман (2017): Профессионализация и обеспечение качества в интеграционной работе: критерии реализации пилотных интеграционных проектов. 1-е издание. Леверкузен: Будрич ЮниПресс; ISBN 978-3-86388-754-4 .

Индивидуальные доказательства

1. ↑ Литц, Роман: Профессионализация и обеспечение качества в работе по интеграции: критерии реализации пилотных проектов по интеграции . 1-е издание. Будрич ЮниПресс, Леверкузен 2017, ISBN 978-3-86388-754-4 , стр. 37 .
2. ↑ Литц, Роман: Профессионализация и обеспечение качества в работе по интеграции: критерии реализации пилотных проектов по интеграции . 1-е издание. Будрич ЮниПресс, Леверкузен 2017, ISBN 978-3-86388-754-4 , стр. 41 .
3. ↑ Литц, Роман: Профессионализация и обеспечение качества в критериях работы по интеграции для реализации пилотных проектов по интеграции . 1-е издание. Будрич ЮниПресс, Леверкузен 2017, ISBN 978-3-86388-754-4 , стр. 49 .
4. ↑ Юбелакер, Йоханна: языковое и культурное посредничество с точки зрения сотрудников берлинского районного офиса. В: Borde, Theda / Albrecht, Niels-Jens (ed.): Инновационные концепции интеграции и участия. Анализ потребностей в межкультурной коммуникации в учреждениях и в моделях новых областей работы. Verlag für Interkulturelle Kommunikation, Франкфурт-на-Майне 2007, стр. 44 .
5. ↑ Беккер, Карстен / Греб, Тим / Лейпольд, Энрико: Посредник языка и интеграции как новая профессия. Диакони Вупперталь, Вупперталь 2010, стр. 18 .
6. ↑ Литц, Роман: Профессионализация и обеспечение качества в работе по интеграции: критерии реализации пилотных проектов по интеграции . 1-е издание. Будрич ЮниПресс, Леверкузен 2017, ISBN 978-3-86388-754-4 , стр. 46 .
7. ^ Геземанн, Франк: Обзор пилотных проектов интеграции в Германии — концепции, области применения и финансирование. Ред .: Уполномоченный Берлинского сената по вопросам интеграции и миграции. Берлин 2015, стр. 47 .
8. ↑ Социально-экономическая панель: Знание немецкого языка — родной язык не немецкий 2011 | Опрос. 2013, доступ к 23 ноября 2017 .
9. ↑ Литц, Роман: Профессионализация и обеспечение качества в работе по интеграции: критерии реализации пилотных проектов по интеграции . 1-е издание. Будрич ЮниПресс, Леверкузен 2017, ISBN 978-3-86388-754-4 , стр. 54 .
10. ↑ Литц, Роман: Профессионализация и обеспечение качества в работе по интеграции: критерии реализации пилотных проектов по интеграции . 1-е издание. Будрич ЮниПресс, Леверкузен 2017, ISBN 978-3-86388-754-4 , стр. 63 .
11. ↑ Литц, Роман: Профессионализация и обеспечение качества в работе по интеграции: критерии реализации пилотных проектов по интеграции . 1-е издание. Будрич ЮниПресс, Леверкузен 2017, ISBN 978-3-86388-754-4 , стр. 18 .
12. ^ Геземанн, Франк: Обзор пилотных проектов интеграции в Германии — концепции, области применения и финансирование . Ред .: Уполномоченный Сената Берлина по вопросам интеграции и миграции. Берлин 2015, стр. 10 .
13. ↑ Хут, Сюзанна: Руководства по интеграции — модели взаимодействия и интеграции — опыт и стратегии реализации. Франкфурт а. М. 2007.
14. ↑ Huth, Susanne / Pöhnl, Berit: Обмен опытом и семинар по разработке стратегий реализации. Документация проекта: Руководства по интеграции — модели взаимодействия и интеграции. (PDF) 2007, доступ к 23 ноября 2017 года .
15. ↑ Литц, Роман: Профессионализация и обеспечение качества в работе по интеграции: критерии реализации пилотных проектов по интеграции . 1-е издание. Будрич ЮниПресс, Леверкузен 2017, ISBN 978-3-86388-754-4 .
16. ↑ Литц, Роман: Профессионализация и обеспечение качества в работе по интеграции: критерии реализации пилотных проектов по интеграции . 1-е издание. Будрич ЮниПресс, Леверкузен 2017, ISBN 978-3-86388-754-4 , стр. 185 .
17. ↑ Литц, Роман: Профессионализация и обеспечение качества в критериях работы по интеграции для реализации пилотных проектов по интеграции . 1-е издание. Будрич ЮниПресс, Леверкузен 2017, ISBN 978-3-86388-754-4 , стр. 7 .
18. ↑ Боммес, Майкл / Севекер, Марина / Парал, Юдифь / Тембориус, Сабрина: Оценка пилотного проекта интеграции в Нижней Саксонии — окончательный отчет . Ред .: ИМИС. Оснабрюк 2010.
19. ↑ Мюллер-Вилле, Кристина: Гиды по интеграции в Нижней Саксонии. Материалы для базового курса . Ред .: Министерство социальных дел, женщин, семьи, здравоохранения и интеграции Нижней Саксонии. Ганновер 2012.
20. ↑ Кранц, Сандра / Шиндель, Вибке / Бахмад, Лейла / Гебрем, Ханна: Гессенская сеть проводников по интеграции — наведение мостов, усиление личной ответственности, совместное формирование интеграции . Ред .: Министерство юстиции земли Гессен по вопросам интеграции и Европы. Висбаден 2011.
21. ↑ ^{a b} Лептиен, Кай / Каппхан, Андреас: Государственная рамочная программа для гидов по интеграции . В: Social Extra . лента 6 , 2014, с. 28-30 .
22. ↑ Юлия Хернбёк: Как «ага-переживания» способствуют интеграции. В: derStandard.at. 16 ноября, 2012. Проверено 29 ноября, 2017 .
23. ↑ Литц, Роман: Профессионализация и обеспечение качества в критериях работы по интеграции для реализации пилотных проектов по интеграции . 1-е издание. Будрич ЮниПресс, Леверкузен 2017, ISBN 978-3-86388-754-4 , стр. 180 .
24. ↑ Литц, Роман: Профессионализация и обеспечение качества в критериях работы по интеграции для реализации пилотных проектов по интеграции . 1-е издание. Будрич ЮниПресс, Леверкузен 2017, ISBN 978-3-86388-754-4 , стр. 176 .

Интеграция программного обеспечения. Описание процесса от бизнес консультанта

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

Википедия.

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

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

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

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

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

Интегра́ция (от лат. integratio — «соединение») — процесс объединения частей в целое. В зависимости от контекста может подразумеваться:

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

.

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

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

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

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

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

Лично я делю процесс интеграции на такие этапы:

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

В результате возникают самые разные казусы. Например, вы используете в качестве ключевого слова для поиска при сопоставлении слово «дилер». Клиент по каким-то причинам меняет его в программе-источнике на слово «дилеры». Казалось бы, мелочь! Но эта мелочь приведет к тому, что поиск в 1С перестанет работать.

Я решил эту проблему таким образом:

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

Почему я пришел к такому варианту работы?

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

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

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

Самые распространенные решения:

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

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

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

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

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

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

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

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

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

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

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

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

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

Самые распространенные ситуации:

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

Для интернет магазинов при интеграции чаще всего требуются:

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

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

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

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

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

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

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

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

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