IBM i Portal Applications

Portal Applications let users launch IBM i programs and menus from CoderFlow Portal using their personal IBM i login. Application definitions stay in CoderFlow; you do not need to add users or applications to Atrium environment tables.

For answering questions in Portal Ask conversations or the application Assistant, see Interactive replies. These answers only send conversation messages; they do not launch applications.

To choose which IBM i libraries and tables Portal users can query from Ask, reports and scheduled questions, see Portal Data Access.

Two separate configurations are required: launch trust for the Profound UI instance, and an initial-program entry point for each IBM i user. CoderFlow's guided trust setup does not change user profiles.

Prerequisites

• Enable Portal in CoderFlow Server Settings and give the intended users access to Portal and its applications.
• Set up Settings → Portal → Application hosting. This server-wide setting gives Portal a separate browser address for applications and applies to every environment; hosted installations need custom HTTPS addresses. A server administrator configures it.
• Configure an IBM i connection with Portal Applications selected under Available For and the correct PUI Base URL.
• Install a Profound UI backend that includes Portal launch support and the PUICFLOGIN program. Use the programs from the same installation together.
• Have users save their personal IBM i login under Profile → IBM i Connections.
• Users need normal IBM i authority to the selected programs, menus, libraries, and application data. Portal does not grant additional IBM i authority.

Set up instance trust

The connection's Portal Applications section shows both launch prerequisites: Application hosting, the server-wide setting above, and Launch trust for this PUI Base URL. If hosting isn't ready, the section says so; server administrators get a link to its settings, which opens in a new tab.

Save the connection, then choose Set up launch trust… under Launch trust. The guided setup opens in its own dialog. After the first save of a new Portal connection, or an edit that adds Portal Applications or changes the PUI Base URL, the connection dialog stays open at this launch trust step. The guided setup discovers Profound UI instances, lets you review the selected instance and changes, and can restart that HTTP instance when requested.

The connection row shows the last recorded setup status:

Status	Meaning
Trusted	The recorded setup completed and its signed launch check passed.
Restart needed	Changes were installed but the HTTP instance still needs a restart.
Not verified	The signed launch check did not pass; review the instance and run setup again.
No setup recorded	CoderFlow has no setup record. Trust may already exist from an earlier setup or the downloaded script.

This is a recorded setup result, not a live trust check. The setup dialog lets you discover instances, review changes, install them, and read the result before choosing Done. While installation runs, closing or cancelling is blocked.

Use a temporary setup profile authorized to update the HTTP configuration and trust files, create the protected key object in the Profound UI product library, and transfer its ownership to QPGMR. Restarting requires the appropriate HTTP server authority. The temporary credentials are not saved as the connection's login.

Setup installs CoderFlow's public verification key and creates a protected challenge key on IBM i. The private CoderFlow signing key stays on the CoderFlow server. No additional database table or library is required. Launch expiration is measured using IBM i's clock, so IBM i and CoderFlow do not need matching clocks.

Configure user sign-on

An IBM i administrator performs this step. Replace PUIINST below with the Profound UI product library serving this connection's PUI Base URL, and MYUSER with the user's IBM i profile.

First inspect and record the existing initial program and initial menu:

DSPUSRPRF USRPRF(MYUSER) TYPE(*BASIC)

Do not replace an existing initial program without deciding how to preserve its startup logic.

Users without an existing initial program

Set the profile's initial program to the Portal-specific entry point:

CHGUSRPRF USRPRF(MYUSER) INLPGM(PUIINST/PUICFLOGIN)

PUICFLOGIN takes no parameters. Its behavior depends on the session:

Session	Behavior
Verified CoderFlow Portal launch	Runs the Portal-selected program or menu through the Profound UI launcher, under the signed-on user's authority.
Ordinary Genie session	Returns immediately; normal sign-on processing continues.
Non-Genie sign-on, such as a 5250 emulator	Returns immediately; normal sign-on processing continues.
Invalid or incomplete Portal launch context	Rejects the launch instead of falling through to ordinary startup.

Returning from the initial program lets IBM i continue with the profile's existing initial menu. If that menu is *SIGNOFF, the session signs off. PUICFLOGIN does not supply a replacement menu or recover an initial program that you overwrote.

Use PUICFLOGIN, rather than PUILOGIN, for this pass-through behavior. PUILOGIN also handles Atrium environment selection on non-Genie sign-ons and can report “User not found in environment table” when that configuration is absent.

Users with existing startup logic

Call PUICFLOGIN first from your initial-program wrapper, then continue with your existing startup logic. For example, if the previous initial program was MYLIB/OLDINIT, a CL wrapper could contain:

PGM
  CALL PGM(PUIINST/PUICFLOGIN)
  CALL PGM(MYLIB/OLDINIT)
ENDPGM

Compile the wrapper into your application library and assign that wrapper as the user's initial program. Alternatively, add the first call to your existing initial program. Adapt the example if your existing program needs parameters or other setup.

For ordinary sign-ons, the Portal entry point returns and OLDINIT runs. For a Portal launch, the selected application runs and the Profound UI launcher signs off the Portal job when the application ends. The wrapper's remaining startup code does not run afterward.

Do not catch a Portal launch failure and then continue into the ordinary application. Handle it as a failed launch.

Test the configuration

1. Launch a Portal application in a fresh session and confirm the expected program or menu opens.
2. Launch a second Portal application with a different target to confirm that selection is dynamic.
3. Sign on through ordinary Genie and through your normal non-Genie client. Confirm the existing initial menu or wrapper behavior is preserved.
4. End the Portal application and confirm it closes without entering the wrapper's ordinary application or initial menu.

