Работали ли вы с SOAP

Что проверяют

Вызывали ли вы чужой SOAP-сервис из Python на практике: как разбирали WSDL, как строили типы, как отличали бизнес-отказ от сетевой ошибки. Заодно смотрят, не растеряетесь ли вы, когда контракт оказывается кривым.

Как отвечать

Основной инструмент это zeep. Расскажите механику:

• клиент строится по WSDL, схемы разбираются при инициализации, сложные типы создаются через client.get_type, вызов идёт как client.service.Имя(...);
• транспорт настраивается отдельно: своя requests.Session, тайм-ауты, клиентский сертификат, кэш разобранного WSDL, иначе старт приложения упирается в загрузку схем;
• ошибки: zeep.exceptions.Fault для отказа сервиса, детали лежат в поле detail, сетевые исключения приходят из транспорта;
• подпись и шифрование сообщения делаются через модуль WSSE, под капотом xmlsec;
• если WSDL невалиден или сервер отступает от стандарта, проще собрать конверт шаблоном и отправить requests.post с нужным Content-Type и заголовком SOAPAction.

from zeep import Client
from zeep.exceptions import Fault

client = Client(WSDL_URL)
try:
    order = client.service.GetOrder(orderId=order_id)
except Fault as err:
    log.warning("soap fault %s: %s", err.code, err.message)

Библиотека suds встречается в старом коде, но оригинальная ветка давно заброшена, живут только форки.

Где спотыкаются

Ловят всё одним except Exception. Отказ по бизнес-правилу и таймаут требуют разной реакции: повторять имеет смысл второе, а первое надо показать вызывающей стороне с текстом из ответа.

Второе: не кэшируют разбор схем. Каждый запуск процесса тянет WSDL и импортированные XSD, старт растягивается, а при недоступности сервера с описанием сервис вообще не поднимается, хотя сам вызов ему сейчас не нужен.

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