Profile as SOAP web service (dynamic response)
This section explains how to create a profile that is acting as a SOAP web service and sends a dynamic response back to the client that called this web service.
Please import the following profile and set it active: Profile-Profile_as_web_service_dynamic_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/addition_web_service".
(2) Use option "POST".
(3) Must be set.
(4) Use value "WSDL based on destination tree". This has the effect that the WSDL file is generated on the basis of the source and target structure. In addition, the response of the web service is then dynamic, i.e. based on the data of the target tree (more on this later). More details in section " WSDL File" below .
(5) This option must be set so that we can generate the response for the web service from the target tree (more on this later).
Phase 2
The document type here must be "XML" (is set in the "Main settings"), as we want to process incoming SOAP XML messages.
(6) Set this checkbox.
(7) Necessary for parsing the received XML file into the source structure. See section "Phase 3" below.
(8) Use the value "V3". Note: The XML parser "V4" can also be used, but this is not necessary.
Phase 3
Now switch to phase 3. We want to create a simple calculator web service that adds two numbers and returns the result in the response.
To do this, we first need an XML source structure that holds the two numbers to be added in the fields "intA" and "intB" in node Add, see also (7). Note: Note the match codes of the fields and nodes that are required for XML source structures.
In the target structure, we simply create the node "AddResult" with field "result", on which we use a function to add the values of the source structure fields "intA" and "intB".
Integration Unit
Select the XMLNoTemplateUnit and enter the value "AddResult" in parameter " Root node name". You can ignore all other parameters.
Response
Insert a Response "Custom Class" with class "DefaultWebServiceResponse" and set the content to "Output of IU".
This Response provides the XML response of the web service. See items (4) and (5), target structure and Integration Unit.
Note: The response has the encoding "UTF-8".
WSDL file
Now we can look at the WSDL file of the web service. The WSDL file is automatically created.
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/addition_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 or field attribute "DataCockpit/Portal control".
Defining a service name for the WSDL file
The default service name in the WSDL file 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 astatic 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.
Response header
If system variables of the form VAR_RESPONSE_HTTP_HEADER_<name of response header> are defined, corresponding response headers are set with the values of the variables. Example: The system variable VAR_RESPONSE_HTTP_HEADER_Test with the initial value "mytest" creates the HTTP response header "Test" with value "mytest". Note: The response header " Content-Length" is ignored, i.e. it cannot be overwritten.
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.