- 7 minutes to read

FAQ - Integration & Advanced Use Cases

Common questions about integrating Nodinite Boomi monitoring with other tools and advanced scenarios.

How does Nodinite Boomi monitoring integrate with Power BI for reporting?

The Nodinite Web API exposes Boomi monitoring data as REST endpoints consumable by Power BI:

Available data:

  • Atom availability metrics - Uptime percentage per Atom (last 7/30/90 days), offline incidents (count, duration, MTTR), Atom version distribution across fleet
  • Process execution statistics - Success rate per process (last 7/30/90 days), error count by error type (SocketTimeoutException, NullPointerException, etc.), execution duration trends (min/max/avg/p95), execution volume per process per day
  • JVM performance metrics - Heap memory usage trends per Atom (12-month history), GC frequency and pause time trends, thread count trends, CPU utilization
  • Alert history - Alert count by severity (Warning/Error/Critical), alert count by process, MTTR (Mean Time To Resolution), unacknowledged alert duration

Example Power BI reports:

  1. Executive KPI Dashboard - Overall Boomi health score (weighted: availability 40%, error rate 30%, performance 30%), month-over-month error rate trend, top 10 failing processes, SLA compliance percentage
  2. Capacity Planning Report - Atom heap usage trends (12 months), projected heap exhaustion dates per Atom (linear regression), process execution volume growth rates, infrastructure budget forecast
  3. Team Performance Report - Process success rate by owning team (Billing 98.2%, Finance 99.1%, Operations 97.5%), MTTR by team, alert volume by team, most frequent error messages

