Learn Pentaho - Pentaho Server & Web Console

#Introduction

So far you've been working on the desktop with Spoon. Now it's time to move to the big stage: Pentaho Server. This is where the transformations and jobs you build are executed centrally, scheduled, and accessed by many people — complete with access control.

This episode covers how to set up the server, upload PDI assets, run and schedule jobs from the web, and manage users and roles. After this episode, you'll understand the "design in Spoon, execute on the server" workflow.

#Setting Up the Pentaho Server

The Pentaho Server (BI Server) is a Java application that unites the repository, scheduler, and user console. The basic installation:

1. Download Pentaho Server community edition.
2. Extract the ZIP file into a server folder.
3. Make sure JDK 8/11 is available and PENTAHO_JAVA_HOME is set.
4. Run the startup script for your operating system.

On Linux, the server folder contains scripts like the following:

cd ~/lab/pentaho-server-ce-9.4.0.0-343
./start-pentaho.sh

The server listens on port 8080 by default. Open your browser to http://localhost:8080/pentaho and log in with the default admin credentials. To stop the server, run ./stop-pentaho.sh.

#Uploading Transformations and Jobs to the Server

The server works with a repository — the centralized storage of Pentaho objects. The first step after logging in is uploading your PDI files:

1. Log in to the Pentaho User Console (PUC).
2. Open the menu File > Import and select your .ktr or .kjb file.
3. Choose the folder location in the repository and confirm.

Once uploaded, the object becomes part of the repository and can be accessed by other users with the appropriate rights. Location names in the repository follow a folder structure like the filesystem — create the same hierarchy as your project structure (staging, dimension, facts) to keep it tidy.

When importing, watch the Overwrite existing option and the .zip export format from PDI (via File > Export), which carries the folder structure along. A tidy pattern: export from Spoon as a .zip, import it on the server, then store that zip archive in Git together with the code — so what's on the server can always be reconstructed from source at any time.

#Running and Scheduling Jobs from PUC

Once uploaded, there are two ways to execute:

• Run now: right-click the object in the repository and choose Run or Execute. The server runs the job/transformation using its internal PDI engine.
• Schedule: right-click and choose Schedule to schedule recurring execution — daily, weekly, or based on a specific calendar.

The advantage of the Pentaho Server scheduler over cron: you have a visual interface to see schedules, execution history, and status — plus notifications when a job finishes or fails. In Schedule, you can also set variable parameters per execution, similar to -param on the command line.

Execution history is visible under Browse > Schedules. From here you can see the result logs of every run and decide whether a job needs fixing.

When creating a schedule, mind the server time zone: a 02:00 schedule must be interpreted according to the server machine's time zone, not yours. Many teams find jobs running at the wrong hour simply because of a time zone difference between the development machine and the server. Set the server time zone explicitly and document it in the runbook (episode 19).

#User Access, Roles, and Security on the Server

The Pentaho Server has a user and role model that governs what each person can see and do:

• User: a login identity, for example budi or siti.
• Role: a group of access rights, for example Admin, Developer, Business Analyst, Read-only.
• Permissions: rights on repository objects — read, write, execute, schedule — which can be set per folder and per object.

User and role configuration can be done from the administration interface, or from configuration files in the server folder. Here's a look at the user configuration files you'll get to know:

tomcat/webapps/pentaho/WEB-INF/
├── applicationContext-security-ldap.xml
├── applicationContext-spring-security.xml
└── jdbc.properties

The main concern when setting rights: separate the execute and schedule rights from the edit right. Analyst teams usually only need to run and view reports; only developers should change transformations. Episode 12 will cover LDAP/Active Directory authentication and RBAC in depth.

#Remote Execution and REST API

Besides the web interface, the Pentaho Server exposes a REST API that enables programmatic execution. This is useful when you want to trigger jobs from other systems — for example from CI/CD or internal applications.

An example of triggering a job via the REST API with curl:

curl -s -u admin:password \
  "http://localhost:8080/pentaho/api/jobs?jobName=/home/etl_daily.kjb&action=start"

Replace admin:password with the correct credentials and the path with the object's location in the repository. With this pattern, Pentaho execution can fit into a larger automation workflow.

To check execution status from outside, Pentaho exposes a status endpoint that can be called from monitoring scripts — this pattern becomes an important part of the observability covered in episode 13.

#Conclusion

In episode 10 you got to know the Pentaho Server as an operations hub: setting up the server, uploading transformations and jobs, running and scheduling execution from the Pentaho User Console, and managing user access and roles.

The key takeaways:

• The Pentaho Server executes PDI assets centrally from the repository, not from local files.
• The server scheduler replaces cron with a visual interface and execution history.
• The user and role model controls who sees, runs, and edits what.
• The REST API enables programmatic execution from other systems.

In episode 11, we shift to the end results people can see: reporting & dashboarding — introducing the Pentaho Report Designer, creating tabular, chart, and parameterized reports, then integrating them into dashboards in the Pentaho User Console.