Profile as SOAP web service (static response)
This section explains how to create a profile that is acting as a SOAP web service and sends a static response back to the client that called this web service.
Please import the following profile and set it to active: Profile-Profile_as_web_service_static_response.pak
Phase 1
Open the profile and navigate to phase 1. There you can see the event-driven Input Agent of type "HTTP".
(1) Specifies the URL under which your web service can be accessed. So here "https://<URL/IP Integration Server>/dw/Request/my_web_service".
(2) Use option "POST".
(3) Must be set.
(4) Use this value. This has the effect that the WSDL file is only generated on the basis of the source structure. In addition, the response of the web service is then 'static', i.e. it only contains the job number of the profile started by the web service call and does not contain any data from the target tree. More details in section "WSDL File". Note: The response has the encoding "UTF-8".
Phase 2
The document type here must be "XML" (is set in the "Main Settings"), as we want to process incoming SOAP XML messages.
Phase 3
Now switch to phase 3, where an XML source structure is required.
The source structure is based on the following XML file. How to create the source structure with this file is described in section XML to XSD (to structure).
The target structure was simply created by using a 1:1 mapping, because it is not relevant for our static response.
<?
xml
version
=
"1.0"
encoding
=
"UTF-8"
?>
<
Data
>
<
Article
name
=
"Jacket"
group
=
"Clothing"
>
<
Number
ean
=
"4711"
>123</
Number
>
<
Description
>Waterproof</
Description
>
</
Article
>
</
Data
>
WSDL file
Now we can look at the WSDL file of the web service. The WSDL file is created automatically.
To do this, enter the following URL in the browser. This is the same URL that is used to call the web service (1), but the suffix "?wsdl" is added at the end.
https://<URL/IP Integration Server>/dw/Request/my_web_service?wsdl |
Below you will find further information on the WSDL file, which you can ignore for the time being.
Ignoring nodes and fields during WSDL generation from source structure
If you want certain nodes or fields to be ignored when the WSDL file is automatically generated from the source structure, you can achieve this by specifying value _exclude_ in the node attribute or field attribute "DataCockpit/Portal control".
Defining a service name for the WSDL file
The default service name in the WSDL file created is "ProfileService". If you want to define your own service name, you can do that in the source and target structure as shown in the screenshot above. Make sure to use the mandatory prefix "Service:".
Type of WSDL creation
If the value WSDL returning job status is used in (4), the WSDL file is only created based on the source structure. In addition, the response of the web service is then "static", i.e. it only contains the job number of the profile started by the web service call and does not obtain any data from the target tree.
If the value WSDL based on destination tree is used in (4), the WSDL file is created based on the source and target structure. In addition, the response is then generated dynamically based on the data of the target tree. Details on this can be found in section Profile as SOAP web service (dynamic response). The following procedure is used to generate the element definition.
The name of the field/node in the target structure (without _val or _attr) is used or the description of the field/node if it exists. This makes it possible to use elements with the same name within the definition, which is not possible in the target structure itself.
If the description of a node contains the string _exclude_, then this node is skipped in the WSDL generation.
Using unique root element names
When the WSDL file is generated based on the target structure, it is assumed that the XML root elements in the generated request and response structure are unique. The XML names are generated from the match codes of the nodes/fields in the source structure and from the names of the nodes and fields, or the node names defined in the field description in the target structure. Therefore, the root nodes of the source and target structure should not have the same name. If same names are unavoidable, the dynamic WSDL generation cannot be used and a static WSDL has to be used instead. This WSDL file usually has to be created manually or reworked.
Static WSDL creation
As an alternative to the dynamic generation of the WSDL file, you can save the WSDL file under ./conf/wsdl/<URL address suffix>.wsdl. The character / has to be replaced with a _ in the file name. The file is searched for under this path and used instead of the dynamically generated WSDL if it exists, is readable, and not empty. In the file, you can adjust the area of the response, which is embedded in WSDL requests, accordingly.
Request headers
Request headers can be read with the system variables MSG_CALL_HEADER_HTTP_<name of header in uppercase letters>. Note: The system variable MSG_CALL_HEADER_HTTP_AUTHORIZATION (header "Authorization") is not set by default. However, you can force this variable to be set with the system property hub.datawizard.http.copy.allHeader=true.
Further system variables:
MSG_CALL_HEADER_HTTP_METHOD
MSG_CALL_HEADER_HTTP_PROTOCOL
MSG_CALL_HEADER_HTTP_REMOTE_HOST
MSG_CALL_HEADER_HTTP_URI
MSG_CALL_HTTP_AUTH_USER.
Calling the web service
We will show you how to call such a web service in sections Calling SOAP web service with profile in Input Agent, Calling SOAP web service with profile in function and Calling SOAP web service with profile in Response.