Integration Platform, Resilience, and Quality

Challenge

A dozen MuleSoft apps, JBoss and Spring Boot services, and vendor syncs had accumulated platform debt: an old runtime, no DR configuration, credentials in request headers, and manual regression testing.

Approach

• ▸Migrated five integration apps to CloudHub 2.0 in July 2025, coordinated across every air-operations team; upgraded the Mule runtime to 4.9 and cleared tech debt (parent POM, trust store, email apparatus, async-scope timeouts).
• ▸Moved JBoss and Spring Boot builds from OKD v3 to v4; supported Kafka dead-letter topics in production.
• ▸Added disaster-recovery configuration for the NavBlue and Trax integrations (endpoints, CLI script, documentation) and a Trax 2.0 replica environment; hardened the Trax-to-NavBlue sync with a three-minute timer, an operating-count fix, duplicate-message handling, and post-production monitoring.
• ▸Converted API request headers to managed secrets; set up environment configuration and a feature flag for the CAE authentication token.
• ▸Built MUnit coverage for the charter sync and QA automation suites for Navitaire passenger sync, weight sync, CAE sync, SSIM validation UI, insert-on-not-found, and closed-on-OOOI; managed the release-testing transition and QA lead backfill; piloted an AI coding agent for Mule integration work.

Outcome

• Integration estate on a current, supported platform with DR paths documented.
• Regression for every CAE-facing sync automated ahead of cutover.