Information Systems:Strategy for developing in Python on IBM i

From uniWIKI
Revision as of 15:33, 19 April 2017 by Norwinu (talk | contribs)
Jump to navigation Jump to search 
Meta: This article stems from the initiative to implement a modern development platform on IBM i. Python is being strongly considered as the back-end programming language for any future development. This page will discuss the use of Python and its implementation on the i, with the assumption that we will move forward with this endeavor. Otherwise, this other page will continue to be linked to here, and represents the more general endeavor to consider programming modernization (other languages). -norwizzle (talk)

Strategy of the modernization initiative

It is worth noting that the initiative to modernize development does not just mean choosing a more current language like Python. There are several underlying key points:

  • Development should follow a proper documentation method. Extensive inline code-commenting as well as wiki documentation (following an agreed-upon structure e.g. separate namespace) may work for us. Third party development should follow the same protocol to document contributions and new creations. To compare, all program development following the initial project by Steelnet (ASW Extensions) is basically documented in less-technical wiki articles (transcribed from a manual in Word) or inline code-commenting. No detailed technical references exist, which poses problems today in troubleshooting programs and solutions at a technical level.
  • Program design should be modular (whether following an object-oriented paradigm or not is moot). The lack of documentation for most post-Steelnet development is not the only reason current RPG programs cannot be used or interfaced with; program design was also such that each program (or group of programs constituting a black-box solution) is self-contained - meant to perform its specific function only. To contrast, base ASW, although programmed in RPG, allows you to call some of its programs to perform functionality without touching its code and from other languages other than RPG (that's right, a 20-year+ old program is more interface-able than more current programs). In modern speak, this is referred to as developing an API. Modular program design coupled with point 1 (extensive documentation) will serve this company best moving forward.
  • Version control should be used. Git is a no-brainer, and that means our i will be a Git server, which in turn probably means another Apache instance. Alternatively (and support for this has to be determined), a private GitHub repo can be obtained to keep the git service external (but still hidden).
  • New libraries/folders will have to be created and ACL'ed to house program source code. Program execution also needs to be secured (make sure access to QSH is restricted to authorized personnel and service accounts). Python is an interpreted language, so source files are text-readable. On the other hand, RPG requires special tools (not to mention a white, wizardly beard) like RDi/SEU to read and understand.
  • SQL needs to be assessed in the future for security, and database security needs to be considered. For practicality purposes, we can acknowledge that security by obscurity is enough for now.
  • Boundaries will have to be defined for front-end/back-end programming, and a solution needs to be agreed upon for front-end programming. Programming in RPG essentially dictates a green-screen front-end (assuming user interaction is involved), but with Python, you have the ability to use a web framework like Django, Bottle, or Flask to host the front-end (e.g. Python to HTML). However, we have and love the WebSmart development platform. It is best to continue with that to develop interfaces for the programs we're looking to build, keeping Python to back-end processing. If so, it needs to be realized that any solution developed in this new way spans two development platforms (which is not uncommon these days, which is why you have front-end, back-end, and full-stack (front and back) developers).
  • The technical review of potential projects should still go through the change request process. Not having the primary development in-house (not yet at least) means that project details (business wants and needs) have the potential to be lost/mangled in translation. Think about how much info regarding Web Orders or Exware projects we've retained in official documentation (virtually none, it's all personal recollection).

Python package for IBM i

Python is offered as part of the open-source package 5733-OPS (initially released c. 2014 and under continuous development), which in turn is delivered as a PTF group. It is free to install and use. As an open-source package, it is worth noting the unique stance IBM takes for this package: The PTF package itself is developed, maintained and supported by IBM. However, the tools and runtimes in the package - Python, Node.js, git, Orion - are all open-source and thus are not subject to IBM software maintenance. As with most OSS (open source software), many products in this package have its roots in a Github or Google code project group, where IBM may or may not be involved. For example, Python is just a language, so the runtime itself doesn't need IBM's oversight or involvement, but the Python module 'ibm_db', which allows Python to communicate with DB2, is partly maintained by IBM through their open-source initiative. You still can't call them for support on how to use the module, but they're active in the project forums.

Retrieved from "https://owl.unipharm.com/mediawiki/index.php?title=Information_Systems:Strategy_for_developing_in_Python_on_IBM_i&oldid=7374"