The catalog: offers, CFS, RFS and resources
In a catalog-driven OSS, the catalog isn't a price list. It's the configuration that tells the system how to turn what the customer buys into what the network has to do. Three different people told me the same thing in my first weeks on a service-ordering project: we do what the catalog says, and how it's configured decides how the system behaves. For a QA engineer, that sentence means something concrete: configuration is code, and it deserves tests.
The hierarchy
The standard model has four levels, each with its own specifications (characteristics such as speed or bandwidth hang from every level):
| Level | What it is | Example |
|---|---|---|
| Offer | The commercial package | "Fiber + Mobile Pro" bundle |
| Product | What the offer is made of | Fiber, mobile line |
| Service | Each product as a service, separately | 1 Gbps internet access; mobile voice + data with 5G and roaming |
| Resource | The physical or logical elements behind it | Router, SIM, access port, VLAN, IP range |
At the service level, TM Forum's information model (SID) splits services in two:
| CFS: Customer-Facing Service | RFS: Resource-Facing Service | |
|---|---|---|
| What | What the customer contracts, in customer language | How the network realizes it |
| Example | 1 Gbps fiber at an address, with the speeds as characteristics | Router, VLAN, IP network, network planning, port reservation |
| Visible to the customer | Yes | No, but it always depends on what was requested |
CFS and RFS are connected through translated characteristics, so each technical piece knows which request it answers. And the direction is fixed: CFS → RFS → resource, never the other way round. A resource never hangs directly from a CFS, and an RFS never hangs from a resource. Knowing the direction helps you read both the catalog and any order.
What the catalog does with an order
When an order arrives, the catalog does two jobs, and each one is a separate family of tests:
- Validate completeness: is the information enough to provision? This produces the rejection tests (see the rejection checklist).
- Decompose: translate the commercial request into technical services with their characteristics. This produces the decomposition tests: were the right RFS created, with the right values?
Decomposition rules
Each CFS → RFS link carries a decomposition rule: an expression evaluated against the order that decides whether that RFS is instantiated or skipped. That's the mechanism behind every "skipped" item you see in an order's execution diagram. Test ideas that came straight out of reading rules:
- Literal values inside rules. If provider names (or product codes) are written literally in a rule, test with a value that isn't in the list, and remember that a new provider means a rule change.
- Quantifiers. A rule that says "instantiate if any line section matches" will instantiate two RFS if two sections match. Is that intended?
- Branches that need specific data. Some rule branches can only be exercised with very particular inputs (an address with no third-party carriers, for example). Find that data before the story reaches testing.
Translations: mapping characteristics from CFS to RFS
- Direct translation: a mapping table,
target['x'] = source['x']. It always copies, even when the value is empty. - Advanced translation: a script that can condition (
if (source['x'] != null) {...}) or transform values. - A sensible rule: optional characteristics (cardinality 0..1) go through an advanced translation with a null check; mandatory ones (1..1) can go direct.
- An empty translations table doesn't mean there are no translations. They may all live in the script. A colleague concluded translations were missing after looking only at the table. Check both before reporting anything.
- Not every value is translated. Some are written by the provisioning process itself (cost items, for instance). Know where each value comes from before deciding it's wrong.
- A mandatory characteristic can arrive in the payload or be generated by a script. Test both origins.
Dependencies and ordering
The catalog also declares dependencies between items (reliesOn) that order the execution: of three resources, two may wait for the first because it reserves the ID the others need. These dependencies change with catalog releases. One release removed an unnecessary dependency, and suddenly two items could start in parallel instead of one. Don't hardcode assumptions about execution order in your tests.
Allowed values, defaults and versions
- Allowed values (free minutes: only 60 or 120) and defaults (billing cycle 15 if none is sent): test that an invalid value is rejected and that omitting the field produces the default.
- Validation features that nobody uses. Our catalog supported regular expressions and allowed-value lists per characteristic, and none of the characteristics we reviewed used them. Invalid values were caught later, deeper in the flow, with worse error messages. That's both a test idea and an improvement proposal.
- Specification versions follow the commercial life of offers: a new version is launched while the old one stays for existing customers. Test orders against both, and an order referencing a version that doesn't exist.
Validating a catalog deployment between environments
When catalog changes are promoted from one environment to another, compare every CFS and RFS the task touched, in both environments:
- Header: version, lifecycle status (launched) and start date.
- Category.
- Related RFS: relationship, type and status.
- Characteristics: count, type, default value and cardinality (watch out for pagination in long lists).
- Translations: the table and the script.
- Last update: a later "last updated" date in the source environment than in the target reveals changes made after the promotion.
Practical tips:
- Paste the listings as text and diff them line by line.
- Differences unrelated to the task are expected if the promotion starts from the target environment and only adds the task's changes. Don't report them as defects.
- Look, don't touch. The catalog is shared and every modal has a Save button: close with Cancel or the ✕, and don't press "auto-link"-style buttons that create mappings for everyone.
- A shared catalog can change under your feet. Re-verify the configuration when you resume a task after a few days.
- An internal tool to compare catalogs between environments is worth building if you do this often.
Key idea
In a catalog-driven system, a one-line configuration change can alter every order of a product. Treat catalog changes like code changes: reviewed, promoted through environments, and tested with orders that exercise each rule branch.
References
- TM Forum — Open Digital Architecture, home of the SID information model
- TM Forum Open APIs: TMF633 Service Catalog Management, TMF620 Product Catalog Management
- Service orders (TMF641): what happens to an order once the catalog has decomposed it.