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.
In such cases the back-end programs involved accumulate data in the system that must eventually be cleaned up, lest you fill up your disk space with unneeded temp data.
Using the QTEMP library for work files is a common way to alleviate the need to deal with many clean-up tasks, since any work files created there will be discarded once the CGI job ends. But using the job-specific QTEMP library is not always advisable, such as when doing page-at-a-time grid loads, because you can't guarantee the same CGI job that created the QTEMP data for the first page load will be handling the call to load the second page, as described in a prior blog post.
So in cases where you're loading work data into a non-QTEMP file, typically keyed by the Valence session ID, there are two ways to handle the clean-up: (1) Via a global exit program that is called whenever a user logs out or times out of the Portal; or (2) via an exit program called whenever the user closes the app. Let's explore both approaches...
(1) Calling a global exit program upon logout
If you don't need to worry about cleaning up your work file data until the user logs off or gets booted off by virtue of timing out or closing the browser, this is the simplest, catch-all mechanism to use. Using the RPG program EXEXITPGM in your VALENCE6 library as a template, skip down to the LOGOUT section where you'll see the following sample code:
In this case, we're using SQL to delete any records where the session ID corresponds to the session that was just logged out. The "vvsid" field is populated at the start of the program by virtue of the session data passed in via the first input parameter.
Once you've compiled your program, you must register it in Portal Admin > Settings > Exit Programs > "Session logout" as depicted here:
(2) Calling a global exit program upon leaving the app
In some cases you may want to perform clean-up or other special tasks whenever the user exits a specific application, rather than waiting until they log out. To handle this scenario you can set up a special front-end instruction for the Valence Portal to call a specific RPG program whenever an app is closed. That program can then determine which app is being terminated and act accordingly.
There is no template for this type of RPG program, though you can use something simple like EXSQLJSON as your starting point, as that includes the requisite copy source needed to access the Valence RPG toolkit. Your program would need to start by pulling in the app ID using a line like this:
appId = vvIn_num('closing_appId');
Your program could then determine what cleanup tasks or other processes need to be performed based on the app Id. You may find it preferable to act on the app's actual name, which you can pull using the app ID directly from file VVAPPS via the VVAPPNAME field.
Once your exit program is compiled, you will need to tell the Portal to call that program using the front-end configuration "hook" file called Hook.js located in the /resources/desktop/ folder of your Valence directory (i.e., /valence-6.0/resources/desktop/Hook.js). This is a special file that is not overridden whenever you apply a Valence update, so any changes you make here will "stick" between builds.
Once this adjustment to Hook.js is saved, then beginning with the next login to the Portal the program (MY_EXITPGM in this case) will be called every time any app is closed. Note that the exit program may initially be considered "foreign" by the VVCALL program since it's not affiliated with a specific Valence app, resulting in an error message like this:
To resolve this authority issue, go into Portal Admin > Settings > IBM i Settings > "Programs that may be called without checking authority" and click the "Edit" link to add your exit program to the list, as depicted here:
Keep in mind that the logic executed using method (2) could possibly be skipped under certain circumstances, such as when a user's computer loses power unexpectedly, freezes up, etc. So it may be advisable to always apply method (1) as a housekeeping catch-all.