mulesoft-bdr

name: mulesoft-bdr description: "BDR Group MuleSoft integration project tracker. Reads the Implementation Playbook, tracks phase progress (0A→0B→0C→1A→1B→1C), flags blockers by owner (Ben/Anil/Dave/Julie/Ryan/Nikith), maintains credential state, generates stakeholder status updates. Use whenever Adam asks about BDR MuleSoft status, blockers, next steps, or phase gates. NOT for generic MuleSoft work — use /mulesoft or subskills for that."

Skill: BDR MuleSoft Project Tracker

Hardened Rules (load-bearing)

1. Anypoint control plane is EU. Always eu1.anypoint.mulesoft.com. Applies to: UI login, Runtime Manager URL, Exchange Maven URL (https://maven.eu1.anypoint.mulesoft.com/api/v3/maven), pom <uri> in mule-maven-plugin <cloudHub2Deployment>, CloudHub deploy target (Cloudhub-EU-West-1), API Manager / Connected App / Access Management links, OAuth token endpoints. Wrong region = auth errors that don't say "wrong region."

2. Deploy path = manual JAR upload via Runtime Manager. ACB rocket stalls silently after the CloudHub 1 vs 2 selector. GitHub Actions CI needs 5 repo secrets that aren't set (ANYPOINT_CLIENT_ID, ANYPOINT_CLIENT_SECRET, SF_USERNAME, SF_PASSWORD, SF_SECURITY_TOKEN). Until those are populated, deploy by: build JAR with bundled Maven (C:\Users\Adam\.vscode\extensions\salesforce.mule-dx-dependencies-1.6.1-win32-x64\build\deps\apache-maven-3.9.4\bin\mvn.cmd -B -U clean package -DskipTests -DskipMunitTests after setting JAVA_HOME to the bundled JDK 17), upload via Runtime Manager → Settings → Applications → Choose File. Smoke test /api/health after rolling restart.

3. GitHub account = a-savage-bdr ONLY in .claude-work/ or C:\Users\Adam\Mulesoft\bdr-integrations. Every other context = Mrsavage92. Run gh auth status before any push. Switch back to Mrsavage92 immediately after BDR work — accidental pushes to BDR-named repos are a confidentiality breach. Read operations (gh run view, gh pr view, logs) without confirmation. Write operations (push, merge, close, delete, workflow trigger, secret/settings change) require explicit "do it" in the same turn.

4. CloudHub 2.0 has NO Promote button in Runtime Manager — that's CH1 legacy. For CH2 sandbox→prod app deployment the path is: download JAR from sandbox app's ⋯ menu (Settings → Application File → Download) → switch env → Runtime Manager → Deploy Application → Choose file → Import file from Exchange OR upload local file → set per-env Properties tab → Deploy. However API Manager DOES have "Promote API from environment" — that promotes the API instance + policies + SLAs (NOT the JAR). Don't conflate them: Runtime Manager handles binary; API Manager handles policy layer. Verified 2026-05-15 via docs.mulesoft.com/cloudhub-2/ch2-update-apps.

5. CloudHub 2.0 application name has a 48-character limit. broadband-availability-process-api-production (47) fits but anything ≥38 chars + "-production" is rejected at submit. Use -prod instead. The deploy/deploy-production.json applicationName field can aspirationally say -production but the Runtime Manager UI is source of truth — override at deploy.

6. Last-Mile Security setting MUST match the Mule app's internal listener protocol — they MUST be the same. LMS controls whether the ingress→pod last hop is HTTPS. If they disagree → 502 Bad Gateway. External callers always get HTTPS either way (ingress terminates TLS at edge). The mapping:

   • <http:listener-connection ... protocol="HTTPS" /> (with tls:context) → LMS ON (CHECKED). Both BDR broadband apps (ITS, Process). Verified 2026-05-15 — forgetting LMS-ON gave 502 on ITS prod.
   • <http:listener-connection ... /> with no protocol= attribute → defaults to HTTP → LMS OFF (UNCHECKED). SF System API (salesforce-system-api/src/main/mule/global-config.xml). Verified 2026-05-18 — leaving LMS-ON with HTTP listener gave 502. Toggling LMS off resolved it in one rolling restart.
   • To check before deploy: grep "http:listener-connection" <app>/src/main/mule/global-config.xml → if you see protocol="HTTPS" → LMS ON; if no protocol attribute → LMS OFF. Each app may differ. Don't apply one rule to all of them.

7. Process API listener path is /api/v1/*, NOT /api/* like ITS API. Process API health URL = /api/v1/health. ITS API health URL = /api/health. Hitting wrong path returns APIKit "No listener for endpoint: /api/health" 404. Same in sandbox + prod. PROD-CUTOVER-CHECKLIST.md and BROADBAND-RUNBOOK.md both had wrong URL — flagged for correction. Memorise: ITS → /api/health, Process → /api/v1/health.

8. Client ID Enforcement is OWASP API02 baseline for prod APIs even with one known consumer — but BDR's Mule apps DO NOT have <api-platform-gw:api> autodiscovery wired in (verified 2026-05-15 via grep of integrations/*/src/). Without autodiscovery the apps cannot be registered as "Mule Gateway" type in API Manager. The remaining options are (a) Endpoint with Proxy = deploy a separate Mule Proxy app in front (adds infra + latency) or (b) Endpoint without Proxy = governance-only, no enforcement. Neither is a "click in API Manager today" job. Doing CIE properly = a v1.0.3 sprint: add autodiscovery to both Mule apps' global-config.xml → build new JARs → deploy sandbox → UAT → apply CIE policy in API Manager → generate Connected App per env → update SF External Credential per env → repeat in prod. ~1-2 days work. For Phase 1 cutover: ship without CIE, calendar v1.0.3 hardening for week 1. Audit MULE-H1 in docs/DEEP-DIVE-AUDIT-2026-05-13.md already flagged this. Don't suggest "click in API Manager" without first checking if the Mule source has autodiscovery wired.

