Прокси soap-сервер. Когда 1С не может в SOAP

19.12.18

Интеграция - WEB-интеграция

Думаю, многие сталкивались с проблемой "своеобразной" поддержки SOAP в 1с. То wsdl не парсится, то методы не вызываются, то xdto пакет толком не читается из-за вольностей (к слову, допустимых) в xsd. Ещё хуже дело обстоит, если в soap-сообщение нужно добавить заголовки - так называемые soap-headers, которые есть в стандарте soap 1.2, и которые конечно же не поддерживает 1С. Попробуем решить проблему и написать свой прокси-сервис "за 10 минут".

Вступление

Кто-то может сказать: "Ой, да что там руками формировать, XML простая". Однако протокол содержит некоторое количество расширений, таких как, например, WS-Addressing и WS-Security, которые могут превратить ручное формирование в боль.

На работе мне пришлось столкнуться с довольно замороченным soap-сервером, с которым не получалось легко работать из 1С. Сегодняшняя моя статья про то, как можно разработать легковесную прослойку между 1С и soap-сервером, принимающую в себя обычный http-запрос и перекладывающую содержимое в вызов soap-сервера. Естественно, код в статье максимально упрощен для простоты восприятия. Код работающего у меня production-решения сильно отличается от указанного примера и более «архитектурный» :).

Подготовка

В качестве инструмента для решения задачи я буду использовать node.js. Почему? Во-первых, мне так удобнее: я его знаю :). Во-вторых, на нем есть простые для запуска библиотеки для построения веб-приложений, работы с soap и кластеризацией. В качестве редактора я рекомендую использовать Visual Studio Code, но это уже дело вкуса. Тренироваться будем на классическом сервисе курсов валют.

После установки node.js в командной строке вам должна быть доступа утилита npm - пакетный менеджер для node.js. Для работавших с opm - это почти тоже самое, только для node.js и мощнее :).

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

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

npm install --save soap body-parser express

Файл с wsdl положим в корень каталога с именем DailyInfo.wsdl в кодировке UTF-8.

Для достижения нашей цели нам надо решить следующие задачи:

  1. Написать веб-сервер, который сможет принимать POST запросы (это совсем не так сложно, как звучит).

  2. Подключиться к soap-серверу как клиент.

  3. Преобразовать входящий POST-запрос в вызов soap-метода и вернуть на клиент результат.

Страшно? 10 минут, помните?

Реализация – веб-сервер

Создадим скелет нашего приложения - файл index.js в корневом каталоге (если вы не указывали иное при выполнении npm init) со следующим содержимым:

// express – фреймворк для построения веб-приложений
const express = require('express');
// Преобразователь тела сообщения к объекту JavaScript. Мы его будем
// использовать для автопреобразования сообщения с Content-Type
// application/json из собственно JSON в объект.
const bodyParser = require("body-parser");

// Объявление главной функции. Async-возможность нам понадобится чуть позднее.
async function main() {
    // Порт, который будет слушать веб-сервер
    const port = 3000;
    // Создание экземпляра веб-приложения
    const app = express();

    // Указание реагировать на POST-запрос
    app.post(
        "/",                // по «пустому» ресурсу
        bodyParser.json(),  // с автоматическим преобразованием json-содержимого
        (req, res) => {     // и выводом Привет, мир :)
            res.send("Hello, World");
        }
    );

    // Запуск приложения – указание слушать порт
    // и выводить сообщение в консоль по готовности
    app.listen(port, () => console.log(`Test app listening on port ${port}!`));
}

// Точка входа
main();

Этим небольшим скриптом мы сразу же решили задачу №1 из нашего списка. Осталось запустить и проверить.

Для запуска приложения у нас есть два варианта:

  • запуск из командной строки через node index.js;

  • запуск отладчика в VSCode.

С первым вариантом все просто: вбили в консоль и радуемся:

Останавливаем работу через Ctrl-C.

Отладчик VSCode запускается по кнопке F5. В выпадающем меню надо выбрать Node.js:

После выбора node.js на вкладке Debug console можно убедиться, что наше приложение запустилось и готово обрабатывать запросы:

Для проверки работоспособности я воспользуюсь чудесным инструментом отладки http-запросов Postman:

В ответе сервиса видим, что он не может обработать GET-запрос, что логично. Поменяем запрос на POST и получим уже ожидаемый ответ:

Реализация – soap-клиент

