Skip to main content
Version: 2.4

Ordering Blueprint

This document provides a business-oriented runtime blueprint for ordering in Global Telecom Company.

This page connects with:

Simplification Scope

This is a simplified, documentation-focused example. It does not model full commercial policy, all billing edge-cases, or full network orchestration internals.

1. Business Context

Global Telecom Company needs controlled execution of customer demand from capture to service provisioning.

Main runtime drivers:

  • one business order identity across the lifecycle,
  • explicit line-level decomposition and operations,
  • deterministic process startup and progress tracking,
  • traceability from catalog intent to inventory runtime impact,
  • controlled cancellation and change handling.

2. Runtime Scope in tSM

This blueprint covers:

  • order capture (OrderPublic),
  • order decomposition (OrderLinePublic),
  • CFS/RFS-oriented service decomposition on line level,
  • process governance (OrderType, OrderStatus),
  • service provisioning impact through inventory-linked lines.

Detailed runtime process mechanics are documented in Order Process Handling.

3. End-to-End Flow

4. tSM Example: Order Capture and Decomposition

4.1 Draft Order with Lines (tSM Entities)

{
"id": "5f0b4579-2c7e-4f8f-9d87-b8a6a0c0c98f",
"key": "ORD-2025-000201",
"subject": "Business Internet 100M + Public IP",
"orderType": "SERVICE.ACTIVATION",
"status": "DRAFT",
"description": "Activation for new SME customer site.",
"orderDate": "2025-02-24T09:30:00.000+00:00",
"deliveryDateRequested": "2025-03-05T00:00:00.000+00:00",
"customerId": "b75aa001-36f8-4f8d-a4f3-813e8d4f77b0",
"accountId": "9c8aa879-b2de-45d2-9c11-13ca6f30d7f9",
"dataTags": ["B2B", "INTERNET"],
"chars": {
"salesChannel": "SELFCARE",
"salesMode": "ACTIVE"
},
"orderLines": [
{
"id": "0f3f3dfd-95a8-4292-90e2-dc4e4f4c9b0f",
"name": "Internet Product",
"lineType": "PRODUCT",
"operation": "ADD",
"entityCatalogSpecificationId": "43cc8433-0477-4d2b-b5dc-15c33c0f3576",
"quantity": 1,
"chars": {
"bundleCode": "BIZ-INTERNET-100"
}
},
{
"id": "57ff6ea4-8ef6-43a4-bf11-ab8a9785057f",
"name": "Internet Service",
"lineType": "SERVICE",
"operation": "ADD",
"parentOrderLineId": "0f3f3dfd-95a8-4292-90e2-dc4e4f4c9b0f",
"entityCatalogSpecificationId": "8bde2bfa-2de1-4775-9954-c48ef49ae89b",
"quantity": 1,
"chars": {
"internetService": {
"internetBandwidth": "100",
"internetServiceSla": "99",
"internetServiceMaxSpeed": "1"
}
}
},
{
"id": "f31e3cc8-7792-46cb-b109-c3a0e26b0f26",
"name": "Public IP Service",
"lineType": "SERVICE",
"operation": "ADD",
"parentOrderLineId": "57ff6ea4-8ef6-43a4-bf11-ab8a9785057f",
"entityCatalogSpecificationId": "cb8cedfe-94e2-4791-9b6b-13d5c345f65d",
"quantity": 1
}
]
}

4.2 Decomposition View

In telco decomposition practice, SERVICE lines can represent CFS and RFS levels according to the catalog model and fulfillment process design.

5. Runtime Transition and Provisioning Impact

5.1 Status Transition

5.2 In-Progress Snapshot

When status changes to IN_PROGRESS, process startup is triggered. As lines are fulfilled, service lines typically gain linkage to runtime inventory configurations.

