Information Systems:IBM i open-source development conventions

From uniWIKI
Revision as of 13:41, 12 January 2018 by Norwinu (talk | contribs)
Jump to navigation Jump to search 
Audience:  For developers programming on/for this system (IBM i), or for technical staff wanting to understand the development guidelines that were used to make the modern extensions that exist on the system.

This page outlines the conventions established for modern (post-2017) development on IBM i. While other, related articles are exploratory, this page will be kept to documenting stuff that is more-or-less set in stone.

Principles

  • Python on IBM i is being used to develop new business programs/software. Prior to this (pre-2018), the RPG language was used. WebSmart PML (ProGen Markup Language) and CL (Control Language) were also used to support solutions that were primarily RPG-based.
  • Django is the web framework used to make the front end of these new programs.
  • Python and Django together can thus be regarded as the development platform for making new ERP extensions, in place of RPG/DDS (green screen interactive programs/extensions) and PML/RPG/CL (i.e. current Infonet programs).
  • There is Python-Django, and there is also just Python. Python (without Django) is also be used to make batch/scheduled programs (with no user interface). This replaces what was formerly done through RPG/CL.
  • Command-line interactive Python programs will not be made (at least not for general use e.g. maybe some admin utilities). Developing such programs is not part of the modernization strategy, and generally does not make sense for the company, since we are trying to replace green-screen / terminal-based usage with web interaction. Whenever a business need calls for an interactive program/extension, Django will be used to make the front-end of said program, and the resulting app will be interacted with through the web.
  • Since Python-Django creates web applications, newly developed extensions can be regarded as 'extending' what we currently know as Infonet. However, as will be explained, this 'extending' of Infonet merely refers to presentation. There are two separate technologies driving programs of either type.
  • Infonet (or more accurately, the entire collection of WebSmart programs we consider the company intranet site), will not be replaced. It will continue to run and be maintained using WebSmart. Addition of functionality will have to be assessed by a steering committee to determine whether it is a large enough change to warrant rewriting the program in Python-Django vs. making the changes in WebSmart.
  • Infonext (abbr. INX) is the proposed name for referring to the collection of new Python/Django programs/extensions that will be added to Infonet. The term will mostly be used internally to begin with, so as to not cause confusion amongst end users.
  • Despite being programmed differently (Infonet in WebSmart PML/RPG and Infonext in Python/Django), the users will interact with the intranet site the same way. The concept of the web browser being a front-end (HTML/CSS/Javascript), which is common to both platforms and development methods, is what enables presenting it all as a unified site to the end user.
  • Python/Django apps will not be served using the built-in IBM i HTTP server (Apache), the way WebSmart (Infonet, Web Orders) is currently hosted. This is for reasons of performance/compatibility of Python on Apache (mod_wsgi). Instead, an alternative web server will be used and Infonext programs will be accessed through this server that will run on a different port.
  • IBM i HTTP Server / Apache will be used as a reverse proxy, so it can route requests by URL path (e.g. /infonext/carrierint.py, /infonet/in_stksts.pgm) to either Infonet or Infonext programs.

Programming Environment

  • The flavor of Python used is an official IBM i release that belongs to (and was installed through) the 5733-OPS IBM i Open Source Solutions licensed program.
Theory: It is likely the same Python code you would run in Linux or Windows, but packaged differently. It is almost certainly CPython.
  • Currently, the version of Python is 3.4.6.
  • Python is updated through PTFs - through Technology Refreshes and the specific PTF Group for open source (SF99223 for IBM i 7.2).
  • Python runs within a special environment on the i called PASE. To put simply, it is an area of the system carved out to operate like a Linux/Unix system, using the IFS as its 'home'. More info on that here.
  • Python modules are installed/maintained through the native Python package manager pip. The following modules are exceptions, which should not be managed/upgraded through pip: ibm_db, ibm_db_django.
  • PASE is best accessed through SSH. Administrative functions, such as pip installations, can be done in the bash terminal through SSH.

The ibm_db Db2 driver

  • ibm_db and ibm_db_dbi are Python modules used to access the Db2 database running on i (production database).

Virtual Environments

  • A virtual environment is an isolated Python environment dedicated to a project. The premise is that instead of using the system's Python installation for all projects, a copy of Python (and all its dependencies) is created in a specifc folder, which in turn becomes the "base" folder for that project's Python environment. This allows multiple instances and versions of modules (and even Python itself) to be installed to cater to each project. It also ensures that the project does not break when the system's Python - and its modules - gets upgraded (e.g through PTFs).
  • pyvenv is the utility to manage virtual environments and is to be used for each project.
  • The location for virtual environments will be in /uwdsrc/.venvs
  • (chroot will be explored with Krengeltech)

Versioning and Change Management

  • Git is for version control and source code management. The free git hosting provider, BitBucket, will be used as the cloud repository.
  • IBM i has git functionality (another program in the 5733-OPS suite). git has been tested on the i (command-line git commands).

Data Libraries

  • The INX_D library will house data/tables used for INX programs. It will be automatically journaled (QDFTJRN) for compatibility with Django.
  • The UWDX_D library will house data (tables) that is less directly involved with Infonet.
  • These two libraries parallel the current conventions where we have WEBPRDD for data used in WebSmart programs and UWDASWPRDD for general extensions data.
  • Historically, there would also be a LIBRARYNAMEP library and a LIBRARYNAMES library to go along with the data library (e.g. UWDASWPRDD, UWDASWPRDP, UWDASWPRDS. This is because RPG source code exists as members in a source file object, that in turn needs to be in a library. The RPG program compiled from the source would also need to go into a library, hence the P and the S libraries. In Python, the source and program exist as a single .py file on the IFS, so the aforementioned libraries are not necessary and the convention will not be carried forward.

Naming conventions

  • The 10-character limit is pervasive with regards to naming things on the i (objects, fields etc.)
  • Through SQL, IBM i allows you to get past the 10-character limit by having a SQL name (or just column name / field name), and a system name. In fact, if mostly interacting with files through SQL, the system name is mostly invisible and can be ignored. This is to the extent that if the system name is not specified when creating a column/field or table, the system will just generate one for you (a truncated and number-padded, fixed 10-character version of the SQL name provided).
  • Despite the previous statement, in respect to the ILE side of IBM i, system names are still being set manually (to be more meaningful than auto-generated ones). For example, for the table HCDB_ROUTE_AP, the system name HCDBROUTAP is more meaningful than the auto-generated HCDBR00001.
  • It is thus a convention to create meaningful table and field names, with length being a lower priority.
  • Schemas/libraries and tables can be created using the Schemas app in IBM i Access Client Solutions. This has proven to be faster and more error-proof compared to creating through raw SQL statements or Navigator. Creating and managing tables/fields through a GUI also allows for greater consistency.
  • In naming fields and tables, underscores are used in filenames and instead of camel casing.

Permissions

  • User c
Retrieved from "https://owl.unipharm.com/mediawiki/index.php?title=Information_Systems:IBM_i_open-source_development_conventions&oldid=10756"