Код ошибки soap server

Проблемы

Если вы посещаете на корпоративном портале такие страницы, связанные с проектом, такие как ввод времени, запись расходов, веб-часть Communicator, аналитик проекта и руководитель проекта, вы получаете сообщение об ошибке, которое напоминает один из указанных ниже вариантов.

Сообщение об ошибке 1:

Ошибка: вложение: превышено максимальное число повторных попыток соединения. HRESULT = 0x80004005: Неопределенная ошибка — клиент: произошла непредвиденная ошибка во время обработки этого запроса. HRESULT = 0x80004005: Неопределенная ошибка — клиент: Отправка сообщения SOAP завершилась сбоем или не удается распознать полученный ответ (HRESULT = 0x80004005) HRESULT = 0x80004005: Неуказанная ошибка FaultCode = клиент faultString = вложение: максимально допустимое число повторных попыток подключения истекло.

Дополнительные сведения можно найти в разрешениях 6, 7, 8 и 9.

Сообщение об ошибке 2:

Соединитель: истекло время ожидания подключения. HRESULT = 0x800A1527-Client: в ходе обработки запроса возникла непредвиденная ошибка. HRESULT = 0x800A1527-клиент: не удалось отправить сообщение SOAP или не удается распознать полученный ответ HRESULT = 0x800A1527-клиент: Неуказанная ошибка клиента.

Дополнительные сведения можно найти в разрешениях 6, 7, 8 и 9.

Сообщение об ошибке 3:

Соединитель: неверный сертификат. HRESULT = 0x800A1529-Client: в ходе обработки запроса возникла непредвиденная ошибка. HRESULT = 0x800A1529-клиент: не удалось отправить сообщение SOAP или не удается распознать полученный ответ HRESULT = 0x800A1529-клиент: Неуказанная ошибка клиента. HRESULT=0x800A1529

Ознакомьтесь с разрешениями 6 и 9

Сообщение об ошибке 4:

Соединитель: Неуказанная ошибка HTTP. HRESULT = 0x800A1518-Client: в ходе обработки запроса возникла непредвиденная ошибка. HRESULT = 0x800A1518-клиент: не удалось отправить сообщение SOAP или не удается распознать полученный ответ HRESULT = 0x800A1518-клиент: Неуказанная ошибка клиента. HRESULT=0x800A1518

Дополнительные сведения можно найти в разрешениях 6, 7, 8 и 9.

Сообщение об ошибке 5:

Сбой подключения.: в соединителе не включена совпадающая схема авторизации. HRESULT = 0x80004005: Неопределенная ошибка — клиент: произошла непредвиденная ошибка во время обработки этого запроса. HRESULT = 0x80004005: Неопределенная ошибка — клиент: Отправка сообщения SOAP завершилась сбоем или не удается распознать полученный ответ (HRESULT = 0x80004005) HRESULT = 0x80004005: Неопределенная ошибка

Дополнительные сведения о разрешениях 7 и 9

Сообщение об ошибке 6:

Клиент: не удалось загрузить запрос в SoapReader. HRESULT = 0x80070057: неверный параметр. -Клиент: ошибка «неопределенный клиент». HRESULT = 0x80070057: неверный параметр. FaultCode = Client.

Дополнительные сведения можно найти в разрешениях 6, 7, 8 и 9.

Сообщение об ошибке 7:

Приложению не удается открыть системную базу данных. [DBNETLIB] [ConnectionOpen (соединение ()).] SQL Server не существует или в доступе отказано.Чтобы устранить эту проблему, системный администратор должен запустить pcConfiguration на сервере бизнес-портала.

Дополнительные сведения о разрешениях 5 и 9

Сообщение об ошибке 8:

Произошла ошибка. Ошибка: произошла ошибка при попытке открыть системную базу данных. (pcconnect)

Дополнительные сведения о разрешениях 1, 2, 3, 4 и 9

Сообщение об ошибке 9:

Приложение не может считать сведения о подключении к Соломоновы. Чтобы устранить эту проблему, системный администратор должен запустить pcConfiguration на сервере бизнес-портала.

Дополнительные сведения о разрешениях 1, 2, 3, 4 и 9

Сообщение об ошибке 10:

Не удается подключиться к системной базе данных. Запустите PCConfiguration. Недопустимые имя пользователя и пароль.

Дополнительные сведения о разрешениях 4 и 9

Сообщение об ошибке 11:

Ошибка: Клиент SOAP: при обработке запроса SOAP произошла ошибка. Недопустимый путь к PCService. asmx, указанному в ProjectService. wsdlYour. чтобы устранить эту проблему, запустите системный администратор pcConfiguration-Update на сервере бизнес-портала.

Ознакомьтесь с разрешениями 6 и 9

Причина

Для того чтобы страницы проекта были доступны, службы IIS должны иметь возможность подготовить и отправить запрос протокола SOAP в файл PCService. asmx.  Для работы необходимо настроить несколько вещей.  Если один или несколько из указанных ниже параметров заданы неправильно, это может привести к ошибкам, перечисленным в разделе «проблема».

1. Данные для входа в базу данных Microsoft Dynamics SL отсутствуют или неправильно хранятся в реестре.

2. Приложение Microsoft. Соломоновы. PMA. Security. ImpersonateDLL. dll отсутствует, не зарегистрировано или у пользователей нет разрешений на доступ к файлу.

3. Учетная запись в пуле приложений не имеет разрешений на доступ к разделу реестра HKEY_LOCAL_MACHINE SOFTWAREMicrosoftBusiness PortalPMASolomon

4. Файл CAPICOM. dll отсутствует, не зарегистрирован, имеет неверную версию или у пользователей нет разрешений на доступ к файлу.

5. Сервер, на котором запущены службы IIS и SQL Server, должен поддерживать связь с помощью протокола TCP/IP.

6. Путь к файлу PCService. ASX в файле ProjectService. WSDL указан неправильно

   1. Путь должен указывать на имя сервера IIS

   2. Путь должен содержать номер порта

   3. Путь должен быть URL-адресом, который не является SSL

   4. При использовании заголовков узлов IIS путь должен разрешаться на соответствующий веб-сайт.