Changing the profile affects subsequent sign-ons, not an already running session. No CoderFlow restart is needed solely for a profile change.

To undo a profile change, restore the initial-program value you recorded, including its library. If it was *NONE, restore INLPGM(*NONE). Keep the original program or wrapper available until testing is complete.

Troubleshooting

• A hardcoded program opens: the user's initial program may still call it directly. Configure PUICFLOGIN or add it before that call in the wrapper.
• “User not found in environment table” on an ordinary sign-on: the profile or wrapper is entering PUILOGIN's Atrium path. Use PUICFLOGIN for Portal-only handling, preserving any intentional Atrium setup separately.
• “Portal launch trust is not ready”: check the connection's PUI Base URL, installed backend support, and launch trust setup. A profile change does not repair instance trust.
• “Application hosting is not ready”: a server administrator checks Settings → Portal → Application hosting. The connection's Portal Applications section shows the same status.
• The selected target is denied: check the user's authority, the qualified target in the application catalog, and the required application library configuration.

Portal readiness in Ask

Ask CoderFlow reports the application catalog count, server Application hosting and the last recorded launch-trust result separately. It does not run the PUI readiness check or the launch trust setup: it opens the connection's dialog and points at Test connection, or at Set up launch trust… (and Review setup or Cancel setup in the Launch trust dialog). Saving the application catalog does not establish Portal hosting readiness. A recorded trust result is not a new remote verification, and PUI readiness does not establish that users can sign on.

Launch trust setup stays in the connection's guided setup dialog, including setup credentials, trust installation, downloads, restart choices and closing the setup session. Ask can open the connection for you, but it never accepts a setup password, key or token. Cancelling a diagnostic preserves installed trust and other earlier changes.

Launch trust troubleshooting

In a saved IBM i connection's Portal Applications section, select Check trust…, enter a temporary IBM i login, discover instances and select the correct instance. Check trust inspects folder authority, then verifies the current signed trust if the folders pass. It does not install, change permissions or ownership, initialize keys, change HTTP configuration or restart anything. It closes the temporary session afterward and does not save the password. After a manual repair, choose Check again with a temporary login. The connection's last-installation badge is historical; it is not updated by a read-only check.

Blocked folders

For the standard layout, review /www, /www/<instance>, /www/<instance>/conf and /www/<instance>/conf/coderflow. Each must be a real directory, not a symbolic link, with no group or other write permission. The exact /www directory is the only exception: on IBM i it can be writable when QSYS owns it. That exception does not extend to the instance, conf, another path or a symlink. An administrator must also restrict native *OBJEXIST/*OBJMGT authority on the instance.

Review setup lists every blocked folder together, including its owner and mode. For example, if both /www/PUIDEV and /www/PUIDEV/conf allow group/other writes, their owner or an IBM i administrator can review and, if appropriate, run:

chmod go-w '/www/PUIDEV' '/www/PUIDEV/conf'

Review permission impacts first. This can prevent other users and deployment jobs from creating or deleting entries directly in those folders. It does not repair missing read/search authority, symlinks, ownership or native IBM i authorities. Do not recursively change permissions or change owners just to clear a warning. CoderFlow does not change existing folder permissions or ownership.

The installer also requires the existing coderflow directory to belong to the setup profile; safe parent directories need no particular owner. Check trust does not impose that installer owner requirement. If only the final coderflow directory is absent and its parent is verifiably accessible, Review allows the installer to create it with mode 755. Missing parents or unverifiable inspection results block installation; Check trust requires an existing trust directory.

Select Review folders again after a manual correction. Installation rechecks authority, so changes since Review can block it. Prevent concurrent path or permission changes while installing. Custom instance layouts still need manual setup. The guided installer applies these folder protections even for a standard explicitly configured trust path; some PUI versions apply their own folder guard only when using the default path.

Signed check did not pass

Open Details for the HTTP status and a recognized PUI message. Raw server responses are intentionally not displayed.

Result	What to check
HTTP 401/403	HTTP login/access rules, installed trust files, signing identity and protected Portal key. A generic denial does not identify which check failed, even when folder permissions pass.
Other HTTP status or malformed response	Correct instance/HTTP route and a Portal-capable PUI backend.
Timeout or network failure	Running instance, local HTTP port and SSH route.
TLS failure	Trusted certificate chain and the instance certificate's hostname.
Missing CoderFlow signing identity	The server's launch trust setup. Check trust does not create keys.
Disabled, custom or mismatched trust setting	The instance's trust configuration; guided installation remains blocked.

Setup uses an uppercase IBM i profile consistently for both signed identity and HTTP authentication. Password case is preserved. Normal setup already normalized entered profiles; a lowercase-profile customer failure has not been established. An unexplained 403 should not be treated as proof of a username/signature issue.

The Portal challenge service program PUICFC is built to use USRPRF(*OWNER) with owner QPGMR. An administrator can inspect it with DSPSRVPGM SRVPGM(PUILIB/PUICFC) DETAIL(*BASIC), replacing PUILIB with the selected Profound UI product library. If ownership or the user-profile setting differs, consult the PUI administrator or support team before changing it. A generic denial does not establish that this is the cause.

Older PUI versions return only “Portal launch trust rejected.” More specific PUI reason codes require upstream support; this CoderFlow change does not add them.

Finding applications with Ask

Ask CoderFlow can list the applications you can open in a Portal workspace, with your favorites, and give you a link that opens Portal with an application or its favorite star highlighted. Launching stays your own click in Portal: Ask never starts an application or receives its sign-on.