The common IBM i (AS400, iSeries) use case is to share the application data with other systems. In this article I will show how easy it is to build IBM i Data API with Mulesoft Anypoint. We will define our RAML API first then add the code to pull data directly from DB2 database using standard Database connector and IBM i database driver. Depending on complexity and design of IBM i application, the persistent data must be transformed through complex business rules first before it can be used by consuming applications. In this case, API implementation must execute IBM i programs that implement such business logic – we will do it in the follow up post.
It may appear at first that creating API adds more work and operational overhead compared to point to point integrations. Based on our experience, however, building out API layers is one of the most efficient ways to promote the reuse and secure, govern and monitor the access to application data and logic. Relatively small upfront investment results in greatly improved delivery speed, especially as the number of interfaces grows.
Google “Digital Transformation” and you’ll get a lot of diagrams, white papers and dire predictions for companies not fully embracing it. The common theme is business must innovate at ever increasing speed. The limitations of the traditional IT delivery model make it difficult to evolve the systems at this pace. The recipe is to let business teams rapidly deliver their own projects, by reusing core business data and logic packaged as APIs. Modern low code development tools further democratize the delivery of new UI and process layers. The result is a network of applications that address specific business capabilities, evolve rapidly and independent of other components, and communicate through common integration fabric.
It’s a great model for startups that can get up and running in no time with modern cloud-based applications such as Salesforce, Netsuite, Workday, ServiceNow (extra shot of readily available capital never hurts either). Most modern SaaS applications have been built from the ground up around core APIs, and can be easily plugged into an integration platform. By contrast, established companies are saddled with a number of applications that have been developed over time with limited or no pre-built APIs or other out of the box integration methods.
In this post I discuss typical IBM i integration use cases and summarize the technology options for plugging into application network. As we all know, for any given IT problem there is always at least a half dozen tools and methods, and often many more. Below I list the tools our team used or evaluated. Don’t see your tool or technique of choice listed here? I appreciate if you send it to me!
Anyone who has been on the receiving end of a PCI audit knows that encrypting data in transit is a sensible thing to do. It’s a must have requirement for sensitive customer data, personally identifiable information and as a general rule should be applied by default unless there’s a compelling reason not to. In this article I will show how to securely connect Mule to IBM i (AS/400, iSeries, System i).
Mule flows typically communicate with IBM i data and business logic via the following transports:
In this article, I will show how to setup IBM i server encryption and secure Mule Database and Data queue communications.
In this demo I show how to connect IBM i (AS400, iSeries, System i) data and processes with Mule and Infoview’s AS400 connector and Web Transaction Framework.
Connecting, modernizing and migrating off of legacy systems is a complex undertaking. We are a capable cross-functional team of seasoned integration and IBM i professionals focused on customer care and business outcomes. Contact us to find out how we can help making your Digital Transformation initiatives a success.
On a recent call with a prospect I ran into a use case where they needed to send data to AS400 multi member files with MuleSoft Anypoint. IBM i (AS/400, iSeries, System i) operating environment includes an integrated DB2 database that is widely used as an application data store. Remote clients can access IBM i data via DB2 SQL Query Engine, JDBC or ODBC interfaces, and this works well for regular files and DB2 tables. There is a special file type widely used in older IBM i applications that supports partitioning content into multiple “members” and provides methods for isolating the data for traditional programs. The challenge of interfacing with multi-member files is that they cannot be easily accessed via standard SQL clients.
There are several “brute force” options for remotely creating and working with multi-member files in Mule, including: