Status of entities

Activation status

The state diagram for Associate, Contract, PersonalizedProduct, PersonalizedProductPart (i.e., entities with an activation status) shows possible values and transitions:

Diagram Activation states and transitions

The state of new object is created, after its activation its state can freely change between active, inactive and deactivated.
Objects in state created or deactivated are passive, i.e., they are not allowed to access the network. This is why OSB allows to delete objects in one of these states. While it is possible to modify an object in the created state, e.g., to configure a personalized product part or to add new children, it is not possible to apply these changes to an object in the deactivated status. This is very practical rule: why should we change an object that does no more contribute to our business?

• A created object may be deleted without restrictions, any reserved resources (e.g., a phone number) can be reused immediately.
• A deactivated object should be deleted only after some time it has reached the state. Possibly we need to archive some or all of its data before removing it from the OSB database.

Status of Associate

The possible states for an Associate are shown in diagram

Diagram Status diagram for Associate

The order of the status is: active(4) > inactive(3) > deactivated(1).
Thus, if we say that an associate's status is decreased, we mean that its status is changed from active to (inactive or deactivated) or from inactive to deactivated.

Status of Contract

The valid status and transitions for a Contract are shown in diagram

Diagram Status diagram for Conract

The order of the status is: active(4) > inactive(3) > created(2) > deactivated(1).
We'll see in the discussion about compatible status why it is appropriate to rank created is between inactive and deactivated.

Status of PersonalizedProduct and PersonalizedProductPart

The status and transitions for a personalizedProduct and personalizedProductPart are the same. They are shown in diagram

Diagram Status diagram for PersonalizedProduct and PersonalizedProductPart

The order of the status is: active(4) > inactive(3) > assigned(2) > deactivated(1).

Status compatiblity

The classes Associate, Contract, PersonalizedProduct and PersonalizedProductPart are in a parent - child relationship to each other, with Associate at the top of the pyramid. Within an hierarchy the status of an object must be compatible with the status of its parent. The table below show the consistency matrix for each parent - child pair:

Compatible states for hierarchically structured Associates

The rule for the table above is: status(parent) >= status(child).

Compatible states for Associate(contract owner) and Contract

The status of a contract must be compatible with the status of the contract owner as defined in the table below. OSB allows that new contracts are created for inactive associates, such contract however can be activated only after the contract owner is active again.

When using the numerical values for the status of the contract owner and the contract, the rule for table above is:
status(contract owner) >= status(contract).
It is actually the simplicity of this rules that motivated the ranking of the contract status created between inactive and deactived.

Compatible states for Contract and PersonalizedProduct

Using numerical values for the status, the rule is:
status(contract) >= status(personalized product).

Note that for the personalized product it is not possible to reach the status inactive or deactivated if the contract status is (and remains) created: Both status are only reachable after the personalized product is activated. But this is only possible if the contract is activated also, and once activated there is no way back to the initial status created. This observation nicely fits our neeeds because it allows for the simple status consistency rule that otherwise wouldn't be valid for created(contract) - deactivated(personalized product).

Compatible states for Associate (product user) and PersonalizedProduct

Using numerical values for the status, the rule is:
status(product user) >= status(personalized product).

Compatible states for PersonalizedProduct and PersonalizedProductPart

The rule for the matrix above is: status(parent) >= status(child).
For the inaccessible status combinations created(parent) - inactive(child) or deactivated(child) please refer to the note given for contract - personalized product.

Handling of incompatible states

When the status of a parent is decreased, the status of dependent childs may contradict the new status of the parent. OSB updates the status of children using the following rules:

¹⁾ The second rule resolves the conflict that the only allowed status for a child of a deactivated parent is deactivated as well. Without the special regulation we'd first have to activate the child before the parent (and the child with it) can be deactivated: In practice this rule means that any resources that have never been used are freed -and therefore available to other users- immediately, without quarantine time.

With the rules above the current status of each entity in a hierarchy associate - contract - personalized product - personalized product part is stored in the database. The status of an entity can obviously change for two different reasons: Firstly because a user explicitly changed its status or secondly because the status of its parent was decreased. This leaves us with the question of how we handle the status of the childs if the status of the parent is increased. The problem is shown in diagram

Diagram explicit and implicit status changes

In diagram the personalized product PP consists of the personalized product parts PPI1 and PPI2. At time T_-2 the status of PPI2 was explicitly changed from active to inactive. At T_-1 the status of the whole product changed to inactive what implicitly also changed the status of PPI1. Now, at time T₀, a users wants to reactivate PP. The question is what should be the status of PPI1 and PPI2 after this transaction? From diagram we expect that PPI1 should be active while PPI2 should remain inactive. But what are the programmable rules for what seems to obvious?
At T₀ all three items are inactive and without further information we are not able to decide that only PPI1 must be activated together with PP. Looking at the status history of PP and PPI2 we can find out that PPI2 was not inactivated together with PP and draw the correct conclusion. Using the status history of all involved entities has some drawbacks: Because rather complex logic is involved the user can not easily understand what is going to happen and housekeeping becomes tricky for the same reason. There is simpler solution: OSB maintains two different status for each entity, the perferred and the effective status. The former is requested by the user and the latter is determined automatically by OSB. For diagram we can set-up the following status table:

Table I: Preferred vs. effective status

Configuration status

The status and transitions for tariff objects, products and their parts are the same. They are shown in diagram

Diagram Configuration status

Only one version of a tariff object, product or product part can be active at any time: When the scheduled date of a new version is reached, the version that was active until that date is considered to be in the status released.

Below here under construction, most of it being old stuff (Apr-01).

Status and status group

The class Status is an abstraction to describe the state of an OSB entity. Status allows to model things like "The contract has been cancelled", "The ISDN line is installed" or "The telephone number is in the grace period".
It is not sufficient to provide the current status of an OSB object. We also need a mechanism that enables us to define all valid states for an OSB class and the allowed transitions between the states. This is the responsibility of the class StatusGroup.

A status group will is defined for at least the following OSB classes: TariffSystem, MarketingPlan, Product, ProductPart, Associate, Contract, PersonalizedProduct, PersonalizedProductPart and Resource.

Status and StatusGroup describe a concept that may actually not be implemented as OSB classes. The state-event-transition problem is well known in software engineering. A status transition is initiated by a business process that is specific to the OSB operator and it is merely impossible provide a generic mecha how to handle state transitions. The decision, how much support the OSB library has to provided in this area, is delayed until we have a better idea about the role of states and transitions in OSB applications. As an example for such an impact look at all possible states for a personalized product (or product part): For billing it must be possible to configure for each state, how much it costs to enter and exit exit the status and how much will be charged while the status is valid. The statusGroup might be responsible to create the initial and final charge on the balance sheet of the related contract.

For selected classes the next sections provide the status that OSB supports. After this we'll define the compatible status for dependent objects and discuss how conflicts are resolved in OSB.

Status summary