7. Сайт IIS не использует проверку подлинности Windows (NTLM)

8. Переменная SessionState в файле Web. config задана неправильно

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

Решение

Разрешение 1- Запуск служебной программы PCConfiguration

1. Откройте файл PCConfiguration. exe на сервере бизнес-портала и дважды щелкните его, чтобы выполнить.  Обычно это расположение находится в папке c:Inetpubwwwrootbin или в папке C:InetpubwwwrootwssVirtualDirectories80bin.

2. Заполните следующие поля:

   1. Имя сервера SQL Server: введите имя сервера SQL Server, на котором размещаются базы данных Microsoft Dynamics SL.

   2. Системная БД — введите имя базы данных системы Microsoft Dynamics SL.

   3. Пользователь SQL: введите имя пользователя SQL, у которого есть доступ к системной базе данных.  «SA» или «BusinessPortalUser» — распространенные параметры.

   4. Password (пароль): введите пароль пользователя, введенного в поле пользователя SQL

3. Нажмите кнопку проверить соединение.  Если появляется сообщение об ошибке, проверьте значения на этапе 2. Примечание. Эта кнопка может не выполнить действие из-за ошибки 55474.

4. Нажмите кнопку обновить реестр.  Появится следующее сообщение: «данные успешно записаны в реестр».

5. Закройте служебную программу и попробуйте еще раз.

Разрешение 2 — проверка файла Microsoft. Соломоновы. PMA. Security. ImpersonateDLL. dll

1. На сервере бизнес-портала запустите диспетчер информационных служб Интернета (IIS).

2. Щелкните правой кнопкой мыши веб-сайт бизнес-портала и выберите пункт «Свойства»

3. На вкладке домашний каталог запишите значение в поле «локальный путь».

4. На вкладке «домашний каталог» Обратите внимание на значение в поле со списком «Группа приложений».

5. Нажмите кнопку ОК, чтобы закрыть окно «Свойства».

6. В диспетчере IIS разверните элемент «пулы приложений».  Щелкните правой кнопкой мыши группу приложений, найденную на шаге 4, и выберите пункт «Свойства».

7. На вкладке «удостоверение» Обратите внимание на пользователя, указанного в качестве удостоверения пула приложений.

8. Нажмите кнопку ОК, чтобы закрыть окно «Свойства».

9. Закрытие диспетчера IIS

10. В проводнике Windows перейдите к каталогу, найденному на шаге 3.

11. Прокрутите папку bin вниз и найдите файл Microsoft. Соломоновы. PMA. Security. ImpersonateDLL. dll.

    1. Если этот файл отсутствует, может потребоваться переустановка бизнес-портала

12. Щелкните файл правой кнопкой мыши и выберите пункт Свойства.

13. На вкладке «безопасность» убедитесь в том, что у пользователя на шаге 7 есть права «чтение» и «чтение & выполнения»

14. Нажмите кнопку ОК, чтобы закрыть окно «Свойства».

15. Щелкните файл правой кнопкой мыши и выберите команду «Открыть с помощью…»

16. Выберите «выбрать программу из списка»

17. Нажмите кнопку «Обзор…»

18. Перейдите в папку C:WindowsSystem32 и найдите файл regsvr32. exe и нажмите кнопку «Открыть».

19. Нажмите кнопку ОК.  Появится следующее сообщение: «DllRegisterServer в C:InetpubwwwrootbinMicrosoft.Solomon.Pma.Security.ImpersonateDLL.dll успешно».

20. Попробуйте еще раз загрузить страницы рабочего портала

Разрешение 3 : Проверка раздела реестра

1. На сервере бизнес-портала запустите диспетчер информационных служб Интернета (IIS).

2. Щелкните правой кнопкой мыши веб-сайт бизнес-портала и выберите пункт Свойства.

3. На вкладке «домашний каталог» Обратите внимание на значение в поле со списком «пул приложений».

4. Нажмите кнопку ОК, чтобы закрыть диалоговое окно «Свойства» и выйти из диспетчера IIS

5. Выберите Пуск-> выполнить и введите RegEdt32.  В этом случае следует открыть редактор реестра.

6. Перейдите на HKEY_LOCAL_MACHINE SOFTWAREMicrosoftBusiness PortalPMASolomon

   1. Если этот раздел реестра отсутствует, ознакомьтесь с разделом разрешение 1, чтобы запустить служебную программу PCConfiguration

7. Щелкните правой кнопкой мыши «Соломоновы» и выберите «разрешения»

8. Убедитесь в том, что пользователь из этапа 3 имеет разрешения «чтение»

9. Попробуйте еще раз загрузить страницы рабочего портала

Более подробную информацию вы видите в статье базы знаний 912363 .

Разрешение 4 : Проверка файла CAPICOM. dll

1. Перейдите в папку C:WindowsSystem32 на сервере бизнес-портала.

2. Щелкните правой кнопкой мыши элемент CAPICOM. Файл DLL и выберите пункт «Свойства»

   1. Если этот файл отсутствует, возможно, потребуется скопировать файл с другой рабочей станции или переустановить бизнес-портал.

3. На вкладке Версия убедитесь в том, что в версии файла отображается 2.1.0.1

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

4. На вкладке Безопасность Убедитесь, что в группе доменные службы есть разрешение чтение и чтение & выполнение прав на этот файл.  Ознакомьтесь состатьей базы знаний 927618

5. Нажмите кнопку ОК, чтобы закрыть диалоговое окно «Свойства».

6. Щелкните файл правой кнопкой мыши и выберите команду «Открыть с помощью…»

7. Выберите «выбрать программу из списка»

8. Нажмите кнопку «Обзор…»

9. Перейдите в папку C:WindowsSystem32 и найдите файл regsvr32. exe и нажмите кнопку Открыть.

10. Нажмите кнопку ОК.  Появится следующее сообщение: «DllRegisterServer в C:WINDOWSsystem32capicom.dll успешно».

11. Попробуйте еще раз загрузить страницы рабочего портала

12. Если вы по-прежнему получаете сообщение об ошибке:

    1. Чтобы снова запустить служебную программу PCConfiguration, ознакомьтесь с разрешениями 1.

    2. Перезапустите IIS, нажав Пуск-> выполнить и введите «IISReset».

    3. Попробуйте еще раз загрузить страницы рабочего портала

