Requests for new business applications often begin with basic lists of data — a perfect use case for a Nitro App Builder grid widget — then grow from there. In some cases a requirement may entail allowing users to click on multiple records in the list, then take an identical action against all the selected records at once.

For instance, your marketing department might be seeking a list of active customers, from which a user would select a bunch of customers to send a special promotion en masse.

Hard as we may try, it's almost impossible to guarantee error-free execution of programs after promotion into a live environment. Even with a crack QA team doing in-depth testing beforehand, inevitably some program will eventually do something unexpected in production that requires debugging. And when such a problem happens in a multi-threaded CGI environment like Valence, determining which job to put into debug to diagnose the issue can be challenging when you're using a 5250-based STRDBG session.

As your repository of data sources, widgets and apps created in Nitro App Builder grows, you're likely to encounter situations where you need to move NAB objects from one instance to another, or even deploy entire NAB apps to another IBM i system or partition altogether. Likewise, you may occasionally have a need to retrieve a prior version of a data source/widget/app in order to "undo" some recent changes.

In your never-ending quest to make your Nitro App Builder-based apps as user-friendly as possible, reducing the amount of typing and clicking required for users to get to the data they're seeking can go a long way. If you know your users will be routinely setting a grid filter to, say, a specific date or date range relative to the current date, or a specific department based on where they work, etc., there are many ways to save them the hassle of having to manually set the filter values each time.

One of the more important elements to keeping your users happy is ensuring the apps with which they regularly interact are performing snappily. As discussed in a previous blog post, users can become impatient or distracted when it takes too long to get to the data they need to do their jobs. So it's critical that developers stay on top of these performance issues as much as possible.

Assembling multiple columns of business data into a grid using Nitro App Builder is so quick and simple that developers can easily overwhelm or even intimidate their users with apps containing huge walls of data. For the most optimal user experience, it's important to present large lists of information as cleanly and clearly as possible.

It is often said that a picture is worth a thousand words, and in business the most fundamental expression of that saying comes in the form of charts and graphs. To that end, Nitro App Builder offers a wealth of configurable chart widgets that can be used to effectively summarize data and trends from any IBM i system.

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.