9. BDR Anypoint deep-link IDs (captured 2026-05-15): Org ID 4d23f27b-2a82-4617-8ac1-56cb3ea622aa. Production env ID dfc0161d-daed-4c93-b71d-5b8fe4701ee4. API Manager URL pattern: https://eu1.anypoint.mulesoft.com/apimanager/bdr-group/#/organizations/{org-id}/environments/{env-id}/apis. Runtime Manager: https://eu1.anypoint.mulesoft.com/cloudhub/. Exchange: https://eu1.anypoint.mulesoft.com/exchange/. Env switcher is in top-right of UI, not in URL path.

10. Anypoint Secret Groups are for Anypoint Runtime Fabric, NOT CloudHub 2.0 Shared Space. BDR is on CH2 Shared Space. For CH2 secrets, use Runtime Manager → app → Settings → Properties → tick "Secure" — that IS encrypted-at-rest secure storage, fit for purpose. Don't suggest creating Secret Groups; they aren't consumable from CH2 apps.

11. Maven IS available locally on Adam's Windows machine — bundled with the Salesforce Mule DX VS Code extension at C:\Users\Adam\.vscode\extensions\salesforce.mule-dx-dependencies-1.6.1-win32-x64\build\deps\apache-maven-3.9.4\bin\mvn.cmd. Set JAVA_HOME to the bundled JDK 17 first. So local builds DO work — just not via plain mvn on PATH. Don't claim "no local Maven" anymore.

12. BDR's Anypoint subscription is "Customer - Integration Advanced" (verified 2026-05-19 by Adam screenshot of Access Management → Subscription). Expires 2030-04-12. This tier includes:

    • Full Anypoint Monitoring (built-in dashboards, custom dashboards, insights, traces, alerts, custom metrics, telemetry exporter, reports)
    • Functional Monitoring (the synthetic API testing product — formerly APIfortress)
    • Log Search + Log Points + Raw Data
    • Runtime Manager basic alerts

    Implication: do NOT propose building custom monitoring Mule apps for BDR. All synthetic checks, log-content alerts, KPI threshold alerts, and dashboards are already in the subscription. Build using the UI in Anypoint Monitoring + Functional Monitoring, not custom Mule scheduler flows. See ~/.claude/skills/mulesoft-platform/references/monitoring.md for the full decision tree.

    Subscription caps to track (Access Management → Subscription → Runtime Manager + Object Store panels):

    • Mule Public Flows: 200 (BDR uses ~25 across 3 prod apps — plenty of headroom)
    • Mule Messages: 20M / month (Phase 1 single-digit % usage)
    • Data Throughput: 40,000 GB / month
    • VPCs: 2 (0 used)
    • Network Connections: 4 (0 used)
    • Object Store API Requests: shown <1% used
    • vCores: check separately on Subscription Usage panel — roughly 1.6 vCores currently used across the 6 deployed apps (3 prod × 0.4 + 3 sandbox × 0.2)

