Running Native Go Binaries in PeopleSoft Process Scheduler

For decades, the standard toolkit for PeopleSoft batch development has remained virtually unchanged: Application Engine, SQR, and occasionally shell scripts or COBOL.

While Application Engine is deeply integrated into PeopleTools metadata, it can feel heavy-handed when your objective is modern data engineering—generating formatted Markdown reports, writing JSON payloads, communicating with modern REST APIs, making LLM calls, or running fast audits across thousands of records. SQR, on the other hand, is an aging legacy language with proprietary tooling and declining developer adoption.

I wanted a better, modern approach: compiled, blazing-fast batch programs that run directly inside the PeopleSoft Process Scheduler ecosystem with zero server runtime overhead.

My v1 implementation is called go-psprcs , which makes Go batch processes “API” Aware so they can report live status back to PeopleSoft Process Scheduler, and in this post, I will explain how the architecture works, and the quirks you need to navigate in PeopleTools to make it run smoothly.

Why Go for PeopleSoft Batch?

When running custom batch logic on PeopleSoft servers, Go provides practical advantages over both traditional PeopleTools engines and interpreted alternatives like Python or Java:

• True Version Control and Modern CI/CD: PeopleSoft objects (Application Engine programs, PeopleCode events, and SQL definitions) do not have native version control. They are stored as relational database metadata across PeopleTools system tables, which makes standard Git workflows, pull requests, branch-based feature development, and meaningful line-by-line diffs painful or nonexistent without heavy third-party tooling. A Go batch program lives entirely in Git: you can branch, review diffs in pull requests, run automated unit tests in CI/CD pipelines, and tag releases like any modern software project.
• AI Development Friendly: Go’s strong typing, modular design, and extensive standard library make it well-suited for integrating AI capabilities into batch processes. Whether you are calling external LLM APIs, performing local inference, or orchestrating complex AI workflows, Go provides the performance and concurrency model needed to handle AI workloads efficiently.
• Single Static Binaries: Go compiles down to a single, standalone executable. There are no Python virtual environments to manage on your batch domains, no node_modules, and no JVM memory warmup overhead. You can cross-compile for different operating systems and architectures from a single development machine (GOOS and GOARCH environment variables).
• Pure-Go Database Connectivity: With pure-Go drivers like go-ora , the binary connects directly to Oracle over TCP without requiring an Oracle Client installation, OCI DLLs, or CGO. You can cross-compile for Windows from macOS or Linux (GOOS=windows GOARCH=amd64) in a single command.
• Native Concurrency for Network-Bound & API-Heavy Batch: Delivered PeopleSoft batch engines (Application Engine, SQR, COBOL) are fundamentally single-threaded. Achieving parallelism historically required complex multi-instance designs: provisioning sets of dedicated temporary state records (MY_AET_1, MY_AET_2), partitioning data ranges, and dynamically spawning multiple sub-processes. This single-threaded bottleneck is devastating for modern batch jobs that interact with external REST APIs (address validation, payment gateways, document signing, or cloud integrations), where the process spends the vast majority of its lifecycle idle in network I/O wait. Go’s lightweight goroutines and channels make concurrent I/O effortless. A single Go binary can run a bounded worker pool of 20, 50, or 100 concurrent HTTP requests with rate limiting, slashing run times from hours down to minutes—all within a single process instance and without touching temporary tables.
• Sub-Second Execution & Low Footprint: A Go batch utility starts in milliseconds, uses minimal memory, and handles complex concurrency out of the box.
• First-Class Operational Integration: Process Scheduler handles queuing, scheduling, priority, and operator permissions in PIA. With an API-aware Go client, your executable reports live status updates back to Process Monitor just like an Application Engine program.

Setting Up the Process Type in Process Scheduler

Before you can run a Go binary through Process Scheduler, you must define a custom Process Type Definition to instruct PeopleTools how to launch the executable.

In the PeopleSoft Internet Architecture (PIA), navigate to:

NavBar: Menu > PeopleTools > Process Scheduler > Process Scheduler Process Type

Create a new Process Type (underlying record: PS_PRCSTYPEDEFN) for each combination of operating system and database type you support:

