Sitemule Platform Native IBM i Integration

Modernizing IBM i landscapes often forces organizations to introduce external middleware, replicate data, or migrate core logic off‑system - each bringing latency, synchronization risk, and maintenance burdens. Platform’s native IBM i integration capability solves this by executing modules, APIs, and user services directly on IBM i, preserving system integrity, reducing complexity, and accelerating modernization.

By running everything in‑place on IBM i, you avoid fragmenting your architecture or duplicating logic. Existing RPG, COBOL, and Db2 assets remain as first-class participants in your new digital ecosystem - without the overhead of middle-tier servers.

Architecture and Core Design Principles

• Architecture: The native IBM i feature is built on a unified runtime that lives on the IBM i OS itself, embedding session management, security, module orchestration, and HTTP/REST adapters as part of the local runtime environment. Rather than offloading logic to separate machines, Platform spawns and manages ILE service programs or IBM i jobs within controlled scopes.
• Design Rationale: One guiding principle is “no middleware overhead.” This avoids external translation layers, serialization hops, or cross-server protocols. Another is “cohesive security context,” meaning user authority, object-level permissions, and audit trails remain part of the IBM i domain. Finally, modules are isolated via service group boundaries so that resource leaks, memory contention, or cross-module dependency issues are contained and manageable.
• Data Flow: When an external client calls a REST API exposed by Platform, the built-in adapter receives the HTTP/JSON payload and routes it into the native runtime environment. The runtime decodes the JSON, maps it to internal method calls or program invocations, and then executes logic directly against Db2 or existing business programs. The result is packaged back through the adapter; no external network or middleware hops are needed.

Integration within Platform

Within Platform, the native IBM i integration is the backbone that all other modules rely on. The runtime core loads first and provides shared services such as logging, session token management, and authentication. Modules - whether Workspace, Hub, or Assist - are built to call into that same runtime context. When one module calls another, communication is often an in-memory or inter-job call rather than an HTTP round trip. Shared services - like monitoring, alerting, and audit logging - draw from the same core infrastructure, ensuring consistency across modules.

“Running natively on IBM i keeps logic, data, and security where they belong - inside the system that already powers your business.”

Dependencies such as security validation or user roles are centralized in the core. API endpoints exposed by modules rely on the same native adapter layer to receive external requests. Because all modules live in the same IBM i context, you don’t require external message buses or API gateways between modules.

Technical Benefits and Performance

• Performance: Eliminating middleware and cross-server calls reduces latency significantly. Calls into Db2 or ILE programs execute with the same speed as native ILE invocations. There is no serialization or network transport overhead inside the boundary.
• Scalability: Platform scales within the IBM i landscape - by adding logical partitions (LPARs), clustering, or distributing modules across system partitions - without needing to scale additional middleware tiers.
• Maintainability: Deploying updates is simpler because modules are versioned within the IBM i environment. You avoid having to manage disparate versions on multiple servers, and rollback is straightforward.
• Resilience: By co‑locating logic on IBM i, failure surface is minimized. Job-level isolation ensures module crashes or memory overruns don’t cascade to unrelated parts of the system.

Compatibility and Interoperability

Because Platform works natively on IBM i, it integrates seamlessly with Db2 for i, invoking SQL or embedded SQL in ILE routines without needing data replication.

Existing RPG and COBOL modules can be wrapped or invoked directly from the Platform runtime as callable services. For external systems, Platform supports REST and JSON payloads: the adapter layer transforms HTTP calls into internal logic. Platform also supports SOAP, XML, GraphQL, or WebSocket endpoints as required, mapping them to IBM i service calls.

If you already have HTTP Server or Integrated Web Services on IBM i, the native runtime can coexist or integrate, routing certain calls to Platform modules. On the messaging side, integration with IBM MQ or Webhooks is enabled by native connectors rather than bridging through external middleware.

Use Case

A distribution company operates its core order entry and inventory logic in RPG on IBM i. They want a modern partner portal so external suppliers can check stock and place orders via REST. With Platform’s native IBM i integration, they developed a Supplier API module that sits directly on IBM i. The API module calls existing RPG routines to verify stock, adjust reservations, and commit orders.

No intermediate servers or data duplication were added. The rollout began with internal testing via Portfolio, then exposed to external partners. Throughout this deployment, audit logging, error handling, and authority checks utilized the same IBM i mechanisms. The result: faster integration, no disruption, and no separate infrastructure to maintain.

Related Features and Internal Links

This native integration underpins Platform’s Workspace modernization capabilities, allowing green-screen applications to call new modules without leaving the same runtime. It also works in tandem with Platform’s Monitoring & Alerting system, since runtime events, performance metrics, and health checks are all real-time and internal.

Conclusion

By operating entirely natively on IBM i, Platform’s native integration feature removes the complexity and risk of middleware, preserves performance, and ensures all modules operate cohesively within one system. Stability, efficiency, and modernization go hand in hand.