Lifecycles
OCS Lifecycles
Rather than hard-code explicit lifecycles for services, or for wallets, the OCS provides a powerful mechanism for the dynamic definition of lifecycles. A lifecycle may be applied to a service as a subscription on a wallet, or to a wallet itself.
Lifecycles allow operators to define whether a subscription is a once-off immediate application of buckets, a regular subscription or some other form of process driven wallet adjustment. Crucially, lifecycle changes may be triggered by external systems, or internally by the OCS in response to expiry events.
Each designed lifecycle is associated with a lifecycle class, which helps the OCS understand where the lifecycle may be applied, and what access the lifecycle state transition logic when accessing the OCS’s engine.
The OCS is supplied with three types of lifecycle classes:
| Lifecycle | Purposes |
|---|---|
| Account | The wallet lifecycle class is used exclusively for wallet specific lifecycles. |
| Subscription | The subscription lifecycle class is used for all OCS service subscriptions. |
| Annotation (Bucket) | A lifecycle that can be applied to a bucket to trigger, eg, a notification prior to the bucket expiry. |
| Voucher | See the voucher lifecycle page for more information. |
To define a lifecycle, use the /resource/lifecycle endpoint and provide a name for the
lifecycle, and which class it belongs to. The lifecycle will be associated with a service
by the service itself.
A lifecycle is built from one or more states, and the transitions between states are defined also through the OCS API. A conceptual lifecycle may consist of multiple states and steps, including cycles within these (the OCS protects against infinite loops, including infinite loops made of multiple states).
Each voucher state consists of:
| State Field | Purposes |
|---|---|
| Name | A name which is used to identify the state in state transitions. The name is crucial to match to state transition rules. |
| Action | An embedded Javascript fragment to execute within the OCS’s Javascript engine when this state is entered. The Javascript action gives the OCS the logic to execute to perform the lifecycle action. This may include debiting the user wallet (using the OCS rating engine), deleting the subscription (or wallet) the lifecycle is attached to, applying buckets to the subscriber, or performing any other activity allowed by the Javascript engine. |
To move between states, a lifecycle employs state transitions:
Transitions are defined on each state within a lifecycle, and consist of one of three types of state transitions:
- A timer transition is one which is triggered after a predefined expiry period (e.g. 1 month, 24 hours, 1 year, or “tomorrow at midday”). This is a very useful transition mechanism for recurring subscriptions.
- A manual transition is one which is triggered by an external entity which uses the OCS engine API to trigger the transition on a wallet subscription. For example, this transition may be used to cancel a recurring subscription which would otherwise have no other mechanism for stopping the recurrences.
- AN action triggered transition is one which is triggered immediately by the state’s Javascript action executing. This is useful to transition between states for auditing and processing clarity. For example this transition mechanism may be used to delete a subscription that applies a once-off set of buckets, or be used to transition from “paying” to “paid” states.