Changes for page Validation
Last modified by Danniar Firdausy on 2024/09/19 08:56
Summary
-
Page properties (2 modified, 0 added, 0 removed)
Details
- Page properties
-
- Author
-
... ... @@ -1,1 +1,1 @@ 1 -XWiki. marijn1 +XWiki.ebakker - Content
-
... ... @@ -1,16 +1,9 @@ 1 -{{html wiki="true"}} 2 -<div class="ez-academy"> 3 - <div class="ez-academy_body"> 4 - 5 -<div class="doc"> 6 - 7 - 8 - 1 +{{container}}{{container layoutStyle="columns"}}((( 9 9 = Validation = 10 10 11 11 In the previous microlearning, we learned how to configure a REST service. In this microlearning, we will discuss how you can validate whether the party calling your REST endpoint is sending the correct information in terms of the structure of the message. We will also learn how you can subsequently report back to the client that a validation error occurred. 12 12 13 -Should you have any questions, please get in touch with academy@emagiz.com. 6 +Should you have any questions, please get in touch with [[academy@emagiz.com>>mailto:academy@emagiz.com]]. 14 14 15 15 * Last update: September 8th, 2021 16 16 * Required reading time: 5 minutes ... ... @@ -39,11 +39,11 @@ 39 39 40 40 When adding or checking the XML validating filter, ensure that the checkbox (Throw an exception on rejection) is activated when the validation is done outside the all-entry. 41 41 42 - <p align="center">[[image:intermediate-rest-webservice-connectivity-validation--exception-on-rejection.png||]]</p>35 +[[image:Main.Images.Microlearning.WebHome@intermediate-rest-webservice-connectivity-validation--exception-on-rejection.png]] 43 43 44 44 As a result, the error handling will be triggered. In the case of an API Gateway solution, the error will automatically be given back to the previous step in the process. And since we advise validating the entry in case of messaging, we can send the message to the discard channel. Knowing that, we now need to follow that up. Since we need to give back the error to the client, the logical next step needs to happen in our all-entry. Here we need to make a distinction between validation errors and generic errors. We can do so by using an XPath router within the all-entry. 45 45 46 - <p align="center">[[image:intermediate-rest-webservice-connectivity-validation--xpath-router-configuration.png||]]</p>39 +[[image:Main.Images.Microlearning.WebHome@intermediate-rest-webservice-connectivity-validation--xpath-router-configuration.png]] 47 47 48 48 With the help of this configuration and a default output channel that leads to the generic setup (500 error), you can ensure that when an XML validating filter returns a validation error, you can define another HTTP status code and a different response body. You can use similar logic as with the generic setup for the 500 error. For specific information in setting that up please check out this [microlearning](intermediate-rest-webservice-connectivity-configuration.md). 49 49 ... ... @@ -51,8 +51,8 @@ 51 51 52 52 if (exists(//err:xml-validation-exception)) then 'validation' else if (exists(//err:exception[@class='org.springframework.integration.MessageTimeoutException'])) then 'timeout' else '' 53 53 54 -===== Practice ===== 55 55 48 + 56 56 == 4. Assignment == 57 57 58 58 Navigate to a flow within your (Academy) project in which you host a REST Webservice. ... ... @@ -77,9 +77,4 @@ 77 77 78 78 Please check out the store for a working example for a messaging solution. 79 79 80 -</div> 81 - 82 -</div> 83 -</div> 84 - 85 -{{/html}} 73 +)))((({{toc/}}))){{/container}}{{/container}}