Прокси 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-файл с конфигом можно тоже почти автоматически.

См. также

Интеграция Альфа Авто 5 / Альфа Авто 6 и AUTOCRM / Инфотек

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

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

36000 руб.

03.08.2020    15748    10    17    

11

Интеграция 1С — Битрикс24. Обмен задачами

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

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

5040 руб.

04.05.2021    17551    6    15    

13

Интеграция с сервисом vetmanager

WEB-интеграция Платформа 1С v8.3 Бухгалтерский учет 1С:Бухгалтерия 3.0 Бытовые услуги, сервис Платные (руб)

Внешняя обработка разрабатывалась для загрузки документов из Ветменеджер в 1С: Бухгалтерия 3.0

12000 руб.

02.02.2021    16360    42    49    

23

[Расширение] БОР-Навигатор.Культура

Зарплата Бюджетный учет WEB-интеграция Обмен с ГосИС Платформа 1С v8.3 Сложные периодические расчеты 1С:Зарплата и кадры государственного учреждения 3 Государственные, бюджетные структуры Россия Бюджетный учет Платные (руб)

Расширение конфигурации, включающее в себя объекты, необходимые для подготовки и сдачи отчета "Штатная численность" системы "БОР-Навигатор.Культура" в программе "1С:Зарплата и кадры государственного учреждения", редакция 3.1.

8400 руб.

01.02.2019    25741    9    0    

7

Заполнение по ИНН или наименованию реквизитов контрагента по данным сайта ФНС

Обмен с ГосИС WEB-интеграция Платформа 1С v8.3 Управляемые формы 1С:Комплексная автоматизация 1.х 1С:Бухгалтерия 2.0 1С:Управление торговлей 10 1С:Управление производственным предприятием 1С:Управление нашей фирмой 1.6 1С:Бухгалтерия государственного учреждения 1С:Документооборот 1С:ERP Управление предприятием 2 1С:Бухгалтерия 3.0 1С:Управление торговлей 11 1С:Комплексная автоматизация 2.х Платные (руб)

Обработка является альтернативой механизму, разработанному фирмой 1С и заполняющему реквизиты контрагента по ИНН или наименованию. Не требуется действующей подписки ИТС. Вызывается как внешняя дополнительная обработка, т.е. используется, непосредственно, из карточки контрагента. Заполнение по ИНН или наименованию реквизитов контрагента по данным сайта ФНС (egrul.nalog.ru) для БП 2.0, БП 3.0, БГУ 1.0, БГУ 2.0, УТ 10.3, УТ 11.x, КА 1.1, КА 2.x, УПП 1.x, ERP 2.x, УНФ 1.5, УНФ 1.6, УНФ 3.0, ДО 2.1

2400 руб.

28.04.2016    88582    160    215    

318
Комментарии
В избранное Подписаться на ответы Сортировка: Древо развёрнутое
Свернуть все
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 1403 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 1403 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 1403 19.12.18 09:59 Сейчас в теме
(5) про ws-security почитайте)
7. nixel 1403 19.12.18 10:00 Сейчас в теме
(5) но вообще любопытная идея - формировать соап сообщение напрямую через xdto. Спасибо, буду иметь ввиду.
9. nixel 1403 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 1138 19.12.18 12:33 Сейчас в теме
На хабре есть хорошая статья. Решается на 1с буквально в десяток строк, коотрые можно вынести в общий модуль и переиспользовать https://habr.com/post/313910/
11. DitriX 2091 19.12.18 13:39 Сейчас в теме
когда я столкнулся с этой проблемой - я не думал что это такая трагедия :)
Мы решили эту проблему за 10 минут, причем тупо средствами 1С.
Тут надо всего лишь понять, что SOAP - это протокол овер http, а это значит, что достаточно использовать http для тех же функций.
Поэтому просто берем работаем как с обычным SOAP - набираем боди как обычно, потом сериализуем его в xml, потом приклеиваем сверху хеадер и отправляем пост запрос.

Да, добавилось лишних 20 строк кода, зато четко все на 1С, универсально и без всяких проблем.
talych; artbear; Irwin; starik-2005; +4 Ответить
12. PLAstic 295 19.12.18 14:14 Сейчас в теме
(11) Т.е. колхозить потэгово? Я правильно понял?
13. DitriX 2091 19.12.18 14:16 Сейчас в теме
(12) Эммм... Не понял, в смысле - потегово? Делаете все как обчно, но в тот момент когда вы делаете вызов функции соапа - вы просто сериализуете параметры, которые вы бы передавали в соап, и отправляете через http. Ничего тут потегово не надо делать.
officeRebot; A_Max; Irwin; +3 Ответить
14. 987ww765 306 05.02.19 08:31 Сейчас в теме
(13) Вас не затруднит выложить пример? На словах я так и не догнал ваш вариант решения. Спасибо
15. DitriX 2091 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 Сейчас в теме
очень помогло, спасибо!
Оставьте свое сообщение