Более подробную информацию вы видите в статье базы знаний 909144 .

Разрешение 5 – Проверка возможности связи сервера IIS и сервера SQL Server с помощью протокола TCP/IP

1. Протокол TCP/IP должен быть включен как на сервере SQL Server, так и на сервере IIS, на котором размещаются сайты бизнес-портала.

2. Сведения о том, как это проверить, можно найти в статье база знаний 954024

Разрешение 6 : Проверьте путь к файлу PCService. ASX в файле ProjectService. WSDL

1. На сервере бизнес-портала откройте файл ProjectService. WSDL.  Обычно это расположение находится в каталоге C:Program FilesMicrosoft DynamicsBusiness PortalApplicationsPMA.

2. Открытие файла в блокноте

3. Прокрутите файл вниз и найдите тег, который начинается со слова «<SOAP: Address Location =»

4. В этом теге должен быть указан URL-адрес для файла PCService. asmx.  Он должен выглядеть примерно так: «HTTP://MachineName: 80/BUSINESSPORTAL/PMA/PCService. asmx» у этого URL-адреса есть несколько конкретных требований.  Проверьте и, при необходимости, исправьте указанные ниже элементы.

   1. URL-адрес должен указывать имя компьютера (например, BPSERVER).  IP-адреса (например, 192.168.0.10), localhost или Domain Name (например, BP.contoso.com) не будут работать для запросов SOAP.

      1. Чтобы найти имя компьютера, нажмите Пуск-> выполнить и введите CMD.

      2. Введите имя узла и нажмите клавишу ВВОД

      3. Должно быть возвращено имя компьютера.  Параметр MachineName в URL-адресе должен соответствовать этому значению.

   2. URL-адрес не должен использовать SSL.  URL-адрес должен начинаться с «http://», а не «https://»

      1. Если на вашем веб-сайте настроено использование SSL, ознакомьтесь со статьей база знаний 924723 , в которой вы узнаете, как настроить исключение, разрешающее подключение к файлу PCService. asmx без SSL.

   3. URL-адрес должен быть разрешаемым на сайте BusinessPortal в службах IIS.

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

      2. Более подробную информацию вы видите в статье базы знаний 2005711 .

5. Протестируйте URL-адрес, чтобы убедиться, что он является допустимым.  Для этого скопируйте URL-адрес и вставьте его в Internet Explorer на сервере бизнес-портала.  Он должен открыть страницу под названием «PCServices».  Если вместо этого вы получаете сообщение об ошибке SharePoint или появляется сообщение об ошибке «не удается отобразить страницу», проверьте элементы на шаге 4.

6. Теперь, когда у файла ProjectService. WSDL есть допустимый URL-адрес, попробуйте еще раз попробовать на странице бизнес-портала

Дополнительные сведения приведены в статье база знаний 892356 или статья базы знаний 897024 .

Разрешение 7 : Проверка способа проверки подлинности в IIS

1. На сервере бизнес-портала запустите диспетчер информационных служб Интернета (IIS).

2. Щелкните правой кнопкой мыши веб-сайт бизнес-портала и выберите пункт Свойства.

3. На вкладке Безопасность каталога в разделе «Управление доступом и проверка подлинности» выберите команду Изменить…

4. Убедитесь, что установлен флажок Встроенная проверка подлинности Windows.

5. Убедитесь, что флажок «разрешить анонимный доступ», «Краткая проверка подлинности для серверов домена Windows» и «Проверка подлинности .NET Passport» не установлены.

6. Проверка подлинности Basic не требуется. Тем не менее, если флажок установлен, это не должно приводить к проблеме.

7. Нажмите кнопку ОК, а затем еще раз нажмите кнопку ОК, чтобы закрыть диалоговое окно «Свойства».

8. Закрытие диспетчера IIS

9. Перезапустите IIS, нажав Пуск-> выполнить и введите «IISReset».

10. Попробуйте еще раз на странице бизнес-портала

Разрешение 8 : проверка переменной sessionState в файле Web. config

1. На сервере бизнес-портала запустите диспетчер информационных служб Интернета (IIS).

2. Щелкните правой кнопкой мыши веб-сайт бизнес-портала и выберите пункт Свойства.

3. На вкладке «домашний каталог» Обратите внимание на значение в поле «локальный путь».

4. Нажмите кнопку ОК, чтобы закрыть диалоговое окно «Свойства» и выйти из диспетчера IIS

5. Перейдите к каталогу, найденному на шаге 3, и найдите файл Web. config.

6. Создание резервной копии файла Web. config

7. Откройте файл web.config в блокноте.

8. Поиск тега, который начинается с «<sessionState»

9. Изменение всего тега для чтения «<sessionState =» INPROC «/>»

10. Сохранение файла и закрытие блокнота

11. Перезапустите IIS, нажав Пуск-> выполнить и введите «IISReset».

12. Попробуйте еще раз загрузить страницы рабочего портала

 Разрешение 9 : запустите сценарий PCConnectDebug и отправьте результаты в службу поддержки. 

1. Скачать B2004933_pcConnectDebug. zip

2. Распаковка файла на сервере бизнес-портала

3. Скопируйте файл «pcConnectDebug. ASP» в каталог C:Program FilesMicrosoft DynamicsBusiness PortalApplicationsPMA.

4. На сервере бизнес-портала откройте Internet Explorer и войдите в бизнес-портал.

5. Щелкните веб-страницу центра проектов

6. Вставьте следующий URL-адрес, чтобы открыть страницу PCConnectDebug: http://ServerName:Port/BusinessPortal/Applications/PMA/pcconnectdebug.ASP замените значение serverName именем сервера BP.  Замените «порт» на номер порта, на котором работает веб-сайт BP.

7. Вам будет предложено «нажмите ОК», чтобы продолжить.  Нажмите кнопку ОК.

8. Откроется веб-страница, которая начинается с «Запуск отладки…».   В Internet Explorer щелкните файл-> сохранить как… и сохраните страницу в файле.

   1. Внимание!в зависимости от того, насколько далеко может быть предоставлена Отладка, результаты могут содержать пароль в открытом тексте.  Вы можете изменить файл в блокноте и заменить Фактический пароль на слово «thePassword» перед отправкой файла для поддержки.