• Process Type: Enter a descriptive type key (for example, go-psprcs).
• Operating System: Windows (or UNIX).
• Database Type: Oracle (or your database platform).
• Generic Process Type: Select Other (stored as 0 in GENPRCSTYPE).
• Command Line: %%TOOLBIN%%%%PRCSNAME%%.exe (points to the PeopleTools client binary folder, e.g. ps_home\bin\client\winx86).
• Working Directory: %%TOOLBIN%%
• Parameter List: Provide the command-line template with PeopleTools meta-strings:

  -CT %%DBTYPE%% -CS %%SERVER%% -CD %%DBNAME%% -CA %%ACCESSID%% -CAP %%ACCESSPSWD%% -I %%INSTANCE%% -R %%RUNCNTLID%% -CO "%%OPRID%%" -OT %%OUTDESTTYPE%% -FP "%%OUTDEST%%" -OF %%OUTDESTFORMAT%%
  

The “Other” Quirk and the 8-Character Name Limit

Notice that on the Process Scheduler Process Type page, the Generic Process Type dropdown is set to Other.

PeopleSoft categorizes every process engine using the GENPRCSTYPE translate field:

• 0 – Other
• 1 – SQR
• 2 – PeopleSoft COBOL
• 3 – Crystal Report
• 5 – Application Engine

For custom executables, GENPRCSTYPE must be set to 0 (Other).

The 8-Character Name Limitation

Setting GENPRCSTYPE to Other triggers a subtle PeopleTools rule. In PRCSDEFN.PRCSNAME.SearchSave, PeopleCode checks:

If GENPRCSTYPE <> "5" Then
   If Len(PRCSNAME) > 8 Then
      Error MsgGet(65, 47, "Process name for type %1 cannot exceed 8 characters in length.", %This.Value);
   End-If;
End-If;

Only Application Engine processes (GENPRCSTYPE = 5) permit 12-character names. All custom binaries and scripts under Other are strictly capped at 8 characters (OPRAUDIT.exe, USRCLNUP.exe). If your binary name exceeds 8 characters, PeopleSoft rejects the process definition with error (65, 47).

Making the Process API-Aware

You can kick off any batch process from PeopleSoft Process Scheduler, whether it is an SQR, Application Engine, or a custom Go executable. The key is making your binary “API-aware” so it can communicate status and results back to the system tables. By treating the executable as “API-aware”, the binary connects back to PeopleSoft system tables using the parameters passed on the command line:

-CT %%DBTYPE%% -CD %%DBNAME%% -CA %%ACCESSID%% -CAP %%ACCESSPSWD%% -I %%INSTANCE%% -R %%RUNCNTLID%% -CO "%%OPRID%%" -OT %%OUTDESTTYPE%% -FP "%%OUTDEST%%" -OF %%OUTDESTFORMAT%%

Using these flags, go-psprcs performs three core functions:

• Lifecycle Transitions: Transitions PSPRCSRQST and PSPRCSQUE from Initiated (5) to Processing (7), and ultimately to Success (9) or Error (10).
• Structured Message Logging: Inserts entries into PS_MESSAGE_LOG and PS_MESSAGE_LOGPARM so operators can view step-by-step progress and diagnostics directly within the Process Monitor Message Log window.
• Exit Code Integrity: If an unhandled failure occurs, the program exits with a non-zero code, ensuring Process Scheduler immediately flags the run as an Error.

Delivering Output to the Report Repository

When running reports with an Output Type of Web, a common pitfall is relying on the command-line flag %%OUTDEST%%. For Web destinations, PeopleSoft populates %%OUTDEST%% with distribution targets (such as User:PS), rather than a filesystem directory.

To ensure generated reports, CSVs, or log files appear under View Log/Trace, the program must write directly into the temporary instance folder created by Process Scheduler. As documented in our article How to get files to show up in the Process Monitor/Report Repository , the canonical solution is querying PS_CDM_LIST.PRCSOUTPUTDIR:

SELECT PRCSOUTPUTDIR FROM PS_CDM_LIST WHERE PRCSINSTANCE = :1

Writing to this directory allows the Distribution Status Agent (PSDSTSRV) to automatically collect the output files upon completion and publish them to Report Manager.

If you are generating non-standard file formats such as Markdown (.md), PeopleSoft’s distribution agent requires a quick one-time front-end setting to authorize the file extension. For a dedicated walkthrough on configuring this, see our companion article: Publishing Markdown Files to the PeopleSoft Report Repository .

The Sample: OPRAUDIT

To demonstrate this architecture in practice, we created OPRAUDIT, a sample Go executable included in the go-psprcs repository .

OPRAUDIT connects to the PeopleSoft database, audits user accounts in PSOPRDEFN for locked statuses and failed logins, writes progress updates to PS_MESSAGE_LOG, and renders an audit report directly to the instance output directory—all compiled into an ultra-fast, standalone executable.