Open APIs

• If we take a simple example, on the initial order, the Service will go from "Feasibility Checked" to "Designed" to "Reserved" to "Active"
• Each of those state changed will trigger a ServiceStateChangeNotification event

• Is the Service Instance of TMF638 supposed to show the pending activities when the Service is already active?
  • Is the state going back from "Active" to "Designed" then "Reserved"... to end "Active" again?
  • Or we don't show the pending States and the Service stays "Active" all a along?
• If we need to show the Pending states,
  • If an external system triggers a GET Service/{Id}, is the expectation to return the "Active" State, or the "Pending" one?
    • I have seen the concept of ServiceConfiguration or version in the model. Is the assumption that there is always one 1 instance of the Service (the latest one which overwrites the previous one everytime)?
  • How do we handle a cancellation of the Order? State will go back from "Designed" (for example) to "Active"? Our datastore will need to bring back the characteristics of the Service before the modification?

• If we take a simple example, on the initial order, the Service will go from "Feasibility Checked" to "Designed" to "Reserved" to "Active"
• Each of those state changed will trigger a ServiceStateChangeNotification event

• Is the Service Instance of TMF638 supposed to show the pending activities when the Service is already active?
  • Is the state going back from "Active" to "Designed" then "Reserved"... to end "Active" again?
  • Or we don't show the pending States and the Service stays "Active" all a along?
• If we need to show the Pending states,
  • If an external system triggers a GET Service/{Id}, is the expectation to return the "Active" State, or the "Pending" one?
    • I have seen the concept of ServiceConfiguration or version in the model. Is the assumption that there is always one 1 instance of the Service (the latest one which overwrites the previous one everytime)?
  • How do we handle a cancellation of the Order? State will go back from "Designed" (for example) to "Active"? Our datastore will need to bring back the characteristics of the Service before the modification?

• If we take a simple example, on the initial order, the Service will go from "Feasibility Checked" to "Designed" to "Reserved" to "Active"
• Each of those state changed will trigger a ServiceStateChangeNotification event

• Is the Service Instance of TMF638 supposed to show the pending activities when the Service is already active?
  • Is the state going back from "Active" to "Designed" then "Reserved"... to end "Active" again?
  • Or we don't show the pending States and the Service stays "Active" all a along?
• If we need to show the Pending states,
  • If an external system triggers a GET Service/{Id}, is the expectation to return the "Active" State, or the "Pending" one?
    • I have seen the concept of ServiceConfiguration or version in the model. Is the assumption that there is always one 1 instance of the Service (the latest one which overwrites the previous one everytime)?
  • How do we handle a cancellation of the Order? State will go back from "Designed" (for example) to "Active"? Our datastore will need to bring back the characteristics of the Service before the modification?

Salut Stéphane!

The best is to separate the service lifecycle management from its design or configuration lifecycle management. TMF638 only deals with actions on a service, but your Inventory should support both the lifecycle of the service and of its design/configuration separately. The service lifecycle reflects the operational state of the service, while its configuration lifecycle reflects its detailed definition.

During a service modification, requested via TMF638 on an "Active" service, the service can remain in its current state (for the most part – see further), while you can go through a complete lifecycle for a new configuration version (containing all values of the current version, which you then modify as needed, such as bandwidth, through its configuration Design & Assign logic).

As you go through the new configuration version lifecycle, it reaches some "Designed" state (meaning, your Design&Assign has completed its job). This may generate an event or you may invoke a process (such as "calculate technical actions") which will ultimately lead to a Service Activation action. It is during the service activation duration that your service may flicker from its Active state.

As your systems go through Service Activation (which may take seconds to a minute or so), you could decide (I would 😉 ) to use an interm service state (possibly not defined in TMF638) such as "Active_pending" (or "Pending"), as you are really, during this time, in a service disruption situation (which may or may not be service affecting). During this service activation time, if there were a query, you'd get "Active_pending" or "Pending", but anytime before the service activation is triggered, you'd still get an "Active" state.

Once the Service Activation successfully completes, then you can move your "Designed" configuration state to "Issued" and/or "Completed", make that new configuration version the active one (replacing the previous version), and then push your service state from "Active_pending" or "Pending" back to "Active".

