Open APIs

 View Only
Expand all | Collapse all

Composite ServiceSepecification and its influence on ServiceOrderItem

  • 1.  Composite ServiceSepecification and its influence on ServiceOrderItem

    Posted Aug 12, 2021 10:55
    I have below service Model where Service1 is related to Service2 and Service2 is in turn composed of service3 and service4.

    It would be very helpful if I can get guidance/suggestion on the below queries.


    1) Whats the best way of representing this composition in 633 specification?
    a) Can service3 and service4 attributes be directly put as one of the specCharacteristics[hope I am correct on my understanding of usage of this field] with value type as Object.
    In this case, i am not sure how will I define the CharacteristicValueSpecification for that obejcts. Can I use use valueType as object again and use @schemaLocation to fetch details about the service3,4 objects?
    b) or Service3 and Service4 goes as atomic ServiceSpec itself and user serviceSpecRelationship to stitch them all together?
    c) while using serviceSpecRelationship, is there any standard way of defining composition relationship. [I can think of defining an appropriate relationship type, not sure if there is a better way]
    2) I can see from 641 resource model:


    a) A serviceOrderItem can have serviceOrderItem [nested object]: how catalogue specification influence the decision that a particular serviceOrderItem should have a nested serviceOrderItem?
    b) what is the difference between ServiceOrderItemRelashionsip and RelatedServiceOrderItem.


    ------------------------------
    Aneesh Damodaran
    BT Group plc
    ------------------------------


  • 2.  RE: Composite ServiceSepecification and its influence on ServiceOrderItem

    Posted Aug 16, 2021 04:49
    Hi Aneesh
    Your diagram was not presented well in the post - I tried opening it in a different tab but this didn't help. As a general point, always best to give concrete business examples (if you can do so without leaking IP), rather than service 1 service 2 etc.

    Anyway I'll try to address your queries
    • What you call attributes, I'm guessing you mean things like Bandwidth, Technology, IP address, etc. These indeed are represented in Service Catalog as service characteristic specifications. If you have a complex characteristic, then yes you would use the @valueSchemaLocation in CharacteristicSpec to describe the schema for this complex characteristic. At some point, however, you need to consider when you would use a complex characteristic as against a contained service. I'm not an OSS expert so I have no feeling for that guideline. I think your points 1 a) and 1 b) hint to this dilemma.
    • For 1 c) we don't currently have a closed list of value for relationship types, perhaps this will come in the future. So for the meantime you could use composition to represent the containment relationship.
    • For 2 a) I don't think we have a concrete guideline, but in general I would expect each ServiceSpecification to be instantiated in a ServiceOrderItem, and the nesting would be used for composite services (as in your 1 c) )
    • For 2 b) - RelatedServiceOrderItem is a relation from Service - it could indicate the order item that created this service, or perhaps a pending order item open on this service. ServiceOrderItemRelationship describes relationships between service order items themselves, e.g. a service order for a HD TV might depend on the corresponding service order for FTTH.
    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.
    ------------------------------