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.

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.