Open APIs

 View Only
  • 1.  Resource activation throttling

    TM Forum Member
    Posted Feb 29, 2024 01:58

    Hello,

    I am trying to implement Resource activation (RA) for activating a resource. But our vendor system has no throttle mechanism. In RA, we are need to organize throttling for the system. If RA has throttle mechanism. It should be splitted to 2 programs. First one receives resource request and insert it to a queue. Next one fulfills the resource activation. I don't know if RA functions should be splitted. What options did you implement?



    ------------------------------
    Myagaa Nm
    Mobicom Corporation
    ------------------------------


  • 2.  RE: Resource activation throttling

    TM Forum Member
    Posted Feb 29, 2024 03:25

    Hi Myagaa

    I don't know very much about the details of resource activation. But specifically for throttling, simply writing the request to a queue won't help, since I'm guessing that your vendor system won't be able to take the request directly from a queue. You'll have to write some software (or see if you can find equivalent on the Internet) that you can trust, which does the throttling. For example if you want to control the throughput to (say) one request every 10th of second (0.1s), you'd have a wait timer in your code that goes off every 0.1s and retrieves the next message from your topic.

    You'll also need to manage failures (such as if your vendor system couldn't honor a particular request), perhaps by writing failed requests to a Dead Letter Queue (DLQ), and then having human or automatic handling of the failures.

    Good luck



    ------------------------------
    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: Resource activation throttling

    TM Forum Member
    Posted Feb 29, 2024 10:09

    Hi Jonathan,

    Yes, the vendor system can't get data from the queue. RA receives a "resource" request, it stores the request as what it receives on the queue. If it stores the request successfully on the queue, it just respond acknowledge the request to what a client call it (Resource order management). Another application throttles reading the queue. When it reads "resource" data from the queue, it transfers a request to vendor system's api. In order to implement the throttle, RA should be splitted to the 2 different programs. My question is how good solution it is.



    ------------------------------
    Myagaa Nm
    Mobicom Corporation
    ------------------------------



  • 4.  RE: Resource activation throttling

    TM Forum Member
    Posted Feb 29, 2024 10:24

    I don't have the knowledge to advise you further, sorry. I ask you to consider what you mean by "good solution". What KPIs are you measuring to define "good", could be:

    • throughput
    • latency
    • hardware requirement
    • fallout rate

    and many more. This is to some extent a question of requirements - your solution is "good" if it meets those non-functional KPIs in addition to the functional requirements



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



  • 5.  RE: Resource activation throttling

    TM Forum Member
    Posted Mar 01, 2024 01:56
    Edited by Vance Shipley Mar 01, 2024 03:35

    @Myagaa Nm describes an asynchronous use case for resource activation (i.e. TMF702/664). The asynchronous pattern is described in TMF630 Part 1.

    In TMF664 Resource Function Activation and Configuration API I included examples of both synchronous and asynchronous operations:

    The following is an example of an asynchronous request to create a resource function.

    The response status code SHOULD be '202 Accepted'. A 'Link:' header SHOULD be included providing a URI, with 

    the 'title' parameter having value 'monitor', at which progress of the request may be tracked.

    See TMF630 REST API Design Guidelines Part 1 section 9 Monitor Pattern.

    Unfortunately the API tooling didn't do a great job representing the asynchronous sample, including showing the wrong status code (201).

    Refer to TMF630 Part 1, Chapter 6, Create Resource Patterns:

    A creation operation MUST return a 202 Accepted HTTP response code when the resource creation is asynchronous.
    ...

    If operation is async, a Monitor resources MUST be returned. Please check section on Monitor pattern for more details. 

    The response for an asynchronous operation includes a Link header providing a reference to a new item in the "queue" you refer to, represented by the REST Collection of the asynchronous controller as described in Chapter 9, Monitor Pattern. The URI provided in the Link header of the response may be used to poll the item, or to subscribe to notifications so that the client is informed when the operation completes.

    [Looking at TMF630 1.8. Request and Response HTTP Headers – Server Side I see it has a misleading statement so I created Jira issue AP-4886 to get it corrected.]


    ------------------------------
    Vance Shipley
    SigScale
    ------------------------------