Thanks for the quick reply Ludovic,
You are
undoubtedly right about "modify", "delete", and "noChange" actions.
But in the case of "add", wouldn't the service state be mandatory?
Or do you mean that the default target service state in the "add" case should be "active" but can be overridden?
Maybe it's better to explicitly specify the state in the "add" case to make system behavior more transparent and predictable for requester?
------------------------------
Igor Veliev
Netcracker Technology
------------------------------
Original Message:
Sent: Aug 25, 2020 03:15
From: Ludovic Robert
Subject: TMF641. ServiceRefOrValue.state why not mandatory?
Hi Igor,
For my perspective, the presence in the serviceOrderItem of an action to be performed allow to not pass the service state for each orderItem. Indeed the request is to add, modify, delete, nochange a service and it could be up to the server side to have rule to compute the service state. If I want to change some service characteristic value of an active service (without requesting any service state change), or if I request a service termination I probably don't need each time to specify service state.
Hope it helps
Ludovic
------------------------------
Ludovic Robert
Orange
My answer are my own & don't represent necessarily my company or the TMF
Original Message:
Sent: Aug 24, 2020 08:57
From: Igor Veliev
Subject: TMF641. ServiceRefOrValue.state why not mandatory?
Hello, community.
I have a question related to TMF 641.
https://projects.tmforum.org/wiki/display/PUB/TMF641+Service+Ordering+API+User+Guide+v4.0.1
https://projects.tmforum.org/wiki/display/PUB/TMF641B+Service+Ordering+API+Conformance+Profile+v4.0.0
Why ServiceRefOrValue.state is not mandatory while state is mandatory in TMF640?
Isn't it normal scenario when TMF641 is like a bulk for TMF640?
------------------------------
Igor Veliev
Netcracker Technology
------------------------------