Обмін з «1С» в реальному часі: протокол SOAP

Про популярність і можливості застосування програми «1С: Підприємство» можна писати довго... А можна просто привести статистику, що даний програмний продукт використовується в більш ніж 90% підприємств країн колишнього СНД... І, звичайно, в 2019 році у більшості підприємств-користувачів «одинескою» є свої сайти, а це перша ознака, що керівництву компанії знадобиться інтеграція з «1С». Цей спосіб обміну даними заснований на файловому механізмі, який є базисом всіх сучасних операційних систем. Головною перевагою обміну файлами є те, що система-джерело нічого не повинна знати про системи-споживачі. Ми просто формуємо файл з даними і викладаємо його в сховище (наприклад, файловий каталог), де інші учасники інтеграційного процесу можуть отримати з нього інформацію. Але цей спосіб має безліч недоліків, і я, як розробник, сказав би фатальних:

• Актуальність інформації;

• Швидкість оновлення;

• Досить складно централізовано простежити маршрути і історію проходження даних.

Якщо у Вас сайт на «Бітріксі»

В «1С-Бітрікс: Управління сайтом» (а саме так правильно називається популярна CMS, яку в народі завжди скорочують) передбачений стандартний обмін даними з «1С», але він працює за принципом файлового обміну і він не працює в режимі реального часу. А це дуже важливо, оскільки в сучасному світі ніхто не хоче чекати — все повинно працювати миттєво. Тому я вважаю за краще використовувати веб-сервіси і з радістю поділюся цим методом.

По суті, веб-сервіси — це реалізація абсолютно чітких інтерфейсів обміну даними між різними додатками, які написані не тільки на різних мовах, але і розподілені на різних вузлах мережі. Саме з появою веб-сервісів розвинулася ідея SOA — сервіс-орієнтованої архітектури веб-додатків (Service Oriented Architecture). Перевагою web-сервісів, які можу виділити це:

1. Можливість організувати онлайн-обмін;

2. Можливість організувати віддалений онлайн-обмін, тобто через Інтернет;

3. База-приймач і база-джерело можуть працювати на різних релізах і навіть версіях платформи;

4. Дуже швидка установка з'єднання і дуже швидка передача даних;

5. Зручність для розробника.

На сьогодні найбільшого поширення набули такі протоколи реалізації веб-сервісів:

• SOAP (Simple Object Access Protocol) — по суті, це трійка стандартів SOAP / WSDL / UDDI;

• REST (Representational State Transfer);

• XML-RPC (XML Remote Procedure Call).

Насправді, SOAP пішов від XML-RPC і є наступним етапом його розвитку. У той час як REST — це концепція, в основі якої лежить швидше архітектурний стиль, ніж нова технологія, що базується на теорії маніпуляції об'єктами CRUD (Create Read Update Delete) в контексті концепцій WWW. Для реалізації веб-сервісу на базі SOAP протоколу, є вбудований пакет в PHP для роботи з SOAP.

Як це працює на практиці

Не так давно до нас звернувся замовник із запитом на розробку порталу сервісної вимоги побутової техніки з інтеграцією «1С». Особливою умовою була можливість для клієнтів додавати сервісні вимоги (які повинні відразу потрапити в «1С»), запрошувати всі свої сервісні вимоги з їх характеристиками і описами, сервісні документи, товари, при цьому, основною БД повинна бути «1С». Додатково, повинна бути можливість фільтрації записів за різними параметрами, наприклад: гарантія, не гарантія, назва, дата, серійний номер і т.д.

Звичайно ж ми вирішили організувати обмін по SOAP-протоколу. Програмісти «1С» налаштували Web-сервіс зі свого боку; нам же потрібно було реалізувати під’єднання до сервісу, як клієнт, за допомогою php-класу SoapClient (використовуючи WSDL-документ).

Для роботи за допомогою WSDL-документа не потрібно вказувати URI-сервера, простір імен, заголовок SOAPAction, спосіб кодування і типи параметрів. Вся ця інформація береться з WSDL файлу. Так простіше, але можуть виникнути проблема. Єдиний аргумент проти його використання полягає в тому, що клієнт повинен прочитати WSDL з сервера до того, як можна буде викликати якусь процедуру, а в веб це може зайняти досить багато часу. Для того, щоб прискорити роботу в SOAP-розширенні, передбачені наступні параметри конфігурації: soap.wsdl_cache_enabled, soap.wsdl_cache_dir і soap.wsdl_cache_ttl. Їх можна задати у файлі php.ini або за допомогою ini_set (). Приклад коду підключення SOAP клієнта в файлі init.php:

Далі все просто: програміст «1С» створив методи, які ми використовували для отримання і виведення, в реальному часі, потрібної інформації на порталі з «1С», або ж для надсилання даних в «1С».

Приклад роботи обміну на порталі: на скріншоті нижче видно форму, де користувач вводить дані, а саме — проміжок часу і назва товару, і за допомогою кнопки «Знайти» шукає результат.

На сервері завдяки методу get_search_nomenclature_for_name ($ param), створеним програмістом «1С», отримуємо всі документи товарів в реальному часі з бази «1С». Код виклику функції і отримання всіх даних в реальному часі:

Далі миттєво виводимо на сайт інформацію про товари, які задовольняють запит користувача:

Потім, вибравши потрібний нам товар, додаємо додаткові параметри для опису несправності товару для сервісної вимоги і знову за допомогою ajax-запиту відправляємо параметри на сервер, де, використовуючи метод get_created_doc ($ param), створюємо в 1С сервісну вимогу.

Створення сервісної вимоги на сайті:

Код виклику методу get_created_doc ($ param) для створення сервісної вимоги в БД «1С»:

Підсумок

У цій статті я коротко описав тільки основні моменти SOAP-розширення. Головне те, що воно розв’язує питання обміну в реальному часі, і Ви вже можете пробувати це на власному сайті. Але це далеко не межа розширення! Воно може набагато більше, але продемонструвати всі його можливості в рамках однієї короткої статті просто не вийде. Наша компанія з радістю розгляне Ваші питання щодо цього методу і запропонує ефективне рішення.