Validate policy schema

[karimksafraoui-]

Hi everyone,

I'm using the libxmljs's node module to validate our policies's schema and syntax versus the official schemas.

Validation is one of the steps in our Devops pipeline, which rests on the shoulders of the apigeetool's node module

I'm facing some problems:

• libxmls is caring about element's sequence order.
• some schemas are incomplete/wrong. Examples :
  • messag_logging, the element Syslog is missing in the message_logging.xsd.
  • xml_to_json, Error: Element 'TextNodeName': This element is not expected. Expected is one of ( NullValue, NamespaceBlockName, DefaultNamespaceNodeName, NamespaceSeparator, TextAlwaysAsProperty )
  • service_callout: Error: Element 'HTTPTargetConnection': This element is not expected. Expected is ( ##other* )

My purpose is to validate our policie's syntax and schemas before deploying bundle to apigee.

How Apigee validates the policy's schema, even though a policy doesn't match the schema (example the element Syslog in message_logging.xsd).

Is it relevant to validate policies's schema before deploying bundle, juste to avoid sending bad bundle.

Thank you

[jonesfloyd]

Hi @karimksafraouiextern -

Apologies for the poor experience with the schemas. We have a ticket open to address the issues (65731298), but the fix may not happen for a while. So I'll recommend a few things, none of which, unfortunately, will help you pre-validate before deploying but will help ensure you get policies that are as valid as possible at deploy time.

• Use the policy reference docs as guidance.
• Assume no element ordering requirement inside the policy configuration.
• On the Update an API Proxy Revision management API call, be sure to set the validate=true query param. If the bundle isn't valid, you should get a list of errors back without a failed deployment.

Hope that helps, and once again apologies for the sub-optimal experience. I'll add a note to our schemas readme on Github that mirrors the guidance I just gave you.

[#3]

Glad I came across this post. I was attempting to do something similar.

Having to read the policy reference docs or waiting until you make the management API call to find out the document is not valid isn't the most efficient use of development time.

I'd much prefer to have autocomplete and document validation in my IDE. 🙂

If element ordering is not required, is it not a simple search and replace of "xs:sequence" to "xs:all" in the schema directory? Or does order matter on some child nodes and all ~300 or so instances need to be evaluated individually?

I would also note, the timeLimit attribute on the Javascript policy is marked as a required attribute, though this doesn't seem to be enforced.

[jonesfloyd]

+1 on not the most efficient use of time, @Tom Ashe! It's not optimal to say the least. Thanks for the notes as well. We'll need to double-check the code in many cases to make schema updates (since the validation is actually happening in the code, not against schemas). There are likely a handful of discrepancies like the JS attribute you pointed out.

[karimksafraoui-]

Thank you @Floyd Jones

I will drop the validation step of the schema and keep the validation of the syntax.

We already use validate = true in the deployment request.

If a deployment is rejected because of a bad schema, does Apigee send a specific message?

[jonesfloyd · Accepted solution]

Actually, it doesn't appear that the API gives you a helpful message about what's invalid. This is what I get:

{
  "code": "repository.cassandra.UnableToReadApiProxy",
  "message": "Unable to read/find APIProxy contents",
  "contexts": []
}

If I paste my change into the UI, I get a more helpful message:

Error Saving Revision 1
Error occurred while validation of bean Quota-1.xml. Reason: - Schema validation failed. Cause : unexpected element (uri:"", local:"Foo").
...

So the UI, when you click Save, may be a better way to check validation.