Working with flow services

• Predefined connectors are used to establish connections to SaaS providers.
  Note: A few connectors are deprecated in this release. A deprecated connector displays the Deprecated label where ever it appears in the user interface IBM® fully supports deprecated connectors, which continue to work as before. If you are using deprecated connectors in your existing workflows or flow services, they work as expected. No new feature enhancements are made for deprecated connectors. If you are creating new workflows or flow services, use the provided alternative connectors instead of the deprecated connectors. The deprecation is applicable for Actions. The deprecation is not applicable for Triggers, that is, triggers are supported for both deprecated and alternative connectors. For the list of triggers, see the documentation for alternative connectors.
• REST connectors. Enable the definition of REST resources and methods for creating custom REST connectors. REST APIs can be initiated in flow services that use REST connectors.
• SOAP connectors. Displays custom SOAP connectors. Custom SOAP connectors provide access to third-party web services that are hosted in the cloud or on-premises. A SOAP API can also be started in a flow service that uses a SOAP connector. You can also start a SOAP API in a flow service by using a SOAP connector.
• On-Premises connectors. On-Premises applications uploaded from on-premises systems.
• Flat file connectors. Displays the Flat file connectors created either manually or from a sample file.

• Sequence. Use the sequence when you want to group steps and make sure that they run in a specific order.
• If. Use the If statement to return one value if a condition is true and another value if it's false.
• If Else. Use the If statement to return one value if a condition is true and another value if it's false. Else runs if the result of a previous test condition evaluates to false.
• Else If. The If step evaluates a Boolean condition. If the condition is true, the flow runs the statements inside the If step. You can follow the If step with an Else step, which runs when the condition is false. The flow processes If statements in sequential order. You can also nest one If or Else If statement inside another to handle more complex conditions.
• Nested Condition. Nested conditions comprise condition statements that are contained within other condition statements. Conditions consisting of multiple statements are connected by using the logical AND and OR operators.
• Loop. Runs a set of steps multiple times based on the selected block. It runs a sequence of child steps for each element in a specified array. For example, when a pipeline contains an array of purchase-order line items, a Loop processes each line item in the array. Loop uses an input array that holds individual elements for one or more steps in the Loop. At run time, the Loop runs once for each member in the specified array. For example, a Loop that processes each line item in a purchase order uses the document list of line items as its input array.
  • Repeat. The repeat step iterates on an array and the number of executions is equal to the size of the array.
  • Repeat for Count. Repeat for count specifies the maximum number of times webMethods Integration re-runs the child steps in the Repeat step. If the count is set to 0, the Repeat step does not re-run the child steps. If the count is set to any value > 0, the Repxeat step re-runs the child steps up to this number of times. Child of a Repeat step runs at least one time. The count property specifies the maximum number of times the children can be re-run. The concept is the same as Repeat for each. The difference here is that you iterate for a specific count. It can be specified directly on a step or through a variable (I/O or pipeline).
  • Repeat for input-output. The concept is the same as Repeat for each. The difference here is that you can iterate on two different arrays concurrently.
  • Use the While loop to repeat a part of the program multiple times. When the number of iterations is not fixed, the While loop provides a flexible way to continue execution if a condition remains true.
  • Do Until. Do until loops are similar, except that they repeat their bodies until some condition is false.
  • Break. Use the Break step within a loop. It stops execution within the containing loop and exits. In nested loops, the Break step first exits the inner loop and then continues with the outer loops. Child steps cannot be attached to the Break step.
    Note: An infinite loop triggers a default timeout that is configured in webMethods Integration. If the time taken for execution exceeds this limit, the flow service execution is stopped. Contact your administrator to customize the default timeout.
  • Switch case. A switch statement compares a variable against a list of values, called cases. It runs the first matching case and then exits. A default case placed last, runs if no other case matches. Only one default is allowed. Cases can handle null (when the variable is missing or explicitly set to null) and empty strings (when the variable exists but has no value).
  • Exit. The Exit flow service step is used to stop the execution of a flow service and indicate either a successful or failed outcome.

    (Success) The Exit flow service step that signals success stops the currently running flow service and indicates that it has completed successfully. Child steps cannot be attached to this step.

    (Failure) The Exit flow service step that signals failure stops the flow service abnormally and indicates a failure. A custom failure message can be specified for display. To include the value of a pipeline variable in the message, enclose the variable name in % symbols. For example: %mymessage%.

  • Branch. A Branch step conditionally runs one of several child steps based on the value of pipeline variables. It evaluates each condition (called an expression) in order and runs the first one that evaluates to true. If no expressions match, a default step can be used to handle unmatched cases.

    At run time, the Branch evaluates the conditions that are provided and runs the first expression whose condition is evaluated to true. If none of the expressions are true, the default expression if included, is run.

    If you want to complete different actions on different values of one or more pipeline variables, use the Branch construct. In the following example, action is a pipeline variable created that uses the Define input and output fields dialog.

    The Branch contains two conditional expressions and a default expression.

    Scenario 1

    If the value of the action starts with mult, webMethods Integration evaluates the first expression (action = /^mult/) and runs step 3, that is, performs the multiplication operation.

    Scenario 2

    If the value of the action is addition (action == "addition"), then the Branch starts its execution from step 2. As step 2 evaluates to false, execution moves to the next expression, Step 4. Because Step 4 is evaluated true, Step 5 runs, performing the addition operation. Remaining expressions in the Branch, if any, are ignored and the execution falls through to the next step after the Branch in the flow service.

    Scenario 3

    Assume that the value of action is subtraction. The Branch then starts its execution from Step 2. As webMethods Integration evaluates Step 2 to false, the execution moves to the next expression, Step 4. webMethods Integration evaluates Step 4 to false, and then proceeds to evaluate Step 6 ($default). It then runs Step 7, causing the execution to exit the flow service.

    Key points to consider for Branch steps.

    If you are specifying a field in a document or in a document reference, format it as document/documentVariable. For example, if you want to specify a field name from the document employeeProfile, then format it as employeeProfile/name.

    If you specify a literal value in an expression, the value you specify must exactly match the runtime value of the pipeline variable. Further, the value must be case-sensitive.

    webMethods Integration runs only the first target step whose expression evaluates to true. If none of the expressions evaluate to true, none of the child steps start. Without a default expression, execution then falls through the next step in the flow service.

    If you want to prevent the execution from falling through a Branch step when an unmatched value occurs at run time, include a default target step to handle unmatched cases. Branch can have zero to many default expressions. webMethods Integration runs the first sequentially encountered default expression.

    The default step does not need to be the last step of a Branch but webMethods Integration always evaluates the default step at the end.

    Any step other than an expression cannot be a direct child of a Branch step. Further, you cannot add the expression step anywhere outside a Branch. If you are branching on expressions, make sure that the expressions you assign to the target steps are mutually exclusive. In addition, do not use null or empty values for branching on expressions. webMethods Integration ignores such expressions and does not display any errors. You can provide multiple conditions for each expression and can also use regular expressions, for example, /^mult/. The expressions that you create can also specify a range of values for the variables.

    Specify the value of the variables in the expressions, as mentioned in the following table.

    To Match...	Specify...
    That exact string	A string
    The string representation of the object’s value. Example for Boolean object - true. Example for Integer object - 123.	A constrained object value
    The regular expression specifies criteria that a string must match. Example /^REL/.	A regular expression
    An empty string	A blank field
    A null value	$null
    Any unmatched value (that is, run the step if the value does not match any other label)	$default

