Need to interface a mobile app with your IBM i? A number of IBM i integration patterns can be leveraged to keep mobile apps in sync with enterprise systems.
Your IBM i system holds a lot of very useful data that can be leveraged for mobile apps. However, you need the right tools and methods to extract the data in the most effective way. This is where an integration platform comes in.
The purpose of system integration is to ensure smooth-running business processes across multiple systems. To do this, an IT department needs to be armed with integration and business process management tools that can recognize all of the needed integration patterns for your environment.
Therefore, IBM i users should look for mobile app development solutions that support nine familiar IBM i integration touchpoints.
1. Mobile Access Through Remote Procedure Calls
A very strong pattern for integration is one that will allow you to call System i programs for the purpose of passing parameters back and forth or simply executing a batch program. Remote Procedure Calls (RPCs) can be used not only to access data, but to execute existing business logic running on IBM i. For example, a mobile order-entry app can run an inventory lookup program on IBM i or check for available stock.
Typically, IBM i programs are written in RPG, although COBOL or other IBM i legacy languages may be involved. Utilizing existing application logic has a number of advantages: It preserves investment in prior software, ensures consistency in business processes, and allows changes in logic to be made in familiar languages.
2. Mobile Access Through System-Level Commands
With so many capabilities written into the IBM i OS itself, it makes sense to consider the system command line as an integration pattern. One can access, for example, current security system values using -*SEC-. The possibilities with system commands are numerous and provide extensive power for mobile apps designed to access them. Obviously, Control Language (CL) command integration will be limited to capabilities at the CL level. Capability to retrieve CPF and CPD error messages and job log messages will also be regarded as an important requirement in some apps.
3. Mobile Access to the User Space
One of the powerful integration patterns somewhat unique to IBM i is the user space. You can think of the user spaces as objects of up to 16 MB that can be used to save user-defined information. A user space object is permanent and can be stored in either the system domain or user domain. Mobile apps that work with the user space allow apps to create user spaces for lists of data; to access and store pointers; to deal with large amounts of data; to add, update, and delete information using Control Language (CL) commands; to exchange data between jobs, applications, and systems; etc. For example, a mobile app that accesses a user space containing contact data can provide a mobile device with access to enterprise directories of information.
Working with the user space is a useful integration pattern for mobile apps accessing the IBM i because it provides the app with a way to deal with a commonly used IBM i methodology. Rather than requiring extensive changes to existing jobs or applications, the mobile app can interface with the user space already employed in an existing IBM i scenario. This reduces the invasiveness and fragility of the integration. Not all IBM i procedures are based on the user space, however, so this will be the primary consideration as to when to use the user space.
4. Mobile Access to the Data Queue
Data queues are one of the powerful and unique capabilities of the IBM i that help an otherwise batch-oriented environment to deal with both synchronous and asynchronous activities. The data queue works with both data and metadata or one could even say messaging. Their purpose is to facilitate both synchronous and especially asynchronous communications. One possible use case is a mobile time-and-attendance app: A payroll system may have a single job to run payroll that is triggered by multiple time-card entries that are stored in the data queue. Among the attributes of the data queue is the "Async read," which allows data in the data queue to be protected while it is being read. It is a type of transactioning mechanism that has specific parameters related to wait time. The data is essentially removed while it is being read but only for the specified wait time.
Use of the data queue by mobile apps is most powerful when existing processes are already using data queue as a method. This allows you to take advantage of previously considered business rules for access of data in the data queue and avoids “reinventing the wheel.”
5. Mobile Access to Spool Files
The print spool is a frequently used IBM i operating system feature. Spool files can be considered proprietary to the IBM i environment, in particular because of their traditional connection to IBM printer formats. However, increasingly, IBM i shops have engaged in spool file conversion to get output data into popular formats such as PDF. The spool files can take on several formats: SCS, AFPDS, IPDS, AFPDSLINE, and PCL. For example, rather than a large printed report with rows and columns of data, records from the print spool file can be parsed and then may be displayed on the mobile device in a whole new interface such as a searchable stack of records that may be browsed on the mobile device by swiping left or right.
6. Mobile Access to IFS Objects
Mobile apps could also access IFS objects. The Integrated File System (IFS) of the IBM i supports stream input/output and storage management within an integrated structure across the system. The IFS supports binary formats, which can be useful for mobile interfaces and rich media types. Mobile apps may be designed that access both transactional and master item data via IFS.
7. Mobile Access Through Java on IBM i
Some IBM i-based IT departments have introduced Java into their environments with varying degrees of success. Since many teams seem to be searching for ways to minimize further investment in Java, integration of mobile apps to pre-existing Java capabilities on IBM i may be particularly important. To best integrate with various Java technologies, the mobile app will need to access abstracted capabilities for dealing with Java objects, classes, EJBs, and even in some instances the Java Message Service (JMS). A consumer-facing mobile app that provides current balance information, for example, may be able to access backend data via a JMS.
8. Mobile Access to Databases on IBM i
Direct data and database access is an important option for mobile apps. In addition to the IFS access already mentioned, the DB2/400 or DB2 UDB databases, SQL tables, SQL interfaces to physical files, and Open Query File (OPNQRYF) functionality may need to be employed as a point of mobile access to IBM i data. With the Open Query File, one will want to be able to sort and select records. With SQL access to physical files (as opposed to native IFS access previously mentioned), the option for use of direct SQL statements and access to views, triggers, functions, and stored procedures presents itself. Databases are ideal for mobile apps that execute transactions and where rollback and two-phase commit may be needed.
9. Mobile Web and Web Services
Mobile apps that access IBM i can utilize API-style interactions hosted on IBM i. Both HTTP and Web Services integration can become an important integration pattern for mobile access to IBM i. While most mobile integration tools will provide support for Web Services and HTTP, it is important to make certain that the system supports the native Apache requester on the IBM i as well as the Apache server, which may in some cases be on a Linux partition. In addition to HTTP get and post for RESTful Web Services, mobile apps accessing a SOA environment on the IBM i will need to be supported by use of SOAP/WSDL/UDDI Web services and WS-Security. The support of the mobile app development and integration system for Web Services becomes especially powerful in combination with the other integration patterns discussed here, essentially service-enabling the IBM i platform and mobile apps.
A variety of other integration patterns and capabilities will present themselves in the IBM i, although many of these can be considered non-native. XML, PDF, email, and other format support will be important as any of these may be utilized for input, output, and transport.
Conclusion
The mobile development and integration platforms that you ultimately select should support loose coupling between your mobile devices, your mobile app servers, and the IBM i environment. Loose coupling is desirable because it means that there is less interdependency between any two elements—a change in one component is less likely to require a change in the other.
Solutions and toolkits for mobile app and IBM i integration will ideally support as many of these IBM i patterns as possible, provide EAI and BPM orchestration architecture, and support mobile app deployment to numerous mobile device platforms, especially iOS, Android, and Windows 10 Mobile.
Vendors that provide a full stack of application, platform, and integration capabilities for mobile access to the IBM i should be conversant in the touchpoints discussed here. With the right application development and integration platform, all of the patterns discussed here and more are incorporated as a part of the solution set offered, making for a successfully integrated mobile app supporting users based on an IBM i system.
LATEST COMMENTS
MC Press Online