Здесь проблема в том, что ваше понимание сути того, что необходимо сделать, расходится с реальным положением дел.
Скажем так: вам «подключение сервиса бронирования» кажется задачей на раз-два: есть некий WSDL у них, а у вас WordPress, – так что бы такое в WordPress включить, чтобы вся та информация с того сайта красиво отобразилась бы у вас на странице.
SOAP API – это интерфейс, позволяющий получать данные или их логические порции. Порядком вызова методов SOAP API, обработкой информации, построением логики вызовов и сборкой этих данных должны заниматься вы, а не WordPress – то есть необходимо написать некий серверный сценарий, который будет общаться с SOAP API, вызывая методы в нужном вам, и в какой-то мере определенной логикой сервиса, порядке.
Т.е. SOAP API не дает вам за один присест получить какой-то правильный набор
данных вместе с логикой – это интеракция, которая основана на сборе данных их формы, расположенной на вашем сайте, компоновке запроса в формате SOAP, получении данных в ответе, при необходимости, вызове следующего метода (или методов) SOAP API, обработке ответа, и подстановка структурированных данных из ответа в тот же самый HTML вашей страницы.
Допустим, ваш посетитель сайта хочет получить список свободных яхт, удовлетворяющих условиям (указанным им же в форме поиска на сайте) - клиент ищет яхту на Кипре, на 15-е июля, на 4-х человек, цена 500-800$, с рулевым, плюс какие-то дополнительные параметры. После нажатия символической кнопки «Искать» данные из формы передаются в некий серверный скрипт, в котором описана логика взаимодействия с SOAP API.
Далее будет приблизительное и возможное описание логики (за подробной в документацию) – как это может выглядеть.
Скрипт:- Берет параметры из формы
- Вызывает, к примеру, метод «getBases», передавая код страны аргументом
- Получает список портов
- Вызывает, к примеру, метод «getResources», передавая код порта (или коды портов) аргументом
- Получает список яхт
- Вызывает, к примеру, методы «isResourceAvailable» и «getReservations», передавая желаемые даты
- Получает ответы
- Отображает на странице
- Пользователь нажимает «Подробно» на конкретном варианте
- Скрипт вызывает, к примеру, методы «getResourceDetails», «getResourceDiscount» и «getActiveReservation»
- Отображает подробное описание яхты с параметрами скидок, графика, цены
- Пользователь нажимает «Заказать»
- Заполняет форму с данными пасажиров
- Скрипт заносит данные, вызывая методы «insertCrewMember» и «confirmReservation»
- Пользователь нажимает «Оплатить»
- Скрипт заносит данные, вызывая метод «insertPayment» и производит все, связанное с оплатой, вызывает «getInvoices» и отправляет его на почту пользователю.
Все выше – это приблизительный сценарий, само собой. Если вы внимательно посмотрите на доступные методы (они все описаны в документации), то вынесете идею из всего этого – методы представляют собой логически завершенные единицы получения/занесения информации. Это логические блоки, которые вы вызываете в том порядке, который подходит вашей логике – в этом смысл такого рода API: есть страна – смотрим, есть ли такая в базе, если есть страна в списке обслуживаемых – то какие порты, есть порты – то какие яхты есть вообще там, если есть яхты – то смотрим, удовлетворяют ли заданным пользователем характеристикам, отображаем на странице списком, пользователь выбирает детальную информацию – берем детальную, отображаем, пользователь начинает процесс – вызываем методы резервации и оплаты и т.д. Все зависит от вашей бизнес-логики. Да, конечно, могут быть у них и веб-сервисы, которые за раз (за один запрос) могут принимать на вход все параметры, указанные пользователем в форме (зависит от разработчика на стороне того сервиса яхт - но стоит помнить, что в программировании приветствуется принцип "один метод - одна задача") - страна, порт, количество людей, время, ценовой диапазон и пр., но это опять же не меняет суть - поиск осуществляться будет посредством вызова одного метода, резервация - вызовом другого, оплата - вызовом третьего и т.д.
Так что здесь нет какой-то простой интеграции API с WordPress - чтобы «одним нажатием» бизнес-логику наворотить. Это не только вёрстка, а программная логика многошаговой интеракции с пользователем плюс отображение на странице.
Ну а сам XML-SOAP запрос-ответ выглядит такЗапрос:POST /cbm_web_service2/services/CBM HTTP/1.1
Accept-Encoding: gzip,deflate
Content-Type: text/xml;charset=UTF-8
SOAPAction: ""
Content-Length: 352
Host: www.booking-manager.com
Connection: Keep-Alive
User-Agent: Apache-HttpClient/4.1.1 (java 1.5)
<soapenv:Envelope xmlns:soapenv="http://schemas.xmlsoap.org/soap/envelope/"
xmlns:cbm="http://cbm.mmk.com">
<soapenv:Header/>
<soapenv:Body>
<cbm:getCompanies>
<cbm:in0>1000</cbm:in0>
<cbm:in1>username</cbm:in1>
<cbm:in2>password</cbm:in2>
</cbm:getCompanies>
</soapenv:Body>
</soapenv:Envelope>
Ответ (здесь код 500, так как у меня же нет реальных username/password - но это не суть важно)HTTP/1.1 500 Internal Server Error
Date: Mon, 01 Jul 2019 06:58:23 GMT
Server: Apache/2.4.25 (Debian)
Content-Type: text/xml;charset=UTF-8
Connection: close
Transfer-Encoding: chunked
<soap:Envelope xmlns:soap="http://schemas.xmlsoap.org/soap/envelope/"
xmlns:xsd="http://www.w3.org/2001/XMLSchema"
xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance">
<soap:Body>
<soap:Fault>
<faultcode>soap:Server</faultcode>
<faultstring>XML disabled for company 1000</faultstring>
<detail>
<errorcode>-1</errorcode>
<errormessage>XML disabled for company 1000</errormessage>
</detail>
</soap:Fault>
</soap:Body>
</soap:Envelope>
