Open APIs

Hi,

Seeking some clarity around startDate in TMF640 API. The description in R18.5.1 is "A date time (DateTime). Date when the service starts."
Prior to the service being started/activated, can the service be in any non-active state (e.g. feasiblityChecked, reserved, inactive, terminated etc) or does the startDate field pertain only to the inactive->active state transition?

Thanks,
Anu

I am facing the same issue.

It is not clear how startDate (and endDate) relate to the state in TMF638/640. This is, as far as I could find, neither explained in the standards themselves, nor in the general design guidelines TMF630.

I see two contradicting interpretations for TMF640:

1. When creating a service, the state passed in the API request is the desired end-state to be reached on the startDate, and up until the arrival of the startDate, the state should be something else - perhaps feasabilityChecked, designed or reserved? 
2. When creating the service, the state passed in the API  request is the state that the service should be in until the startDate arrives. Once that date arrives, the service should be activated and when activation is complete, the state should become active.

Similarly, for the endDate, it is unclear, when the endDate arrives, if the service should no longer be active, but should TMF640 automatically delete the service to state terminated or should it be retired and deleted completely? Furthermore, it is not clear if the DELETE REST call should execute the state transition named delete, so the state ends up in terminated, or if the DELETE REST call should actually retire the service, completely erasing it from inventory.

Concerning TMF638, this is related to this question: https://engage.tmforum.org/communities/community-home/digestviewer/viewthread?MessageKey=de69285a-144d-4f0e-bef7-741c2b4a3c75&CommunityKey=d543b8ba-9d3a-4121-85ce-5b68e6c31ce5&tab=digestviewer - where I interpret the answer as saying that TMF638 should return the actual state of the service at any point in time, and not the desired state when the startDate arrives. Any interpretation indicating that TMF638 should return the final state would imply that if an endDate is specified, then the state returned by TMF638 should be terminated, since the inventory record indicates that at the indicated point in the future, that will be the value of the state.

Since none of this behavior is specified in the standards, I have to assume that this is completely up to the implementations to decide, but of course that will not be good for interoperability.

Any comments?

------------------------------
Peter Bruun
Hewlett Packard Enterprise
------------------------------