Перейдем ко второй части – подключение по soap-серверу в качестве клиента. Для этого в уже существующий файл нужно добавить два участка кода. В секцию подключения библиотек добавим подключение “soap” – библиотеки, с помощью которой можно как подключиться к чужому soap-серверу, так и опубликовать собственный.

const soap = require("soap");

Внутрь функции main добавим создание soap-клиента:

// создание soap-клиента на базе предварительно скачанной wsdl.
// В качестве параметра может выступать как адрес к файлу на диске,
// так и URL, по которому этот WSDL можно получить (прямо как WS-Ссылка)
const soapClient = await soap.createClientAsync("./DailyInfo.wsdl");
soapClient.setEndpoint("http://www.cbr.ru/DailyInfoWebServ/DailyInfo.asmx");

Иии… всё. Теперь через созданного клиента мы можем вызывать методы soap-сервера, как указанные с «полным» именем в виде soapClient,service.port.methodName(), так и по короткому soapClient.methodName().

Реализация – Преобразование запроса

Добавим, собственно, вызов нужного нам soap-метода. В качестве API нашего сервиса предлагаю такую простую схему: в теле POST-запроса передается JSON следующей структуры:

  • method – строка – имя вызываемого soap-метода;

  • body – произвольный – тело soap-запроса в виде js-объекта.

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

{
      "method": "GetCursOnDate",
      "body": { "On_date": "2018-01-01" }
}

Заменим наш ответ «привет, мир» на следующий код:

// Десериализованное тело запроса доступно в переменной req.body
// В случае корректного запроса req.body будет содержать два свойства:
// method и body

// Попробуем получить указатель на функцию для вызова soap-метода
const soapMethod = soapClient[req.body.method];

// Если метод не нашелся, выбросим исключение
if (soapMethod == undefined) {
    throw new Error("Wrong method name");
}

// Если все хорошо, вызовем soap-метод, передав ему в качестве параметров
// тело сообщения и обработчик результата вызова
soapMethod(req.body.body, (err, result) => {
    
    // В случае возникновения ошибки вернем ее клиенту.
    if (err) {
        res.send(err);
        return;
    }

    // Если все хорошо, переведем ответ в JSON и вернем клиенту.
    res.send(JSON.stringify(result));
});

Кода меньше, чем комментариев :). Сохраняемся, перезапускаемся и снова идем в Postman. На вкладке body укажем, что мы отправляем raw-данные с типом application/json и содержимым из примера выше:

В результате видим тело soap-ответа в виде JSON.

Реализация – вызов из 1С

Postman – это хорошо, но мы же изначально пришли с проблемой вызова из 1С. Выполнить обычный POST-запрос из 1С не составит труда, однако, я приведу пример реализации здесь, чтобы показать работу с JSON и XDTO.

Для начала добавим пакет XDTO в конфигурацию 1С. Если WSDL от поставщика soap-сервера читается, можно сразу добавить WS-ссылку. Сэмулируем проблему "нечитабельности" wsdl и добавим XDTO пакет вручную. В этом нам поможет знание о том, что WSDL содержит XSD для содержимого всех сообщений и методов.

Вытащим из WSDL все содержимое тега s:schema в отдельный файл и перенесем объявление пространства имен s из заголовка WSDL в заголовок нового файла. Получится что-то вроде такого:

Сохраним содержимое в файл с разрешением XSD, и, если все прошло успешно, полученная схема успешно импортируется в конфигуратор как XDTO пакет:

Если от вендора пришла «нечитаемая» в 1С XSD, то использование фабрики XDTO из следующего примера не имеет смысла, однако десериализацию из JSON будет просто написать по аналогии с сериализацией.

Для формирования запросов создадим внешнюю обработку со следующим кодом:

&НаСервереБезКонтекста
Процедура ВыполнитьЗапросНаСервере()

    // Создадим тело нашего запроса - параметры вызываемого soap-метода
    ТелоЗапроса = Новый Структура;
    ТелоЗапроса.Вставить("On_date", Дата(2018, 1, 1));

    // Сериализуем его в JSON
    ТекстСообщения = СериализоватьВJSON(ТелоЗапроса);

    // Проверим, что полученный JSON удовлетворяет XSD

    // Если бы у данного свойства был бы выделенный "тип объекта",
    // то мы бы могли получить тип проще...
    //ТипXDTO = ФабрикаXDTO.Тип(Метаданные.ПакетыXDTO.ПакетXDTO1.ПространствоИмен, "GetCursOnDate");

    КорневыеСвойства = ФабрикаXDTO.Пакеты.Получить(Метаданные.ПакетыXDTO.ПакетXDTO1.ПространствоИмен).КорневыеСвойства;
    СвойствоЗапросКурсовНаДату = КорневыеСвойства.Получить("GetCursOnDate");
    ТипXDTO = СвойствоЗапросКурсовНаДату.Тип;

    ЧтениеJSON = Новый ЧтениеJSON;
    ЧтениеJSON.УстановитьСтроку(ТекстСообщения);

    // Если здесь не выдалось исключения, значит, пакет корректен и его можно отправлять.
    ФабрикаXDTO.ПрочитатьJSON(ЧтениеJSON, ТипXDTO); 

    // Создадим верхнеуровневую структуру, принимаемую промежуточным сервером
    СтруктураЗапроса = Новый Структура;
    СтруктураЗапроса.Вставить("method", "GetCursOnDate");
    СтруктураЗапроса.Вставить("body", ТелоЗапроса);

    // Сериализуем его в JSON для последующей отправки
    ТекстСообщения = СериализоватьВJSON(СтруктураЗапроса);

    // Создадим новое соединение с промежуточным сервером
    Хост = "localhost";
    Порт = 3000;
    Таймаут = 30;

    Соединение = Новый HTTPСоединение(Хост, Порт, , , , Таймаут);   

    // "Корневой" адрес ресурса, как мы его объявили в app.post
    Ресурс = "/";

    // Обязательно передаем тип содержимого для работы преобразователя body-parser
    ЗаголовкиЗапроса = Новый Соответствие();
    ЗаголовкиЗапроса.Вставить("Content-type", "application/json");

    // Создаем и отправляем запрос
    Запрос = Новый HTTPЗапрос(Ресурс, ЗаголовкиЗапроса);
    Запрос.УстановитьТелоИзСтроки(ТекстСообщения);

    Ответ = Соединение.ОтправитьДляОбработки(Запрос);   
    ТелоОтвета = Ответ.ПолучитьТелоКакСтроку();

    // Десериализуем ответ сервиса из JSON в объект XDTO
    ЧтениеJSON = Новый ЧтениеJSON;
    ЧтениеJSON.УстановитьСтроку(ТелоОтвета);

    ТипXDTO = ФабрикаXDTO.Тип(Метаданные.ПакетыXDTO.ПакетXDTO1.ПространствоИмен, "GetCursOnDateResponse");
    Данные = ФабрикаXDTO.ПрочитатьJSON(ЧтениеJSON, ТипXDTO);

КонецПроцедуры

&НаСервереБезКонтекста
Функция СериализоватьВJSON(Объект)
    Запись = Новый ЗаписьJSON;
    Запись.УстановитьСтроку();
    ЗаписатьJSON(Запись, Объект);
    ТекстСообщения = Запись.Закрыть();

    Возврат ТекстСообщения;
КонецФункции

&НаКлиенте
Процедура ВыполнитьЗапрос(Команда)
    ВыполнитьЗапросНаСервере();
КонецПроцедуры

Некоторые пояснения по коду.

Первое, за что может зацепиться взгляд – использование «обычной» ЗаписиJSON вместо ФабрикиXDTO. Причина тут довольно проста – ФабрикаXDTO умеет записывать произвольные типы, но с «мусорными» тегами “#value” и “#type” (тип добавляется, только если это указано явно в настройках записи). Наш промежуточный сервер ни про какие value ничего не знает. Выхода тут два – либо научить понимать сервер, либо использовать упрощенный сериализатор на базе структуры и записи. Выбор за вами.

Второе – пляски с бубном вокруг ФабрикиXDTO. Это всего лишь проверка валидности нашего сообщения. Мы же порядочные граждане, хотим быть уверены, что мы не шлем soap-серверу что-то, чего он не ожидает. В конкретно данном случае дополнительный реверанс пришлось сделать для получения типа создаваемого свойства, т. к. исходная wsdl вообще не содержит явных описаний типов значений, а только описания свойств с вложенными описаниями типов.

А вот чтение сообщения мы уже выполним «честной» ФабрикойXDTO для получения объекта XDTO и возможности работы в объектной модели.

Ставим в конец процедуры точку останова, выполняем обработку… Вуаля:

Цель достигнута!

Кластеризация

Окей, сервис готов, можно в прод? :)

