Start from Transact application boundaries

Temenos Transact R22 is best learned as an application platform with defined banking applications, records, versions, enquiries, APIs, hooks, services, and a TAFJ runtime—not as a collection of isolated routines. Developers become effective faster when they first understand which layer owns the business record and which extension mechanism is intended for the change.

The developer surfaces worth knowing

  • Application records and versions define much of the transaction experience and validation surface.
  • Enquiries are for controlled retrieval/presentation, while transactional changes belong to application/version flows.
  • Java/TAFJ hooks should extend lifecycle behavior at documented points rather than bypassing application processing.
  • OFS/IRIS/service interfaces are integration boundaries with their own contracts and authorization.
  • Deployment packages, local references, data setup, and runtime services must be treated as one change set.

From customization to runtime behavior

The change starts with the owning application/version, adds a documented hook or configuration, is packaged, deployed to TAFJ, then verified through the same transaction lifecycle users run.

Diagram

A Transact customization from design to runtime

The change starts with the owning application/version, adds a documented hook or configuration, is packaged, deployed to TAFJ, then verified through the same transaction lifecycle users run.

A small controlled extension

Where beginners create maintenance debt

R22 development checklist

  • Identify the owning application, version, and lifecycle point.
  • Prefer documented configuration before custom code when it fits.
  • Keep hooks narrow and deterministic.
  • Package code and required data/configuration together.
  • Test authorization, company/branch context, error paths, and restart/runtime requirements.