Sap soap что это
SAP API Management – SOAP Service as REST API
In this tutorial, I will explain how to expose a SOAP WebService as a REST API.
The prerequisite for this tutorial, is that you are acquainted with SAP API Management, eg. that you have already created some API proxies like described in Holger Bruchelt’s document How to use SAP API Management on HCP Trial
This proxy can be created on the SAP API Management Trial environment.
For the purpose of the tutorial, I will use a public web service called “Calculator” that is availablehere. This WebService allows to execute mathematical operations. In our case, we will hardcode the “add” operation.
If you are interested in getting a working proxy, that you can import into your environment, feel free to reach out to me.
Overview
First of all, note that with an API Proxy, you can access a web service either by setting up the backend to be the target of your proxy, or by making a so called “Callout” from within the proxy. In our tutorial, we will use the WebService as target backend.
Before we get our hands dirty, let’s see what our master plan is. The diagram below is a view of what we’ll do in this tutorial:
1- Create the API proxy: we will create a proxy that will expose the “Calculator” WebService as a REST API, that can be reached over “ /v1/calculator”, using the calculator web service as target backend.
API Proxy Request flow:
2- Generate the SOAP request: SOAP WebServices requires specifically formatted requests. The REST API we’ll provide is easier to use, and only requires 2 query parameters. To map these parameters to the specific SOAP WS request, we will generate the request using an “Assign Message” policy.
Response:
The web service response is an XML response, with a lot of metadata, that is not always useful to the REST API consumer. JSON has proven to be an ideal notation for apps or web applications, being lightweight, simple to understand and to use. For these reasons, we will convert the XML response into JSON, and remove the metadata, so that the REST API is easy to use and lightweight.
To achieve this we will:
3- Convert the response to JSON: with a “XML t oJSON” policy, the XML response will be converted to JSON,
4- Beautify the response: with an “Extract Variables” policy, we will extract the desired information from the JSON, add set it as the API proxy response.
1- Create the API Proxy
Log into your Hana Cloud Cockpit, and navigate to the “API Management” Service.
In the APIM Dashboard, select “Quick Actions” > “Create Artifacts” > “API”:
In the API Proxy creation window, enter the details as follows:
API Provider: None
Name: Calculator
Title: Calculator
Description: This API will execute mathematical operations
API base path: /v1/calculator (it is a best practice to always add a version to the base path of your API)
Service Type: REST
Hit the “Create” button, and then “Save and deploy”.
2- Generate the SOAP request
When calling our REST API, we will use 2 parameters, Number1 and Number2. These will be the number used for the addition the service will make, for instance:
The response of /v1/calculator?Number1=10&Number2=30 will be 40
In order to place a SOAP call, we need to generate a SOAP request. This SOAP request has a specific structure, with specific headers and XML payload, containing the request parameters.
To do so, open the Policy Designer by clicking on “Policies” from within your API.
Click on the “Edit” link on the right-bottom corner.
Click on the “ProxyEndpoint>PreFlow” on the left “Flow” panel.
Click on the “+” sign of the “Assign Message” policy, on the right-handed “Policies” panel.
Name: GenerateSOAPRequest
EndpointType and FlowType were set for you when you clicked on the “ProxyEndpoint>PreFlow” link in the previous step
Stream: Incoming Request
Click on “Add” to add the policy to the flow.
The “Assign Message” policy is very powerful, and lets you assign values to headers, query parameters, payload, custom variables, etc.. In our case, we will use it to define the required SOAP call, dynamically created using our query parameters.
Replace the XML configuration of your Assign Message policy with the following:
Note that the AssignMessage policy will:
– create the XML payload as required by the web service,
– set the “Verb” to POST since all SOAP transactions are “POST”.
This configuration is then assigned to the request that will go to the backend, ie. the Calculator web service.
Also note that we are dynamically setting the parameters “x” and “y” that are required by the web service endpoint, using a specific notation: the curly brackets mean that we reference the value a flow variable: “ <>“. This flow variable is either user-defined, and set by using an “Assign Message” policy, or pre-defined, and set during runtime.
In our case, we use a pre-defined variable called “request.queryparam” and append the name of the query parameter we want to retrieve. At runtime, “ ” will be replaced by the value of the query parameter “Number1”.
Click on the “Update” link at the right-bottom corner of the PolicyDesigner.
Click on the “Save” link at the right-bottom corner of the API Proxy overview.
It’s a good idea to test the proxy now. To do so, simply open a browser window (preferably Chrome) and paste the URL of your proxy. Add the parameters “Number1” and “Number2” to your request and run the query.
As you can see, the request is passed to the SOAP backend, which returns the XML data according to your query parameters.
However, as an app developer, I would love to have that information in a lightweight and simple-to-use format: JSON. Therefore we will convert and beautify the response.
3-Convert the response to JSON
Converting XML data to JSON is very simple with SAP API Management. You only need to add a “XML to JSON” policy on the response flow of your proxy.
To do so, open the Policy Designer by clicking on “Policies” from within your API.
Click on the “Edit” link on the right-bottom corner.
Click on the “ProxyEndpoint>PreFlow” on the left “Flow” panel.
Click on the “+” sign of the “XML to JSON” policy, on the right-handed “Policies” panel (you may need to scroll down to see the policy).
Name: XMLtoJSON
EndpointType and FlowType were set for you when you clicked on the “ProxyEndpoint>PreFlow” link in the previous step
Stream: Outgoing Response
Click on “Add” to add the policy to the flow.
The “XML to JSON” policy can be configured in several ways to fit your needs. In our case, we simply specify that the text for an empty node name is “value”.
Use the following configuration for your policy:
Click on the “Update” link at the right-bottom corner of the PolicyDesigner.
Click on the “Save” link at the right-bottom corner of the API Proxy overview.
Test your proxy again using the previous URL.
The response of the proxy now looks much simpler and easier to consume:
4- Beautify the response
Even though the response is now lightweight and easy to use, let’s improve it even more (this is not a necessity, but a good excuse to have a look at another policy!).
Just as there is XPath for XML, there is JSONPath for JSON. SAP API Management provides an “Extract Variables” policy that can execute a JSON path expression against JSON payload.
Our current response payload looks like this:
What we would like to end up with, is only the “addResponse” code:
We will use the following JSONPath expression: “$.Envelope.Body.addResponse” that points at the “addResponse” element of our payload, starting from the root (“$”).
To do so, open the Policy Designer by clicking on “Policies” from within your API.
Click on the “Edit” link on the right-bottom corner.
Click on the “ProxyEndpoint>PreFlow” on the left “Flow” panel.
Click on the “+” sign of the “Extract Variables” policy, on the right-handed “Policies” panel (you may need to scroll down to see the policy).
Name: GetResponseOnly
EndpointType and FlowType were set for you when you clicked on the “ProxyEndpoint>PreFlow” link in the previous step
Stream: Outgoing Response
Click on “Add” to add the policy to the flow.
Use the following code the configures the execution the above JSONPath:
The policy above executes the JSONPath against the source “response”, and sets the value of the result into the variable “response.content“. This variable is a predefined variable, and contains the response of the API proxy. We are actually overwriting the response, with the result of the JSONPath expression with our policy.
Click on the “Update” link at the right-bottom corner of the PolicyDesigner.
Click on the “Save” link at the right-bottom corner of the API Proxy overview.
Test your proxy again using the previous URL.
Final words
As you may have seen throughout this tutorial, SAP API Management provides the ability to quickly and simply adapt a web service to expose it as REST API, and adapt it to your specific needs. I hope that even if we only have scratched the surface, you got an idea of what is possible, and that you’ll have fun in the future using HCP SAP APIM!
For any questions or comment feel free to contact me or to leave a comment below.
Создание web-сервиса в системе SAP
Sergey Ignatov
Так как еще не было ни одного слова сказано про создание web-сервиса в системе SAP на этих уютненьких страницах, исправляюсь.
Начну с двух обязательных составляющих, являющихся неотъемлемыми атрибутами архитектуры любого веб-сервиса, будь он реализован в системе SAP или ей подобной.
Протокол обмена данными между различными системами посредством XML сообщений, если можно так сказать.
SOAP (originally Simple Object Access Protocol) is a messaging protocol specification for exchanging structured information in the implementation of web services in computer networks. Its purpose is to induce extensibility, neutrality and independence. It uses XML Information Set for its message format, and relies on application layer protocols, most often Hypertext Transfer Protocol (HTTP) or Simple Mail Transfer Protocol (SMTP), for message negotiation and transmission.
Язык описания структуры самого веб-сервиса для его использования внешними системами (системами-потребителями). Структура сервиса описывается посредством XML.
The Web Services Description Language (WSDL) is an XML-based interface definition language that is used for describing the functionality offered by a web service. The acronym is also used for any specific WSDL description of a web service (also referred to as a WSDL file), which provides a machine-readable description of how the service can be called, what parameters it expects, and what data structures it returns. Therefore, its purpose is roughly similar to that of a type signature in a programming language.
Что мне дает симбиоз SOAP и WSDL?
Безусловно экономию времени, а также удобство в использовании. В системе SAP возможно в автоматическом режиме сгенерировать WSDL схему вашего сервиса для предоставления коллегам, которые собираются его вызывать извне. Структура сервиса становится доступной из любого soap-клиента, который вы, или ваши коллеги, используют в работе.
Пример создания веб сервиса
Разберем хрестоматийный пример создания веб-сервиса в системе SAP. Полезности в нем особенно не будет, но последовательность действий может пригодиться, что называется, для общего развития.
0. Задача
Создать веб-сервис, возвращающий из системы SAP фамилию и имя работника по его табельному номеру.
1. Создание функционального модуля
Для решения выше поставленной задачи я создам функциональный модуль, возвращающий в качестве параметров фамилию, имя работника ну и его табельный номер, который также будет передаваться в качестве входного параметра.
При создании ФМ, обратите внимание на то, что для него должно быть активировано свойство Remote-Enabled Module
Наполнение ФМ, согласно поставленной выше задаче, будет следующим
За использование конструкции вида SELECT * FROM прошу строго не судить. Исключительно демонстрации ради.
2. Создание веб-сервиса (1)
Система поможет вам в создании нового веб-сервиса, предложив указать дополнительную информацию
В результате проделанных манипуляций будет создан новый веб-сервис
В созданном веб-сервисе я изменю настройки безопасности, выбрав значение None на закладке Configuration в блоке Security Profile (исключительно для демонстрации в заметке)
Не забудьте активировать вновь созданный сервис.
3. Промежуточное тестирование веб-сервиса на стороне SAP
Выполните тест нового веб-сервиса
4. Создание веб сервиса (2)
Последующие манипуляции по настройке нового веб-сервиса должны быть проделаны в транзакции SOAMANAGER. На ниже представленном видеофрагменте представлена соответствующая последовательность действий
5. Тестирование доступа к веб-сервису из внешнего приложения
В качестве демонстрации доступа к новому веб-сервису извне, я буду использовать клиент SoapUI.
Скопируйте WSDL ссылку на свой сервис
В клиенте SoapUi создайте новый проект и выполните тестирование
За более подробной информацией по этой, безусловно, интересной теме, обращайтесь к справочному материалу вендора
Sign up for more like this.
Использование Function Import в oData сервисе
Использование Function Import в oData сервисе
Small SAP Talk. VSCode и SAPUI5
Small SAP Talk. VSCode и SAPUI5
ABAP CDS. Коротко о главном (3)
Обзор вариантов добавления ABAP CDS к существующему или новому oData сервису, а также создания нового oData сервиса на основе ABAP CDS
Web-сервисы 1С для обмена с SAP
Кому предназначена эта статья? Наверное, начинающим программистам веб-сервисов 1С. Хотя она и не даст ответы на все возникающие вопросы, в интернете легко найти информацию по более узким вопросам а-ля что такое пакет XDTO или SOAP UI. Сверхзадача этой статьи – морально подготовить читателя к тому, что не всё может зависеть от знаний, что не стоит расстраиваться из-за всяких глюков, а к ошибкам других людей нужно относиться с пониманием.
1. Исторический обзор обмена информации между базами 1С
Проблема обмена информации между базами 1С появилась одновременно с 1С и как только она не решалась! Самым распространенным в какое-то время стал (да так и остался) обмен xml-файлами. Плюсы этого подхода (гибкость и универсальность), общеизвестны, а о недостатках, как обычно, мало кто говорит.
Году так в 2010 у меня был проект по обмену с сайтом на битриксе, где файл обмена приближался по размеру к 2 ГБ. При его разборе успешно падал Microsoft парсер. В результате доработанный за два месяца обмен не прошел испытание объемом, а заказчик оставил меня без денег. Прошло уже 10 лет, но до сих пор 2ГБ остаются критичным размером для файлов обмена.
Можно ли сделать обмен по-другому? Да, и не слишком большими затратами! Зачастую бэкап всей базы средствами SQL занимает минуты, а по объему – те же гигабайты. Выгрузка данных в xml файл занимает часы, потому что каждую порцию данных надо завернуть в теги xml, которые и добавляют объема файлу выгрузки.
Поскольку способов обмена всегда было много, неизбежно должна была появиться идея обмена посредством протокола http, через web-сервисы. Предыдущие технологии обмена между базами 1С уже оставляли довольно большое наследство и при обмене web-сервисами ими просто грех было не воспользоваться.
2. Web-сервисы для обмена с SAP
В основе данного способа обмена лежит всё тот же обмен xml-файлами, но через http-протокол. Каждый xml файл древовидно описывает какой-то простой объект базы данных, обычно ему соответствует пакет XDTO. Как и следовало ожидать, многие объекты в 1С и SAP во многом похожи – и там и там есть товары, у которых есть единицы измерения, a поскольку xml позволяет довольно удобно описать любую структуру, то даже несовпадение внутреннего устройства объектов не создает особых неудобств. К тому же можно обмениваться данными по каждой номенклатуре и не сливать всё в один мегафайл.
Следующим уровнем является описание нескольких близких по смыслу объектов в одном месте – WSDL файле. WSDL файл описывает уже весь web-сервис.
Например, обмен по номенклатуре был реализован через web-сервис:
Он может принимать xml-файлы 4 видов:
· CLSMAS03 – вид номенклатуры;
· CLFMAS02 – дополнительные реквизиты номенклатуры;
Почему на скриншоте к пакетам по номенклатуре добавился пакет AEAUD01? В этом пакете описывается ответ 1С для SAP после приема пакетов по номенклатуре. Он относится к другому web-сервису, но в списке пакетов XDTO все стоят рядом.
3. Публикация веб-сервиса
Итак, вы сделали свой web-сервис c модулем и пакетами XDTO, а теперь нужно, чтобы он заработал. Закавыка в том, что у 1С пока нет своего сервера. Поэтому приходится запускать web-сервисы 1С на самых распространенных web-серверах – IIS и Apache. Обычно этот процесс сопровождается некоторыми проблемами. Дружелюбный Апач можно взгромоздить куда угодно, хоть на свою домашнюю машину, но даже он может потребовать установки подходящей версии, потому что последняя именно с сервисами 1С может работать некорректно. Веб-сервер IIS обычно работает в связке со множеством других в разных компаниях: вы заходите на терминальный сервер, подключаетесь к серверу 1С, к хранилищу на другом сервере и обнаруживаете, что для веб сервера IIS есть еще один сервер. И конечно, на каждый сервер не так просто попасть, почти везде нужны административные права.
Попробуем опубликовать его:
Первая проблема при публикации веб-сервиса – требование административных прав. Даже если Вы всемогущий Администратор в 1С, системе Windows об этом не известно.
Тут может быть всего два варианта решения проблемы: получить права от заказчика, что бывает непросто, или же по несколько раз на дню публиковать Ваши сервисы администратору – а это трудно назвать решением проблемы даже с натяжкой.
Ну, допустим, Вы запустили 1С под правами администратор Windows. Дальше будьте готовы к новым испытаниям:
В целом понятно, чего хочет 1С, однако эти модули расширения, наверное, надо устанавливать на машину, где работает IIS. В нашем проекте на сервере c IIS пришлось устанавливать и 1С, и модули расширения веб-сервера 1С, чтобы просто опубликовать их для IIS. Для работы с 1С эта машина была слабой, а для веб-сервера – вполне нормальной.
Вам знакомо выражение «в конце концов, среди концов, найдешь конец ты наконец»? Вот-вот. Скриншот публикации нарисован для сервера Apache. Но зачем нам Apache, если мы работаем на IIS?
Скорее всего, пока вы получите доступ к череде серверов для публикации ваших веб-сервисов на IIS, вы успеете:
· скачать и установить на своей локальной машине Апач, запустить его и обрадоваться, что оно работает;
· опубликовать веб-сервис и убедиться, что он не работает;
· найти нужную версию апача, переустановить его и переопубликовать свой веб-сервис.
При первом запуске окна Публикация на web-сервере обычно включены все галки, нужно оставить то, что действительно необходимо.
4. Отладка веб-сервиса 1С 8.3
Программист 1С считается состоявшимся, если умеет копировать в буфер и извлекать из него, а также пользоваться отладчиком. При работе с web-сервисами ситуация отладки довольно пикантна – может отлаживаться программа, не имеющая отношения к 1С. Будьте уверены, что 1С будет мстить вам за такой подход и не будет отлаживаться до последнего. Настройками отладки довольно просто пользоваться – достаточно задать правильные параметры на закладке Прочие при публикации веб-сервисов:
Потом в Конфигураторе настроить подключение к отладке:
Можно попробовать настроить отборы предметов отладки:
А также параметры отладки:
Но даже это может оказаться бесполезным. В моем случае при отладке ничего не работало из-за того, что IIS использовал нестандартный порт. Так что даже с правильными настройками отладка может не запуститься. На ситуацию эту стоит смотреть с философской точки зрения – в конце концов все настройки станут понятными. Любая проблема решаема, даже если на первый взгляд это не так.
5. Что такое SOAP
Итак, мы закодировали и опубликовали веб-сервис, разобрались с настройками отладки и хотим показать заказчику, что всё работает. Прямо сразу показывать не советую, так как есть риск, что код не заработает корректно с первого раза, особенно когда его много.
Если бы наш запрос к веб-серверу был простым, через методы POST или GET, то данные такого запроса веб-сервису передал бы сам браузер. Для передачи пакетов XDTO нужна особая программа. К счастью, проблем с ней практически не возникает.
Эта программа называется SOAP UI и в алгоритме ее работы есть немало здравых идей.
Самая гениальная идея – всё описание веб-сервиса есть в wsdl-файле. Кстати, нам его дал заказчик вместе с тестовыми данными, что значительно ускорило весь процесс.
В SOAP UI мы можем сделать новый SOAP проект.
Загрузим в него wsdl-файл.
В проекте сразу будут шаблоны запроса к нашему веб-сервису.
Мы можем заполнить эти шаблоны вручную, а если повезет, то и содержимым тестовых файлов от заказчика. На скриншоте красным выделено место, с которого до закрывающего тега в конце просто вставляется содержимое тестового файла заказчика. Наградой за старания будет маленькая желтая стрелка слева в красном кружочке в конфигураторе 1С после отправки запроса из SOAP UI. Через непродолжительное время он даже посчитает, что запрос не удался, таймаут превышен, и никогда не узнает, что у вас просто заработала отладка!
Следует обратить внимание еще на два момента:
1. Нужно будет указать правильный url обращения к веб-сервису. Мой первый url был правильный с точностью до нестандартного порта IIS. Из-за этого в ответе была ошибка 500 – внутренняя ошибка веб-сервиса. Но именно из-за неё я был уверен, что дело не в моём коде, а в сервере IIS, так что обратился к администратору заказчика, который просто подсказал, как добавить нестандартный порт в url.
2. Потом была ошибка 401 – ошибка авторизации. Оказалось, для функционирования веб-сервиса нужен пользователь 1C с ролями «Полные права» и «Административные права». После сообщения SOAP UI этого пользователя и его пароля всё заработало. Естественно, что он был заведен на латинице, как и все url.
Если Вы дочитали, и даже допрограммировали до этого места, вам самим впору писать статьи про 1С. Как ни странно, программировать веб-сервисы довольно просто, особенно при наличии сделанного проекта перед этим. В них нет кучи кода и особо сложных запросов, похожих на написанные роботом. Узкие места в веб-сервисах, конечно, есть, но нам повезло, что мы просто адаптировали проект, где они уже были решены.
Если Вам удалось запустить отладчик, через некоторое время вы обнаружите, что всё идеально работает! Китайцы не зря советовали опасаться своих желаний, потому что когда они исполнятся, ребром станет вопрос – а что со всем этим делать? Например, оказалось, что гениальная схема SAP из 4 файлов для номенклатуры может подкинуть вам фокус в виде пришедшего файла с номенклатурой и файла с видом номенклатуры, но пустым видом номенклатуры в самой номенклатуре, потому что эта связка приходит в третьем файле, который вам не послали из SAP. С удивлением вы обнаружите, что SAP – это не только высокооплачиваемые специалисты, но и люди творческие и условно обязательные, которым не чуждо ничто человеческое. Бывает, они пришлют вам несвязанные данные, которые при Вашем идеальном коде всё равно будут недозаполненными. Понятно, что они это делают не специально – когда номенклатуры несколько тысяч позиций, то такие вещи неизбежны. Как же можно бороться с этим хаосом?
Давайте будем на каждый пришедший пакет делать файл лога. Идея замечательная, но первая же полная выгрузка справочника номенклатуры завалит вас кучей довольно больших файлов xml, смотреть которые довольно неудобно. И тогда придется писать просмотр логов, который из каждого файла находит ключевые элементы (обычно их немного – до 2-3). Тогда файл превращается в строчку табличного поля, из которой можно посмотреть номенклатуру и на которую можно наложить отбор, вывести всё табличное поле в файл Excell и т.д.
У обработки простейший дизайн – 4 табличных поля по числу файлов обмена:
Каждый вид файлов заполняется примерно так:
Именно эта обработка позволила практически в онлайн режиме отвечать на вопросы типа сколько данных пришло, какие были незаполненные и т.п. Она оказалась нужна для проверки больших объемов выгрузки. Почему не сделали вместо файлов лога какой-нибудь регистр? На это не было добра от заказчика, да и все эти проверки нужны только на период отладки и запуска. Может вам она даже и не понадобится. Просто знайте, что всего одна страница кода может сэкономить вам кучу нервов и времени.
Обычно на проекте сложности бывают программного характера, но оказалось, что могут быть и организационного.
Что можно сделать лучше на проекте с веб-сервисами?
1. С первого дня работы обеспечить нормальную среду разработчику:
I. работающее без больших задержек хранилище. (в нашем случае нужно было просто сделать новое);
II. работающую без больших задержек 1С. (в нашем случае нужно было добавить памяти в сервер, однако от этой процедуры слетают лицензии);
III. достаточное количество лицензий: на программиста может уходить 4-5 лицензий, поэтому несколько программистов могут создать их дефицит.
2. Обеспечить оперативную поддержку со стороны админов.
3. Иметь нормальное ТЗ. Впервые на этом проекте я столкнулся с тем, что выпрашивал себе работу. Нельзя сказать, что загрузки не было из-за того, что быстро кодировали, просто внимания РП на всех не хватало. С хорошим ТЗ сделали бы в два раза больше и быстрее.
4. Общаться с заказчиком по скайпу, а не через электронную почту. Ведь тогда можно оперативно получить ответ на свой вопрос, что-то показать по демонстрации экрана, да и вообще сделать взаимодействие быстрым и эффективным. Почему заказчик выбрал путь общения через E-Mail, непонятно, но, полагаю, из-за каких-то соображений политики безопасности, что тоже имеет смысл.
Все вышеперечисленные вещи очевидны, но потери от них у нас составили порядка 30 % от общего времени проекта.