Purpose

Track the BDR Group MuleSoft integration programme against the Implementation Playbook. Phase 1 scope is NetSuite entitystatus → Salesforce On Stop flag. Future phases expand to liquidations sync, event-driven workflows, and platform-wide integration per the 6-Phase Enterprise strategy.

When to Use

• Status check — "where am I on BDR MuleSoft?"
• Blocker audit — "what am I waiting on and who owns it?"
• Phase gate check — "can I start building yet?"
• Stakeholder update — "draft a message for Dave/Ben/Julie"
• Discovery input review — "has Ben sent the TBA creds?"

When NOT to Use

• Building flows, DataWeave, connector configs — use /mulesoft-flow, /mulesoft-dataweave, /mulesoft-connector
• Anypoint Platform admin tasks — use /mulesoft-platform
• Generic MuleSoft questions — use /mulesoft

Canonical Sources

Always read these before answering:

1. C:/Users/Adam/Documents/Claude/BDR/MuleSoft_Implementation_Playbook.docx — primary truth
2. C:/Users/Adam/Documents/Claude/BDR/MuleSoft/Phase 1-6 *.txt — enterprise strategy
3. ~/.claude/projects/.../memory/project_bdr_mulesoft.md — current state
4. C:/Users/Adam/MuleSoft/bdr-integrations/ — actual project directory

Modes

Mode 1 — Status Check

Report current phase, % complete, active blockers, next 3 actions. Read references/playbook-summary.md for the phase structure.

Mode 2 — Blocker Audit

Who owes what. Include chase history and escalation path. Read references/blockers-matrix.md for the full dependency grid.

Mode 3 — Phase Gate Review

Before recommending "start building" or "deploy to prod", check gate criteria. Read references/phase-gates.md for exit criteria per phase.

Mode 4 — Stakeholder Comms

Generate WhatsApp/email update to team members. Use templates/status-report.md as the base.

Phase Map (Condensed)

Key People Map

Proactive Triggers

• If Adam mentions building flows and 0B discovery inputs aren't all received → flag gate risk
• If Adam mentions deploying to production and JWT auth isn't configured → flag security gap
• If a blocker has been "chased" for >3 business days without resolution → escalate to Dave Beach
• If Adam asks about NetSuite sandbox without it being confirmed → flag as testing risk
• If an action is taken against live production data without UAT sign-off → STOP and log

Output Artifacts

Anti-Patterns (do NOT do these)

• Assuming phase completion without verification — always check actual state (files, credentials in config yaml, Anypoint screenshots) before marking done
• Generic MuleSoft advice — always ground in the playbook. If the playbook says OAuth Username-Password for dev and JWT for prod, don't recommend something else
• Ignoring the enterprise strategy — Phase 1 Account Suspension is scaffolding for the larger programme. Decisions here affect Phase 2-6. Don't optimise locally at the expense of the bigger architecture
• Hardcoding credentials in docs or memory — always reference by variable name (${sf.consumer.key}), never paste actual values

Related Skills

• Use /mulesoft-connector when setting up the SF/NS connectors during Phase 0C
• Use /mulesoft-flow when building the polling flow during Phase 1A
• Use /mulesoft-dataweave for the NS→SF field mapping during Phase 1A
• Use /mulesoft-platform for Secrets Manager and deploy during Phase 1C
• Use /mulesoft for routing when the ask spans multiple subskills