{
"id": "5f0b4579-2c7e-4f8f-9d87-b8a6a0c0c98f",
"key": "ORD-2025-000201",
"status": "IN_PROGRESS",
"orderLines": [
{
"id": "57ff6ea4-8ef6-43a4-bf11-ab8a9785057f",
"lineType": "SERVICE",
"operation": "ADD",
"entityInstanceConfigurationId": "1b1f8687-4ed5-4b7a-818e-914ad299f735"
},
{
"id": "f31e3cc8-7792-46cb-b109-c3a0e26b0f26",
"lineType": "SERVICE",
"operation": "ADD",
"entityInstanceConfigurationId": "5667fcf4-4ec3-47ac-bd7b-6f050d74af8d"
}
]
}

6. Operation-to-Impact Matrix

Order line operationTypical meaningInventory impact pattern
ADDcreate new commercial/technical elementcreate new runtime config/instance
UPDATEmodify existing elementupdate current or create pending config
REMOVEterminate/disconnect elementterminate or end-date runtime config
MOVErelocate serviceupdate place/location attributes and related resources
TAKEOVERownership/account transferchange customer/account context and related governance
LINKattach dependency/associationcreate runtime relationship or linkage record

7. Runtime Integration Context

Ordering orchestrates cross-module and external interactions:

  • Catalog for design-time rules,
  • Inventory for runtime instance/configuration state,
  • Process engine for orchestration,
  • external fulfillment interfaces for implementation tasks,
  • CRM/Billing for customer and charging effects.

8. General TMF Concepts (Core Level)

In ordering integrations, TMF is used conceptually in focused layers:

  • TMF622 for product-order business interface,
  • TMF641 for service-order orchestration interface,
  • TMF652 for resource-order interface.

Service Activation is adjacent to ordering APIs: activation/configuration steps are typically executed after service/resource order decomposition and handled by activation/configuration capabilities (commonly referenced around TMF640 scope).

General Service Provisioning / Fulfillment process spans beyond one API and usually includes:

  1. order validation,
  2. feasibility and availability checks,
  3. decomposition to service/resource layers,
  4. design and allocation,
  5. activation (automatic/manual),
  6. field work,
  7. verification and documentation.

8.1 Focused Orders vs Fulfillment Scope

FocusTypical TMF contractMain purpose
Product OrderTMF622commercial request and product-level intent
Service OrderTMF641service-level operational execution
Resource OrderTMF652resource-level operational execution
Service Activationadjacent activation/configuration domainapply technical configuration changes

9. TMF Mapping Reference (Payloads and Explanation)

TMF Mapping Approach

Core tSM ordering concepts map to TMF, and TMF itself is designed with extensibility as a core principle.

For implementation projects, mapping must be validated against business rules, process model, and integration contracts. TMF payloads are stable contracts, while tSM internal entities remain the execution system-of-record.

9.1 TMF622 Product Ordering Mapping

TMF622 operation scope in this blueprint:

  • GET /productOrder, GET /productOrder/{id},
  • POST /productOrder, PATCH /productOrder/{id}, DELETE /productOrder/{id},
  • GET /cancelProductOrder, GET /cancelProductOrder/{id}, POST /cancelProductOrder.

TMF622 payload example for the same order:

{
"@type": "ProductOrder",
"id": "ORD-2025-000201",
"externalId": "5f0b4579-2c7e-4f8f-9d87-b8a6a0c0c98f",
"description": "Activation for new SME customer site.",
"category": "B2B",
"state": "inProgress",
"orderDate": "2025-02-24T09:30:00.000Z",
"requestedCompletionDate": "2025-03-05T00:00:00.000Z",
"relatedParty": [
{
"id": "b75aa001-36f8-4f8d-a4f3-813e8d4f77b0",
"role": "customer",
"@referredType": "Customer"
},
{
"id": "9c8aa879-b2de-45d2-9c11-13ca6f30d7f9",
"role": "billingAccount",
"@referredType": "BillingAccount"
}
],
"productOrderItem": [
{
"id": "0f3f3dfd-95a8-4292-90e2-dc4e4f4c9b0f",
"action": "add",
"state": "inProgress",
"productOffering": {
"id": "43cc8433-0477-4d2b-b5dc-15c33c0f3576",
"name": "Business Internet Product"
},
"quantity": 1
}
]
}

