Investigating a REST web service invocation issue
This page is legacy documentation. For the current HTTP REST connector, see its dedicated section. |
When working with REST web services, there are lots of parameter combinations and contexts which may require some rigor and adjustement in order to get the expected behavior from the web service.
This article provides some helpful information for analyzing a misfunctionning REST web service invocation.
Consulting the request & response contents
Each web service invocation consists of a request (sent message) and a response (received message)
-------------- --------------
| Semarchy xDI | ----( Sent message )---> | Web service |
| Runtime | <---(Received message)---- | provider |
-------------- --------------
The Integration Rdbms to WSDL template has two useful parameters for consulting these messages:
-
Sent messages folder: when set to a folder path, the Runtime will create a
.in
file for each request -
Received messages folder: when set to a folder path, the Runtime will create a
.out
file for each response
https://demo.winddle.com/api/v1/recent/productshttps://demo.winddle.com/api/v1/recent/products?scope=company&delta_days=3
⇒ In this invalid example, we see that the request URL is malformed. Probably the metadata is incorrect (in this example, base URL is repeated in both the Service node and the Operation node).
<html>
<title>404</title>
<style>
[...]
⇒ This file contains the raw response of the remote web service provider. In this case the server replied with an HTML 404 response (because the request was invalid).
Consulting the temporary data file
When invoking a service, the Runtime writes input data (whatever the format: Json, Xml, raw…) to a temporary XML file.
You can consult this file by getting its path from the Variable View for the "Call Webservice" action.
This can be helpful to see how the extracted data looks like.