9. Отправьте этот файл службе поддержки пользователей Майкрософт для дальнейшего анализа.

10. После устранения проблемы удалите файл pcConnectDebug. ASP из каталога C:Program FilesMicrosoft DynamicsBusiness PortalApplicationsPMA.

SOAP — Fault

Testing using SOAP UI

8 Lectures 4 hours

Soap UI: The Beginners Course

18 Lectures 47 mins

Soap UI: The Videocourse

18 Lectures 52 mins

If an error occurs during processing, the response to a SOAP message is a SOAP fault element in the body of the message, and the fault is returned to the sender of the SOAP message.

The SOAP fault mechanism returns specific information about the error, including a predefined code, a description, and the address of the SOAP processor that generated the fault.

Points to Note

A SOAP message can carry only one fault block.

Fault is an optional part of a SOAP message.

For HTTP binding, a successful response is linked to the 200 to 299 range of status codes.

SOAP Fault is linked to the 500 to 599 range of status codes.

Sub-elements of Fault

The SOAP Fault has the following sub elements −

It is a text code used to indicate a class of errors. See the next Table for a listing of predefined fault codes.

It is a text message explaining the error.

It is a text string indicating who caused the fault. It is useful if the SOAP message travels through several nodes in the SOAP message path, and the client needs to know which node caused the error. A node that does not act as the ultimate destination must include a faultActor element.

It is an element used to carry application-specific error messages. The detail element can contain child elements called detail entries.

SOAP Fault Codes

The faultCode values defined below must be used in the faultcode element while describing faults.

Sr.No	Sub-element & Description
1

Found an invalid namespace for the SOAP Envelope element.

An immediate child element of the Header element, with the mustUnderstand attribute set to «1», was not understood.

The message was incorrectly formed or contained incorrect information.

There was a problem with the server, so the message could not proceed.

SOAP Fault Example

The following code is a sample Fault. The client has requested a method named ValidateCreditCard, but the service does not support such a method. This represents a client request error, and the server returns the following SOAP response −

Источник

Simple Object Access Protocol (SOAP) 1.1

W3C Note 08 May 2000

Abstract

SOAP is a lightweight protocol for exchange of information in a decentralized, distributed environment. It is an XML based protocol that consists of three parts: an envelope that defines a framework for describing what is in a message and how to process it, a set of encoding rules for expressing instances of application-defined datatypes, and a convention for representing remote procedure calls and responses. SOAP can potentially be used in combination with a variety of other protocols; however, the only bindings defined in this document describe how to use SOAP in combination with HTTP and HTTP Extension Framework.

Status

This document is a submission to the World Wide Web Consortium (see Submission Request, W3C Staff Comment) to propose the formation of a working group in the area of XML-based protocols. Comments are welcome to the authors but you are encouraged to share your views on the W3C’s public mailing list (see archives).

This document is a NOTE made available by the W3C for discussion only. Publication of this Note by W3C indicates no endorsement by W3C or the W3C Team, or any W3C Members. W3C has had no editorial control over the preparation of this Note. This document is a work in progress and may be updated, replaced, or rendered obsolete by other documents at any time.

A list of current W3C technical documents can be found at the Technical Reports page.

Table of Contents

1. Introduction

SOAP provides a simple and lightweight mechanism for exchanging structured and typed information between peers in a decentralized, distributed environment using XML. SOAP does not itself define any application semantics such as a programming model or implementation specific semantics; rather it defines a simple mechanism for expressing application semantics by providing a modular packaging model and encoding mechanisms for encoding data within modules. This allows SOAP to be used in a large variety of systems ranging from messaging systems to RPC.

SOAP consists of three parts:

• The SOAP envelope (see section 4) construct defines an overall framework for expressing what is in a message; who should deal with it, and whether it is optional or mandatory.
• The SOAP encoding rules (see section 5) defines a serialization mechanism that can be used to exchange instances of application-defined datatypes.
• The SOAP RPC representation (see section 7) defines a convention that can be used to represent remote procedure calls and responses.

Although these parts are described together as part of SOAP, they are functionally orthogonal. In particular, the envelope and the encoding rules are defined in different namespaces in order to promote simplicity through modularity.

In addition to the SOAP envelope, the SOAP encoding rules and the SOAP RPC conventions, this specification defines two protocol bindings that describe how a SOAP message can be carried in HTTP [5] messages either with or without the HTTP Extension Framework [6].

1.1 Design Goals

A major design goal for SOAP is simplicity and extensibility. This means that there are several features from traditional messaging systems and distributed object systems that are not part of the core SOAP specification. Such features include

• Distributed garbage collection
• Boxcarring or batching of messages
• Objects-by-reference (which requires distributed garbage collection)
• Activation (which requires objects-by-reference)

1.2 Notational Conventions

The keywords «MUST», «MUST NOT», «REQUIRED», «SHALL», «SHALL NOT», «SHOULD», «SHOULD NOT», «RECOMMENDED», «MAY», and «OPTIONAL» in this document are to be interpreted as described in RFC-2119 [2].

The namespace prefixes «SOAP-ENV» and «SOAP-ENC» used in this document are associated with the SOAP namespaces «http://schemas.xmlsoap.org/soap/envelope/» and «http://schemas.xmlsoap.org/soap/encoding/» respectively.

Throughout this document, the namespace prefix «xsi» is assumed to be associated with the URI «http://www.w3.org/1999/XMLSchema-instance» which is defined in the XML Schemas specification [11]. Similarly, the namespace prefix «xsd» is assumed to be associated with the URI «http://www.w3.org/1999/XMLSchema» which is defined in [10]. The namespace prefix «tns» is used to indicate whatever is the target namespace of the current document. All other namespace prefixes are samples only.

Namespace URIs of the general form «some-URI» represent some application-dependent or context-dependent URI [4].

This specification uses the augmented Backus-Naur Form (BNF) as described in RFC-2616 [5] for certain constructs.

1.3 Examples of SOAP Messages

