Considerations for Serving and Consuming APIs Directly From IBM i

Companies leveraging IBM i to run their core systems of record often require integrating these applications with external CRM, eCommerce, and other enterprise applications. Modern integration architectures focus on surfacing the data and business logic via reusable and standards-based APIs or event streams.  

There are several approaches and tools available to implement APIs for IBM i based applications. One option is to implement and host the APIs directly within IBM i application platform. IBM Integrated Web Services (IWS), Krengeltech’s RPG-XML, Profound API, and several other tools fall into this category and offer products to develop and operate the integration assets within IBM i environment. This option offers several benefits, the most obvious being the simplified architecture and no need for a separate dedicated middleware layer. As with everything in life, it comes with a number of downsides and considerations. As companies evolve and mature their architecture and integration competence, these points become more prominent. Most customers eventually shift most of their integration workloads to dedicated integration platforms such as Mulesoft Anypoint, Confluent Cloud, or AWS or Azure integration stacks that offer high performance, advanced security policies, governance, and process automation out of the box.  

In this article, we will discuss the main considerations for serving and consuming APIs directly from IBM i. We will use Mulesoft Anypoint as an example of a dedicated integration platform throughout the article. However, the same points would apply to most other integration stacks.  

Security 

Transport: HTTP-based protocols typically represent a higher risk of exploitation. For example, IBM published an HTTP server vulnerability as recently as this summer. A quick google of "IBM I" cve will provide quite a list of issues. If attackers can gain access to the infrastructure where the API is running, this means they break directly into critical systems of record. 

When serving the APIs via MuleSoft, the APIs operate on a different infrastructure and in a different security zone. The interactions between the and IBM i are typically limited to raw socket connections on specific ports only for Database, Data Queue, and Program Call operations. Therefore, even if an attacker gains access to MuleSoft runtimes and raw port traffic, they will have very limited opportunity to gain access to the underlying IBM i systems. Essentially the integration platform represents a “demilitarized zone” that offers more fine-tuned options to limit the surface of potential attack and set up perimeter-, role- and device-based security policies.  

Authorization and Authentication: At a minimum, any integration tool must always communicate via HTTPS (TLS / encrypted protocol) and authenticate all requests with OAuth2 or a similar token-based provider. In most cases, when setting up dedicated secure connections with regulated external providers, companies may require more complex authorization schemas such as mutual TLS, request signing, and other advanced security features. Most IBM i tools include some of these features, but they are specific to the tool in question and have to be managed separately from companywide authorization and authentication policies. 

MuleSoft supports external identity management, role-based access, and authorization services such as Okta, as well as advanced features such as mutual TLS, out of the box with little to no custom development.  

API gateway and policies are intended to stop the attack before it reaches the critical back-end system, preventing impacts on daily operations. Out-of-the-box MuleSoft includes Rate Limiting, JSON/XML threat protection, and several other policies that are critical for secure API operations.  

Most IBM i based tools do not include external API gateways or policies, meaning the traffic (and potential attack) reaches the server first then the policies are at best evaluated directly on the system, making it more vulnerable to Denial of Service attacks when the system becomes overwhelmed by a high volume of dummy requests. 

Secrets Management: Any mature integration or API tool must support externalizing and encrypting credentials and other sensitive properties. Mulesoft provides Security Vault and native encryption services to ensure no sensitive data is stored or transmitted in clear text. MuleSoft also can be configured to work with external secret management services, offering an extra layer of protection for securing access credentials for critical endpoint systems.  

Quality of Service  

Alerting and Monitoring: MuleSoft can be natively connected with alerting, monitoring, log aggregation services, and analytic platforms such as Splunk. When an issue happens in the API implementation, an alert can be configured in Splunk to notify relevant IT and business teams via a variety of channels (email, SMS, Teams, Webex, Slack) to address the issue. On the other hand, when the API is hosted directly on IBM i servers, they lack native configuration bases integrations with logging, monitoring, or alerting platforms like Splunk. This means companies must develop it manually or miss the important alerts, notifications, and insights. 

Retries and Time-outs: Most integration components communicate with external services over the network. It is natural for distributed systems to have occasional breaks in connection or for the target services not to be available. However, most flexible integration designs account for API consumers or providers occasionally being unavailable and include the ability to auto-recover per retry policy and back off models, as well as save the unprocessed message into Dead Letter Queue or similar hold area for future review and recovery process. The MuleSoft platform supports these resilient integration patterns. 

Caching: For slow-changing data, the API or integration flow can be configured to cache the response and return it right away based on previously obtained results.  

DevOps, CI/CD, and Test Automation 

Most of the IBM i tools favor visual (“low code / no code”) API development, which is great and offers non-integration developers and analysts a quick option to launch the APIs. The downside is that the process is manual, relies on specific screen actions, and does not offer the same level of source code management and automation practices as most other modern development platforms.  

MuleSoft provides native support for Git repositories (GitHub, bitbucket, GitLab, Azure Develops, etc.). The de-facto standard for agile teams, multiple developers can work on several features for the same API in parallel. MuleSoft applications can be automatically built using a standard build manager (Maven plugin) that will automatically execute all unit tests, verify the dependencies, and assemble the deployable artifacts. Many DevOps providers offer to build and deployment pipelines that can be easily integrated with MuleSoft and automatically triggered based on the repository events to have a fully automated flow from feature code push to deployment and smoke tests. This approach greatly reduces the risks of unintended or buggy code making it to production and increases the development team's agility and throughput.   

Test coverage is an important metric for mature integration teams. MuleSoft munit framework provides a low code API test automation tool where tests can be developed addressing both internal MuleSoft API functionality and optional end-to-end functional tests.  

IBM i System Impact 

When the integration work is offloaded to a scaled-out platform such as MuleSoft, it protects the IBM i system from performance degradation and provides more options for tuning the API throughput. When the API/integration tool is running directly on the IBM i it typically consumes more system resources. 

Furthermore, Mulesoft workloads run in isolated containers, meaning one API performance or usage has minimal or no impact on another API or the endpoint system. If running multiple APIs and integration assets on the IBM i system, if one component starts consuming significant amounts of system resources, this can impact the performance of other integration components or the underlying system. 

East of Use, Training, and Standards 

MuleSoft is one of the leading integrations platforms with plenty of specialists and resources available for companies standardizing on this stack, but there is a wide variety of other middleware options such as Kafka, AWS, and Azure. Whereas running on APIs hosted directly on IBM i servers might require specialized training to develop and operate the APIs and increases operational risk in case a key developer familiar with the specialized tool leaves the team. 

Conclusions 

In this article, we reviewed several key considerations for any mature integration practice, focusing on security, quality of service, and performance impact. Introducing a dedicated integration platform such as MuleSoft may appear to be an overkill for some organizations, and surfacing the business data and logic as APIs directly from IBM i seems to be a simpler and easier approach. I hope this article helps evaluate these points and come up with a more mature target state integration architecture.