This website uses Cookies. Click Accept to agree to our website's cookie use as described in our Privacy Policy. Click Preferences to customize your cookie settings.
Accept
Reject
Preferences
Log in to ask a question
Log in to ask a question

Pass-through vs Soap-Rest impact on fine grained analytics and traffic monitoring

Posted on 04-13-2017 11:06 AM
Not applicable
Reply posted on --/--/---- --:-- AM

When exposing Soap service, is there any impacts/limitations in analyzing or monitoring traffic if exposed as a pass-through vs Soap-rest conversion?

1 2 6,876
Topic Labels
2 REPLIES 2

Posted on --/--/---- --:-- AM
DChiesa
Staff
Reply posted on --/--/---- --:-- AM

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.

Posted on --/--/---- --:-- AM
Former Community Member
Not applicable
Reply posted on --/--/---- --:-- AM

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.