Author Piyush Chamat | Coliance B2Bi Consultant

"Unveiling the Menace: Runaway Processes and the Looping Threat to IBM B2Bi"

Imagine a scenario where a single program goes rogue, devouring system resources like a voracious beast. It engulfs CPU time, gobbles up memory, engenders disk I/O chaos, and overwhelms network bandwidth, leaving your system gasping for breath.

This insatiable consumption can lead to unresponsiveness or even crashes, resulting in significant performance issues and rendering the system unusable. In certain situations, manual termination of the runaway process becomes necessary to restore normal operation.

Regular monitoring of system resources and components is crucial to ensure they remain under control. By proactively keeping an eye on resource usage, you can identify potential runaway processes early on and take necessary steps to mitigate their impact.

Join me today, as we explore effective strategies to prevent runaway processes, maintain system stability, and enhance overall performance: 

How does a runaway process happen?

The occurrence of a runaway process can be attributed to numerous factors, including:

  1. Programming Error or Bug
  2. Conflict between Different Programs.
  3. Malicious Attack
  4. Hardware Failure
  5. Insufficient System Resources

In the context of IBM B2Bi, we will be focussing on factor “Programming Error or Bug” in this article, as other factors are well managed in robust B2Bi infrastructure.

What are the causes of runaway processes in business processes?

When it comes to runaway processes within business processes, the underlying cause often lies in uncontrolled looping. This phenomenon occurs when loops implemented in BPML (Business Process Modelling Language) go awry, causing the business process to execute indefinitely. But what leads to these looping mishaps, specifically in the context of business processes?

  • Improper Exit Condition: One common scenario is when the exit condition for the loop is never reached. This can happen when, for example, a count is not decremented, or an item is not removed as expected. Additionally, using a relative path instead of an absolute path for the exit condition can cause the loop to either not change the condition, skip it altogether, or proceed in the wrong direction.
  • Unclear Exit Condition: Another culprit is the lack of clarity in defining the exit condition. A typical mistake involves using an alphanumeric comparison instead of a numeric one, leading to unexpected results. For instance, in an alphanumeric comparison, “10” would be considered less than “2,” causing a loop to continue indefinitely. Such scenarios may appear to work in certain cases but can fail when deployed in a production environment.

To mitigate these errors, it is crucial to adopt a clear and consistent approach in your decision-making.

Ensuring that your exit conditions are properly defined and employing a unified method for handling loops can help minimise the occurrence of runaway processes within business processes.

One way to combat errors is to be clear in your choices use a consistent approach every time.

Below are few use cases that illustrate each of the instances mentioned above and shed light on how they can contribute to runaway processes:

Use Case 1: Improper condition for termination(exit)

To facilitate effective loop handling and minimise the risk of runaway processes, it is beneficial to adhere to the following skeleton:

01

Add a Rule: Specifies when to stop looping, favouring numeric comparisons using the number/count function instead of relying on alphanumeric comparisons with ">" or "<" operators. 

02

Evaluate a Condition/Rule: It is advisable to maintain consistency by using the same logical name across Choice Name, Case Reference, Activity, and Sequence Name. For example, "ForEachMsg" used throughout loop skeleton.

03

Handling Released Processed Variables: To prevent the reprocessing of the same data, it is advisable that data being processed is clean. Also, reduce the value of counter variable to reach to a condition closer to true. This approach ensures efficient management of data and avoids redundant processing.

04

Iteration and Looping: This step directs the control flow back to the next iteration, allowing the revaluation of conditions for subsequent variables and values. It is advisable to use the choice name as a reference name for clarity and consistency in the process.

05

Loop Exit Condition: This specifies the condition that determines when the loop should terminate. The loop should continue as long as a specific condition remains true, and it should exit promptly when the condition becomes false.

Let's consider an example scenario:

We have a mailbox named “Migration” containing multiple messages.

Our requirement is to identify and list all messages that match a specific filename pattern, such as “*.CRM0004.txt“, and process them individually. Within the “/Migration” directory, there are four messages present, each with a different filename. Out of these, two messages meet the specified criteria.

