Ordering Blueprint
This document provides a business-oriented runtime blueprint for ordering in Global Telecom Company.
This page connects with:
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 operation | Typical meaning | Inventory impact pattern |
|---|---|---|
ADD | create new commercial/technical element | create new runtime config/instance |
UPDATE | modify existing element | update current or create pending config |
REMOVE | terminate/disconnect element | terminate or end-date runtime config |
MOVE | relocate service | update place/location attributes and related resources |
TAKEOVER | ownership/account transfer | change customer/account context and related governance |
LINK | attach dependency/association | create 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:
- order validation,
- feasibility and availability checks,
- decomposition to service/resource layers,
- design and allocation,
- activation (automatic/manual),
- field work,
- verification and documentation.
8.1 Focused Orders vs Fulfillment Scope
| Focus | Typical TMF contract | Main purpose |
|---|---|---|
| Product Order | TMF622 | commercial request and product-level intent |
| Service Order | TMF641 | service-level operational execution |
| Resource Order | TMF652 | resource-level operational execution |
| Service Activation | adjacent activation/configuration domain | apply technical configuration changes |
9. TMF Mapping Reference (Payloads and Explanation)
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 area | tSM source | Mapping rule |
|---|---|---|
ProductOrder.id / ServiceOrder.id / ResourceOrder.id | Order.key (or integration key) | business-visible order identifier |
externalId | Order.id or upstream external key | cross-system traceability |
state | Order.status | code translation policy per API |
orderDate, requestedCompletionDate | Order.orderDate, Order.deliveryDateRequested | direct date projection |
relatedParty | Order.customerId, Order.accountId, Order.personRoleIds | role-based party projection |
productOrderItem[] / serviceOrderItem[] / resourceOrderItem[] | OrderLine[] | line-level projection by lineType and operation |
item action | OrderLine.operation | enum normalization (ADD -> add, etc.) |
| item references/specification | entityCatalogSpecificationId / entityInstanceConfigurationId | design-to-run linkage projection |
| item characteristics | OrderLine.chars | JSON 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.