9.2 TMF641 Service Ordering Mapping

TMF641 operation scope in this blueprint:

  • GET /serviceOrder, GET /serviceOrder/{id},
  • POST /serviceOrder, PATCH /serviceOrder/{id}, DELETE /serviceOrder/{id},
  • GET /cancelServiceOrder, GET /cancelServiceOrder/{id}, POST /cancelServiceOrder.

TMF641 payload example derived from service lines:

{
"@type": "ServiceOrder",
"id": "ORD-2025-000201-SVC",
"externalId": "5f0b4579-2c7e-4f8f-9d87-b8a6a0c0c98f",
"description": "Service fulfillment for Business Internet 100M + Public IP.",
"state": "inProgress",
"orderDate": "2025-02-24T09:30:00.000Z",
"requestedCompletionDate": "2025-03-05T00:00:00.000Z",
"relatedParty": [
{
"id": "b75aa001-36f8-4f8d-a4f3-813e8d4f77b0",
"role": "customer",
"@referredType": "Customer"
}
],
"serviceOrderItem": [
{
"id": "57ff6ea4-8ef6-43a4-bf11-ab8a9785057f",
"action": "add",
"state": "inProgress",
"service": {
"@type": "Service",
"serviceType": "Internet.Service",
"serviceSpecification": {
"id": "Internet.Service",
"name": "Internet Service",
"version": "1.0"
},
"serviceCharacteristic": [
{
"name": "internetService",
"valueType": "object",
"value": {
"internetBandwidth": "100",
"internetServiceSla": "99",
"internetServiceMaxSpeed": "1"
}
}
]
}
}
]
}

9.3 TMF652 Resource Ordering Mapping

TMF652 operation scope in this blueprint:

  • GET /resourceOrder, GET /resourceOrder/{id},
  • POST /resourceOrder, PATCH /resourceOrder/{id}, DELETE /resourceOrder/{id},
  • GET /cancelResourceOrder, GET /cancelResourceOrder/{id}, POST /cancelResourceOrder.

TMF652 payload example derived from resource-facing execution:

{
"@type": "ResourceOrder",
"id": "ORD-2025-000201-RSC",
"externalId": "5f0b4579-2c7e-4f8f-9d87-b8a6a0c0c98f",
"description": "Resource allocation and activation order for Internet service realization.",
"state": "inProgress",
"orderDate": "2025-02-24T09:30:00.000Z",
"requestedCompletionDate": "2025-03-05T00:00:00.000Z",
"resourceOrderItem": [
{
"id": "r-001",
"action": "add",
"state": "inProgress",
"resource": {
"id": "ce-port-001",
"name": "Access Port Prague4",
"@referredType": "LogicalResource"
}
}
]
}

9.4 Mapping Matrix

TMF areatSM sourceMapping rule
ProductOrder.id / ServiceOrder.id / ResourceOrder.idOrder.key (or integration key)business-visible order identifier
externalIdOrder.id or upstream external keycross-system traceability
stateOrder.statuscode translation policy per API
orderDate, requestedCompletionDateOrder.orderDate, Order.deliveryDateRequesteddirect date projection
relatedPartyOrder.customerId, Order.accountId, Order.personRoleIdsrole-based party projection
productOrderItem[] / serviceOrderItem[] / resourceOrderItem[]OrderLine[]line-level projection by lineType and operation
item actionOrderLine.operationenum normalization (ADD -> add, etc.)
item references/specificationentityCatalogSpecificationId / entityInstanceConfigurationIddesign-to-run linkage projection
item characteristicsOrderLine.charsJSON characteristic projection

9.5 Notifications and Cancel Tasks

TMF622, TMF641, and TMF652 define notification families and cancel-task resources. In tSM implementation patterns, these concepts usually map to:

  • order/process status transitions,
  • process events (milestones, exceptions),
  • explicit cancellation intent routed into process logic and status updates.