The SOAP Component provides the SOAP Web Services work opportunity within a elastic.io flow.
As an integration platform, elastic.io should has an opportunity to invoke SOAP Web services over HTTP.
Find and select SOAP component in the component repository
Create new or select existing credentials
Specify WSDL URL, then choose binding and operation consecutively. The order matters!
Configure an input data and click “Continue”
Retrieve sample or add sample manually
Retrieve sample result
The platform supports next SOAP protocol versions:
Component supports next wsdl styles:
EIO_REQUIRED_RAM_MB - recommended value of allocated memory is 2048MB
You can select next authorization type:
Username for Basic authorization header in the SOAP request
Password for Basic authorization header in the SOAP request
Makes a call to SOAP service over HTTP using public WSDL URL
A SOAP fault is used to carry error information within a SOAP message. The component handles SOAP faults and emits platform exception in this case. SOAP Fault should comply with the W3C SOAP Fault standard.
The component does not have static input json schema as it is dynamically generated for every wsdl/binding/operation specified in the process of configuration the component input fields. Apache Axis2 and FasterXML JsonSchemaGenerator tools are used by the component internally to generate an input metadata. You can refer these tools documentation in order to get deeper understanding about the product.
Output json schema is generated dynamically the same as for the input (see above).
You should specify input fields exactly in the order below. You’ll get an error otherwise.
The following are limitations of this connector:
All major frameworks for web services support Document/literal messages. Most of the popular frameworks also have some support for rpc/encoded, so developers can still use it to create encoded-only services. As a result it is hard to estimate how many web services, in production use, work only with SOAP encoded messages. However there is a tendency to move away from RPC/encoded towards Document/literal. This is so, because the SOAP encoding specification does not guarantee 100% interoperability and there are vendor deviations in the implementation of RPC/encoded.