Setup: Power BI Desktop → Get Data → Web → Enter Nodinite Web API URL (e.g., https://nodinite.company.com/api/Monitoring/Boomi/Atoms?startDate=2024-01-01&endDate=2025-01-15) → Enter API key (generated in Nodinite Web Client → Settings → API Keys) → Load data → Build reports.

Refresh schedule: Power BI Service scheduled refresh (daily at 6 AM), data exported from Nodinite Web API each refresh, historical data retained in Power BI dataset.

Can I monitor Boomi Atoms running in Docker or Kubernetes?

Boomi Atoms can run in containers (Docker, Kubernetes) with Nodinite monitoring via 2 layers:

Layer 1: Boomi API monitoring (always available)

  • Nodinite polls Boomi AtomSphere REST API regardless of Atom deployment model (bare metal, VM, Docker, Kubernetes)
  • Atom availability, process execution status, execution logs all accessible via API
  • No container-specific configuration required, works identically for all Atom types

Layer 2: JMX monitoring (requires network access)

  • For deep JVM metrics (heap, GC, threads), deploy JMX Monitoring Agent with network access to Atom JMX port

  • Docker: Expose JMX port in container run command:

    docker run -p 5002:5002 \
  -e JAVA_OPTS="-Dcom.sun.management.jmxremote.port=5002 -Dcom.sun.management.jmxremote.authenticate=false -Dcom.sun.management.jmxremote.ssl=false" \
  boomi/atom:latest

  • Kubernetes: Create Service exposing JMX port:

    kubectl expose pod boomi-atom-pod --type=NodePort --port=5002 --target-port=5002 --name=boomi-jmx-service

    Nodinite connects to <kubernetes-node-ip>:<node-port>

  • Kubernetes alternative: Deploy JMX Monitoring Agent as sidecar container in same pod (no external port exposure required, agent connects to localhost:5002)

Best practice: Layer 1 (API monitoring) sufficient for most use cases (Atom availability, process failures, execution logs). Add Layer 2 (JMX monitoring) for performance-critical Atoms requiring capacity planning and memory leak detection (typically Production Atoms processing >10K messages/day).

Can I use Nodinite Boomi Monitoring with Boomi Flow (workflow automation)?

Yes, but limited. Nodinite Boomi Integrations Monitoring Agent is optimized for Boomi Integration (AtomSphere) platform, not Boomi Flow platform:

What works:

  • Monitor Boomi Integration processes that interact with Boomi Flow (Integration process calls Flow via REST API, monitor Integration process execution status + API response times)
  • Extract business data from Integration process payloads sent to/from Flow (configure Message Types + Search Fields for Integration-side logging)

What doesn't work:

  • Direct monitoring of Boomi Flow workflow executions (Flow does not expose REST API for external monitoring, no equivalent to AtomSphere API)
  • Boomi Flow execution history not accessible via Nodinite (must log into Boomi Flow portal to view workflow runs)
  • No remote actions for Boomi Flow workflows (cannot restart/pause flows via Nodinite)

Alternative approach: Implement custom logging in Boomi Flow workflows (use Flow "Log" or "HTTP Request" shapes to POST log events to Nodinite Log API), track Flow executions as custom log events, search by business identifiers. Requires 2-4 hours development per Flow workflow to add logging components. See Custom Logging user guide.

How do I monitor Boomi deployments across environments (Dev → Test → Production)?

Deployment monitoring strategy:

1. Pre-Deployment Verification

Before deploying from Test → Production, verify Test environment health:

  • All processes in Test environment running successfully (0 errors last 24 hours)
  • Atom availability >99.9% last 7 days
  • JVM heap usage <70% (sufficient headroom for production traffic)
  • Execution duration within normal range (no performance regressions)

2. Post-Deployment Health Check

After deploying to Production, automated health check executes:

  • Test message sent through newly deployed process (synthetic transaction with known-good payload)
  • Verify expected response (HTTP 200, correct response format, database record created)
  • Alert if test message fails (deployment configuration issue detected immediately, not hours later when real traffic fails)

3. Deployment Tracking

Log all deployments as custom events in Nodinite:

  • Use Log API to POST deployment event: timestamp, deployer username, source environment, target environment, process names, package version
  • Correlate process failures with recent deployments (if process fails within 4 hours of deployment, alert includes "Recently deployed from Test at 2:15 PM by john.smith@company.com")

4. Rollback Automation

If post-deployment health check fails, Auto-Healing automatically rolls back:

  • Undeploy failed package from Production Atom
  • Redeploy previous known-good package version
  • Send alert to DevOps (auto-rollback executed, investigate deployment issue)

Example timeline:

Time Event Action
2:00 PM Developer deploys "PaymentProcessing v2.3" from Test → Production via AtomSphere Deployment complete
2:01 PM Nodinite detects deployment (new package version on Production Atom) Log deployment event
2:02 PM Post-deployment health check executes (synthetic payment transaction) Test message sent
2:03 PM Health check FAILS (process configured with Test database connection string, not Production) Alert fires
2:03 PM Auto-rollback initiated Undeploy v2.3, redeploy v2.2
2:04 PM Rollback complete (PaymentProcessing v2.2 restored) Production operational
2:05 PM Developer notified (configuration error identified, corrected deployment prepared) Incident closed

Setup: Requires custom scripting (PowerShell or Python) calling Boomi API + Nodinite Log API to log deployment events and execute health checks. Implementation time: 4-8 hours initial setup, 1-2 hours per process to add synthetic transaction tests.

Can Nodinite automatically restart failed Boomi processes?

Yes, via Auto-Healing feature. Configure automatic remediation actions when specific alerts fire:

Example 1: Auto-restart payment processing on transient errors

  • Alert: Process "PaymentGatewaySync" execution error with message contains "SocketTimeoutException" or "Connection refused"
  • Auto-Healing Action: Wait 2 minutes (allow transient network issue to resolve), restart process via Remote Actions, if still failing after restart → escalate to PagerDuty

Example 2: Auto-increase heap when approaching limit

  • Alert: Boomi Atom JVM heap usage >90% (detected via JMX Monitoring Agent)
  • Auto-Healing Action: Execute PowerShell script increasing Atom heap from 4 GB to 6 GB, restart Atom Windows Service, send notification to operations (heap increased, manual review recommended next business day)

Example 3: Auto-resume paused Atoms after maintenance

  • Alert: Boomi Atom state = "Paused" longer than 15 minutes outside scheduled maintenance window
  • Auto-Healing Action: Resume Atom via Remote Actions, send notification to operations (Atom auto-resumed, investigate why it was paused)

Safety guardrails: Auto-Healing includes limits to prevent runaway automation:

  • Maximum 3 restart attempts per hour per process (prevent infinite restart loop if problem not transient)
  • Require approval for production actions (auto-restart in Dev/Test, approval required for Production)
  • Complete audit trail (every Auto-Healing action logged with timestamp + trigger alert + action result)

Configuration: Web Client → Settings → Auto-Healing Rules → Add Rule → Select alert type (Boomi process error) → Configure action (Restart process) → Set conditions (error message contains "SocketTimeoutException") → Set limits (max 3 restarts/hour) → Save.

Back to FAQs

← All FAQs | ← Boomi Integrations Monitoring Overview