XML Handling in WebMethods

Click the below button to Download XML- 

1.  invoke pub.xml:xmlStringToXMLNode which will generate the node object and map inputXml to the xmlData variable.
   
   
   

    

2. invoke pub.xml:xmlNodeToDocument which will convert the node object to document and perform the below mappings.
   1. map input node to the node(it will be auto mapped as the variable names are same , it is called implicit mapping)
   2. In the pipeline out right-click click insert and select document reference, it will ask you to select the document to which you want to refer, select the document which was created using xsd, and name it Employee then map the output document to Employee document.
      
      
      

       

   3. Copy the Employee document from the docType folder so that the full path will be copied to the clipboard and hard code the value into dcoumentTypeName field in the Service In.
      Note : When explicitly specifying the documentTypeName, it instructs the compiler to create a document with a structure identical to the designated document type. To avoid any potential exceptions, it’s important to additionally set the makeArray parameter to false. This ensures that the document is created as a single instance rather than as an array, facilitating proper handling and manipulation of the XML data within the flow service.
      
      

      

       

       

   4. Now double-click on makeArrays and select false.

      

       

3. Now we have created our document, which holds the structured data, we can utilize it for further mapping purposes. Since the “Employee” document represents a list of employees, we need to incorporate a loop step in the flow service. Set the inputArray property of the loop step to “Employee/EmployeeDirectory/Employee” to enable iteration through the employee list.
   
   
   

    

    

    

4. To remove the last name of the employee, we will use the pub.string:tokenize service in webMethods. We will invoke this service with the separator parameter set as a space (” “), which will split the full name of the employee into a list. By extracting the value at the 0th index of the list, we will obtain the first name. This first name can then be mapped back to the Name field, effectively removing the last name.
   
   
   
5. To update the phone number, we will first check if “+91” is present at the beginning of the phone number. To perform this check, we will use the pub.string:substring service in webMethods. We will invoke this service, mapping the Telephone to the inString parameter and setting the beginIndex to 0 and the endIndex to 2. This will extract the first three digits from the phone number, allowing us to determine if it starts with “+91”.
   
   
   

    

6. To verify if the extracted value is ‘+91’, we will add a branch step to the flow service. In the branch step, we will set the switch property as the value variable so that at the run-time value of the variable will be checked.
   
   

   

    

    

7. As we have discussed in the Branch tutorial, when using the branch step as a switch, we need to provide the exact expected value that will be evaluated at runtime in the child label. Therefore, in our case, we will configure the child label of the branch step with the variable name containing the extracted value, enabling us to evaluate it against the specific expected value of ‘+91’.
8. Inside the branch step, we will include two map steps. In the first map step, set the label to ‘+91’ to handle the scenario when the extracted value matches ‘+91’. In the second map step, set the label to ‘$default’ to handle all other cases that do not match the expected value.
   
   

   

    

9. To append ‘+91’ in case it is not present, we will add the pub.string:concat service as a transformer to the $default map step. In the pub.string:concat service, we will set inString1 to ‘+91’ (hardcoded value) and inString2 to be mapped from ‘Employee/EmployeeDirectory/Employee/Telephone’.
   
   

   

    

    

10. Now we need to validate the updated document against the schema so after the loop step invoke pub.schema:validate step and perform the below mapping:
    1. Map Employee document to object in the validate step service input.
    2. Hard code conformsTo variable with the full path of the Emploee document, you can copy the path and paste it into the confirmsTo variable.
    3. To retrieve all errors in the requested document at once, set the maxErrors parameter to ‘-1’. This configuration ensures that all errors present in the document are returned in a single run, rather than encountering and fixing one error at a time.
       
       
       

        

11. The pub.schema:validate service will provide two main outputs. Firstly, the isValid flag will indicate the validation status, with a value of true or false. Secondly, the errors document list will contain a collection of errors encountered during the validation process. 
12. To verify the success of the schema validation, we will incorporate a branch step in the flow service. This branch step will utilize the isValid flag as the switch property, allowing us to evaluate whether the validation process was successful or not.
13. Within the branch step, we will include a Sequence step to accommodate multiple operations in case of validation failure and a DebugLog step to write a log entry to the server log when the validation is successful.
14. To configure the DebugLog step, set the label to true within the branch step. Additionally, hard code the message to “Employee Data validated successfully”.
    
    
    

     

15. Set SEQUENCE label to false and follow the below steps to extract error and log.
    1. Add one map step and in the pipeline out create a document structure like below mentioned in the screenshot.
       
       
       

       
       Note : Since the errors variable is a list of documents, directly converting it to a string would result in considering only the first index. To ensure accurate extraction of error details, it is preferable to create a document structure and then map the error information accordingly. While it is possible to loop through the error list and extract details individually, for this scenario, our intention is to extract all error information at once and convert it into a single string. This string will then be utilized for logging purposes, consolidating all error details into a comprehensive log entry.

    2. Add one map step and map errors document list to the Error/Errors.
       
       

        

    3. Invoke the pub.xml:documentToXMLString service. In the service input, we will map the Error document to the document parameter, allowing the entire error document to be converted into XML.
       
       
       

        

    4. To log the schema validation error, we will add a DebugLog step. In the DebugLog step, set the message as “Schema validation error occurred. Error: %xmldata%”. It is important to ensure that the variable substitution option is checked so that the %xmldata% placeholder will be replaced with the actual value of the xmldata variable at runtime.
16. Now, execute this service with the input XML that was downloaded at the beginning of this exercise. By running the service with the provided XML input, we will trigger the XML handling operations.
    
    
17. To test the validation error scenario, you can click the download button below to obtain the XML file. Once downloaded, execute the service by providing this XML file as input. 
    

     

18. Now see the output it got failed with schema validation Error

    

    To obtain the source code, simply click on the download button below to initiate the package download. This will allow you to access and save the code files for further reference😊.