The DataPower B2B Gateway is a different beast from the API Gateway. It processes high-volume, high-value B2B transactions — purchase orders, invoices, shipping notices, payment instructions. When a B2B Gateway goes down or slows down, the ripple effect hits trading partner integrations immediately. The Royal Mail DataPower B2B case involved a firmware upgrade that inadvertently triggered a RAID re-initialisation, corrupting the B2B transaction log and requiring a full re-synchronisation with three trading partners. It took two days to resolve and generated significant financial exposure for the customer.

This article covers the two highest-impact operational issues in DataPower B2B Gateway: RAID storage management and SFTP connectivity regressions after firmware upgrades.

1. B2B Persistence and RAID Volume: How It Fills

The DataPower B2B Gateway stores transaction data — AS2 messages, MQTT payloads, EDI documents — on a RAID volume before processing. The lifecycle:

  1. Receipt: Incoming document received from partner → written to RAID
  2. Processing: Document is processed, transformed, routed
  3. Acknowledgement: Partner acknowledgement received → document marked complete
  4. Purge: Completed documents are purged from RAID on a configurable schedule

How it fills up:

  • High transaction volume without corresponding acknowledgement receipt
  • Partner system downtime (acknowledgements not received → documents not purged)
  • Purge schedule too infrequent for transaction volume
  • RAID volume too small for the B2B transaction throughput

Monitoring RAID consumption:

# DataPower CLI — check RAID status
show raid

# Example output:
# RAID Array: 0
#   Status: Online
#   Volume: b2b-raid
#   Total Size: 500 GB
#   Used: 487 GB  (97.4%)
#   Free: 13 GB
#   State: ONLINE

# Check B2B transaction store
show b2b-transaction-store-usage

# Example:
# Total transactions: 1,847,293
# Pending: 12,847
# Completed: 1,834,446
# Failed: 0

At 90%+ RAID utilisation, you should be actively monitoring and planning purge. At 95%+, you are in emergency territory.

2. RAID Full Emergency Procedure

The correct sequence is critical:

Step 1: Do NOT restart DataPower while RAID is full

Restarting DataPower with a full RAID can cause the firmware to attempt a RAID consistency check (CHKDSK equivalent) which can take hours on a large volume and will block all B2B processing.

Step 2: Purge transactions first

# DataPower CLI — purge completed transactions
# This removes transaction records and their attachments from the RAID
# Does NOT delete documents that have not received partner acknowledgement

b2b purge completed --older-than 7d
# Purge transactions completed more than 7 days ago

# If you need to be more aggressive:
b2b purge completed --older-than 1d
# Purge all completed transactions older than 1 day

# Verify purge completed
show raid
# Used space should have decreased

Step 3: Reinitialise RAID filesystem (only if purge didn’t free enough space)

# Reinitialize RAID filesystem — THIS WILL DELETE ALL UNACKNOWLEDGED TRANSACTIONS
# Only use this if RAID is critically full AND purge cannot free enough space
# AND you have confirmed with business owners that unacknowledged transactions can be resent

raid initialize force

# After initialization, DataPower will restart
# All pending (unacknowledged) transactions will be lost — partners will need to resend

Why order matters: Purging first frees space without data loss (completed transactions are already acknowledged, so the business has them). Reinitialising deletes everything. If you reinitialise first and then restart, you may have lost the audit trail for transactions that were in-flight at the moment of restart.

Post-purge/reinitialisation health checks:

# Verify RAID is online and has free space
show raid

# Verify B2B transaction store is operational
show b2b-transaction-store-usage

# Verify B2B services are processing
show b2b-connection-status

# For AS2 partners specifically:
show as2-status

3. Temporary Measures While RAID Is Full

If you cannot immediately purge (e.g., waiting for partner acknowledgement batches to arrive):

Option 1: Configure emergency purge to run more aggressively

# Temporarily change purge schedule to run hourly instead of daily
# This is a configuration change on the B2B domain:
configure
b2b
purge-schedule interval 3600  # Run purge every hour (3600 seconds)
exit

Option 2: Redirect logging to a secondary location

If your B2B configuration allows it, temporarily configure transaction logging to a different volume while the primary RAID recovers.

Option 3: Request partners pause transmissions

Contact key trading partners (SIBS payment network, Royal Mail, Haleon/GSK cluster partners) and request a temporary pause in non-urgent transmissions while you clear the backlog. Most B2B partners have a mechanism for this and will accommodate a planned pause.

4. SFTP Connectivity Regression in DataPower 10.6.0.x

The Haleon/GSK DataPower B2B cluster case and the SIBS payment network cases both involved a regression introduced in DataPower firmware 10.6.0.x where SFTP connectivity to previously-working trading partners started failing.

