Governance Engine client for the engine-action operations Egeria moved (ISSUE-153)

[dwolfson]

Governance Engine client for the engine-action operations Egeria moved (ISSUE-153)

Egeria main (odpi/egeria#9371, "Add Governance Engine API") moved the engine-action participation operations out of the Automated Curation view service and into a new Governance Engine view service, with URL marker governance-engine. pyegeria ≤ 6.2.4 still calls the old automated-curation paths. On Egeria main those return 404, which pyegeria reports as "unable to connect" (ISSUE-151 labelling). Resource Explorer's engine host hit this as soon as a quickstart was built on Egeria main: its completion pass failed every minute, and claims would fail the same way.

Changes

• New GovernanceEngine client (pyegeria/omvs/governance_engine.py), base {platform}/servers/{view_server}/api/open-metadata/governance-engine, sync and async:

  • get_approved_engine_actions (new): approved, unclaimed actions for one engine
  • claim_engine_action
  • get_active_claimed_engine_actions
  • update_engine_action_status
  • update_action_target_status
  • record_completion_status

  Only the URL marker changed from the old calls. Paths after the marker, verbs, body classes, query params and responses are identical.

• Exported and registered in pyegeria/omvs/__init__.py and pyegeria/__init__.py. Added to _subclient_map as gov_engine / governance_engine in egeria_client.py and egeria_tech_client.py.

• AutomatedCuration:

  • New cancel_governance_action_process(process_instance_guid): POST, no body, .../automated-curation/governance-action-process-instances/{guid}/cancel.
  • The cancel_engine_action docstring now says that on 6.3 a finished action is left unchanged.
  • The five moved methods are kept as deprecated wrappers (DeprecationWarning) that delegate to GovernanceEngine.

• Compatibility with Egeria ≤ 6.2: the deprecated wrappers fall back to the old automated-curation path once, only on an HTTP 404, the first time a client calls. The choice is cached per client. They never fall back on other errors, on an Egeria-level not-found, or after the new path has worked. A GovernanceEngine created directly never falls back.

Tests

• tests/micro-tests/test_issue_153_governance_engine.py, 20 tests:
  • URL, verb, body and params for all six governance-engine calls
  • the deprecated wrappers and their warning
  • cancel-process
  • the 404 fallback and its caching
  • no fallback on 500/403/401, an Egeria not-found, or a direct GovernanceEngine
• The file fails to collect on upstream/main (no GovernanceEngine); 20/20 pass on this branch.
• scripts/omvs_audit.py, run against Egeria main's Egeria-api-governance-engine.http and Egeria-api-automated-curation.http: governance-engine OK=6, automated-curation OK=9, no mismatches.

Not verified live

The GET paths have not been run against a server yet. The local quickstart's qs-view-server doesn't have the governance-engine view service enabled: it is IN_DEVELOPMENT, so enable-all leaves it out. That config change is in progress separately.

🤖 Generated with Claude Code

[dwolfson]

Live check, read-only, 2026-10-16: against a quickstart on Egeria main (85d6c48a) with the governance-engine view service enabled on qs-view-server, this branch's GovernanceEngine.get_approved_engine_actions and get_active_claimed_engine_actions both return 200 (no elements). The deprecated AutomatedCuration.get_active_claimed_engine_actions wrapper reaches the new path and raises its DeprecationWarning. The old automated-curation active-claimed path returns 404 on that server, as expected. The POST calls (claim, status, completion) weren't exercised; that needs a real engine action.