Які найважливіші вимоги висуваються до бізнес-додатків? Одними з найголовніших є такі завдання:
- Легкість зміни/адаптації логіки роботи програми до мінливих бізнес-завдань.
- Легкість інтеграції з іншими програмами.
Те, як вирішується в 1С перше завдання, було стисло описано в розділі «Кастомізація та підтримка» ; ми ще повернемося до цієї цікавої теми в одній із майбутніх статей. Сьогодні ж мова йтиме про друге завдання, про інтеграцію.
Інтеграційні завдання
Інтеграційні завдання можуть бути різними. Для вирішення одних досить простого інтерактивного обміну даними, наприклад, для передачі до банку списку співробітників для оформлення зарплатних пластикових карток. Для складніших завдань може бути необхідний повністю автоматизований обмін даними, можливо, із зверненням до бізнес-логіки зовнішньої системи. Є завдання, що мають спеціалізований характер, на зразок інтеграції із зовнішнім обладнанням (наприклад, торговим обладнанням, мобільними сканерами тощо) або з успадкованими або вузькоспеціалізованими системами (наприклад, із системами розпізнавання RFID-міток). Вкрай важливо для кожного завдання вибрати найбільш підходящий механізм інтеграції.
Можливості інтеграції з 1С
Існують різні підходи до реалізації інтеграції з додатками 1С, який із них обрати – залежить від вимог завдання.
- Реалізація на основі , що надаються платформою, свого власного спеціалізованого API на стороні програми 1С (наприклад, набору Web- або HTTP-сервісів, які будуть викликати сторонні програми обміну даними з додатком 1С). Плюс цього підходу – стійкість API до зміни реалізації за програмі 1С. Особливість підходу - потрібно змінювати вихідний код типового рішення 1С, що потенційно може вимагати зусиль при злитті вихідних кодів при переході на нову версію конфігурації. У цьому випадку може прийти на допомогу нова прогресивна функціональність. . Розширення – це, власне, механізм плагінів, що дозволяє створювати доповнення прикладних рішень, не змінюючи самих прикладних рішень. Винесення інтеграційного API у розширення конфігурації дозволить уникнути складнощів при злитті конфігурацій при переході на нову версію типового рішення.
- Використання механізмів інтеграції платформи, які надають доступ зовні до об'єктної моделі програми та не вимагають доопрацювання програми або створення розширення. Плюс такого підходу – не потрібно змінювати додаток 1С. Мінус - якщо додаток 1С було доопрацьовано, то можуть знадобитися доопрацювання в додатку, що інтегрується. Приклад такого підходу - використання для інтеграції протоколу OData, реалізованого на стороні платформи 1С:Підприємство (докладніше про нього нижче).
- Використання готових прикладних протоколів, реалізованих у типових рішеннях 1С. Багато типових рішень від 1С та партнерів реалізують на основі механізмів інтеграції, що надаються платформою, свої власні прикладні протоколи, орієнтовані на конкретні завдання. З використанням цих механізмів не потрібно написання коду за додатку 1С, т.к. ми користуємося штатними можливостями прикладного рішення. На стороні 1С нам потрібно лише виконати певні налаштування.
Механізми інтеграції у платформі 1С:Підприємство
Імпорт/експорт файлів
Припустимо, маємо завдання двонаправленого обміну даними між додатком 1С і довільним додатком. Наприклад, нам потрібно синхронізувати список товарів (довідник Номенклатура) між додатком 1С та довільним додатком.
Для вирішення такого завдання можна написати розширення, яке вивантажує довідник Номенклатура у файл певного формату (текстовий, XML, JSON, …) та вміє зчитувати цей формат.
У платформі реалізовано механізм серіалізації прикладних об'єктів у XML як безпосередньо через методи глобального контексту ЗаписатиXML/ЧитанняXML, так і за допомогою допоміжного об'єкту XDTO (XML Data Transfer Objects).
Будь-який об'єкт у системі 1С:Підприємство може бути серіалізований у XML представлення та навпаки.
Ця функція поверне уявлення об'єкта у вигляді XML:
Функция Объект_В_XML(Объект)
ЗаписьXML = Новый ЗаписьXML();
ЗаписьXML.УстановитьСтроку();
ЗаписатьXML(ЗаписьXML, Объект);
Возврат ЗаписьXML.Закрыть();
КонецФункции
так буде виглядати експорт довідника Номенклатура в XML за допомогою XDTO:
&НаСервере
Процедура ЭкспортXMLНаСервере()
НовыйСериализаторXDTO = СериализаторXDTO;
НоваяЗаписьXML = Новый ЗаписьXML();
НоваяЗаписьXML.ОткрытьФайл("C:DataНоменклатура.xml", "UTF-8");
НоваяЗаписьXML.ЗаписатьОбъявлениеXML();
НоваяЗаписьXML.ЗаписатьНачалоЭлемента("СправочникНоменклатура");
Выборка = Справочники.Номенклатура.Выбрать();
Пока Выборка.Следующий() Цикл
ОбъектНоменклатура = Выборка.ПолучитьОбъект();
НовыйСериализаторXDTO.ЗаписатьXML(НоваяЗаписьXML, ОбъектНоменклатура, НазначениеТипаXML.Явное);
КонецЦикла;
НоваяЗаписьXML.ЗаписатьКонецЭлемента();
НоваяЗаписьXML.Закрыть();
КонецПроцедуры
Шляхом нескладної ситуації коду експортуємо довідник у JSON. Товари будуть записані до масиву; для різноманітності наведемо англомовний варіант синтаксису:
&AtServer
Procedure ExportJSONOnServer()
NewXDTOSerializer = XDTOSerializer;
NewJSONWriter = New JSONWriter();
NewJSONWriter.OpenFile("C:DataНоменклатура.json", "UTF-8");
NewJSONWriter.WriteStartObject();
NewJSONWriter.WritePropertyName("СправочникНоменклатура");
NewJSONWriter.WriteStartArray();
Selection = Catalogs.Номенклатура.Select();
While Selection.Next() Do
NomenclatureObject = Selection.GetObject();
NewJSONWriter.WriteStartObject();
NewJSONWriter.WritePropertyName("Номенклатура");
NewXDTOSerializer.WriteJSON(NewJSONWriter, NomenclatureObject, XMLTypeAssignment.Implicit);
NewJSONWriter.WriteEndObject();
EndDo;
NewJSONWriter.WriteEndArray();
NewJSONWriter.WriteEndObject();
NewJSONWriter.Close();
EndProcedure
Далі залишиться лише передати дані кінцевому споживачеві. Платформа 1С: Підприємство підтримує основні інтернет-протоколи HTTP, FTP, POP3, SMTP, IMAP, включаючи їх безпечні версії. Також для передачі даних можна використовувати HTTP та/або Web-сервіси.
HTTP- та веб-сервіси
Додатки 1С можуть реалізовувати свої HTTP-і веб-сервіси, а також викликати HTTP-і веб-сервіси, реалізовані сторонніми програмами.
REST інтерфейс та протокол OData
Починаючи з версії 8.3.5, платформа 1С:Підприємство може автоматично для всього прикладного рішення. Будь-який об'єкт конфігурації (довідник, документ, регістр відомостей тощо) можна зробити доступним для отримання та модифікації даних через інтерфейс REST. Як протокол доступу платформа використовує протокол Версія 3.0. Публікація сервісів OData виконується з меню Конфігуратора «Адміністрування -> Публікація на веб-сервері», прапорець «Публікувати стандартний інтерфейс OData» має бути позначений. Підтримуються формати atom/XML та JSON. Після того, як прикладне рішення опубліковано на веб-сервері, сторонні системи можуть звертатися до нього через інтерфейс REST за допомогою HTTP запитів. p align="justify"> Для роботи з додатком 1С через протокол OData програмування на стороні 1С не потрібно.
Так, URL виду http://<сервер>/<конфигурация>/odata/standard.odata/Catalog_Номенклатура поверне нам вміст каталогу Номенклатура у форматі XML - колекцію елементів entry (заголовок повідомлення пропущено для стислості):
<entry>
<id>http://server/Config/odata/standard.odata/Catalog_Номенклатура(guid'35d1f6e4-289b-11e6-8ba4-e03f49b16074')</id>
<category term="StandardODATA.Catalog_Номенклатура" scheme="http://schemas.microsoft.com/ado/2007/08/dataservices/scheme"/>
<title type="text"/>
<updated>2016-06-06T16:42:17</updated>
<author/>
<summary/>
<link rel="edit" href="Catalog_Номенклатура(guid'35d1f6e4-289b-11e6-8ba4-e03f49b16074')" title="edit-link"/>
<content type="application/xml">
<m:properties >
<d:Ref_Key>35d1f6e4-289b-11e6-8ba4-e03f49b16074</d:Ref_Key>
<d:DataVersion>AAAAAgAAAAA=</d:DataVersion>
<d:DeletionMark>false</d:DeletionMark>
<d:Code>000000001</d:Code>
<d:Description>Кондиционер Mitsubishi</d:Description>
<d:Описание>Мощность 2,5 кВт, режимы работы: тепло/холод</d:Описание>
</m:properties>
</content>
</entry>
<entry>
<id>http://server/Config/odata/standard.odata/Catalog_Номенклатура(guid'35d1f6e5-289b-11e6-8ba4-e03f49b16074')</id>
<category term="StandardODATA.Catalog_Номенклатура" scheme="http://schemas.microsoft.com/ado/2007/08/dataservices/scheme"/>
...
Додаючи до URL рядок «?$format=application/json», отримаємо вміст каталогу Номенклатура у форматі JSON (URL виду http://<сервер>/<конфигурация>/odata/standard.odata/Catalog_Номенклатура?$format=application/json ):
{
"odata.metadata": "http://server/Config/odata/standard.odata/$metadata#Catalog_Номенклатура",
"value": [{
"Ref_Key": "35d1f6e4-289b-11e6-8ba4-e03f49b16074",
"DataVersion": "AAAAAgAAAAA=",
"DeletionMark": false,
"Code": "000000001",
"Description": "Кондиционер Mitsubishi",
"Описание": "Мощность 2,5 кВт, режимы работы: тепло/холод"
},{
"Ref_Key": "35d1f6e5-289b-11e6-8ba4-e03f49b16074",
"DataVersion": "AAAAAwAAAAA=",
"DeletionMark": false,
"Code": "000000002",
"Description": "Кондиционер Daikin",
"Описание": "Мощность 3 кВт, режимы работы: тепло/холод"
}, …
Зовнішні джерела даних
У деяких випадках обмін даними через може бути оптимальним рішенням. Зовнішні джерела даних – це прикладний об'єкт конфігурації 1С, що дозволяє взаємодіяти з будь-якою ODBC-сумісною базою даних як читання, і запис. Зовнішні джерела даних доступні як у Windows, так і Linux.
Механізм обміну даними
призначений як створення територіально розподілених систем з урахуванням 1С:Предприятия, так організації обміну даними з іншими інформаційними системами, не заснованими на 1С:Предприятии.
Цей механізм активно використовується у впровадженнях 1С, і спектр завдань, які вирішуються за його допомогою, дуже широкий. Це і обмін даними між додатками 1С, встановленими у філіях організації, і обмін між додатком 1С та сайтом інтернет-магазину, та обмін даними між серверним додатком 1С та мобільним клієнтом (створеним за допомогою мобільної платформи 1С:Підприємства), та багато іншого.
Одне з ключових понять у механізмі обміну даними – це план обміну. План обміну – це особливий тип об'єкта прикладної платформи 1С, визначальний, зокрема, склад даних, що братимуть участь у обміні (які довідники, документи, регістри тощо.). План обміну містить також інформацію про учасників обміну (так званих вузлах обміну).
Друга складова механізму обміну даними – механізм реєстрації змін. Цей механізм автоматично відстежує у системі зміни даних, які мають бути передані кінцевим споживачам у межах плану обміну. За допомогою цього механізму платформа відслідковує зміни, що відбулися від часу останньої синхронізації, і дозволяє мінімізувати обсяг даних, що передається в рамках чергового синхронізації.
Обмін даними відбувається за допомогою XML-повідомлень певної структури. Повідомлення містить дані, що змінилися з часу останньої синхронізації з вузлом, та деяку службову інформацію. Структура повідомлень підтримує нумерацію повідомлень та дозволяє отримувати підтвердження від вузла-отримувача про отримання повідомлень. Таке підтвердження міститься у кожному повідомленні, яке надходить від вузла-отримувача, у вигляді номера останнього прийнятого повідомлення. Нумерація повідомлень дозволяє зрозуміти платформі, які дані були успішно передані на вузол-одержувач, і уникнути повторної передачі, передаючи лише дані, змінені з часу прийому вузлом-відправником останнього повідомлення з квитанцією про отримані вузлом-отримувачем даних. За такої схеми роботи забезпечується гарантована доставка навіть за ненадійних каналів передачі та втрати повідомлень.
Зовнішні компоненти
У ряді випадків при вирішенні завдань інтеграції доводиться стикатися зі специфічними вимогами, наприклад, протоколами взаємодії, форматами даних, робота з якими не передбачена у платформі 1С:Підприємство. Для такого кола завдань у платформі передбачено , яка дозволяє створювати модулі, що динамічно підключаються, що розширюють функціонал 1С:Підприємства.
Типовим прикладом завдання з подібними вимогами може служити інтеграція прикладного рішення 1С з торговим обладнанням, починаючи від ваг і закінчуючи касовими апаратами та сканерами штрих-кодів. Зовнішні компоненти можуть бути підключені як на стороні сервера 1С:Підприємства, так і на клієнтській частині (включаючи, зокрема, веб-клієнт, а також 1С: Підприємства). Технологія зовнішніх компонентів передбачає досить простий і зрозумілий програмний (C++) інтерфейс взаємодії компоненти з платформою 1С:Підприємство, який повинен реалізувати розробник.
Можливості, що відкриваються під час використання зовнішніх компонент, дуже широкі. Можна реалізувати взаємодію за специфічним протоколом обміну даними із зовнішніми пристроями та системами, вбудувати специфічні алгоритми обробки даних та форматів даних тощо.
Застарілі механізми інтеграції
У платформі є механізми інтеграції, які не рекомендується використовувати в нових рішеннях; вони залишені з міркувань зворотної сумісності, і навіть у разі, якщо інша сторона неспроможна працювати з більш сучасними протоколами. Один із них – робота з файлами формату DBF (підтримується у вбудованій мові за допомогою об'єкта XBase).
Інший застарілий механізм інтеграції – використання технології COM (доступне лише на платформі Windows). Платформа 1С:Підприємство надає два способи інтеграції для Windows, що використовують технологію COM: Automation-сервер та Зовнішнє з'єднання. Вони дуже схожі, але однією з принципових відмінностей є те, що у випадку Automation-сервера запускається повноцінний клієнтський додаток 1С:Підприємство 8, а у разі зовнішнього з'єднання запускається відносно невеликий внутрішньопроцесний COM-сервер. Тобто у разі роботи через Automation сервер можна задіяти функціонал клієнтської програми, виконувати дії, аналогічні до інтерактивних дій користувача. При використанні зовнішнього з'єднання можна використовувати лише функції бізнес-логіки, причому їх можна виконувати як на стороні клієнта з'єднання, де створюється внутрішньопроцесний COM-сервер, так і здійснювати виклик бізнес-логіки на стороні сервера 1С:Підприємства.
Також технологію COM можна використовувати для звернення до зовнішніх систем із коду програми на платформі 1С:Підприємство. У цьому випадку додаток 1С виступає як COM-клієнт. Але слід нагадати, що ці механізми працюватимуть лише тому випадку, якщо сервер 1С функціонує серед Windows.
Механізми інтеграції, реалізовані у типових конфігураціях
Формат EnterpriseData
У ряді конфігурацій 1С (список нижче) на основі описаного вище платформного механізму обміну даними реалізований готовий механізм обміну даними із зовнішніми додатками, що не вимагає зміни вихідного коду конфігурацій (підготовка до обміну даними робиться в налаштуваннях прикладних рішень):
- «1C:ERP Управління підприємством 2.0»
- «Комплексна автоматизація 2»
- "Бухгалтерія підприємства", редакція 3.0
- "Бухгалтерія підприємства КОРП", редакція 3.0
- «Роздріб», редакція 2.0
- «Управління торгівлею базова», редакція 11
- «Управління торгівлею», редакція 11
- «Зарплата та управління персоналом КОРП», редакція 3
Для обміну даними використовується формат , заснований на XML. Формат є бізнес-орієнтованим – описані в ньому структури даних відповідають бізнес-сутностям (документам та елементам довідників), представленим у програмах 1С, наприклад: акт виконаних робіт, прибутковий касовий ордер, контрагент, номенклатура тощо.
Обмін даними між додатком 1С та стороннім додатком може відбуватися:
- через виділений файловий каталог
- через каталог FTP
- через веб-сервіс, розгорнутий за програмі 1С. Файл даних передається як параметр веб-методів
- через електронну пошту
У разі обміну через веб-сервіс стороння програма ініціюватиме сеанс обміну даними шляхом виклику відповідних веб-методів програми 1С. В інших випадках ініціатором сеансу обміну буде додаток 1С (шляхом поміщення файлу з даними у відповідний каталог або відправкою файлу з даними на налаштовану поштову адресу).
Також на стороні 1С налаштовується, з якою періодичністю відбуватиметься синхронізація (для варіантів із файловим обміном через каталог та електронну пошту):
- за розкладом (із заданою періодичністю)
- вручну; користувач повинен буде вручну запускати синхронізацію щоразу, коли це буде потрібно
Квітування повідомлень
Додатки 1С ведуть облік відправлених та отриманих повідомлень синхронізації та очікують того ж від сторонніх додатків. Це дозволяє використовувати механізм нумерації повідомлень, описаний вище в розділі «Механізм обміну даними».
Додатки 1С у ході синхронізації передають лише інформацію про зміни, що відбулися з бізнес-сутностями з часу останньої синхронізації (щоб мінімізувати обсяг інформації, що передається). При першій синхронізації програма 1С вивантажить всі бізнес-сутності (наприклад, елементи довідника номенклатури) у форматі EnterpriseData у XML-файл (оскільки всі вони є «новими» для зовнішньої програми). Стороннє додаток повинен обробити інформацію з XML-файлу, що прийшов від 1С, і при наступному сеансі синхронізації помістити у файл, що відправляється в 1С, в спеціальну секцію XML, інформацію, що повідомлення від 1С за певним номером успішно прийнято. Повідомлення-квитанція є для додатка 1С сигналом, що всі бізнес-сутності успішно оброблені зовнішнім додатком та інформацію про них передавати більше не потрібно. Крім квитанції XML-файл від сторонньої програми, також може містити дані для синхронізації з боку програми (наприклад, документи реалізації товарів та послуг).
Після отримання повідомлення-квитанції додаток 1С позначає всі зміни, передані в попередньому повідомленні як успішно синхронізовані. Лише несинхронізовані зміни в бізнес-сутностях (створення нових сутностей, зміна та видалення існуючих) будуть відправлені до зовнішнього додатка при наступному сеансі синхронізації.
При передачі даних від зовнішнього додатка додаток 1С картина змінюється на зворотну. Зовнішня програма має заповнити секцію-квитанцію у XML файлі відповідним чином і помістити бізнес-дані для синхронізації зі свого боку у форматі EnterpriseData.
Спрощений обмін даними без квитування
Для випадків простої інтеграції, коли достатньо лише передавати інформацію від стороннього додатка до додатка 1С та зворотної передачі даних з додатка 1С до стороннього додатку не потрібно (наприклад, інтеграція онлайн-магазину, що передає інформацію про продаж до «1С:Бухгалтерію»), є спрощений варіант роботи через веб-сервіс (без квитування), що не вимагає налаштувань на стороні 1С.
Спеціалізовані інтеграційні рішення
Існує типове рішення «1С:Конвертація даних», яке використовує механізми платформи для конвертації та обміну даними між типовими конфігураціями 1С, але може бути використане для інтеграції зі сторонніми додатками.
Інтеграція з банківськими рішеннями
Cтандарт , Розроблений фахівцями 1С більше 10 років тому, фактично став стандартом індустрії в Росії. Наступний крок у цьому напрямку – технологія , що дозволяє відправляти платіжні документи до банку та отримувати витяги з банку безпосередньо з програм системи «1С:Підприємства» натисканням однієї кнопки у програмі «1С»; при цьому не потрібне встановлення та запуск додаткових програм на клієнтський комп'ютер.
Є також .
Інше
Заслуговують на згадку , стандарт обміну комерційною інформацією (розроблений спільно з Microsoft, Intel, Price.ru та іншими компаніями), .
Джерело: habr.com