Exit Step in WebMethods

• Purpose: The “Exit” step is primarily used to prematurely exit a flow service or a specific branch within the flow based on certain conditions or requirements.
• Exit Types: The “Exit” step supports different types of exit conditions, including “success,” “failure,” “done,” or custom conditions defined using expressions or variables.
• Success Exit: When the “Exit” step is configured with the “success” exit type, it allows you to exit the flow service or branch only if all preceding steps have been executed successfully.
• Failure Exit: If the “Exit” step is set to the “failure” exit type, it enables you to exit the flow service or branch when any preceding step encounters a failure.
• Done Exit: The “done” exit type allows you to exit the flow service or branch when the execution of all preceding steps has been completed, regardless of success or failure.
• Custom Conditions: The “Exit” step also supports custom conditions based on expressions or variables. This allows you to define specific criteria for exiting the flow service or branch, providing flexibility in controlling the flow’s execution.
• Configuring the Exit Step: To configure the “Exit” step in webMethods, you typically specify the exit type and any additional conditions or expressions that determine the exit behavior.
• Placement in the Flow: The “Exit” step can be placed at any point within the flow service or branch, allowing you to exit the execution flow as per the desired logic or conditions.

• Comments: Adding comments to exit steps enhances the overall readability and maintainability of the service by providing clear explanations of each step’s purpose and functionality. This makes it easier for future developers or administrators working on the same service to understand and work with it effectively.
• Label: The exit step label properties in webMethods can be utilized to specify conditions for invoking the exit steps, allowing for more controlled execution within the service.
• Signal: Signal properties in webMethods exit steps offer two options for controlling flow and handling errors within the service execution.
  • FAILURE: Enabling the Signal “FAILURE” option in the exit step allows you to throw exceptions that can be caught and handled in the catch block of your service.
  • SUCCESS: By setting the exit step to signal “Success,” you can exit the current step and smoothly transition control to the subsequent step in the execution flow.
• Exit From: The “EXIT from” property in the webMethods exit step is used to specify the specific step or service to exit from within the flow or service invocation.
  • $parent: It allows for an immediate exit from the parent flow step, regardless of its type, ensuring a quick and unconditional transition in the execution flow.
  • $loop:  It enables a direct exit from the closest ancestor LOOP or REPEAT flow step, regardless of the nesting level, ensuring efficient flow control within the service.
  • $flow: It allows the Integration Server to exit parent flow steps until it reaches the top of the flow service. Setting the exit from value as “$flow” indicates that the Integration Server exits the entire flow service, providing a way to terminate the service execution at any desired point.
  • $iteration:  It facilitates exiting the current iteration of the nearest parent LOOP or REPEAT step. The Integration Server terminates the ongoing iteration of the parent step and proceeds to execute the next iteration of the LOOP or REPEAT step, ensuring smooth control flow within the service.
• Failure Message: When the “Signal Failure” option is enabled in an exit step, it provides the ability to specify a failure message. This message can be caught in a catch block as an error message, allowing for effective error handling and troubleshooting.

• • Create a flow service with the name exitStepDemo.
  • Create an input variable named “inputList” of type stringList to hold the list of inputs for the flow service.
    

     

  • Next, include a loop step in the flow service and configure it to iterate through the “inputList” by adding it to the input array for the loop step.
    

     

  • Inside loop step, incorporate a branch step and assign the “inputList” to the switch property. Additionally, remember to include a comment to provide relevant information about the purpose or functionality of the branch step.
    
    
    
  • Within the branch step, include a map step for handling the default condition and a sequence step specifically for processing the case when the value is 5. The map step will handle the default condition, while the sequence step will be utilized to retrieve the index and log the message, aligning with the specified requirement.
  • In the map step, set the level to “$default” to indicate it as the default condition. In the sequence step, set the level to “5” to specify it for handling the case when the value is 5.
    
    

     

  • Invoke the service “pub.math:subtractInts” and map the “$iteration” variable to both “num1” and “num2” inputs. Set the value of “num1” and “num2” as 1 since the list index starts from 0, while the $iteration starts from 1.
    
    

     

  • To log the message, invoke the service “pub.flow:debugLog” and ensure that the variable substitution checkbox is checked. Set the message as ” %inputList% found at position %value%”, where “%inputList%” represents the input list variable and “%value%” denotes the retrieved index value.
    
    

     

  • To exit the loop upon finding the desired value and prevent further iterations, set the signal property to “SUCCESS” and the “Exit from” property to “$loop”. This configuration ensures a successful exit from the loop step.
    
    

     

  • Let’s execute the service using the input values 1, 2, 3, 4, 5, 6, and 7 to observe and evaluate the resulting output.
    
    

     

    

     

• Create a copy of the “exitStepDemo” service in the same folder and rename it as “exitStepFailureDemo” to differentiate and maintain separate versions of the service.
• Please remove the debugLog step from the service, as it is no longer required for the intended functionality.
  

   

• Update the exit step by changing the signal to “Failure” and setting the “Exit From” property to “$flow”. Additionally, set the failure message as “%inputList% found at position %value%”, where “%inputList%” represents the input list variable.
• Save the service and proceed to execute it using the input values 1, 2, 3, 4, 5, 6, and 7. This execution will enable us to observe and evaluate the resulting output as per the defined logic and configurations.
  
  

   

  

   

• Upon execution, you will notice that the service has exited with an error, which aligns with our intended requirement and expected behavior.

We hope you found this article enjoyable. If you would like to explore the service further, please click the download button to obtain the source code for downloading😊.