One of the more popular features of Nitro App Builder is the ability for IBM i developers to quickly roll out a file maintenance app in the form of an edit grid. A developer simply creates a data source over the desired file(s), maps it to an edit grid widget, and voilà!  In virtually no time they've created a fully functional maintenance app.

This week brought news of an exploitable hack to which certain applications executing Java may be vulnerable. Specifically, any applications using the popular Apache log4j logging tool may, under certain circumstances, be exposed to hackers executing nefarious code on their servers. This includes applications running on IBM i.

In most cases, apps running inside the Valence Portal pull whatever data they need directly from the company's IBM i or remote database, providing pertinent information to users with no intermediate steps required. Hence there's nothing to "clean up" after the apps complete.

But for more complex scenarios, you may find back-end work files are needed to support the process.

We pride ourselves on how quickly you can create an elegant application for editing a physical file, or even multiple joined physical files, in well under an hour in Valence using the Nitro App Builder tool.

But what if you've got to leave to catch a train in two minutes, and one of your users comes to you with an emergency need to edit the contents in a single physical file?

In most cases, grid applications developed with Nitro App Builder have static columns that never need to change. That is, a "Customer Number" column will always hold the customer number or customer ID; a "Product Number" column will always hold the item number or SKU, etc.

But in some cases you may have grid columns that, ideally, would have different column headings depending on the type of data being rendered.

Lists or grids of business data are often pretty straightforward to filter, particularly when applying single-column comparisons. Do your users need a way to limit a list of customer orders to a specific destination country and shipping date? No problem! Two simple column filters — one over the ship-to country, one over the ship date — and the users are able to retrieve what they're looking for.

But occasionally users may come to you with some more unusual filtering needs...

If your company's ERP system database had its genesis in the 1980s or early 1990s, and it hasn't "evolved" a whole lot since then, you likely have a number of files where date values are stored inside numeric fields. Whether your dates are parsed into separate year/month/day fields, or held in single YYYYMMDD, CYYMMDD fields, etc., you're already well aware of the hurdles you must jump over when trying to do otherwise simple things like date arithmetic, filtering, sorting, etc.

In today's internet-connected society, just about any kind of information you need to know can be pulled into your system through a web service API. These APIs make it possible to pull public (or private) record sets into your Valence apps from databases that are not necessarily located within the walls of your company's data center.

Without doubt, the most effective way to create powerful web or mobile apps with minimal code is achieved by harnessing the power of SQL in your data sources. We've used variations of SELECT * FROM DEMOCMAST in countless examples here over the years, and likely you've leveraged that concept in many of your own applications as well. The columns returned by SQL automatically propagate into your widgets, and with some quick configurations you can have a ready-to-run app for your users in no time.

If you spend enough time handling end user app requests, you're bound to run into a case where someone wants to see data from a detail level file inside a grid displaying header-level data. For instance, a customer service rep might ask you to integrate a list of line items into a customer orders app that currently only shows header information.

Upon hearing such a request, you might respond, "So you want to be able to click on an order row to drill down and see all the items?"

When creating grid apps, it can be tempting to pull in every conceivable column someone in the company might want to see. Consider, for example, the case of a grid of inventory items. You know users in accounting like to see dollars, while warehouse users like to see quantities, people in purchasing like to see dates, etc... Everybody has something special they want to see.

Business systems are replete with lists of data, many of which entail users editing, adding or removing records in one or more underlying physical files. Conventionally, a maintenance app for, say, basic customer info would be initially presented to users in the form of a grid. Users would then click on a row to bring up a pop-up window, where the respective data is arranged in a form for editing.

Since the official Valence 6 release in September, many sites currently using a prior version of Valence face the somewhat daunting task of getting users to change their URLs to the new instance. If you're not using some sort of an alias or permanent redirect in Apache — meaning the port number for your Valence instance is part of the URL — then you're looking at potentially hundreds of users needing to update their browser bookmarks to point to a different port.

Programs running on IBM i routinely need to retrieve the specific user ID associated with the person executing the code. In traditional interactive 5250 programs, the user ID is often accessed in RPG through the program status data structure, or by making a call to a CL program that uses the RTVJOBA command. These "old school" green screen approaches for obtaining the user ID may need to be tweaked a bit when running within a web environment.  

A checkbox filter is one of the most intuitive user constraints you can add to a grid. The user simply checks a box and the rows of the underlying grid are immediately filtered to reflect the condition labeled on the checkbox.

Imagine going to a buffet and being told you can only choose ONE item for your plate, and if you wanted more you'd first need to take that single-item plate back to your table, consume it, then return for the next item.  Wouldn't it be great if you could just load up your plate with two, three, four items or more and consume them all at once?  

If you're creating NAB forms or custom apps that send emails using the VVMAIL service program module, as demonstrated in the "Send Email" utility nested inside the Examples app, you can set up a back-end routine to globally intercept all outbound messages using an exit program. The exit program you create can be used to override the mechanism through which emails are sent, or to store pertinent details in a custom "outbound email log" for auditing purposes. 

In our previous newsletter tip we explored how to create an app in which users can upload files to specific locations on the IFS. Now we'll take a look at how to create a separate app that can put those uploaded files to use, in this case rendering them as thumbnail-size images inside a grid column.

Even as companies move toward a more paperless workplace, printed documents and paperwork remain an inevitable part of doing business. Whether it be a supplier invoice, a bill of lading, a certificate of quality, a signed contract, a proof-of-delivery or what-have-you, many business transactions are still supplemented with a piece of paper somewhere.

The coronavirus pandemic and accompanying "social distancing" has created unique business challenges on many fronts.  This is particularly true for companies who weren't already set up to support large swaths of employees suddenly looking to access their IBM i-based ERP systems from home.