When exposing Soap service, is there any impacts/limitations in analyzing or monitoring traffic if exposed as a pass-through vs Soap-rest conversion?
No - no impact.
Let's suppose you have an existing SOAP endpoint that is serving load today. You could simply point clients to a pass-through API PRoxy configured in Apigee Edge, that would connect to the existing SOAP endpoint. you then get automatic analytics, TP95/TP99 stats, error analysis, all the Apigee Edge analytics goodness.
Now let's suppose you run the SOAP-to-REST wizard on that same SOAP service. Now you have two proxies in Apigee Edge that both point to the existing SOAP endpoint. One of the proxies exposes a REST /JSON interface to clients, and one exposes the same existing SOAP interface (Defined by the WSDL).
The second API proxy still gets all the same Analytics and monitoring capability that I described above.
I don't know if it qualifies as impact, but there are differences to be aware of
1) The SOAP to REST convertor exposes each WSDL operation as a sub resource. Ex: /basepath/operation1, /basepath/operation2 etc. Analytics can be obtained for each of these resources (operations). However, when creating a proxy as a WSDL passthru, all requests are sent to the same /basepath. There are no sub resources - therefore requires additional attention to get operation level analytics. If you use the WSDL pass wizard, the proxy generator generates flows/conditions for each operation. However, it is still up to the developer to include a stats collector policy in each of those conditions to feed data to analytics.
2) Another difference is how you package the API as a product. If you use the SOAP to REST generator, you can use API products to group some of the resources (operations) in a product. There are ways to achieve this with pass thru SOAP proxies also, but requires a little more work. Refer to the documentation and it explains one such way.
User | Count |
---|---|
1 | |
1 | |
1 | |
1 | |
1 |