Open APIs

 View Only
  • 1.  TMF655 - ChangeRequestSpecification

    TM Forum Member
    Posted Mar 22, 2021 13:34
    According to the TMF655 Change Management API, there must be exactly one ChangeRequestSpecification for each ChangeRequest. What would be a good example of a ChangeRequestSpecification and why does it have to be exactly one?

    ------------------------------
    Matthias Albrecht
    IBM Corporation
    ------------------------------


  • 2.  RE: TMF655 - ChangeRequestSpecification

    TM Forum Member
    Posted Feb 21, 2022 05:15
    Hi,

    the latest Change Management API User Guide v4.0.0 mandates an entity specification now. I still would like to understand why a specification is mandatory for every Change?

    Matthias

    ------------------------------
    Matthias Albrecht
    IBM Corporation
    ------------------------------



  • 3.  RE: TMF655 - ChangeRequestSpecification

    TM Forum Member
    Posted Feb 21, 2022 09:14
    Hi Matthias
    This API is currently being worked on by @Abdul Majid Hussain - maybe he can relate to this query.
    But as a general rule, ​​when we have characteristics in a managed entity, our TMF Open API design pattern is that there will be a corresponding specification that defines the characteristics. Without the specification, a list of characteristics becomes an arbitrary bucket of name-value pairs, making the contract very weak.
    Hope it helps.

    ------------------------------
    Jonathan Goldberg
    Amdocs Management Limited
    Any opinions and statements made by me on this forum are purely personal, and do not necessarily reflect the position of the TM Forum or my employer.
    ------------------------------



  • 4.  RE: TMF655 - ChangeRequestSpecification

    TM Forum Member
    Posted Feb 22, 2022 02:08
    Hi Jonathan,

    the specification concept perfectly makes sense to us. But why is a specification required for every change? The change information model is absolutely sufficient for our use case, even without specifications. However, according to the model, we need to include a specification reference in POST changeRequest transactions. We are therefore wondering what kind of change request information is provided in the specifications that we have not considered so far?

    Thanks
    Matthias

    ------------------------------
    Matthias Albrecht
    IBM Corporation
    ------------------------------



  • 5.  RE: TMF655 - ChangeRequestSpecification

    TM Forum Member
    Posted Feb 22, 2022 02:08

    Hi Matthias,

    The cardinality of ChangeRequest to its ChangeRequestSpecification is unchanged as part of the upgrade from v2 to v4. It was mandatory earlier and the same has been reflected as part of v4 also. The only change around that is the linkage of ChangeRequest to EntitySpecification so that the ChangesRequestSpecification can be designed using EntitySpecification. Note, there is no schema called ChangeRequestSpecification in TMF today, so it was not possible to evolve to v4 by keeping that object.

    I agree with Jonathan rationale for having it mandatory. Unless a definition of Change Specification exists, there is no semantic meaning of the Change Request type or its characteristics during run-time. This will not help either the consumer or provider of Change Request API.

    Happy to hear the use case where you think this might not be required or will require cardinality to change to Many instead of 1.



    ------------------------------
    Abdul Majid Hussain
    Telstra Corporation
    ------------------------------



  • 6.  RE: TMF655 - ChangeRequestSpecification

    TM Forum Member
    Posted Feb 22, 2022 03:02
    Hi Abdul,

    thanks for the prompt reply!

    Our use case is about consumers requesting a change to a service from the provider. The consumer may not have full insight into the specifics of the change when making the request for change. Similarly, it could be up to the provider to work out the specifics while planning the change. The service consumers might not even have to know about the underlying service or resource specifics at all. We therefore think specifics should not be required when creating a change (POST) so the cardinality would rather be zero or one.

    Matthias

    ------------------------------
    Matthias Albrecht
    IBM Corporation
    ------------------------------



  • 7.  RE: TMF655 - ChangeRequestSpecification

    TM Forum Member
    Posted Feb 22, 2022 03:06
    Hi Matthias

    Can you give more details about this, including examples (if you can do so without leaking IP). Seemingly changes to a service would be requested by a Service Order (TMF641). And here also the contract is backed by a specification (Service Catalog TMF633).



    ------------------------------
    Jonathan Goldberg
    Amdocs Management Limited
    Any opinions and statements made by me on this forum are purely personal, and do not necessarily reflect the position of the TM Forum or my employer.
    ------------------------------



  • 8.  RE: TMF655 - ChangeRequestSpecification

    TM Forum Member
    Posted Feb 22, 2022 08:34
    Hi Jonathan and Abdul,

    thank you for helping me to understand this properly!

    An example could be a consumer requesting a provider to change the timeout setting of a service so that long running requests via the service interface no longer fail. The consumer in this case would send a change request to the provider referencing the target service as the targetEntity. Via this connection, there is already a reference to the service specification from the service inventory.

    However, the timeout value may never have been considered part of the contract and therefore may not have been specified for the service at all. Nevertheless, a change is necessary as it is a configuration change in a production environment.

    As said, I might not right understand the concept of change specifications here which is why an example would help but if that is to link a change to a service or resource specification, there might be many occasions where there is no characteristics identified yet which becomes subject to a change. In this case, the question is what we would expect from the consumer as a change specification? A reference to the same specification as for the target entity? Or is it a reference to a new specification of what the service should be after the change and which the consumer would have to create on the provider side in advance?

    ------------------------------
    Matthias Albrecht
    IBM Corporation
    ------------------------------



  • 9.  RE: TMF655 - ChangeRequestSpecification

    TM Forum Member
    Posted Feb 23, 2022 19:02

    Hi Matthias,

    My understanding of the above scenario is you want to make changes to API timeout (unless I have misunderstood it) and not to service/resource?

    E.G., TMF641 takes 60 sec to return acknowledgement when either a Mobile Service specification or a Fixed Service specification is invoked. The requirement here is to increase TMF641's initial timeout to maybe 120 secs as the business/technical validation behind the Fixed Access takes that much time, before it can return an Acknowledgment. 




    ------------------------------
    Abdul Majid Hussain
    Telstra Corporation
    ------------------------------