Если не страшно, то можно сразу и в прод, однако, я бы на вашем месте помимо обработки ошибок и общего причесывания кода добавил бы еще одну вещь. Node.js штука хоть и быстрая, но не всемогущая. Возможно вам знакома фраза, что «нода – асинхронная, но однопоточная». В новых версиях node.js уже появилась честная поддержка многопоточности, но для простоты воспользуемся другим старым и проверенным механизмом – кластеризацией. А асинхронность обработки в нашем случае есть, но нам не помешает воспользоваться дешевым ускорителем.

Ставим пакет cluster-service с помощью команды:

npm install -g cluster-service

Запускаем наше приложение в командной строке, но в вместо node укажем приложение cservice:

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

Что там было про WS-Addressing?

Ах-да, заголовки, те самые soap-headers, которые не поддерживает 1С. Добавить их довольно просто – для этого в soapClient есть метод addSoapHeaders, в который можно передать либо готовую строку с заголовками, либо JS-объект. Попробуем реализовать добавление пары заголовков семейства WS-Addressing, а именно Action и MessageID.

Для генерации UUID сообщения установим библиотеку uuid:

npm install --save uuid

Добавим ее в секцию импорта библиотек:

const uuidv4 = require("uuid/v4");

Между проверкой указателя на soap-метод и самим вызовом soap-метода добавим заполнение заголовков:

// Создадим объект для хранения заголовков
const wsaHeader = {
    MessageID: {
        // В качестве значения для заголовка MessageID сгенерируем случайный UUID
        $value: uuidv4()
    },
    Action: {
        // Для Action передадим имя вызываемого метода, как того требует протокол
        $value: req.body.method
    }
};

// Очистим заголовки soap-запроса
soapClient.clearSoapHeaders();

// Добавим новый заголовок
soapClient.addSoapHeader(
    wsaHeader,    // объект, в котором хранятся заголовки
    "WSA",        // имя группы заголовков
    "wsa",        // префикс пространства имен
    "http://www.w3.org/2005/08/addressing" // само пространство имен
);

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

Дополнительные вопросы

- А зачем JSON? Можно гонять туда-сюда XML?
- Можно, но зачем, если есть возможность гонять более легковесный JSON, а 1С уже умеет нативно с ним работать?

- Можно ли накрыть авторизацией?
- Можно, причем и веб-приложение (для этого надо добавить еще один middle-ware с авторизацией в вызов app.post), и soap-сервер, который можно поднять в этом же приложении как сервис обратного вызова в случае асинхронного soap-обмена.

Заключение

Вот таким нехитрым способом мы смогли обойти ограничение возможностей платформы 1С, таких как отсутствие поддержки soap-headers и не полной поддержки WSDL-описания.

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

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

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

См. также.

Сайты и интернет-магазины WEB-интеграция Системный администратор Программист Пользователь Платформа 1С v8.3 Конфигурации 1cv8 1С:Управление торговлей 11 Автомобили, автосервисы Россия Управленческий учет Платные (руб)

Интеграционный модуль обмена между конфигурацией Альфа Авто 5 и Альфа Авто 6 и порталом AUTOCRM. Данный модуль универсален. Позволяет работать с несколькими обменами AUTOCRM разных брендов в одной информационной базе в ручном и автоматическом режиме.

36000 руб.

03.08.2020    16430    15    18    

15

Сайты и интернет-магазины Интеграция WEB-интеграция Платформа 1С v8.3 Конфигурации 1cv8 Управленческий учет Платные (руб)

Интеграция 1С и Битрикс 24. Разработка имеет двухстороннюю синхронизацию 1С и Bitrix24 задачами. Решение позволяет создавать пользователя в 1С из Битрикс24 и наоборот. Данная разработка технически подходит под все основные конфигурации линейки продуктов 1С:Предприятие 8.3 (платформа начиная с 8.3.23). При приобретении предоставляется 1 месяц бесплатных обновлений разработки. Доступна демо-версия продукта с подключением Вашего Битрикс24

5040 руб.

04.05.2021    18676    10    15    

16

WEB-интеграция 8.3.8 Конфигурации 1cv8 Автомобили, автосервисы Беларусь Украина Россия Казахстан Управленческий учет Платные (руб)

