docs / plm / Families, templates and the bake worker

Families, templates and the bake worker

Families and templates work on a PLM the way they work on files, except that members and copies are parts of their own, created and numbered by the server.

Families

A family part (class family, a .fbrep document) holds a table: one row per member, each row the values of the family's parameters. On a PLM each row names the member's part and the revision it is written to.

Generate writes each row to its member: it creates a member part that does not exist yet (in the family's member part type, numbered by that type's rule), overwrites a member revision that is in work and not held by someone else, skips a row that has not changed, and fails only a row whose revision is released or checked out by someone else. It never releases or deletes anything.

Generate always works from the family revision's saved document. You can run it:

From the CAD app's family table pane. The app builds and checks each member itself first (numbers that cannot be part numbers, numbers used twice, values that do not evaluate, features that do not build) and sends only good members, finished. A family with unsaved edits offers Save and generate. The pane also shows the member part type, offers the family category's attributes as columns, and lists cells the server will refuse before you press Generate.
From the family's page in the web workbench, which also imports rows from CSV and lists orphans (members whose row is gone). Rows generated here are assembled by the server and queued for a bake (below).

A member's catalog values come from its family: the family part's own values, overlaid by the row's values for columns that are attributes of the member's category. They are checked before anything is created and refreshed by every Generate.

Templates

A template part (class template, a .tbrep document) declares inputs with defaults. On its page in the web workbench, the spin-out form makes a new part from it: a name, a number when the part type needs one, and a value for each input. The new part is linked into your workspace and queued for a bake.

The bake queue

The server never runs the CAD kernel. A document it assembled itself (a family member generated from the web page, a template copy) or one marked for Force resave is queued as a bake job. A bake worker takes the job, opens the document in the CAD engine, checks that its expressions evaluate and its features build, and either writes it back or reports why it failed.

A revision waiting for its bake cannot be released, until a worker bakes it or someone saves it from the CAD app.
Bake queue in the web workbench lists the jobs with their state, page by page. Authors can retry a failed job or take back a claimed one.
A claim lasts 15 minutes; a working worker renews it every 5 minutes, so a job whose worker died returns to the queue on its own.
Force resave. On the Parts page, select parts and choose Force resave selected parts: each saved model gets a job that rebuilds it and saves it again with a fresh thumbnail. A check-out you already hold stays held; a job waits while someone else holds the revision; a newer save supersedes an older queued result.

Running a bake worker

The bake worker is the desktop app with no window:

brep-app --bake-worker --plm-url https://plm.example.com --plm-token-file ~/worker-token

Make a user for it in the worker group, and an API token of worker scope for that user (an administrator can make a token for another user on the My account page). Put the token alone in a file readable only by the account that runs the worker. See the command-line reference for every switch and exit code.

The worker prints one line per job:

bake worker: signed in to https://plm.example.com as bakebot
CPART000000123 A: done
CPART000000124 A: failed: <the engine's reason>

To keep one running on Linux, a systemd user service is enough:

[Unit]
Description=BREP PLM family and template bake worker
StartLimitIntervalSec=0

[Service]
Type=simple
ExecStart=%h/.local/bin/brep-app --bake-worker --poll 30
Restart=on-failure
RestartSec=30
UMask=0077
NoNewPrivileges=true
PrivateTmp=true

[Install]
WantedBy=default.target

It reads the server and token from the account's plm.json and plm-token, written once with brep-app --plm-configure URL --plm-token-file FILE.

A server-managed worker

Instead of running the worker yourself, the server can start and stop one. Start the server with all three options:

brep-plm serve --data /srv/plm --bind 0.0.0.0:8088 \
  --bake-worker-executable /opt/brep/brep-app \
  --bake-worker-token-file /etc/brep-plm/worker-token \
  --bake-worker-url http://127.0.0.1:8088

Administrators then get Start and Stop on the Bake queue page, with the worker's process id or its last failure. The page cannot choose the program, change its command or read the token. The server starts with its worker stopped. Its output goes to bake-worker.log in the data directory. Stopping keeps every queued job; a job that was being baked can be retried, or returns to the queue when its claim lapses. Shutting the server down with Ctrl+C or SIGTERM stops the worker first.

When moving from a worker you run yourself to a server-managed one, stop the old worker before starting the new one.