Hi
1. The Open API does not dictate implementation and deployment strategy. So the choice is up to you whether to invoke synchronously or to leave a message and expect service inventory to listen to the message.
2. I am not sure if the GB922 API Map should be treated as a normative part of the specification, or rather as a guideline. But certainly one would expect that an implementation of Service Order would (among other things) cause Service Inventory to be invoked (either directly or indirectly as in 1.), see the following paragraph (3.).
3. The Service entity is the same in Service Activation and Service Inventory - the difference between the APIs is that Service Inventory represents persistence of a Service in storage (such as a relational database) while Activation represents the service in the underlying network. The process implemented within a Service Order manager would be expected to activate the service in the network, and, if successful, to cause creation the service in the inventory, if an inventory was needed for this type of service. I guess it would be an implementation decision whether to create a separate inventory storage, people who know more about OSS than I do might be able to give guidance on this.
4. Service Candidate is a catalog-level entity that wraps a Service Specification and represents its use in a Service Catalog (the same spec can feature in multiple catalogs). No direct relationship is relevant to the Service instance, in the model we of course track the Service Specification from which the Service was instantiated, but not from which Catalog this was taken.
Hope it helps
------------------------------
Jonathan Goldberg
Amdocs Management Limited
------------------------------
Original Message:
Sent: Aug 26, 2019 06:08
From: D Basu``
Subject: TMF641 - serviceRelationship vs supportingService
Thanks @Jonathan Goldberg,
We are in the process of implementing R18.5 version for the time being and it would be extremely helpful if you please clarify the following:
- How does an actual
Service
instance is created? Acc. to the Sample UC of TMF638
, "The Service Inventory API can be called by the Service Order Management to create a new service instance/ update an existing service instance in the Service Inventory."
- Using Notification Model, if
ServiceOrdering
API need to generate ServiceCreateNotification
(Service Inventory Space) then both get strongly coupled?
- Otherwise, if ServiceOrdering invokes REST API(s) to create Service Instances, the performance suffers?
- Also, According to the "GB992_Open_API_Map_R17.0.1 > Section 4. API Dependency Relation", As we see below,
Service Inventory API
and Service Ordering API
is dependent on each other. How these should be ideally connected?
Service
as an "API Resource" features in both "Activation and configuration API
" and "Service Inventory API
". Do we view the same Service instance from either perspective? If yes, would it be possible to clarify with a possible sample representation? Or else, how is it?
- Can we please elaborate with sample representation, how a actual
Service
instance in "Service Inventory API
" is actually different from Service Candidate
in Service Catalog API?
------------------------------
D Basu``
Architect
India
Original Message:
Sent: Aug 22, 2019 10:51
From: Jonathan Goldberg
Subject: TMF641 - serviceRelationship vs supportingService
Hi
ServiceRestriction is a strict subset of Service - it wast introduced in recognition of the fact that a Service not yet instantiated has less attributes. We don't have a true business-context model that would tailor attributes to the specific needs of the API, so we introduced this pattern to reduce the size of the Service payload in relevant APIs (such as Service Order, Service Qualification).
ServiceRestriction, like Service, is a value object, and as such is completely different from ServiceRef, which is a reference containing only a very few critical attributes to support the reference.
The same has been done in Release 19 for Product, although we have changed the naming convention so it is now Base (thus BaseProduct), this will be visible when R19 assets are published (currently under member review).
Regarding supportingService relationship, perhaps @Ludovic Robert could address this point.
Hope it helps
------------------------------
Jonathan Goldberg
Amdocs Management Limited
Original Message:
Sent: Aug 22, 2019 05:54
From: D Basu``
Subject: TMF641 - serviceRelationship vs supportingService
Hi,
A couple of questions on TMF641.
1. What is the need of having a separate "supportingService
" relationship in ServiceRestriction
? Can we not think it as a different relationshipType
under "serviceRelationship
"? I have gone through Product Ordering (TMF 622) as well, but it seems not to have modeled a separate "supportingProduct" kind of relationship?
2. ServiceRestriction
and it's sub-resources seems to be very similar to Service
adn it's sub-resources in TMF638. Can't it be replaced by ServiceRef
instead?
3. I too had the same questions about having set of Valid Values for relationshipType
, which is already addressed in a previous post here. Just to add, can this be extended to cover the relationshipType
across ServiceOrderRelationship
, ServiceOrderItemRelationship
as well?
Thanks & Regards
------------------------------
D Basu``
Architect
India
------------------------------