Передача больших пакетов через веб-сервисы

0. 10472 05.12.15 20:42 Сейчас в теме
Реализация механизма передачи больших пакетов через веб-сервисы. С его помощью передать файл размером в несколько гигабайт не составит проблем.

Перейти к публикации

Комментарии
В избранное Подписаться на ответы Сортировка: Древо развёрнутое
Свернуть все
1. script 230 06.12.15 09:40 Сейчас в теме
Данная методика давно уже используется во многих типовых решения для обмена с мобильным клиентом. Только регистр там называется ОчередиСообщений. Ну нужно сказать что деление файла на части хоть и позволяет передать много данных, но существенно тормозит процесс обмена. Все как всегда, что быстрее работать с одним большим файлом или с кучей мелких.
2. YPermitin 10472 06.12.15 10:11 Сейчас в теме
(1) script, спасибо за информацию. Там это реализовано немного сложнее. Но принцип, согласен, тот же.
3. DitriX 1848 06.12.15 15:25 Сейчас в теме
А еще до мобильной - это есть все в бсп :)
Но есть и другое решение - вам надо с УТП забрать файл в 1Гб, и поместить его, например, в документооборот, не важно.
Действия такие - документооборот подключается к УТП (возможно по инициализации самой УТП) и забирает оттуда файл в 1Гб без ограничений :)
4. YPermitin 10472 06.12.15 16:36 Сейчас в теме
(3) DitriX, только не говорите, что он подключается по COM =)
19. ojiojiowka 30.07.20 12:11 Сейчас в теме
(3) извините, но не могли бы подсказать, где такое реализовано в БСП? Сходу не смог найти. Название регистра или имя функции, которая использует такой подход скажите пожалуйста.
5. bonv 1128 07.12.15 11:59 Сейчас в теме
В первую очередь, говоря про передачу больших файлов, следует отметить, что использование SOAP имеет накладные расходы в виде увеличения объема передаваемых данных на 33%.
Лучше использовать голый HTTP.
9. YPermitin 10472 07.12.15 22:13 Сейчас в теме
(5) bonv, согласен, можно и JSON использовать, уже будет легче. Совершенству нет предела)
13. Dementor 767 09.12.15 12:00 Сейчас в теме
(5) bonv, если использовать бинарный тип (hexBinary), то накладные расходы SOAP будут всего лишь в добавлении envelope-обвязки пакета - можно пренебречь. Сам к сожалению не экспериментировал, так как мне были доступны для передачи файлы кодированные в Base64 (как раз эти самые потери 33% на увеличении объема), но если возможность в платформе есть, то и имеется вероятность отличная от нуля, что это работает.

При передаче файлов POST-ом по протоколу HTTP та же петрушка, что и при SOAP - данные часто передают типом application/x-www-form-urlencoded
YPermitin; +1 Ответить
16. YPermitin 10472 09.12.15 13:18 Сейчас в теме
(13) Dementor, Вы правы, сам SOAPовский конверт имеет незначительный вес, а вот преобразование в base64 увеличивает размер передаваемых данных на треть.

(14) premier, проще отслеживать состояние передачи пакета, можно запросами платформы получать состояния передачи пакетов и т.д., а с каталогом пришлось бы для этого делать "извраты" с чтением файлов и т.д. Сами данные пакета не обязательно записывать в регистр сведений, можно в нем хранить лишь путь к файлу части пакета на диске (что-то вроде хранения файлов в томах). На рабочей базе лучше реализовать периодическую очистку этого регистра, чтобы старые пакеты в нем не хранились долго.

Вариантов реализации масса)
17. bonv 1128 10.12.15 07:56 Сейчас в теме
(13) срочно учить матчасть!
если использовать бинарный тип (hexBinary), то накладные расходы SOAP будут всего лишь в добавлении envelope-обвязки пакета - можно пренебречь

Если использовать hexBinary, то расходы будут 100%. hexBinary использует для отображения одного байта 2 символа.

А вот MTOM в платформе еще пока нет. Так что только голый HTTP.

При передаче файлов POST-ом по протоколу HTTP та же петрушка, что и при SOAP - данные часто передают типом application/x-www-form-urlencoded

А application/x-www-form-urlencoded то тут причем. Данный формат предназначен для передачи параметров веб-формы. Для передачи бинарных данных никто его в здравом уме использовать не будет.
6. bonv 1128 07.12.15 12:03 Сейчас в теме
(0)
Slash = Символ(92); // Символ "/"
....
ВременныйКаталог = КаталогВременныхФайлов()+"SendingMessageWS"+Slash+ИдентификаторСообщения;

Черт, вы это серьезно? Разделитель задаете через это Символ(92)?
memb3r; vtas; YPermitin; +3 Ответить
8. YPermitin 10472 07.12.15 22:12 Сейчас в теме
(6) bonv, Это не то, что вы подумали! =D
7. comol 4539 07.12.15 14:05 Сейчас в теме
Круто! Вопрос только один: А нафига зачем??? Одно дело упростить себе жизнь и использовать SOAP для построения событийной модели обмена... Другое дело лить через http протокол файлы. Ну и выгружайте тогда уж в файл, притом лучше не XML, а хотя бы FI тогда уж... а по SOAP передавайте ссылку на него...
memb3r; YPermitin; skif47; Mick2iS; +4 Ответить
10. YPermitin 10472 09.12.15 08:49 Сейчас в теме
(7) comol, сразу забыл ответить, сорри)
Так то оно так, но если переход на обмен через веб-сервисы выполняется со старого транспорта, который выполнял выгрузку в XML, то время на изменение обмена может очень дорого стоить компании. Компромиссный вариант - изменить вид транспорта и немного механизмы обработки сообщений, вместо переписки основной части выгрузки и загрузки данных.
11. skif47 335 09.12.15 08:59 Сейчас в теме
В одной своей разработке тоже уткнулся в относительно большие размеры сообщений, передаваемых через SOAP (в моем случае 7-8 МБ).
Загрузка с тестового сервера Амазон во Франкфурте не прошла: отвалилось по таймауту.
Стал на стороне сервера сжимать ответ сервера в ZIP и передавать его тем же SOAP как base64Binary (http://www.w3.org/2001/XMLSchema). Средний размер файла оказался уже около 500 КБ. Распаковка в XML и парсинг в XDTO объект проблем не вызвала, поскольку сам объект WSProxy предоставляет заодно и фабрику XDTO, которой уже можно парсить разжатые ответы.
Протестировал то же самое со сжатием FastInfoSet вместо XML - выигрыш получился незначительный.
Если вместо SOAP использовать HTTP, тоже будет некоторый выигрыш.

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

В любом случае за тему плюс ))
12. Dementor 767 09.12.15 11:35 Сейчас в теме
Идея интересная, если делать тиражное решение для абстрактного клиента, на инфраструктуру которого не возможно повлиять.
Но на своем опыте могу сказать - при задаче частого обмена большими файлами проще в веб-сервере убрать ограничение для опубликованной базы.
15. YPermitin 10472 09.12.15 13:10 Сейчас в теме
(12) Dementor, админы негодуют, когда просишь убрать ограничения. В принципе я с ними согласен)
14. premierex 09.12.15 12:37 Сейчас в теме
(0) А я вот не понял смысла промежуточной записи файлов в регистр сведений. Почему сразу в каталог с неким GUID их не писать, а имена коротких файлов для дальнейшего объединения запоминать в массиве?
18. rail21111991 30.12.15 13:54 Сейчас в теме
Оставьте свое сообщение
Вопросы с вознаграждением