Bundled jobs
The liberty-apps wheel ships a curated catalogue of Nomaflow jobs in plugins/nomaflow/jobs.toml. They land in Nomaflow's catalogue automatically after the wheel install + a framework reload — no [[jobs]] block to author, no scheduling to wire by hand.
Each job is a thin wrapper over a Python callable shipped in the nomasx1 plugin package (plugins/nomasx1/). The bundle keeps the orchestration declarative (the [[jobs]] block in jobs.toml) and the work imperative (the callable in Python) — same pattern Liberty uses everywhere.
| Family | Purpose | Read |
|---|---|---|
| Install | One-time provisioning of databases + schema. | Install jobs |
| Preload | Curated reference data export / import — for fresh customer installs or cross-env promotion. | Preload jobs |
| Sync | Copy upstream control + dictionary tables to the local Nomajde mirror. | Sync jobs |
| Collection | One job collects everything Nomasx-1 needs for one or several applications: JD Edwards security, segregation of duties, licences, Object Usage Tracking, and optionally the directory, the activity log, the Oracle database properties and the cross reference. | Collection job |
| Reports | The two audit reports, rendered every month and mailed to the auditors. | Report jobs |
| Audit trail | LogMiner-driven change capture from the audit-source DB. | Audit-trail jobs |
| Maintenance | Materialised-view refresh, cross-reference dump, configuration versions purge. | Maintenance jobs |
All bundled jobs ship with enabled = false — they appear in the catalogue but don't fire automatically. The operator enables a schedule (or runs them on demand) once the install is wired.
At a glance
How the bundle is delivered
The path of a bundled job from the wheel to the catalogue:
| Step | What |
|---|---|
| 1. Wheel install | pip install liberty_apps-*.whl puts the carried payload inside the framework's site-packages. |
2. liberty-apps install | Copies plugins/nomaflow/jobs.toml to ${LIBERTY_APPS_DIR}/../plugins/nomaflow/jobs.toml and plugins/nomasx1/ to ${LIBERTY_APPS_DIR}/../plugins/nomasx1/. |
| 3. Reload | Nomaflow re-reads jobs.toml; the framework re-imports the nomasx1 package; the new jobs appear in the catalogue. |
Full procedure: Installation → Deploy prebuilt apps.
Editing or extending the bundle
The bundled jobs.toml is operator-editable — it lives in your install's plugins directory after liberty-apps install. Add custom jobs by appending [[jobs]] blocks; the bundle's vendor jobs stay alongside yours. On the next wheel upgrade, the installer replaces the file by default, so commit your local additions to source control or move them to a separate jobs.toml next to the bundle's.
The Python callables (plugins/nomasx1/) are vendor-owned and refreshed on every wheel upgrade — don't edit them in place.
Common parameters
Most jobs in the bundle share the same parameter shape under [jobs.params]:
| Parameter | Default | What |
|---|---|---|
apps_id | 10 | The Nomasx-1 application id the job operates against. Override when running multi-tenant against several nomasx1 apps. |
source_connector | varies | The connector to read from — jdedwards, unused (for jobs that don't read upstream), oracle-target (for DB-introspection jobs). |
target_connector | nomasx1 | The connector to write to. Override for a parallel install (nomasx1b). |
target_schema | nomasx1 | The schema name inside the target connector. |
Overrides at run time: Run now on the job's line opens Run with parameters. Per-schedule overrides: set them on the [[jobs.schedules]] block in your override jobs.toml.
Install jobs
One-time provisioning. Run once at customer-stand-up; safe to re-run (idempotent) but pointless.
deploy-databases
First-deploy DB provisioning. Creates the application login roles and the per-target Postgres databases on the framework's default pool, then runs the Nomasx-1 schema bootstrap on the freshly-created database. The companion-step for the Nomajde mirror is created (empty schema — the sync jobs populate it).
| Step | Callable |
|---|---|
create-roles-and-databases | nomasx1.db:create_databases — creates the nomasx1 + nomajde roles and databases. create_roles = true provisions the login roles too. |
init-schema-nomasx1 | nomasx1.db:init_schema — runs the Nomasx-1 schema bootstrap on the nomasx1 DB. |
Parameters
| Key | Default | What |
|---|---|---|
admin_connector | default | The pool to issue the CREATE DATABASE / CREATE ROLE statements through. Must have those rights on the Postgres server. |
targets | ["nomasx1", "nomajde"] | Per-target databases / roles to provision. |
create_roles | true | Set false if your DBA created the login roles by hand. |
target_connector (init-schema step) | nomasx1 | The freshly-created DB to bootstrap. |
When to run — once on a fresh install, right after liberty-apps install + reload. The deploy-databases run typically takes 5-30 seconds.
nomasx1-init-db
One-time setup of a parallel Nomasx-1 deployment. Clones the existing nomasx1 app configuration under a new name (e.g. nomasx1b) — refuses if the target already exists — and provisions a parallel database. Used for multi-tenant hosting (one Liberty install serving two independent customer-data sets).
| Step | Callable |
|---|---|
clone-app | liberty.web.clone:clone_app_step — duplicates the source app's screens / menus / connector binding under the new name + pool. |
init-schema | nomasx1.db:init_schema — schema bootstrap on the new DB. |
Parameters
| Key | Default | What |
|---|---|---|
source_app | nomasx1 | The app to clone from. |
new_app | nomasx1b | The new app's name. Will become the menu / screens / connector name. |
new_pool | nomasx1b | The new pool name to wire under the cloned connector. |
target_connector (init-schema step) | nomasx1b | Same as new_app by convention. |
When to run — once per additional Nomasx-1 instance. For recurring schema upgrades after Python model changes, use nomasx1-init-schema-1 (below) instead — it skips the clone step.
nomasx1-init-schema-1
Create any missing Nomasx-1 tables + materialised views on target_connector. Idempotent — safe to re-run after models.py changes that add new tables. Does NOT drop columns that disappeared from the model (use nomasx1-upgrade-schema-1 for that).
| Step | Callable |
|---|---|
init-schema | nomasx1.db:init_schema |
Parameters
| Key | Default | What |
|---|---|---|
target_connector | nomasx1 | The DB to add the missing objects to. |
When to run — after every wheel upgrade that adds new tables (release notes will flag it).
nomasx1-upgrade-schema-1
Apply pending alembic migrations on target_connector. Runs alembic upgrade head against the Nomasx-1 schema. Idempotent — no-op when already at head.
| Step | Callable |
|---|---|
upgrade-schema | nomasx1.db:upgrade_schema |
Parameters
| Key | Default | What |
|---|---|---|
target_connector | nomasx1 | The DB to upgrade. |
When to run — after every wheel upgrade that ships schema deltas (release notes will say so). Pair with a database backup; alembic migrations are forward-only.
nomasx1-audit-trail-precheck-1
Read-only verification that the audit-source DB has every AUDIT_TRAIL prerequisite. Checks LogMiner availability, archive-log mode, supplemental-logging settings, and the schema rights the audit-trail collector needs. Reports remediation SQL for any failing check.
| Step | Callable |
|---|---|
AUDIT_TRAIL_PRECHECK | nomasx1.audit_trail:j_audit_trail_precheck |
Parameters
| Key | Default | What |
|---|---|---|
apps_id | 10 | Nomasx-1 app id. |
source_connector | unused | Not used by the precheck — it reads via the audit-source connector configured in the application's settings. |
target_connector | nomasx1 | Where the precheck report is written. |
When to run — once before enabling nomasx1-audit-trail-1; the report's remediation SQL goes to your DBA.
nomasx1-roles
Create or refresh the Nomasx-1 roles.
| Role | Grants |
|---|---|
nomasx1_auditor | Every read of the Nomasx-1 data, the Data Explorer, the AI assistant and the two report jobs; the monthly reports are mailed to it. |
nomasx1_admin | Everything: the whole application, its settings and every nomasx1-* job. |
Run it once after the install and after each upgrade, so that new read queries are granted; then assign the roles to users under Liberty Next → Administer → Access. Idempotent; shipped disabled.
Preload jobs
The curated reference bundle ships in ${LIBERTY_APPS_DIR}/nomasx1-reference.tar.gz. The export job builds the bundle from a source install; the import job loads it into a target install.
nomasx1-export-reference
Dump the curated Nomasx-1 reference tables to a .tar.gz bundle. The bundle contains settings_* + sod_* baseline rows (~2k rows, ~35 KB) — the curated reference data Nomasx-1 ships with, suitable for seeding fresh customer installs. Override output_path / source_connector via Run with parameters.
| Step | Callable |
|---|---|
export | nomasx1.preload:j_export_reference |
Parameters
| Key | Default | What |
|---|---|---|
source_connector | nomasx1 | The DB to read the reference rows from. |
schema | nomasx1 | The schema name inside the source connector. |
output_path | /tmp/nomasx1-reference.tar.gz | Where to write the bundle. The framework's service user needs write access. |
When to run — when curating a vendor release (NOMANA-IT-internal); not part of typical customer ops.
nomasx1-import-reference
Load a curated Nomasx-1 reference bundle into target_connector. Operator must create the target application in Nomasx-1 → Settings → Global → Applications first — the import precheck refuses to start otherwise. Set replace = true for a destructive TRUNCATE-then-INSERT cycle.
| Step | Callable |
|---|---|
import | nomasx1.preload:j_import_reference |
Parameters
| Key | Default | What |
|---|---|---|
target_connector | nomasx1 | The DB to import into. |
schema | nomasx1 | The schema name inside the target connector. |
bundle_path | /tmp/nomasx1-reference.tar.gz | The bundle to load. After liberty-apps install, the default bundle lives at ${LIBERTY_APPS_DIR}/nomasx1-reference.tar.gz — set this parameter accordingly. |
replace | false | When true, TRUNCATE each target table before INSERT. Use only for a clean re-seed. |
target_apps_ids | "" | Comma-separated app ids to restrict the import to (e.g. "10,20"). Empty = all apps in the bundle. |
When to run — once after deploy-databases, to seed the SoD baseline + reference settings. The job is safe to re-run with replace = false (only adds missing rows).
Sync jobs
Mirror upstream control / dictionary tables from JD Edwards into the local Nomajde database. Schedule daily — the data they read changes infrequently.
nomajde-daily-sync
Daily sync of JDE control + data-dictionary tables to Nomajde. Reads from the configured jdedwards connector and overwrites the matching tables in the nomajde connector. Each step is a single-table sql_copy with mode = "overwrite" — full-table refresh per run.
Tables synced
| Source (JDE) | Target (Nomajde) | What it carries |
|---|---|---|
PS920CTL.F0004 | nomajde.f0004 | UDC types. |
PS920CTL.F0005 | nomajde.f0005 | UDC values. Trailing whitespace on DRKY is trimmed via strip_both_columns. |
DD920.F9200 | nomajde.f9200 | Data dictionary master. |
DD920.F9202 | nomajde.f9202 | Data dictionary text. |
DD920.F9210 | nomajde.f9210 | Data dictionary glossary. |
OL920.F9860 | nomajde.f9860 | Object librarian master. |
OL920.F9865 | nomajde.f9865 | Object librarian dependencies. |
Type coercion
Each step uses type_coercion = "jde" + decimal_mode = "truncate" — JDE column types are mapped to standard SQL on the way in (e.g. JULIANDATE → DATE, STRING(N) trimmed to VARCHAR), with truncation rather than rounding on decimals.
Schedule — 30 2 * * * (02:30 daily, Europe/Paris timezone in the bundle). enabled = false by default — enable it from its line on the Jobs page once jdedwards is wired and the first run succeeded as a manual ▶ Run now.
Retry / alerts — 2 retry attempts, alert when the run exceeds 120 minutes.
nomajde-remerge-security
Re-merge the JDE security (F00950 / F00950W / F9006) of every parent role affected by a change captured in the active draft package. Driven by the nomajde.security:j_remerge_security plugin with scope = "package".
This job — and its -all sibling — solves the JDE-specific problem that role security is derived from a tree of parent → child role assignments. Changing a child role's permissions only affects production once every parent that includes it has been re-merged. Doing that by hand on a wide change is tedious and error-prone; the job walks the change package, derives the impacted parents from the captured writes, and re-runs the merge for each.
| Step | Callable |
|---|---|
REMERGE_SECURITY | nomajde.security:j_remerge_security — reads the active draft package, derives the impacted parent set via the anchored F00926 role queries, re-merges F00950 / F00950W / F9006 per parent. |
Parameters
| Key | Default | What |
|---|---|---|
apps_id | 10 | Nomajde application id. |
source_connector | nomajde | Where the merged security tables live (the Nomajde mirror that holds the F564* tables). |
target_connector | jdedwards | The live JDE database the re-merged rows write back to. |
scope | package | package → only the parents impacted by the active draft. all → every parent (use nomajde-remerge-security-all instead). |
When to run — as a post-apply step on a change package that touches roles or role-to-role assignments. Register the job's id (nomajde-remerge-security) on the contributing screen's Screen.post_apply; the framework then runs it once on the target after the bundle's rows land. Manual ▶ Run now works too, in which case the active draft on the configured application is used.
The job's diagnostics land in the run log under the nomajde.* logger namespace (registered by the plugin) — useful when the merge skipped a parent because its F00926 row was missing.
Idempotent — re-running on the same draft package re-merges the same parents and produces the same rows. Safe to retry after a partial failure.
nomajde-remerge-security-all
Re-merge the JDE security of every parent role in the system, regardless of recent changes. Same plugin as above (nomajde.security:j_remerge_security) but with scope = "all".
| Step | Callable |
|---|---|
REMERGE_SECURITY_ALL | nomajde.security:j_remerge_security with scope = "all". |
When to run — once after a clean import of the JDE security tables (F00950 / F00926 from a fresh extract), or as a recovery step after a known-bad merge. Not scheduled by default; not idempotent in the trivial sense (re-running on a stable system is a no-op data-wise but writes the same rows again, which can take minutes on a large JDE install).
For a partial re-merge — only the parents affected by this change — use nomajde-remerge-security (scope = "package").
JD Edwards monitoring and AIS jobs
Jobs that reach the JD Edwards servers themselves: Server Manager for the health of the instances, the AIS server for reports and data.
nomajde-jde-health
Health check of the JD Edwards servers through Server Manager. The nomajde.monitoring:health_check step asks the jde_server_manager API connector for the instances (instancesinfo), runs Server Manager's health check (health) on every running enterprise, web and REST server, and writes one row per instance to the jde_health table of the Nomajde database. The rows feed Monitoring → JDE Servers and the overview tiles.
| Parameter | Default | What |
|---|---|---|
checks | UBE, BSFN, Port Test, Login, Interactive App, OVR | The Server Manager checks that count; blank = all of them. |
groups | blank | JSON {"<host>-<enterprise server>": ["<host>-<instance>", …]} — an enterprise server down or unhealthy fails its instances without checking them; when set, only the instances listed are monitored. |
auto_stop | false | Stops a running instance that failed (stopinstance), and the running instances of a failed enterprise server. |
keep_days | 30 | Rows older than this are removed at each run. |
Schedule — */5 * * * * (Europe/Paris), enabled = false: set the Server Manager address and the jde_admin password on the jde_server_manager connector in Liberty Next → Build → Connectors, then enable the job. Nomajde → Jobs → Check the JDE servers runs it on demand.
Alerts — the run fails when an instance did not pass (failed, down or error), after writing the rows; on_failure alerts are on.
nomajde-ais-report
Run a JD Edwards report (UBE) through AIS and wait until it is done. Step nomajde.ais_steps:j_ais_report over the ais_connection connector.
| Parameter | Default | What |
|---|---|---|
report | — | The report to run, e.g. R0010P. Asked at launch, required. |
version | XJDE0001 | The version. |
queue | blank | The job queue; blank = the default queue. |
po_values | blank | Processing options by id, JSON: {"1": "20261029"} (dates yyyyMMdd). |
wait | true | Waits for the end of the report. |
timeout_seconds | 3600 | The run fails when the report is still running after this delay. |
The run fails when the report ends in error. The log gives the job number, the server and the final status. Run it by hand with Run with parameters, or copy it with fixed parameters and a schedule.
nomajde-ais-export
Export a JD Edwards table or business view to an xlsx file. Step nomajde.ais_steps:j_ais_export: browses the table or view through AIS and writes <run>-<name>.xlsx among the files of the run, the headers being AIS's column titles. The file is downloaded from the run detail; to mail it, add a notify step with attach = ["*"].
| Parameter | Default | What |
|---|---|---|
table / view | — | The table (F0101) or the business view to export — one of the two. |
columns | blank | Data items separated by commas (AN8, ALPH; F4102.LITM for a view's column); blank = every column. |
conditions | blank | JSON: {"AT1": "C"} (equals) or [["AN8", ">=", 500]]. |
max_rows | 5000 | The row limit; 0 = no limit. The log warns when JD Edwards holds more rows. |
filename | blank | The file name; blank = the table or view name. |
The AIS steps
The nomajde.ais_steps entry points appear in the job editor's callable picker for a python step and in the list of the call_plugin screen action. All use the ais_connection connector.
| Entry point | Does |
|---|---|
j_ais_report | Runs a report / version, on a queue, with processing options; waits for its end. |
j_ais_export | Exports a table or a view to an xlsx file of the run. |
j_ais_count | Counts the rows of a table or a view matching conditions. |
j_ais_bsfn | Calls a business function with its parameters; returns its output values. |
j_ais_orchestration | Runs an orchestration with its inputs; returns its response. |
j_ais_scheduler | Starts or stops the JD Edwards scheduler of an environment (action = start / stop). |
Conditions, processing options, parameters and inputs are given as TOML tables in the job, or as JSON text when typed in Run with parameters or an action's parameters. An empty text means not set. On an AIS error, the step fails with AIS's own message.
Collection job
nomasx1-collect-all
Collect everything Nomasx-1 needs for an application, in order, then refresh the materialised views once at the end.
| Family | Steps | On by default |
|---|---|---|
| JD Edwards security | JDE_OBJECTS, JDE_OBJECTS_VERSIONS, JDE_SEC_OBJECTS, JDE_SEC_MENUS, SECURITY_USERS, SECURITY_USERS_DATA, SECURITY_ROLES, SECURITY_ASSIGNMENTS, JDE_TASKS, JDE_MENUS, SECURITY_MENUS, SECURITY_RIGHTS_* (menus, applications, actions, per user, audit) | Yes |
| Segregation of duties | SOD_CONFLICT_DETAILS, SOD_CONFLICT_SUMMARY — the matrix of Settings → Segregation of duties against the security just collected | Yes |
| Licences | LICENSE_JDE_EMPLOYEES, LICENSE_JDE_USERS | Yes |
| Object Usage Tracking | LICENSE_JDE_OUT, LICENSE_JDE_OUT_OBJECTS, LICENSE_JDE_OUT_USERS, LICENSE_JDE_OUT_PURGE | Yes |
| Directory | SECURITY_LDAP — the LDAP / Active Directory set in Settings → LDAP | No |
| Activity log | SECURITY_ACTIVITY_LOG | No |
| Oracle database | DB_ORA_PROPERTIES, DB_ORA_OPTIONS, DB_ORA_FEATURES, DB_ORA_PARTITIONS, DB_ORA_LICENSES | No |
| Cross reference | JDE_XREF_APPS | No |
| Views | REFRESH_VIEWS | Yes |
Presets
| Preset | Runs |
|---|---|
| Security and SoD | The security and the segregation of duties — the licence and OUT steps off. |
| Licences | The licences and OUT — the security and SoD steps off. |
| Everything | Every step, the directory, the activity log, the database and the cross reference included. |
Applications — the job offers the applications of Nomasx-1 → Settings → Global → Applications as checkboxes, with All. It runs once per application ticked, one after the other. On a schedule or in a preset, apps_id = "all" collects every application at each fire.
Params — source_connector = jdedwards, target_connector = nomasx1. Two attempts on failure; an alert after 90 minutes.
Menu — Nomasx-1 → Jobs → Collect security and SoD and Collect licences run the two presets. See Nomasx-1 jobs.
When to run — daily on an active install, with a schedule on a preset: Security and SoD every night, Licences weekly.
Report jobs
nomasx1-report-licences and nomasx1-report-security-sox
Render an audit report and mail it. A report step renders the PDF — the licence audit or the Security & SoD assessment — for one application; a notify step sends it to the nomasx1_auditor role with the file attached.
| Parameter | Use |
|---|---|
| Applications | One or several applications, or All — one report per application. |
| Language | fr or en. |
Schedule — the 1st of each month at 06:00 (Europe/Paris); shipped disabled. Enable it once the e-mail account is set in Notifications.
Audit-trail jobs
LogMiner-driven change-data capture from the audit-source database — Oracle archive logs. Operate independently of the security / license / SoD jobs.
nomasx1-audit-trail-1
Capture LogMiner-driven change-data — Audit Trail using Oracle archive logs.
| Step | Callable |
|---|---|
AUDIT_TRAIL | nomasx1.audit_trail:j_audit_trail |
Source connector — unused here (the audit-source connector is read from the application's settings, not the job's params).
Long-run alert — 30 minutes.
When to run — typically scheduled hourly or every 15 minutes. Before enabling, run nomasx1-audit-trail-precheck-1 and fix any reported gaps.
nomasx1-audit-trail-reset-scn-1
Reset the last SCN used by Audit Trail for an application. Use after a long pause (audit-trail catching up on too much history would be slow) or after switching audit sources. Default scn = 0 makes the next run pick up the current SCN — i.e. start fresh from "now". Override scn via Run with parameters to set a specific SCN.
| Step | Callable |
|---|---|
AUDIT_TRAIL_RESET_SCN | nomasx1.audit_trail:j_audit_trail_reset_scn |
Params — standard shape + scn = 0 (the default).
When to run — on demand. Not scheduled.
nomasx1-audit-trail-purge-values-1
Purge the audit-trail values to reclaim space. Deletes rows of AUDIT_TRAIL_VALUES — the field-level before / after values the Audit Lookup screen filters on. The captured statements (AUDIT_TRAIL_QUERY) are kept, so any period can be rebuilt later with nomasx1-audit-trail-rebuild-values-1.
| Step | Callable |
|---|---|
AUDIT_TRAIL_PURGE_VALUES | nomasx1.audit_trail:j_audit_trail_purge_values |
Params — standard shape, plus:
| Param | Default | Meaning |
|---|---|---|
older_than_days | 0 | 0 or less: delete every value of the application. More than 0: delete only the values whose statement is older than that number of days. |
table | "" | Limit the purge to one table. Empty: every table. |
Records the number of value rows deleted.
When to run — on demand, when the values table grows too large. Not scheduled.
nomasx1-audit-trail-rebuild-values-1
Rebuild the audit-trail values of a table and a period by parsing again the statements kept in AUDIT_TRAIL_QUERY — after a purge, when value-level analysis is needed again. The audited columns set per table are applied, so the rebuilt values match what live capture would have written.
| Step | Callable |
|---|---|
AUDIT_TRAIL_REBUILD_VALUES | nomasx1.audit_trail:j_audit_trail_rebuild_values |
Params — standard shape, plus:
| Param | Default | Meaning |
|---|---|---|
table | "" | The table to rebuild. Empty: every table. |
date_from, date_to | "" | The period, YYYY-MM-DD, end date included. Empty: no bound. |
replace | true | Clear the values of the window first, so that running the job twice gives the same result. |
Records the number of value rows written.
When to run — on demand, after a purge. Not scheduled.
Maintenance jobs
nomasx1-refresh-views
Refresh materialised views — speeds up Nomasx-1 queries. All major collection jobs run this at their end, so a dedicated invocation is rarely needed. Useful after a manual SQL data fix or a bulk import.
| Step | Callable |
|---|---|
refresh-views | nomasx1.db:refresh_views |
Params — target_connector = nomasx1.
When to run — after a manual data fix; not scheduled.
nomasx1-xref-dump-object-1
Diagnostic: dump the raw definition of one JD Edwards object. Writes to files the decompressed OMW XML of the object's forms (F98751) and the text it references (F98750), to inspect the raw structure — for example a missing tab or control id. Read-only: nothing is written to the target database.
| Step | Callable |
|---|---|
JDE_XREF_DUMP_OBJECT | nomasx1.xref:j_jde_xref_dump_object |
Params — standard shape, plus:
| Param | Default | Meaning |
|---|---|---|
object_id | P01012 | The object to dump — set it in Run with parameters. |
output_dir | "" | The folder of the files. Empty: a temporary folder on the server. |
When to run — on demand, to analyse a cross-reference gap. Not scheduled.
config-versions-purge
Purge the old configuration versions kept by the configuration history — file snapshots and screen bundles. For each file, a version is removed when it is beyond the 20 most recent or older than 90 days; the newest version of each file is always kept, so the history never empties.
| Step | Callable |
|---|---|
purge | liberty.jobs.maintenance:purge_config_versions |
Step arguments — max_versions = 20, max_age_days = 90; 0 or less turns that rule off.
Records the number of versions removed. Two attempts in all on failure.
Schedule — enabled, every day at 03:00 (Europe/Paris).
Scheduling tips
A typical cadence on an active install:
| Time | Job |
|---|---|
| 02:30 | nomajde-daily-sync (the shipped schedule). |
| 03:00 | nomasx1-collect-all, preset Security and SoD, every application. |
| Sunday 04:00 | nomasx1-collect-all, preset Licences. |
| 1st of the month 06:00 | The two report jobs. |
Audit-trail (nomasx1-audit-trail-1) typically runs every 15-60 minutes — a separate cadence from the collection.
The bundled jobs are enabled = false out of the box. Set a schedule in the job editor, on the job or on a preset, then switch the job on from its line on the Jobs page. The main ones — the collection, the two reports, the JD Edwards sync — head the list under Main jobs.
Common pitfalls
| Mistake | Symptom | Fix |
|---|---|---|
| A delivered job whose steps were changed is not updated by a wheel upgrade. | The upgrade lists it as kept. | Schedules, presets, alerts and parameter values survive an upgrade on their own; keep the steps as delivered, or mark the job override = true — see Deploy prebuilt apps. |
Collection job fails with No module named 'nomasx1'. | Plugin code isn't in the framework's plugins path. | Run liberty-apps install --target $LIBERTY_APPS_DIR to materialise the payload; reload the framework. |
nomasx1-import-reference fails with "target application not found". | Application not created in Nomasx-1 → Settings → Global → Applications. | Create the app in the UI first; the precheck refuses to start otherwise. |
deploy-databases errors with permission denied. | default pool can't create DBs / roles. | Temporarily point default at a Postgres superuser; revert after the run. |
| Schedule set but job doesn't fire. | The job is disabled (the bundle ships enabled = false). | Switch it on from its line on the Jobs page after setting the schedule. |
| Daily sync runs but Nomajde tables remain empty. | The jdedwards connector isn't configured (the sync job silently runs zero rows). | Liberty Next → Build → Connectors → jdedwards — test the connection from the UI before the next run. |
| Audit trail starts producing thousands of rows per minute. | The job started from SCN 0 — replaying the whole archive log. | Run nomasx1-audit-trail-reset-scn-1 (default scn = 0 → next run picks current SCN) to start fresh. |
| Materialised views show stale data after a custom SQL fix. | The collection job's end-of-run REFRESH_VIEWS step didn't run (you bypassed it). | Run nomasx1-refresh-views manually. |
What's next
- Deploy prebuilt apps — how the bundle reaches the install in the first place.
- Nomaflow → Jobs → Catalog — the Jobs page: enabling schedules, running on demand, Run with parameters.
- Nomaflow → Runs → History — the per-run detail page where the bundled jobs' output lands.
- Nomaflow → Custom Python — how to write your own callables alongside the bundled
nomasx1.*ones.