Message validation policy - Doesn't accept wsdl URL

We use SOAP message validation policy to validate the message against XSD/WSDL definition, but the limitation that I'm able to observe in this policy is that it doesn't accept the actual URL of XSD/WSDL , we are required to store the definition file in resources folder. The problem with this approach is that if in future definition/specification changes then it needs to be manually updated in resources folder.

I'm trying to understand the rational behind not supporting this.

Solved Solved
0 3 797
1 ACCEPTED SOLUTION

Hi @Sunandita Dam, I think this is just an optimization for the runtime performance.

Let's say if the policy did accept URLs - then at runtime - it would have to make a http call to fetch the schemas. This would be expensive to do that at runtime, affecting the performance of every API call.

Ok the next immediate suggestion could be - why not cache it - then the next question is how long to cache it? when to invalidate the cache etc.. this adds a whole resource management aspect to it.

or the next best solution could be - you could implement a webhook in Apigee to Invalidate cache in Apigee when the schema changes -

So anyways, you [or some mechanism] should let Apigee know that schema has changed - for optimal runtime performance -

So I think the rationale is - if you are going to anyway notify Apigee - which is invoke an http endpoint - which is an API - for changes, then why not include the schema itself with the API. This is exactly the functionality Management API provides to import and deploy new proxies using just an API call.

I think this is a reasonable approach that optimizes both runtime performance and change management, do you agree?

View solution in original post

3 REPLIES 3

Hi @Sunandita Dam, I think this is just an optimization for the runtime performance.

Let's say if the policy did accept URLs - then at runtime - it would have to make a http call to fetch the schemas. This would be expensive to do that at runtime, affecting the performance of every API call.

Ok the next immediate suggestion could be - why not cache it - then the next question is how long to cache it? when to invalidate the cache etc.. this adds a whole resource management aspect to it.

or the next best solution could be - you could implement a webhook in Apigee to Invalidate cache in Apigee when the schema changes -

So anyways, you [or some mechanism] should let Apigee know that schema has changed - for optimal runtime performance -

So I think the rationale is - if you are going to anyway notify Apigee - which is invoke an http endpoint - which is an API - for changes, then why not include the schema itself with the API. This is exactly the functionality Management API provides to import and deploy new proxies using just an API call.

I think this is a reasonable approach that optimizes both runtime performance and change management, do you agree?

@Mukundha Madhavan Thanks for the reply. It make sense.

@Mukundha Madhavan Thanks for the reply. It make sense.