In this example, a GetLastTradePrice SOAP request is sent to a StockQuote service. The request takes a string parameter, ticker symbol, and returns a float in the SOAP response. The SOAP Envelope element is the top element of the XML document representing the SOAP message. XML namespaces are used to disambiguate SOAP identifiers from application specific identifiers. The example illustrates the HTTP bindings defined in section 6. It is worth noting that the rules governing XML payload format in SOAP are entirely independent of the fact that the payload is carried in HTTP.

More examples are available in Appendix A.

Example 1 SOAP Message Embedded in HTTP Request

POST /StockQuote HTTP/1.1
Host: www.stockquoteserver.com
Content-Type: text/xml; charset=»utf-8″
Content-Length: nnnn
SOAPAction: «Some-URI»

Following is the response message containing the HTTP message with the SOAP message as the payload:

Example 2 SOAP Message Embedded in HTTP Response

HTTP/1.1 200 OK
Content-Type: text/xml; charset=»utf-8″
Content-Length: nnnn

2. The SOAP Message Exchange Model

SOAP messages are fundamentally one-way transmissions from a sender to a receiver, but as illustrated above, SOAP messages are often combined to implement patterns such as request/response.

SOAP implementations can be optimized to exploit the unique characteristics of particular network systems. For example, the HTTP binding described in section 6 provides for SOAP response messages to be delivered as HTTP responses, using the same connection as the inbound request.

Regardless of the protocol to which SOAP is bound, messages are routed along a so-called «message path», which allows for processing at one or more intermediate nodes in addition to the ultimate destination.

A SOAP application receiving a SOAP message MUST process that message by performing the following actions in the order listed below:

1. Identify all parts of the SOAP message intended for that application (see section 4.2.2)
2. Verify that all mandatory parts identified in step 1 are supported by the application for this message (see section 4.2.3) and process them accordingly. If this is not the case then discard the message (see section 4.4). The processor MAY ignore optional parts identified in step 1 without affecting the outcome of the processing.
3. If the SOAP application is not the ultimate destination of the message then remove all parts identified in step 1 before forwarding the message.

Processing a message or a part of a message requires that the SOAP processor understands, among other things, the exchange pattern being used (one way, request/response, multicast, etc.), the role of the recipient in that pattern, the employment (if any) of RPC mechanisms such as the one documented in section 7, the representation or encoding of data, as well as other semantics necessary for correct processing.

While attributes such as the SOAP encodingStyle attribute (see section 4.1.1) can be used to describe certain aspects of a message, this specification does not mandate a particular means by which the recipient makes such determinations in general. For example, certain applications will understand that a particular element signals an RPC request using the conventions of section 7, while another application may infer that all traffic directed to it is encoded as one way messages.

3. Relation to XML

All SOAP messages are encoded using XML (see [7] for more information on XML).

A SOAP application SHOULD include the proper SOAP namespace on all elements and attributes defined by SOAP in messages that it generates. A SOAP application MUST be able to process SOAP namespaces in messages that it receives. It MUST discard messages that have incorrect namespaces (see section 4.4) and it MAY process SOAP messages without SOAP namespaces as though they had the correct SOAP namespaces.

SOAP defines two namespaces (see [8] for more information on XML namespaces):

A SOAP message MUST NOT contain a Document Type Declaration. A SOAP message MUST NOT contain Processing Instructions. [7]

SOAP uses the local, unqualified «id» attribute of type «ID» to specify the unique identifier of an encoded element. SOAP uses the local, unqualified attribute «href» of type «uri-reference» to specify a reference to that value, in a manner conforming to the XML Specification [7], XML Schema Specification [11], and XML Linking Language Specification [9].

With the exception of the SOAP mustUnderstand attribute (see section 4.2.3) and the SOAP actor attribute (see section 4.2.2), it is generally permissible to have attributes and their values appear in XML instances or alternatively in schemas, with equal effect. That is, declaration in a DTD or schema with a default or fixed value is semantically equivalent to appearance in an instance.

4. SOAP Envelope

A SOAP message is an XML document that consists of a mandatory SOAP envelope, an optional SOAP header, and a mandatory SOAP body. This XML document is referred to as a SOAP message for the rest of this specification. The namespace identifier for the elements and attributes defined in this section is «http://schemas.xmlsoap.org/soap/envelope/». A SOAP message contains the following:

• The Envelope is the top element of the XML document representing the message.
• The Header is a generic mechanism for adding features to a SOAP message in a decentralized manner without prior agreement between the communicating parties. SOAP defines a few attributes that can be used to indicate who should deal with a feature and whether it is optional or mandatory (see section 4.2)
• The Body is a container for mandatory information intended for the ultimate recipient of the message (see section 4.3). SOAP defines one element for the body, which is the Fault element used for reporting errors.

The grammar rules are as follows:

1. Envelope
   • The element name is «Envelope».
   • The element MUST be present in a SOAP message
   • The element MAY contain namespace declarations as well as additional attributes. If present, such additional attributes MUST be namespace-qualified. Similarly, the element MAY contain additional sub elements. If present these elements MUST be namespace-qualified and MUST follow the SOAP Body element.
2. Header (see section 4.2)
   • The element name is «Header».
   • The element MAY be present in a SOAP message. If present, the element MUST be the first immediate child element of a SOAP Envelope element.
   • The element MAY contain a set of header entries each being an immediate child element of the SOAP Header element. All immediate child elements of the SOAP Header element MUST be namespace-qualified.
3. Body (see section 4.3)
   • The element name is «Body».
   • The element MUST be present in a SOAP message and MUST be an immediate child element of a SOAP Envelope element. It MUST directly follow the SOAP Header element if present. Otherwise it MUST be the first immediate child element of the SOAP Envelope element.
   • The element MAY contain a set of body entries each being an immediate child element of the SOAP Body element. Immediate child elements of the SOAP Body element MAY be namespace-qualified. SOAP defines the SOAP Fault element, which is used to indicate error messages (see section 4.4).

4.1.1 SOAP encodingStyle Attribute

The SOAP encodingStyle global attribute can be used to indicate the serialization rules used in a SOAP message. This attribute MAY appear on any element, and is scoped to that element’s contents and all child elements not themselves containing such an attribute, much as an XML namespace declaration is scoped. There is no default encoding defined for a SOAP message.

