Author Chris Thorpe | Technical Director and IBM B2Bi Specialist
IBM B2Bi: Lessons from the Field
I regularly get asked to review IBM B2Bi implementations for a variety of reasons — sometimes a tune-up, a health check, or performance issues that have crept in over time. In other cases, the system has simply never met its original expectations, and users describe it as running slowly or feeling heavy.
What I’ve learned is that sometimes the simplest things make the biggest difference — and other times it’s a combination of small factors that, when brought together in the wrong way, quietly work against each other in surprising and unpredictable ways.
Steps Taken
The first step is always a holistic overview — understanding what the organisation is actually trying to achieve with its B2Bi system. It’s important to avoid the temptation to dive too deep, too quickly. Without that context, you risk optimising the wrong thing.
Sterling File Gateway (SFG), for example, is an IBM-provided framework of services and processes. While that consistency is one of its strengths, it also means many systems share common issues. Frameworks create structure and standardisation — but they can also inherit the same bad habits if not managed carefully.
From there, I move through a few core questions:
– Is the system storing the correct amount of data in the right places?
– Is Control Center attached, and what’s its configuration? Is it collecting too much data?
– Is persistence set appropriately to support stability without overloading the database?
– Is the environment cluttered with ignored errors or halted processes with no purpose?
Next Steps
Once the overall picture is clear, the next step is to assess whether the installation and implementation are appropriate for the job at hand. This means looking at expectation versus reality — what the system was designed to do compared to how it’s actually being used.
Start by checking the fundamentals:
– Is the installation right-sized? Does the system have enough cores, and if clustered, are they functioning correctly?
– Is the database keeping up? Run a dbstats report to check for data litter, missing index rebuilds, and growth patterns.
– Review memory and performance tuning. Increasing memory on the database alone can make a dramatic difference.
DBAs often underestimate the churn B2Bi produces. Drive speeds, log sizes, and storage locations can all have a massive impact on performance.
Shared Services — The Hidden Variable
One of the most overlooked factors in performance reviews is shared infrastructure. Shared disks, shared databases, and shared virtual architectures all have a measurable impact on B2Bi — often in ways that aren’t obvious at first.
When analysing performance, go deeper than you think you need to. It’s not always the configuration inside B2Bi that’s the problem — it’s what’s happening around it. For example, quiet-time processing might overlap with database backups or overnight batch jobs on other systems, causing contention.
Reports can tell you what’s happening, but they don’t show how it feels. The person reading the report might not experience the operational pain the team lives with daily. That’s why combining observation, timing, and context is vital to diagnosing shared service issues.
Reviewing Business Processes
Once the environment is stable, focus on the quality of the business processes themselves. It’s a good idea to capture everything — processes, maps, and services — and put them under version control in Git. That way, you can later build CI/CD improvements around them.
Start by identifying the worst offenders. Use SQL on the workflow_context table to compare start and finish times or step counts. Sometimes, a quick scan through the BPML reveals inefficiencies.
Common issues include:
– Bad XPath usage — inefficient queries can slow processing drastically.
– Uncontrolled loops — hidden performance killers that scale unpredictably.
– Lack of releases — unreleased documents clog memory and persistence.
– Overly complex BPML — processes behaving like code rather than workflows. Simplify logic, use maps or XSLT where possible, and keep Java user exits concise.
Performance Tuning
There are countless documents and opinions on tuning B2Bi. The truth is, it’s part science and part art. Every environment behaves differently, but with structured thinking, some basic tuning can go a long way.
Categorise processes — not all behave the same:
– System processes: stable, predictable.
– Loops and high-iteration workflows: often have competing demands.
– Lightweight CPU, high I/O: like SFTP transfers.
– Heavy CPU: encryption or large mappings — control concurrency carefully.
Thread and Queue Allocation
Once processes are categorised, assign them to appropriate B2Bi queues. At a high level, the number of threads a system can handle is roughly core count multiplied by four or eight. A two-core system might therefore support 8–16 total threads.
These threads are distributed across nine internal queues. Each queue receives a share based on ResourceAllocation, MinPool, and MaxPool values. Idle queues release threads back to the pool automatically.
Processes normally stay within their assigned queue. Execution runs for a set number of steps defined by AE_ExecuteCycle before re-queuing. Be cautious with AE_ExecuteCycle — values set too low can disrupt FIFO order or cause processes to stall unnecessarily.
With control comes responsibility. It’s possible to raise limits — for example, setting 64 threads on a two-core system — but it’s rarely advisable. Still, without flexibility, you can’t fine-tune effectively.
Example queue allocation strategy:
– Q3 – Heavy CPU
– Q4 – System processes
– Q5 – Loops or production workflows
– Q6 – General processing
– Q7 – High I/O
This allows CPU to be controlled via Q3’s Max setting, I/O via Q7’s Max, and ensures critical system tasks on Q4 always have resources. High AE_ExecuteCycle values generally maintain flow; low ones can cause unnecessary pauses or out-of-order execution.
Queue Categorisation and Control
After reviewing hundreds of B2Bi systems, one truth stands out — performance and reliability rarely hinge on a single issue. It’s usually a collection of small misalignments compounding over time.
Tuning B2Bi isn’t about chasing speed; it’s about understanding intent, behaviour, and architecture. When you start grouping processes, balancing queues, and applying consistent logic, the platform starts to breathe again.
Most improvements come from insight, not new features. The system already contains what it needs — it just takes understanding and thoughtful application.
The real power of B2Bi comes from knowing it deeply — and shaping it to fit your business, not the other way around.
Related Articles
