Open APIs

 View Only
  • 1.  Experience API?

    TM Forum Member
    Posted Nov 03, 2020 13:41
    Hi All,

    We are in the process of implementing Service APIs (ServiceOrder: 641, ServiceInventory: 638, ServiceCatalog:633). Looking at how to expose those for our User Interfaces, we started to extend 633 to support localization (for each characteristic and characteristic enum of our PSR instances), but then we realized that we also had to do the same for each properties of the different resource model (641, 638, 633...)

    We are now thinking of building an Experience API focused on user/channel. The Experience API will carry capabilities (like translation, validation, business rules) we want to apply at the UI level without hardcoding them in the UI layer itself

    Is there any plan to add something equivalent to the list of tmf APIs?

    ------------------------------
    Stephane AH-KO
    CGI Info Systems Management Consulting Inc.
    ------------------------------


  • 2.  RE: Experience API?

    TM Forum Member
    Posted Nov 05, 2020 02:55
    Hello Stephane,

    As far as know, I do not see contribution or work in progress on this topic. We had some discussion about localization in the past but not as far as requiring a specific API.
    If you have put some thought on this and willing to share with the team we can set up a discussion during a Monday API development call (or a Thursday architecture call)?

    Thanks

    Ludovic  ​

    ------------------------------
    Ludovic Robert
    Orange
    My answer are my own & don't represent necessarily my company or the TMF
    ------------------------------



  • 3.  RE: Experience API?

    TM Forum Member
    Posted Nov 12, 2020 07:51
    Thanks Ludovic,

    Reading more about ODA, they seem to reference what I described above as "Engagement Management", which contains functionalities around UIs, Content, Authentication.... ​In IG1167 (ODA Functional Architecture R19.0.0), it mentions "The TMFOpen API group is currently working on the definition of these APIs". Is the Engagement Management API in the pipeline in the near future?

    Regards,
    Stef

    ------------------------------
    Stephane AH-KO
    CGI Info Systems Management Consulting Inc.
    ------------------------------



  • 4.  RE: Experience API?

    TM Forum Member
    Posted Nov 12, 2020 08:35
    Hello Stephane
    For me the API mentioned in the part 4.3.2 of IG1167 "engagement management (...)  interacts with other ODA blocks only through Event or Process APIs (new APIs - definition ongoing), or read data through current standard TMF Open API " are the
    • ProcessFlow API (701) to motorize interaction between Engagement management to back end to orchestrate business process and update/create core data,
    • Event API (688) to manage all asynchronous exchange pattern (event-based) - note that ProcessFlow (and task-flow subresources) trigger event as well,
    • and of course use all existingTMF Open APIs to allow engagement management to retrieve any data.

    The processFlow API (701) could be use to expose from your back to the Front-end(s) the business rule & logic. We provided some example in IG1228 ODA/API Call Flow Use Cases v1.0.0 based on very simple UCs. You can perhaps check if this document is covering same requirements that you have.

    Probably my bad to not have correctly answered you in my first response - when you mean Experience API I was thinking something more linked to the UI look and feel.

    Hope it helps

    Ludovic

    ------------------------------
    Ludovic Robert
    Orange
    My answer are my own & don't represent necessarily my company or the TMF
    ------------------------------



  • 5.  RE: Experience API?

    TM Forum Member
    Posted Nov 12, 2020 09:35
    Thanks Ludovic,

    I think you read my initial request correctly. Since we want to decouple rules from UI as much as we can, Having the UI calling let's say 638 directly is not enough. We plan the UI to call another API to know how to decrypt/translate/display the response:
    - one obvious API was 633 to understand a bit more the Service Specification
    - For translation (of the API properties + ServiceCharacteristic + ServiceCharacteristicValue), we were planning to build our own API, unless it was a feature of the "Engagement Management API". Based on your answer, I now have a better understanding.

    Thanks
    Stef

    ------------------------------
    Stephane AH-KO
    CGI Info Systems Management Consulting Inc.
    ------------------------------