In this article I will explain how you can enable payload validation in the Oracle SOA/BPM Suite per composite, both design and deployment time. This works for 11g as well as 12c
When developing BPM processes or SOA services it is advisable enable payload validation on the development server. The reason being that this will force you to work with more representable test data, and in some occasions help you preventing coding errors (like assignment of a string to an integer, or forgetting to map mandatory data in a call). Specifically there where you have to communicate with external systems, this might become very important, not speak of the situation where payload validation is enforced for example by a server bus.
Preferable you have payload validation switched on from the beginning, starting with the development server, but better also for the test server(s). Normally you would leave it off (the default) for production and load and stress test environments (for performance reasons).
However, sometimes you find yourself in a situation where existing composites already violate one or more XML rules. This can make it practically impossible to switch payload validation on for the whole server. You then will have to do it on a composite by composite basis. Fortunately this is supported out-of-the-box by the validateSchema property you can set on a composite, as shown below:
Assuming that you use configuration plans per environment you deploy to, you can switch it on for any environment you want to enable it for, using the following entry in the configuration plan:
When deployed, payload validation will automatically have been enabled for the composite, preventing that you have to do so manually every time you deploy:
No excuses for those lazy developers hiding behind someone else's bad written code!
When developing BPM processes or SOA services it is advisable enable payload validation on the development server. The reason being that this will force you to work with more representable test data, and in some occasions help you preventing coding errors (like assignment of a string to an integer, or forgetting to map mandatory data in a call). Specifically there where you have to communicate with external systems, this might become very important, not speak of the situation where payload validation is enforced for example by a server bus.
Preferable you have payload validation switched on from the beginning, starting with the development server, but better also for the test server(s). Normally you would leave it off (the default) for production and load and stress test environments (for performance reasons).
However, sometimes you find yourself in a situation where existing composites already violate one or more XML rules. This can make it practically impossible to switch payload validation on for the whole server. You then will have to do it on a composite by composite basis. Fortunately this is supported out-of-the-box by the validateSchema property you can set on a composite, as shown below:
Assuming that you use configuration plans per environment you deploy to, you can switch it on for any environment you want to enable it for, using the following entry in the configuration plan:
No excuses for those lazy developers hiding behind someone else's bad written code!
No comments:
Post a Comment