Building IBM i Data API with Mulesoft Anypoint
Overview
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.
IBM i Integration Use Cases
Overview
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!
Traits of Modern IBM i Application
I’ve read somewhere a long time ago that the secret to success is to always start visualizing it in a great many details before thinking about how to achieve it. Otherwise we risk losing sight of the end goal, and waste time and resources fighting windmills. Sure, we’ll still get somewhere, and with some practice can even convince others that this is exactly the result we’ve planned for all along. How does it apply to IBM i modernization initiatives? Before diving into discussions about modernize vs migrate, RPG or SQL, screen scrapers vs RPG Open Access vs JavaScript, DDS or DDL etc, let’s pause for a moment and think about what would the modern IBM i application look like if it were built now, with all the knowledge accumulated over the years of maintaining and enhancing it. This would be our golden standard, very helpful when deciding on the best architecture or technology choices.