Расширение предназначено для конфигурации "1С:Предприятие 8. Управление Автотранспортом. ПРОФ". Функционал модуля: 1. Заполнение регистров сведений по подсистеме "Мониторинг", а именно: события по мониторингу, координаты по мониторингу, пробег и расход по мониторингу, текущее местоположение ТС по мониторингу 2. Заполнение путевого листа: пробег по мониторингу, время выезда/заезда, табличная часть ГСМ, места стоянок по геозонам. 3. Отчеты по данным загруженным в регистры сведений. 4. Предусмотрена автоматическая загрузка данных в фоновом режиме (условия работы данной загрузке читайте в описании товара) Модуль работает без включенной константы по настройкам мониторинга. Модуль формы предоставляется с открытым кодом, общий модуль защищен. Любой заинтересованный пользователь, имеет возможность скачать демо-версию расширения.

22656 руб.

25.05.2021    13189    35    8    

14

Прайсы WEB-интеграция Ценообразование, анализ цен Файловый обмен (TXT, XML, DBF), FTP Системный администратор Программист Автомобили, автосервисы Оптовая торговля, дистрибуция, логистика Управленческий учет Платные (руб)

Программа с заданным интервалом времени (или по ручной команде) скачивает файлы (например, прайс-листы поставщиков) из различных источников: письма электронной почты, FTP или HTTP-адреса, и сохраняет их в каталог упорядоченной структуры. При этом извлекает файлы из архивов, может переименовывать файлы и менять их формат (csv, xls, txt). Можно настроить выгрузку обработанных файлов на сайт (через FTP-подключение). Программа будет полезна компаниям, у которых есть большое количество поставщиков и/или прайс-листы поставщиков обновляются часто (необязательно прайс-листы, файлы могут быть любого назначения). Собранные таким образом актуальные версии прайс-листов можно выгрузить с помощью программы себе на сайт (или на любой FTP-сервер) или выполнить другие необходимые задачи.

25200 руб.

28.05.2015    86409    26    51    

50
Комментарии
Подписаться на ответы Инфостарт бот Сортировка: Древо развёрнутое
Свернуть все
1. savostin.alex 83 19.12.18 04:31 Сейчас в теме
Можно как службу поднять:
nssm.exe install web-app "C:\Program Files\nodejs\node.exe" c:\http\index.js
Прикрепленные файлы:
nssm.exe
2. nixel 1418 19.12.18 05:32 Сейчас в теме
(1) предпочитаю такие вещи упаковывать в докер.
zakiap; starik-2005; +2 Ответить
3. PLAstic 295 19.12.18 09:07 Сейчас в теме
А проблема была сложнее, чем просто обернуть наш пакет в soap:envelope? А то я выкрутился, скачав XSD SOAP, подгрузив в 1С и программно обернув достаточно красиво свой пакет в envelope. Про что мне надо почитать, чтобы проникнуться сложностями топикстартера? Мне кажется, хидеры так же добавляются обычным способом...

1С с жсоном работает просто мерзко, когда пытаешься его сериализовать по XDTO. Попробуйте выгрузить или загрузить пустой массив. Выгрузить - он никак не декларируется, загрузить - натыкаемся на баг платформы с одним только выходом - перезагрузить клиента. Платформенный "ПрочитатьJSON", конечно, парсит уже нормально пустые массивы, но получаем структуру.
4. nixel 1418 19.12.18 09:35 Сейчас в теме
(3) хедеры добавляются не в soap:body, а в soap:headers. В моем случае мне нужно было реализовать ws-addressing и ws-security .X509 гостовскими сертификатами. В итоге body составляет примерно 5 процентов от итогового envelope, все остальное обрабатывалось на стороне прослойки.
5. PLAstic 295 19.12.18 09:43 Сейчас в теме
(4) Загружаем это в пакет XDTO, видим сразу Envelope:Header. Это не то?
Вроде похоже. Почитал про WS-addressing, сразу наткнулся на этот пакет. Грузим его в XDTO, добавляем нужные ссылки. Вроде всё?

Тут в 1.2 и в 7 указаны ссылки на все задействованные пространства имён.
A_Max; nixel; +2 Ответить
6. nixel 1418 19.12.18 09:59 Сейчас в теме
(5) про ws-security почитайте)
7. nixel 1418 19.12.18 10:00 Сейчас в теме
(5) но вообще любопытная идея - формировать соап сообщение напрямую через xdto. Спасибо, буду иметь ввиду.
9. nixel 1418 19.12.18 12:27 Сейчас в теме
(4) и отдельно этот же сервис у меня выступает в роли коллбэка для асинхронного соап обмена с повышенными требованиями по высокой доступности, а 1с с её выводом на обслуживание для обновления тут не подходила.

В общем... Много было заморочек
8. N!ghtmare 19.12.18 11:21 Сейчас в теме
Еще как вариант,не "за 10 минут конечно", чтобы сохранить возможность валидации пакетов на стороне приемника, в проксе реализовать xslt преобразование. был практический опыт реализации на одном из проектов такой штуки на шарпе для интеграции с SAP PI.
в целом эта функция(xslt transoform) есть в большинстве esb -ей. и в WSO2 и в MULE. так же поддержка процессоров xslt есть в java и .net , нужно только обернуть и поднять на сервере приложения(Тomcat,IIS)

И на помечтать... В платформе было бы не плохо не сразу подавать сообщение на валидатор по опубликованному веб-сервису , а добавить возможность провести подготовительную обработку сообщения,дать возможность реализовать прокси внутри. Так же по внешней wsdl ссылке перед отправкой добавить возможность обработки отправляемого сообщения внешнему вебсервису. вот бы зажили тогда....
10. Fragster 1141 19.12.18 12:33 Сейчас в теме
На хабре есть хорошая статья. Решается на 1с буквально в десяток строк, коотрые можно вынести в общий модуль и переиспользовать https://habr.com/post/313910/
11. DitriX 2098 19.12.18 13:39 Сейчас в теме
когда я столкнулся с этой проблемой - я не думал что это такая трагедия :)
Мы решили эту проблему за 10 минут, причем тупо средствами 1С.
Тут надо всего лишь понять, что SOAP - это протокол овер http, а это значит, что достаточно использовать http для тех же функций.
Поэтому просто берем работаем как с обычным SOAP - набираем боди как обычно, потом сериализуем его в xml, потом приклеиваем сверху хеадер и отправляем пост запрос.

Да, добавилось лишних 20 строк кода, зато четко все на 1С, универсально и без всяких проблем.
degtyarev85; talych; artbear; Irwin; starik-2005; +5 Ответить
12. PLAstic 295 19.12.18 14:14 Сейчас в теме
(11) Т.е. колхозить потэгово? Я правильно понял?
13. DitriX 2098 19.12.18 14:16 Сейчас в теме
(12) Эммм... Не понял, в смысле - потегово? Делаете все как обчно, но в тот момент когда вы делаете вызов функции соапа - вы просто сериализуете параметры, которые вы бы передавали в соап, и отправляете через http. Ничего тут потегово не надо делать.
officeRebot; A_Max; Irwin; +3 Ответить
14. 987ww765 307 05.02.19 08:31 Сейчас в теме
(13) Вас не затруднит выложить пример? На словах я так и не догнал ваш вариант решения. Спасибо
15. DitriX 2098 05.02.19 13:58 Сейчас в теме
Простого примера нет, там все раскидано по куче модулей.
Но в двух словах так:
1. Получаем через соап опиание xdto
2. Создаем эти xdto и заполняем все как обычно, как будто мы хотим отправить через соап
3. Когда собрали все данные - берем этотм xdto пакет и сериализуем в xml
4. Берем расширение для хрома https://chrome.google.com/webstore/detail/wizdler/oebpmncolmhiapingjaagmapififiakb­ и набиваем тестовые данные
5. Смотри какой xml надо получить, и то что получили на этапе 3 - приводим к тому, что видим на этапе 4. Обычно - это добавление в начле и вконце тегов всяких. И обязательно смотрим заголовки.
6. Формируем http запрос, где пихаем заголовки и в тело - вот эту нащшу полученную строку
7. Получив ответ - десериализуем его, либо просто через фабрику, либо вычленяем тип и через него.
officeRebot; o.nikolaev; +2 Ответить
17. LookingFor 04.07.19 16:51 Сейчас в теме
(11) Добрый день!
А не могли бы Вы показать на примере более конкретно. Наш сервер не отвечает на HTTP запросы так, как на SOAP.
16. webester 26 05.02.19 15:17 Сейчас в теме
Чего я не понял, так это если вы поднимаете свой сервер который обрабатывает только ваши запросы. Зачем мудрить с передачей параметров? Передавайте нужные данные в теле запроса а уже скриптом пакуйте как надо?
18. user1250657 10.07.19 13:20 Сейчас в теме
очень помогло, спасибо!
Оставьте свое сообщение