Symptom: SFTP handshake fails to a partner endpoint that was working before the firmware upgrade:

SFTP connection to partner sftp://190.187.122.164:1022/ failed
Key exchange algorithm negotiation failed: no common algorithm
Remote server supports: diffie-hellman-group14-sha256,diffie-hellman-group-exchange-sha256
Local client supports: diffie-hellman-group14-sha1

Root cause: DataPower 10.6.0.x changed the default list of supported key exchange algorithms (KEX algorithms) for SFTP. Specifically, diffie-hellman-group14-sha1 was removed from the default list because SHA-1 is considered cryptographically weak. Some trading partner SFTP servers had not updated their key exchange algorithms and were still offering only SHA-1-based algorithms.

The error message pattern to watch for:

Key exchange algorithm negotiation failed: no common algorithm

Workaround — add SHA-1 back to the allowed KEX list:

# DataPower CLI — configure SSH/KEX settings for SFTP
configure
ssh
# For SFTP client connections:
sftp client kex diffie-hellman-group14-sha1,ecdh-sha2-nistp256,ecdh-sha2-nistp384,ecdh-sha2-nistp521
# WARNING: This lowers the security of SFTP connections
# Only use for specific partners who have not updated their servers
# Remove after partner upgrades their SFTP server
exit

[VERIFY: Exact DataPower CLI command syntax for adding KEX algorithms to SFTP client configuration in firmware 10.6.0.x — confirm via IBM DataPower release notes and firmware documentation]

The correct long-term fix: Work with the affected trading partner to upgrade their SFTP server to support SHA-256 based key exchange algorithms. This is the only standards-compliant resolution.

5. Testing B2B Partner Connectivity After Firmware Upgrade

Before declaring a B2B Gateway firmware upgrade complete, test connectivity with every trading partner. The Haleon/GSK cluster had seven partners and the upgrade was declared complete after testing two. Three partners called within 24 hours to report failed transmissions.

Post-upgrade B2B connectivity checklist:

# 1. Verify RAID is healthy (from Section 2)
show raid
# Status should be: Online, Used < 80%

# 2. Verify all B2B services are running
show b2b-services

# 3. Test SFTP connectivity to each partner
# For each partner SFTP endpoint:
sftp -o StrictHostKeyChecking=no -o ConnectTimeout=10 \
  -i /path/to/partner-key.pem \
  partner-user@partner-sftp-host
# If connection succeeds, type "quit" immediately

# 4. Test AS2 connectivity (if applicable)
show as2-status
# Verify MDN (acknowledgement) receipts for each partner

# 5. Verify MQTT broker connectivity (if applicable)
show mqtt connections

# 6. Run a test transaction through the full B2B pipeline
# Use the B2B test message feature or send a known document
# Verify acknowledgement is received within expected window

# 7. Confirm with each partner that they received your test transmission
# Don't rely on your own monitoring alone — confirm with the partner

6. Sizing Recommendations: Calculating Right RAID Persistence Size

The right RAID size for a B2B Gateway depends on three variables:

B2B RAID sizing formula:

Required RAID Size (GB) =
  (Avg Transaction Size KB × Daily Transaction Volume × Retention Days)
  ÷ 1,048,576
  + 20% Safety Margin
  + B2B Firmware Overhead (~10 GB)

Example — SIBS payment network:

  • Average transaction size: 15 KB (AS2 + EDI envelope)
  • Daily transaction volume: 50,000 transactions
  • Business requirement to retain for 30 days (audit/reconciliation)
  • Safety margin: 20%
Required RAID = (15 KB × 50,000 × 30) ÷ 1,048,576 + 20% + 10 GB
             = 22,500,000 KB ÷ 1,048,576 + 20% + 10 GB
             = 21.5 GB + 20% + 10 GB
             = 25.8 GB + 10 GB
             = ~36 GB minimum

For high-volume B2B networks like SIBS, Royal Mail, or Haleon’s partner network, daily volumes can reach hundreds of thousands of transactions. RAID sizes of 500 GB to 1 TB are not unusual.

Monitoring for B2B environments:

Set up proactive alerting on RAID utilisation:

  • Warning: 75% RAID utilisation
  • Critical: 90% RAID utilisation
  • Emergency: 95% RAID utilisation — immediate purge or partner communication required

Next: “API Connect Webhook and Gateway Service Health: Catching the Silent Disconnect Before It Becomes a Sev-1” — covering the Vietnam Joint Stock Commercial Bank pattern, apic-gw-service monitoring, and proactive alerting strategies.