- What is the recommended approach in the TMF 640 model to represent an order that carries multiple, potentially interdependent, services as a bundle, ensuring their correlation and atomicity in processing and responses?
Use TMF641 (Service Order Management) for the single POST that carries the whole bundle as a set of ServiceOrderItems with item‑level dependencies (orderItem relationships) and service‑level relationships where needed. This gives you a correlated order ID, overall status, and per‑item status in one request/response cycle.
Use TMF640 (Service Activation & Configuration) inside your activation domain (e.g., ASAP) to activate/configure the underlying services/resources, leveraging its Monitor pattern for async tracking. Don't try to overload TMF640 with a "multi‑service bundle POST"; TMF640 is designed around the Service resource lifecycle, not order bundling.
2. How can the TMF 640 service model map service dependencies and the overall/line-item statuses within a single order submission, especially for scenarios similar to the mobile service activation example above?
-> How TMF640 expresses service dependencies
TMF640 provides a serviceRelationship array on the Service resource. Each service instance (CFS or RFS) may declare:
relationshipType - a free‑form string such as "dependsOn", "bundles", "parent", "child", "reliesOn"
service - a ServiceRefOrValue pointing to the related service instance
(either by ID, or inline via RefOrValue semantics)
This is the canonical mechanism in TMF640 to express functional dependency between services.
Source: TMF640 specification describes the Service resource and its support for creation, update, deletion, and relationships.
-> How TMF640 expresses statuses (line‑item / per‑service)
TMF640 does not maintain "order item" statuses. It maintains service lifecycle state, such as:
state: designed, active, pendingActivation, inactive, terminated, etc.
(depending on version; TMF640 supports retrieving, creating, updating, deleting services)
So once your orchestration receives the multi-item order, you decompose it into service creation/update actions via TMF640. Each service instance will carry:
✔ Per‑service line‑item equivalent
The Service resource's state acts as the line‑item status, replacing TMF641's serviceOrderItem.state inside the activation domain.
If an activation fails, TMF640 allows partial updates and error notifications; you can propagate error state upward.
✔ Asynchronous activation status
TMF640 introduces the Monitor resource:
Returned after POST/PATCH for long-running activation actions.
The monitor can be polled or retrieved to get execution progress or failure info.
Source: TMF640 includes a Monitor resource to track async activation/configuration requests.
Your orchestration layer collects these monitor statuses and maps them back to the TMF641 order item statuses.
3. Are there recommended best practices or common extensions for supporting atomic bundle activation and rollback using TMF 640?
Best practices & common extensions:
Keep relationship semantics consistent
Standardize allowed relationshipType values in your design authority (e.g., reliesOn, bundles, parent, child, supersedes). The specs allow strings; governance ensures everyone interprets them the same. Community practice endorses this flexibility.
Define "atomic bundle" policy at the orchestration level
Document which item failures trigger whole‑bundle compensation vs. partial acceptance. Implement the policy via TMF641 cancel + TMF640 compensation.
Use the Monitor pattern for long‑running steps
TMF640's Monitor resource is the recommended way to track async activation/config. Don't poll individual NEs ad‑hoc; anchor on monitors and emit events.
Align models across TMF622 → TMF641 → TMF640
If your front‑end sells a product bundle (TMF622), mirror bundle semantics as order item relationships in TMF641, and down to service/serviceRelationship in TMF640 and TMF638. TMF622 community examples show productOrderItemRelationship with relationshipType: bundles-apply the same pattern for services.
Follow TMF630 JSON Patch/Path patterns for incremental updates
This helps keep partial-state updates and compensation uniform across APIs.
Document error and jeopardy handling
Agree on how failures at the NE level bubble to serviceOrderItem.state = failed and when to flip the overall order to failed vs. partiallyFailed. (Many vendor CTKs and guides discuss state transitions; consult your chosen TMF641 version notes.)
------------------------------
Chirag Raval
Lead Consultant
Infosys Ltd
------------------------------
Original Message:
Sent: Jan 21, 2026 06:53
From: Anitha Reddy
Subject: TMF640: Modeling Bundled Services Activation
Hello TM Forum community,
We are seeking guidance on best practices for modeling bundled services activation in TMF 640, particularly when a single customer order contains multiple interdependent services that must be provisioned as a unit.
Context and Use Case:
Our product, Oracle ASAP, handles service activation and integrates with a top-level order management system. This system sends us a single order for fulfillment, which may contain several services that are bundled together. For example, in a mobile context, a customer may order a new mobile plan, number porting, and additional value-added services (like voicemail or data boost) as part of one transaction.
Requirements:
- All the services need to be activated together due to interdependencies (e.g., the number must be ported before the mobile plan is provisioned).
- We require a single POST operation for the order (not separate calls per service) to maintain correlation of all service activations and accurately manage rollback in case of failure.
- Sending services separately would cause the top-level order management to issue multiple calls per order, which is not manageable.
- The order object carries an overall status as well as statuses for each line item/service (critical for rollbacks and status management).
- Network Element (NE) management depends on the entire context of the bundled order.
Questions:
- What is the recommended approach in the TMF 640 model to represent an order that carries multiple, potentially interdependent, services as a bundle, ensuring their correlation and atomicity in processing and responses?
- How can the TMF 640 service model map service dependencies and the overall/line-item statuses within a single order submission, especially for scenarios similar to the mobile service activation example above?
- Are there recommended best practices or common extensions for supporting atomic bundle activation and rollback using TMF 640?
Any pointers to model examples, documentation, or community experiences would be greatly appreciated!
Thank you in advance for your guidance.
#OpenDigitalArchitecture
------------------------------
Anitha Reddy
Oracle Corporation
------------------------------