When you get a cancellation of the order, you simply change the design/configuration state of the new configuration version (which is presumably still undergoing Design&Assign) to "Canceled", effectively never affecting the service state itself which remained "Active". (There is a Point of No Return situation, for order cancellations, once automated Service Activation has been initiated, but that's a longer discussion.)

Hope this helps!

Cheers,

Stéphan

• If we take a simple example, on the initial order, the Service will go from "Feasibility Checked" to "Designed" to "Reserved" to "Active"
• Each of those state changed will trigger a ServiceStateChangeNotification event

• Is the Service Instance of TMF638 supposed to show the pending activities when the Service is already active?
  • Is the state going back from "Active" to "Designed" then "Reserved"... to end "Active" again?
  • Or we don't show the pending States and the Service stays "Active" all a along?
• If we need to show the Pending states,
  • If an external system triggers a GET Service/{Id}, is the expectation to return the "Active" State, or the "Pending" one?
    • I have seen the concept of ServiceConfiguration or version in the model. Is the assumption that there is always one 1 instance of the Service (the latest one which overwrites the previous one everytime)?
  • How do we handle a cancellation of the Order? State will go back from "Designed" (for example) to "Active"? Our datastore will need to bring back the characteristics of the Service before the modification?

• Having a history of all the configurations of the service 
• Ability to return Pending vs In-Service view to external systems
• Ability to compare 2 configurations to analyse delta
• Ability revert back to previous configuration in case of cancel Order

Salut Stéphane!

The best is to separate the service lifecycle management from its design or configuration lifecycle management. TMF638 only deals with actions on a service, but your Inventory should support both the lifecycle of the service and of its design/configuration separately. The service lifecycle reflects the operational state of the service, while its configuration lifecycle reflects its detailed definition.

During a service modification, requested via TMF638 on an "Active" service, the service can remain in its current state (for the most part – see further), while you can go through a complete lifecycle for a new configuration version (containing all values of the current version, which you then modify as needed, such as bandwidth, through its configuration Design & Assign logic).

As you go through the new configuration version lifecycle, it reaches some "Designed" state (meaning, your Design&Assign has completed its job). This may generate an event or you may invoke a process (such as "calculate technical actions") which will ultimately lead to a Service Activation action. It is during the service activation duration that your service may flicker from its Active state.

As your systems go through Service Activation (which may take seconds to a minute or so), you could decide (I would 😉 ) to use an interm service state (possibly not defined in TMF638) such as "Active_pending" (or "Pending"), as you are really, during this time, in a service disruption situation (which may or may not be service affecting). During this service activation time, if there were a query, you'd get "Active_pending" or "Pending", but anytime before the service activation is triggered, you'd still get an "Active" state.

Once the Service Activation successfully completes, then you can move your "Designed" configuration state to "Issued" and/or "Completed", make that new configuration version the active one (replacing the previous version), and then push your service state from "Active_pending" or "Pending" back to "Active".

When you get a cancellation of the order, you simply change the design/configuration state of the new configuration version (which is presumably still undergoing Design&Assign) to "Canceled", effectively never affecting the service state itself which remained "Active". (There is a Point of No Return situation, for order cancellations, once automated Service Activation has been initiated, but that's a longer discussion.)

Hope this helps!

Cheers,

Stéphan

• If we take a simple example, on the initial order, the Service will go from "Feasibility Checked" to "Designed" to "Reserved" to "Active"
• Each of those state changed will trigger a ServiceStateChangeNotification event

• Is the Service Instance of TMF638 supposed to show the pending activities when the Service is already active?
  • Is the state going back from "Active" to "Designed" then "Reserved"... to end "Active" again?
  • Or we don't show the pending States and the Service stays "Active" all a along?
• If we need to show the Pending states,
  • If an external system triggers a GET Service/{Id}, is the expectation to return the "Active" State, or the "Pending" one?
    • I have seen the concept of ServiceConfiguration or version in the model. Is the assumption that there is always one 1 instance of the Service (the latest one which overwrites the previous one everytime)?
  • How do we handle a cancellation of the Order? State will go back from "Designed" (for example) to "Active"? Our datastore will need to bring back the characteristics of the Service before the modification?

• Having a history of all the configurations of the service 
• Ability to return Pending vs In-Service view to external systems
• Ability to compare 2 configurations to analyse delta
• Ability revert back to previous configuration in case of cancel Order

Salut Stéphane!

The best is to separate the service lifecycle management from its design or configuration lifecycle management. TMF638 only deals with actions on a service, but your Inventory should support both the lifecycle of the service and of its design/configuration separately. The service lifecycle reflects the operational state of the service, while its configuration lifecycle reflects its detailed definition.

During a service modification, requested via TMF638 on an "Active" service, the service can remain in its current state (for the most part – see further), while you can go through a complete lifecycle for a new configuration version (containing all values of the current version, which you then modify as needed, such as bandwidth, through its configuration Design & Assign logic).

As you go through the new configuration version lifecycle, it reaches some "Designed" state (meaning, your Design&Assign has completed its job). This may generate an event or you may invoke a process (such as "calculate technical actions") which will ultimately lead to a Service Activation action. It is during the service activation duration that your service may flicker from its Active state.

As your systems go through Service Activation (which may take seconds to a minute or so), you could decide (I would 😉 ) to use an interm service state (possibly not defined in TMF638) such as "Active_pending" (or "Pending"), as you are really, during this time, in a service disruption situation (which may or may not be service affecting). During this service activation time, if there were a query, you'd get "Active_pending" or "Pending", but anytime before the service activation is triggered, you'd still get an "Active" state.

Once the Service Activation successfully completes, then you can move your "Designed" configuration state to "Issued" and/or "Completed", make that new configuration version the active one (replacing the previous version), and then push your service state from "Active_pending" or "Pending" back to "Active".

When you get a cancellation of the order, you simply change the design/configuration state of the new configuration version (which is presumably still undergoing Design&Assign) to "Canceled", effectively never affecting the service state itself which remained "Active". (There is a Point of No Return situation, for order cancellations, once automated Service Activation has been initiated, but that's a longer discussion.)

Hope this helps!

Cheers,

Stéphan

• If we take a simple example, on the initial order, the Service will go from "Feasibility Checked" to "Designed" to "Reserved" to "Active"
• Each of those state changed will trigger a ServiceStateChangeNotification event

• Is the Service Instance of TMF638 supposed to show the pending activities when the Service is already active?
  • Is the state going back from "Active" to "Designed" then "Reserved"... to end "Active" again?
  • Or we don't show the pending States and the Service stays "Active" all a along?
• If we need to show the Pending states,
  • If an external system triggers a GET Service/{Id}, is the expectation to return the "Active" State, or the "Pending" one?
    • I have seen the concept of ServiceConfiguration or version in the model. Is the assumption that there is always one 1 instance of the Service (the latest one which overwrites the previous one everytime)?
  • How do we handle a cancellation of the Order? State will go back from "Designed" (for example) to "Active"? Our datastore will need to bring back the characteristics of the Service before the modification?