Open APIs

 View Only
  • 1.  Network to Inventory Reconcilliation

    TM Forum Member
    Posted Mar 01, 2023 10:18

    I've looked through the OpenAPI's, both current and beta to see if there is an interface that supports a pattern for reconcile. Unfortunately I've been only been able to identify TMF639 which is more inventory management than discrepancy checking.

    e.g.

    Purpose: To invoke the comparison of two datasets, network and OSS Inventory...  TMF MTOSI provided a schema called MDDC (possible: ???Manage Discovery Discrepancy Comparision??? perhaps)  

    Input: Resource or Services ID.

    Output: Context of any discrepancy, between Network and OSS inventory.     MDDC used to provide the discrepancies between data sets in the response structures. 

    Any pointers?



    ------------------------------
    marty oliver
    BT Group plc
    ------------------------------


  • 2.  RE: Network to Inventory Reconcilliation

    TM Forum Member
    Posted Mar 01, 2023 14:52

    Hi Marty

    Reconciliation is a complex topic, and it would cover a wide variety of persistent stores. I'm not sure that an API representation would be the most effective, since you would generally want to verify in bulk.

    Possibly the Data Governance collaborative project (@Sarah Ness , @Aaron Boasman-Patel  ) would be the best place to discuss reconciliation issues.



    ------------------------------
    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.
    ------------------------------



  • 3.  RE: Network to Inventory Reconcilliation

    TM Forum Member
    Posted Mar 02, 2023 04:32

    Thank you for the prompt Reply Jonathan, much appreciated.  

    Yes Bulk reconciliation is tricky and often that would be managed in bulk on our data lakes. 

    In this instance the service is more a diagnostic Discovery/Compare/reconcile (manual at first)  for a single customer service .  e.g. we have a broadband service, and we want to compare our network config , with the OSS assigned config to ascertain whether there is parity between the two (as part of preprovision, or before a test).  Responding to our provision/test systems accordingly with an OK, or the discrepancy.  

    The discrepancy response would look to contain either the discrepancy in the two sets of data (as MDDC use to do) or an issue code (e.g. config mismatch identified).  Thinking of adding context to aid the resolution also (how to fix, either in the OSS or on the Network)... 

    I don't know if this helps suggested alignment to a API, or we're flying solo?  :-)

    Thanks again

    Marty

     



    ------------------------------
    marty oliver
    BT Group plc
    ------------------------------



  • 4.  RE: Network to Inventory Reconcilliation

    TM Forum Member
    Posted Mar 02, 2023 07:33

    Hi Marty,

    As I understand it, you intend to call this logic from the service management layer; I'm not quite clear what the service management layer could reasonably do with the response. If there's a discrepancy that cannot be automatically reconciled then the resolution still belongs to the resource management layer (probably a network engineer will have to log in and manually reconcile things). So, basically within the confines of the network design/inventory management system.

    Hope this helps.



    ------------------------------
    Alexey Rusakov
    Red Hat, Inc.
    ------------------------------



  • 5.  RE: Network to Inventory Reconcilliation

    TM Forum Member
    Posted Mar 02, 2023 10:09

    Thank Alexey, just to give the context.   As an Access Network Provider of Broadband services,

    We have OSS allocating Service Config e.g.  S and C VLAN's on CP handover, and recording ONT Serial Numbers, ONUID's on GPON side.

    They are then pushed to the network for service activation... due to planning changes, migrations, manual intervention, even some corruption etc.  When we provide a service, or when there is a fault, we want to ensure both OSS and Network are aligned before we investigate further (line test or engineer visit etc).   

    In the system responsible for checking, we are building rules to automatically resolve the discrepancies.  However, prior to full automation, we will be running this process manually... The test system will invoke the reconcile system, and in response we want to give the discrepancy, along with the suggested fix.  Probably be manually resolved in the first instnace.

    In the future, we'd hope to have a batch process to routinely cover the entire network, but there will always be the gaps where we do spot check and fixes... 

    Ultimately, we want the reconciliation System will fix the issues automatically regardless of whether the check is invoke via batch or from another system (manual teams). But if invoked from another system, the response would Include the below (probably the bases for a REST call):

    • The discrepancy or context of discrepancy (or list of discrepancies)
    • How the Discrepancy was resolve (changes on network or OSS etc) 
    • Was the discrepancy resolved automatically

    the old TMF MTOSI, used to compare the data sets and send only the discrepancy data, but the logic to fix the issue resides with the consumer of the service.  So trying to avoid that if possible.



    ------------------------------
    marty oliver
    BT Group plc
    ------------------------------



  • 6.  RE: Network to Inventory Reconcilliation

    TM Forum Member
    Posted Mar 02, 2023 13:07
    Edited by Alexey Rusakov Mar 02, 2023 15:35

    I don't think there's a specific API for that kind of request (but I'm not that well-versed in TMF OpenAPIs - could probably miss something), and I wouldn't expect any existing solution to have anything catering to that within TMF639. I would probably use GET /resources, conveying the requirement to check the resource configuration with the network using extra parameters in the query; resourceStatus == unknown or actually anything except available would then signal that the requesting side's information on the resource is not accurate... Or, if checking with the network is an asynchronous operation (which is likely be the case), I would go for TMF652 and make the discovery & reconciliation request a proper resource order that would effectively reserve the resource before activating it.



    ------------------------------
    Alexey Rusakov
    Red Hat, Inc.
    ------------------------------



  • 7.  RE: Network to Inventory Reconcilliation

    TM Forum Member
    Posted Mar 03, 2023 06:15

    Thanks for the advice Alexey much appreciated... 



    ------------------------------
    marty oliver
    BT Group plc
    ------------------------------



  • 8.  RE: Network to Inventory Reconcilliation

    TM Forum Member
    Posted Mar 04, 2023 13:13

    Thanks to everyone who weighed in on this discussion.

    I would add that at the Open API level we do have an open issue in the model of how actually to correlate between network assets (TMF640, TMF702) on the one hand and the corresponding inventory entries (TMF638, TMF639) on the other. The IDs in the two models will not be the same; we should probably consider adding an External Identifier structure to the inventory model, so that the network identifier(s) can be passed into the inventory entity.

    I plan to open a JIRA change request for this, which probably will be executed only in v5 of the relevant APIs.



    ------------------------------
    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.
    ------------------------------



  • 9.  RE: Network to Inventory Reconcilliation

    TM Forum Member
    Posted Apr 10, 2023 01:23

    Hey Marty,  there is no pattern, but internally at Telstra we've built a wrapper for a similar purpose, which includes an expected service, the actual service and a difference (outstanding) service. Ultimately any service related operation: creation, modification, optimisation, restoration, etc, comes down to resolving the differences between an optimum/desired (expected) service and the as-is (actual) service. As your internal domain manager resolves differences (and perhaps creates or discovers new ones...) the outstanding service is recalculated until you ideally get it to {}. The secret is to get all this model driven so that you aren't needing to build orchestration flows to resolve differences, rather the guidance on what to resolve next comes also from the model (which contains all the business rules). Best analogy I can think of is separating the mapping/guidance system from the vehicle operating system, e.g. like a rally car navigator and a driver. All of these services are TMF640, you can substitute product/resource for service too. Hope this helps, would have liked to present on this at DTA but my org didn't let me :-)



    ------------------------------
    Matt Beanland
    Telstra Corporation
    ------------------------------



  • 10.  RE: Network to Inventory Reconcilliation

    TM Forum Member
    Posted Apr 17, 2023 10:19

    Thanks Matt.  I hear what you're saying... I think that is the plan internally, albeit, we've probably not explored the full model driven aspect.  it would help drive the comparision and rules based on metadata rather than hardcoded business rules.  we'll have a look to see if that can be implemented also...
    Thanks for the support
    Marty



    ------------------------------
    marty oliver
    BT Group plc
    ------------------------------