Skip to content
EN FR

Services and publication

Documentation status: guide — see Maturity and evidence.

Publication should expose conceptual capabilities, not duplicate the business model in a second API layer.

Three levels

  • Internal action: callable inside the model, view, script or process.
  • Published action: intentionally part of a callable model contract.
  • Exposed action: a published action bound to HTTP, MCP, messaging, agent tooling or another adapter.

This separation allows the conceptual action to remain stable when the external transport changes.

Mapping a published action

A publication adapter typically resolves:

target class/object
+ published action
+ typed input parameters
+ return/result contract
-> adapter validation
-> runtime invocation
-> response mapping

Primitive request values map directly. Conceptual values should use stable identifiers, object references or declared projections. The adapter must reject malformed or incomplete input before dispatch where the invalidity is known at the boundary.

Declarative HTTP service example

The guide's service example is retained with the TXXX -> XXX normalization applied:

serviceGroupDefinitions:
  - UserManagement:
      uuid: EA588812932A434B87A5F47A795C27E4
      type: HTTP
      moduleClass: DataModuleHTTPServer
      debug: true
      virtualPages:
        - method: GET
          path: /users
          class: PathRequestWebPage
          rewrite: /ClassItem[@name='UserManagement.User']/Collection[@name='Entity']

DataModuleHTTPServer and PathRequestWebPage are the modernized public spellings of the implementation-binding names used by the source example. The example is preserved rather than removed because of the historical prefix.

Long-running operations

Do not model a long-running operation as one blocking HTTP call. Publish an action such as Start, Submit, Request or Finalize, create/update a process object, return an acknowledgement/reference, then expose status and events.

Machine-readable publication

OpenAPI and MCP should be projections of the same declared types and actions, not independent type systems. Keep required fields, conceptual identifiers, relation roles and validation semantics aligned.

See Publication API, ABI, and RPC.