Service transactions are a central concept within the Verne ecosystem. They contain all information relating to a specific instance of a business service, commonly referred to as a service instance, including the registry data associated with that instance. In other words, service transactions are the concrete representation of the abstract service instance concept. That instance may relate to the live version of the registry data on the register, some previously live version or some instance that is still in-flight or was abandoned or cancelled in some way before being applied.
One or more service transactions can relate to a single service instance, but only ever one service transaction, the "current" one, defines the currently accepted state of that service instance. Also see the service transaction section within the context of the business service concept.
The service transaction is backed by an object that can be serialised to/from XML or JSON which is used to transport data to and from data storage.
Service transactions are the concrete representation of the abstract service instance concept
A service transaction is created or updated as the result of a most interactions with the system.
From a functional perspective this includes actions such as:
- Creating or maintaining registry data
- Viewing registry data
- Searching for registry data
From a technical perspective a service transaction includes:
So remember:
- Service transactions are used to store registry data – companies, business names, users, email delivery logs, etc. – as well as details relating to the specific service instance
- Service transactions are a core part of the Verne ecosystem and are created or updated as the result of most interactions with the system
- There can be multiple service transactions relating to the same service instance
Most activity will create and/or update one or more service transactions. This includes actions performed by:
- an external user via the UI or making use of a web service or API call
- an internal user via the UI or making use of a web service or API call
- a function within the Verne engine or platform triggered by a user or system action
- a function within the Verne engine or platform explicitly called by some configuration or rule
- a system scheduled job
It is important to appreciate the various contexts that the service transaction concept works under. Here are some slightly more detailed examples:
- Any application made by an external client will create and update one or more service transactions
- Any internal service (such as maintain a user) will also create and maintain one or more service transactions
- Any entity that is placed on the register will store its data in a service transaction
- Any changes to an entity on the register will store its data in one or more service transactions
- Any view of an entity will create a service transaction
- Any search will create a service transaction