• Try, Catch, Finally. You can use these steps to try a sequence of flow service steps, catch and handle any failures that occur, and then run any cleanup work. Before adding the Try, Catch, and Finally steps to a flow service, decide which usage pattern you want to use. The pattern can be a Try-Catch, a try-finally, or a Try-Catch-Finally. Identify the logic for which you want to provide exception handling. The steps for this logic belong in the Try step. Then, decide whether you want to handle exceptions and if so, which ones. Catch steps can handle all exceptions or specific exceptions. If the service handles exceptions, what recovery logic or logging needs to be added? Lastly, identify any cleanup logic that you want the service to run, that is, decide whether you need to include a Finally step.

  The general usage pattern for try-catch-finally is a single Try step followed by zero or more Catch steps, followed by zero or one Finally step. Catch steps can be configured to handle specific failures. The Finally step runs a set of steps after a Try step completes successfully or fails. If a Catch step runs, webMethods Integration runs the Finally step after the Catch step completes.

  The Try-Catch usage pattern consists of a single Try step followed by one or more Catch steps. The Try step contains any number of child steps to be run. The Catch step contains any number of child steps to be run if the Try step fails.

  The Try-Finally usage pattern consists of a single Try step followed by a Finally step. The Try step contains any number of child steps to be run. The Finally step contains any number of child steps to run regardless of the outcome of the Try step. The Try-Finally usage pattern does not handle any failures that occur in the Try step. As a result, any failure from the Try step remains to pend. After the Finally step completes, webMethods Integration propagates the failure to the parent flow step of the Try step if the Finally step completes normally. The Try-Catch-Finally usage pattern is a combination of Try-Catch and Try-Finally. A Try-Catch-Finally structure includes a Try step that attempts the main logic. One or more Catch steps to handle any failure that occurs and run recovery logic. The pattern is followed by a single Finally step to complete any clean-up.

  The Finally step contains logic that is run regardless of whether the Try step succeeds or fails. Often, the Finally step contains clean-up logic that needs to run regardless of the outcome of the preceding Try or Catch steps.

• Throw error. You can attach the Throw error step inside any step except the catch section of the try catch step. You can explicitly throw an exception with a custom error message. If you use this step inside the try section of the try catch step, the error is detected in the catch section. If you use the value of a pipeline variable for this custom error message, type the variable name between % symbols, for example, %mymessage%. The variable that you specify must be a String. You cannot attach child steps to the Throw error step.

  If a Throw error step runs inside a Try-Catch step, it resets any changes that are done to the pipeline variables within the Try step. The pipeline variables revert to their previous values.

When multiple transformers are added, the Transform Pipeline step behavior is as follows.

• All transformers are contained within a Transform Pipeline step and do not appear as a separate flow service step in the editor.

• All transformers are independent of each other and do not run in a specific order.

Therefore, the output of one transformer cannot be used as the input to another transform. These characteristics make the Transform Pipeline step different than of a normal step in a flow service.

A service takes input parameters, which are the necessary field names and types. It generates output parameters with specific field names and types. Together, these parameters form the service signature.