Stambia versions 2.x, 3.x, S17, S18, S19 and S20 are reaching End of Support January, 15th, 2024. Please consider upgrading to the supported Semarchy xDI versions. See Global Policy Support and the Semarchy Documentation.
The Stambia User Community is moving to Semarchy! All the applicable resources have already been moved or are currently being moved to their new location. Read more…
Stambia offers the possibility to handle web services invocation failures with several mechanisms, such as the possibility to retrieve and handle seamlessly invocation failures or implementing a retry behavior for re-attempting failed invocations.
This article explains how those mechanisms are working and how to use them in Mappings to use it.
When invoking a Stambia Published Web Service, a session starts on the Runtime and when it ends it returns a response to the client that performed the request.
There is the possibility to specify, when invoking the Web Service, that it is not necessary to wait the end of the session to hand back to the client request.
This can be particularly useful when using Web Services to start long sessions.
Read more: Invoking a Stambia REST Web Service asynchronously
When invoking a Web Service, you may have the requirement to retrieve from its response unstructured, raw data.
Retrieving binary data (such as files), or plain text, for instance.
This can be performed quite easily with Stambia DI, as explained in this article.
Read more: Retrieving raw, unstructured data from a Web Service
When invoking a Web Service, you may have the requirement to send unstructured, raw data.
Sending a file, binary data, or plain text, for instance.
This can be performed quite easily with Stambia DI, as explained in this article.
This article is a Work in Progress. Feel free to suggest more content by contacting the support team.
When working with REST webservices, there are lots of parameter combinations and contexts which may require some rigor and adjustement in order to get the expected behavior from the webservice.
This article provides some helpful information for analyzing a misfunctionning REST webservice invocation.
Each webservice invocation consists of a request (sent message) and a response (received message)
------------ -------------
| Stambia DI | ----( Sent message )---> | Webservice |
| Runtime | <---(Received message)---- | provider |
------------ -------------
The "Integration Rdbms to WSDL" template has two useful parameters for consulting these messages:
Example of a "1484911188176.in" file content
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).
Example of a "1484911188176.out" file content
<html>
<title>404</title>
<style>
[...]
=> This file contains the raw response of the remote webservice provider. In this case the server replied with an HTML 404 response (because the request was invalid).
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.