The attribute value is an ordered list of one or more URIs identifying the serialization rule or rules that can be used to deserialize the SOAP message indicated in the order of most specific to least specific. Examples of values are

«http://schemas.xmlsoap.org/soap/encoding/»
«http://my.host/encoding/restricted http://my.host/encoding/»
«»

The serialization rules defined by SOAP in section 5 are identified by the URI «http://schemas.xmlsoap.org/soap/encoding/». Messages using this particular serialization SHOULD indicate this using the SOAP encodingStyle attribute. In addition, all URIs syntactically beginning with «http://schemas.xmlsoap.org/soap/encoding/» indicate conformance with the SOAP encoding rules defined in section 5 (though with potentially tighter rules added).

A value of the zero-length URI («») explicitly indicates that no claims are made for the encoding style of contained elements. This can be used to turn off any claims from containing elements.

4.1.2 Envelope Versioning Model

SOAP does not define a traditional versioning model based on major and minor version numbers. A SOAP message MUST have an Envelope element associated with the «http://schemas.xmlsoap.org/soap/envelope/» namespace. If a message is received by a SOAP application in which the SOAP Envelope element is associated with a different namespace, the application MUST treat this as a version error and discard the message. If the message is received through a request/response protocol such as HTTP, the application MUST respond with a SOAP VersionMismatch faultcode message (see section 4.4) using the SOAP «http://schemas.xmlsoap.org/soap/envelope/» namespace.

SOAP provides a flexible mechanism for extending a message in a decentralized and modular way without prior knowledge between the communicating parties. Typical examples of extensions that can be implemented as header entries are authentication, transaction management, payment etc.

The Header element is encoded as the first immediate child element of the SOAP Envelope XML element. All immediate child elements of the Header element are called header entries.

The encoding rules for header entries are as follows:

1. A header entry is identified by its fully qualified element name, which consists of the namespace URI and the local name. All immediate child elements of the SOAP Header element MUST be namespace-qualified.
2. The SOAP encodingStyle attribute MAY be used to indicate the encoding style used for the header entries (see section 4.1.1).
3. The SOAP mustUnderstand attribute (see section 4.2.3) and SOAP actor attribute (see section 4.2.2) MAY be used to indicate how to process the entry and by whom (see section 4.2.1).

The SOAP Header attributes defined in this section determine how a recipient of a SOAP message should process the message as described in section 2. A SOAP application generating a SOAP message SHOULD only use the SOAP Header attributes on immediate child elements of the SOAP Header element. The recipient of a SOAP message MUST ignore all SOAP Header attributes that are not applied to an immediate child element of the SOAP Header element.

An example is a header with an element identifier of «Transaction», a «mustUnderstand» value of «1», and a value of 5. This would be encoded as follows:

4.2.2 SOAP actor Attribute

A SOAP message travels from the originator to the ultimate destination, potentially by passing through a set of SOAP intermediaries along the message path. A SOAP intermediary is an application that is capable of both receiving and forwarding SOAP messages. Both intermediaries as well as the ultimate destination are identified by a URI.

Not all parts of a SOAP message may be intended for the ultimate destination of the SOAP message but, instead, may be intended for one or more of the intermediaries on the message path. The role of a recipient of a header element is similar to that of accepting a contract in that it cannot be extended beyond the recipient. That is, a recipient receiving a header element MUST NOT forward that header element to the next application in the SOAP message path. The recipient MAY insert a similar header element but in that case, the contract is between that application and the recipient of that header element.

The SOAP actor global attribute can be used to indicate the recipient of a header element. The value of the SOAP actor attribute is a URI. The special URI «http://schemas.xmlsoap.org/soap/actor/next» indicates that the header element is intended for the very first SOAP application that processes the message. This is similar to the hop-by-hop scope model represented by the Connection header field in HTTP.

Omitting the SOAP actor attribute indicates that the recipient is the ultimate destination of the SOAP message.

This attribute MUST appear in the SOAP message instance in order to be effective (see section 3 and 4.2.1).

4.2.3 SOAP mustUnderstand Attribute

The SOAP mustUnderstand global attribute can be used to indicate whether a header entry is mandatory or optional for the recipient to process. The recipient of a header entry is defined by the SOAP actor attribute (see section 4.2.2). The value of the mustUnderstand attribute is either «1» or «0». The absence of the SOAP mustUnderstand attribute is semantically equivalent to its presence with the value «0».

If a header element is tagged with a SOAP mustUnderstand attribute with a value of «1», the recipient of that header entry either MUST obey the semantics (as conveyed by the fully qualified name of the element) and process correctly to those semantics, or MUST fail processing the message (see section 4.4).

The SOAP mustUnderstand attribute allows for robust evolution. Elements tagged with the SOAP mustUnderstand attribute with a value of «1» MUST be presumed to somehow modify the semantics of their parent or peer elements. Tagging elements in this manner assures that this change in semantics will not be silently (and, presumably, erroneously) ignored by those who may not fully understand it.

This attribute MUST appear in the instance in order to be effective (see section 3 and 4.2.1).

4.3 SOAP Body

The SOAP Body element provides a simple mechanism for exchanging mandatory information intended for the ultimate recipient of the message. Typical uses of the Body element include marshalling RPC calls and error reporting.

The Body element is encoded as an immediate child element of the SOAP Envelope XML element. If a Header element is present then the Body element MUST immediately follow the Header element, otherwise it MUST be the first immediate child element of the Envelope element.

All immediate child elements of the Body element are called body entries and each body entry is encoded as an independent element within the SOAP Body element.

The encoding rules for body entries are as follows:

1. A body entry is identified by its fully qualified element name, which consists of the namespace URI and the local name. Immediate child elements of the SOAP Body element MAY be namespace-qualified.
2. The SOAP encodingStyle attribute MAY be used to indicate the encoding style used for the body entries (see section 4.1.1).

SOAP defines one body entry, which is the Fault entry used for reporting errors (see section 4.4).

4.3.1 Relationship between SOAP Header and Body