To achieve this, we implement a loop operation that iterates through the matching messages and invokes a child business process for each message. This diagram demonstrates the step-by-step execution flow for processing the identified messages within the loop. 

Processing Data within the Loop Execution:

During the loop execution, it is evident that there are two eligible messages that match the specified pattern “CRM0004“. The loop will iterate over these messages, allowing for their individual processing.

Processing Data after the First Iteration:

After the completion of the first iteration, the initial message is released, resulting   in a count of 1.

Processing Data after Loop Exit:
After the Loop Exit, the first message is once again released, resulting in a count of 0. This signifies that the “do nothing” route is taken within the choice, leading to the exit from the loop.

Use Case 2: Utilising Relative Path instead of Absolute Path

Another common error that arises in this context is when the services or adapters are not configured to use an absolute path, it can lead to unintended access of incorrect elements or XML tags. This programming error causes the execution to continue indefinitely.

For example, the following scenario where you intend to access the first “Message” tag within the “SplitMessage” XML tag. 

It is imperative for programmers to refrain from utilising relative paths, such as //Message/text(), as it can lead to unintended consequences. In this particular case, using //Message/text() will result in listing all six values found within the six Message tags, including: 

To ensure the desired outcome, it is essential to employ appropriate path specifications and carefully consider the desired elements to be accessed by using absolute paths, such as /ProcessData/SplitMessage/Message[1]/text(), to achieve the intended outcome. In this specific scenario, using the absolute path mentioned will result in listing the exact value present inside the appropriate Message tag: 

By employing absolute paths, programmers can ensure precise access to the desired elements within the data structure.

Advanced Strategies to Prevent Runaway Processes in B2Bi:

To effectively mitigate runaway process issues in B2Bi, implementing the following strategies:

  • Thoroughly validate & Control Input Data: Validate and sanitize all input data before processing it within your BPML workflows. This helps prevent unexpected data errors or malicious inputs that could cause a process to go into an infinite loop or consume excessive resources. Implement strict input validation rules and apply appropriate error handling mechanisms for invalid data.
  • Implement Business Process Monitoring: Incorporate process monitoring capabilities into your B2Bi environment. This can involve using monitoring tools or implementing custom logging mechanisms to track the progress and performance of running business processes. Monitoring allows you to identify any potential issues, including runaway processes, and take corrective action in a timely manner.
Advanced Strategies to Prevent Looping in BPML:

To effectively mitigate looping issues in BPML, implementing the following strategies:

  • Limit Recursion and Loops: Be cautious with recursive and loop structures in your BPML processes. Ensure that loops have appropriate exit conditions, and that recursion depth is bounded to avoid excessive resource consumption. Recommended Value for Max Loop Count is 250 or 300. For example, if you have 1200 records that need to be iterated upon, instead of processing all 1200 records at once, consider splitting them into 4 batches each of 300 records.

 

  • Use Variables for Loop Control: Variables play a vital role in controlling loops. Typically referred to as a “counter,” these variables can be modified within the loop to ensure the loop continues or terminates as required. It is crucial to ensure that you move closer to the exit condition with each iteration of the loop.

 

  • Data Cleaning:  This plays a crucial role in preventing looping issues within a system. By ensuring that the data being processed is clean, valid, and error-free, you can mitigate the risk of loops caused by erroneous or inconsistent data.

 

Incorporating these advanced strategies into your BPML processes not only helps prevent looping issues but also enhances the overall reliability and efficiency of your workflows. By being proactive in addressing looping concerns, you can ensure the smooth execution of your processes, improve productivity, and deliver consistent results. If you require assistance or expertise in managing and optimising your BPML workflows, Coliance are here to help. With our specialised knowledge and experience, we can provide valuable guidance and support.

Related Topics

B2Bi

Unlocking the Power of B2Bi Middleware in a Hyper-Connected Business...

Read More

Author Piyush Chamat

Coliance B2Bi Consultant

Let's get started

Book a consultation

Contact Us

Coliance © 2023 All rights reserved