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
------------------------------
Original Message:
Sent: Feb 22, 2022 03:05
From: Jonathan Goldberg
Subject: TMF655 - ChangeRequestSpecification
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.
Original Message:
Sent: Feb 22, 2022 03:02
From: Matthias Albrecht
Subject: TMF655 - ChangeRequestSpecification
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
Original Message:
Sent: Feb 22, 2022 02:07
From: Abdul Majid Hussain
Subject: TMF655 - ChangeRequestSpecification
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
Original Message:
Sent: Feb 21, 2022 09:13
From: Jonathan Goldberg
Subject: TMF655 - ChangeRequestSpecification
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.
Original Message:
Sent: Feb 21, 2022 05:15
From: Matthias Albrecht
Subject: TMF655 - ChangeRequestSpecification
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
Original Message:
Sent: Mar 22, 2021 10:51
From: Matthias Albrecht
Subject: TMF655 - ChangeRequestSpecification
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
------------------------------