While the Header and Body are defined as independent elements, they are in fact related. The relationship between a body entry and a header entry is as follows: A body entry is semantically equivalent to a header entry intended for the default actor and with a SOAP mustUnderstand attribute with a value of «1». The default actor is indicated by not using the actor attribute (see section 4.2.2).

4.4 SOAP Fault

The SOAP Fault element is used to carry error and/or status information within a SOAP message. If present, the SOAP Fault element MUST appear as a body entry and MUST NOT appear more than once within a Body element.

The SOAP Fault element defines the following four subelements:

faultcode The faultcode element is intended for use by software to provide an algorithmic mechanism for identifying the fault. The faultcode MUST be present in a SOAP Fault element and the faultcode value MUST be a qualified name as defined in [8], section 3. SOAP defines a small set of SOAP fault codes covering basic SOAP faults (see section 4.4.1) faultstring The faultstring element is intended to provide a human readable explanation of the fault and is not intended for algorithmic processing. The faultstring element is similar to the ‘Reason-Phrase’ defined by HTTP (see [5], section 6.1). It MUST be present in a SOAP Fault element and SHOULD provide at least some information explaining the nature of the fault. faultactor The faultactor element is intended to provide information about who caused the fault to happen within the message path (see section 2). It is similar to the SOAP actor attribute (see section 4.2.2) but instead of indicating the destination of the header entry, it indicates the source of the fault. The value of the faultactor attribute is a URI identifying the source. Applications that do not act as the ultimate destination of the SOAP message MUST include the faultactor element in a SOAP Fault element. The ultimate destination of a message MAY use the faultactor element to indicate explicitly that it generated the fault (see also the detail element below). detail The detail element is intended for carrying application specific error information related to the Body element. It MUST be present if the contents of the Body element could not be successfully processed. It MUST NOT be used to carry information about error information belonging to header entries. Detailed error information belonging to header entries MUST be carried within header entries.

The absence of the detail element in the Fault element indicates that the fault is not related to processing of the Body element. This can be used to distinguish whether the Body element was processed or not in case of a fault situation.

All immediate child elements of the detail element are called detail entries and each detail entry is encoded as an independent element within the detail element.

The encoding rules for detail entries are as follows (see also example 10):

1. A detail entry is identified by its fully qualified element name, which consists of the namespace URI and the local name. Immediate child elements of the detail element MAY be namespace-qualified.
2. The SOAP encodingStyle attribute MAY be used to indicate the encoding style used for the detail entries (see section 4.1.1).

Other Fault subelements MAY be present, provided they are namespace-qualified.

4.4.1 SOAP Fault Codes

The faultcode values defined in this section MUST be used in the faultcode element when describing faults defined by this specification. The namespace identifier for these faultcode values is «http://schemas.xmlsoap.org/soap/envelope/». Use of this space is recommended (but not required) in the specification of methods defined outside of the present specification.

The default SOAP faultcode values are defined in an extensible manner that allows for new SOAP faultcode values to be defined while maintaining backwards compatibility with existing faultcode values. The mechanism used is very similar to the 1xx, 2xx, 3xx etc basic status classes classes defined in HTTP (see [5] section 10). However, instead of integers, they are defined as XML qualified names (see [8] section 3). The character «.» (dot) is used as a separator of faultcode values indicating that what is to the left of the dot is a more generic fault code value than the value to the right. Example

The set of faultcode values defined in this document is:

The processing party found an invalid namespace for the SOAP Envelope element (see section 4.1.2)

An immediate child element of the SOAP Header element that was either not understood or not obeyed by the processing party contained a SOAP mustUnderstand attribute with a value of «1» (see section 4.2.3)

The Client class of errors indicate that the message was incorrectly formed or did not contain the appropriate information in order to succeed. For example, the message could lack the proper authentication or payment information. It is generally an indication that the message should not be resent without change. See also section 4.4 for a description of the SOAP Fault detail sub-element.

The Server class of errors indicate that the message could not be processed for reasons not directly attributable to the contents of the message itself but rather to the processing of the message. For example, processing could include communicating with an upstream processor, which didn’t respond. The message may succeed at a later point in time. See also section 4.4 for a description of the SOAP Fault detail sub-element.

5. SOAP Encoding

The SOAP encoding style is based on a simple type system that is a generalization of the common features found in type systems in programming languages, databases and semi-structured data. A type either is a simple (scalar) type or is a compound type constructed as a composite of several parts, each with a type. This is described in more detail below. This section defines rules for serialization of a graph of typed objects. It operates on two levels. First, given a schema in any notation consistent with the type system described, a schema for an XML grammar may be constructed. Second, given a type-system schema and a particular graph of values conforming to that schema, an XML instance may be constructed. In reverse, given an XML instance produced in accordance with these rules, and given also the original schema, a copy of the original value graph may be constructed.

The namespace identifier for the elements and attributes defined in this section is «http://schemas.xmlsoap.org/soap/encoding/». The encoding samples shown assume all namespace declarations are at a higher element level.

Use of the data model and encoding style described in this section is encouraged but not required; other data models and encodings can be used in conjunction with SOAP (see section 4.1.1).

5.1 Rules for Encoding Types in XML

XML allows very flexible encoding of data. SOAP defines a narrower set of rules for encoding. This section defines the encoding rules at a high level, and the next section describes the encoding rules for specific types when they require more detail. The encodings described in this section can be used in conjunction with the mapping of RPC calls and responses specified in Section 7.

To describe encoding, the following terminology is used:

1. A «value» is a string, the name of a measurement (number, date, enumeration, etc.) or a composite of several such primitive values. All values are of specific types.
2. A «simple value» is one without named parts. Examples of simple values are particular strings, integers, enumerated values etc.
3. A «compound value» is an aggregate of relations to other values. Examples of Compound Values are particular purchase orders, stock reports, street addresses, etc.
4. Within a compound value, each related value is potentially distinguished by a role name, ordinal or both. This is called its «accessor.» Examples of compound values include particular Purchase Orders, Stock Reports etc. Arrays are also compound values. It is possible to have compound values with several accessors each named the same, as for example, RDF does.
5. An «array» is a compound value in which ordinal position serves as the only distinction among member values.
6. A «struct» is a compound value in which accessor name is the only distinction among member values, and no accessor has the same name as any other.
7. A «simple type» is a class of simple values. Examples of simple types are the classes called «string,» «integer,» enumeration classes, etc.
8. A «compound type» is a class of compound values. An example of a compound type is the class of purchase order values sharing the same accessors (shipTo, totalCost, etc.) though with potentially different values (and perhaps further constrained by limits on certain values).
9. Within a compound type, if an accessor has a name that is distinct within that type but is not distinct with respect to other types, that is, the name plus the type together are needed to make a unique identification, the name is called «locally scoped.» If however the name is based in part on a Uniform Resource Identifier, directly or indirectly, such that the name alone is sufficient to uniquely identify the accessor irrespective of the type within which it appears, the name is called «universally scoped.»
10. Given the information in the schema relative to which a graph of values is serialized, it is possible to determine that some values can only be related by a single instance of an accessor. For others, it is not possible to make this determination. If only one accessor can reference it, a value is considered «single-reference». If referenced by more than one, actually or potentially, it is «multi-reference.» Note that it is possible for a certain value to be considered «single-reference» relative to one schema and «multi-reference» relative to another.
11. Syntactically, an element may be «independent» or «embedded.» An independent element is any element appearing at the top level of a serialization. All others are embedded elements.

Although it is possible to use the xsi:type attribute such that a graph of values is self-describing both in its structure and the types of its values, the serialization rules permit that the types of values MAY be determinate only by reference to a schema. Such schemas MAY be in the notation described by «XML Schema Part 1: Structures» [10] and «XML Schema Part 2: Datatypes» [11] or MAY be in any other notation. Note also that, while the serialization rules apply to compound types other than arrays and structs, many schemas will contain only struct and array types.

The rules for serialization are as follows:

1. All values are represented as element content. A multi-reference value MUST be represented as the content of an independent element. A single-reference value SHOULD not be (but MAY be).
2. For each element containing a value, the type of the value MUST be represented by at least one of the following conditions: (a) the containing element instance contains an xsi:type attribute, (b) the containing element instance is itself contained within an element containing a (possibly defaulted) SOAP-ENC:arrayType attribute or (c) or the name of the element bears a definite relation to the type, that type then determinable from a schema.
3. A simple value is represented as character data, that is, without any subelements. Every simple value must have a type that is either listed in the XML Schemas Specification, part 2 [11] or whose source type is listed therein (see also section 5.2).
4. A Compound Value is encoded as a sequence of elements, each accessor represented by an embedded element whose name corresponds to the name of the accessor. Accessors whose names are local to their containing types have unqualified element names; all others have qualified names (see also section 5.4).
5. A multi-reference simple or compound value is encoded as an independent element containing a local, unqualified attribute named «id» and of type «ID» per the XML Specification [7]. Each accessor to this value is an empty element having a local, unqualified attribute named «href» and of type «uri-reference» per the XML Schema Specification [11], with a «href» attribute value of a URI fragment identifier referencing the corresponding independent element.
6. Strings and byte arrays are represented as multi-reference simple types, but special rules allow them to be represented efficiently for common cases (see also section 5.2.1 and 5.2.3). An accessor to a string or byte-array value MAY have an attribute named «id» and of type «ID» per the XML Specification [7]. If so, all other accessors to the same value are encoded as empty elements having a local, unqualified attribute named «href» and of type «uri-reference» per the XML Schema Specification [11], with a «href» attribute value of a URI fragment identifier referencing the single element containing the value.
7. It is permissible to encode several references to a value as though these were references to several distinct values, but only when from context it is known that the meaning of the XML instance is unaltered.
8. Arrays are compound values (see also section 5.4.2). SOAP arrays are defined as having a type of «SOAP-ENC:Array» or a type derived there from.

SOAP arrays have one or more dimensions (rank) whose members are distinguished by ordinal position. An array value is represented as a series of elements reflecting the array, with members appearing in ascending ordinal sequence. For multi-dimensional arrays the dimension on the right side varies most rapidly. Each member element is named as an independent element (see rule 2).

SOAP arrays can be single-reference or multi-reference values, and consequently may be represented as the content of either an embedded or independent element.

SOAP arrays MUST contain a «SOAP-ENC:arrayType» attribute whose value specifies the type of the contained elements as well as the dimension(s) of the array. The value of the «SOAP-ENC:arrayType» attribute is defined as follows:

The «atype» construct is the type name of the contained elements expressed as a QName as would appear in the «type» attribute of an XML Schema element declaration and acts as a type constraint (meaning that all values of contained elements are asserted to conform to the indicated type; that is, the type cited in SOAP-ENC:arrayType must be the type or a supertype of every array member). In the case of arrays of arrays or «jagged arrays», the type component is encoded as the «innermost» type name followed by a rank construct for each level of nested arrays starting from 1. Multi-dimensional arrays are encoded using a comma for each dimension starting from 1.

The «asize» construct contains a comma separated list of zero, one, or more integers indicating the lengths of each dimension of the array. A value of zero integers indicates that no particular quantity is asserted but that the size may be determined by inspection of the actual members.

For example, an array with 5 members of type array of integers would have an arrayTypeValue value of «int[][5]» of which the atype value is «int[]» and the asize value is «[5]». Likewise, an array with 3 members of type two-dimensional arrays of integers would have an arrayTypeValue value of «int[,][3]» of which the atype value is «int[,]» and the asize value is «[3]».

A SOAP array member MAY contain a «SOAP-ENC:offset» attribute indicating the offset position of that item in the enclosing array. This can be used to indicate the offset position of a partially represented array (see section 5.4.2.1). Likewise, an array member MAY contain a «SOAP-ENC:position» attribute indicating the position of that item in the enclosing array. This can be used to describe members of sparse arrays (see section 5.4.2.2). The value of the «SOAP-ENC:offset» and the «SOAP-ENC:position» attribute is defined as follows:

Note that rule 2 allows independent elements and also elements representing the members of arrays to have names which are not identical to the type of the contained value.

5.2 Simple Types

For simple types, SOAP adopts all the types found in the section «Built-in datatypes» of the «XML Schema Part 2: Datatypes» Specification [11], both the value and lexical spaces. Examples include:

Источник

Sr.No	Error & Description
1