Open APIs

 View Only
Expand all | Collapse all

TMF622 - asking in a request for handling relating to a specific back-end data store

  • 1.  TMF622 - asking in a request for handling relating to a specific back-end data store

    TM Forum Member
    Posted Jan 06, 2022 07:29
    Hi

    The scenario is this :-

    1. we have a single service exposed using TMF622 for clients to use to create orders. This service acts to create assets on system A
    2. a new client wishes to use the same service, for the same purpose BUT wants to instruct the service to act differently - to create its assets on system B where B is a similar but distinct system to A

    What is the best way for the this new client to supply this instruction?

    eg. as some HTTP header parameter?
    eg. as some TMF622 payload resource attribute such as relatedParty where system B could be considered a related party?

    any advice welcome :-)

    Darren

    ------------------------------
    Darren Wylie
    BT Group plc
    ------------------------------


  • 2.  RE: TMF622 - asking in a request for handling relating to a specific back-end data store

    TM Forum Member
    Posted Jan 06, 2022 09:13
    just noticed 'category' (in the product order resource) which seems a good choice?

    ------------------------------
    Darren Wylie
    BT Group plc
    ------------------------------



  • 3.  RE: TMF622 - asking in a request for handling relating to a specific back-end data store

    TM Forum Member
    Posted Jan 06, 2022 11:15
    Hi Darren

    It really depends on where the "knowledge" should be. I think it would help if you could be more concrete about your examples (if you can do so without giving away BT's IP). But I would guess that you are referring to two different product order management silos, perhaps (shall we say) one deals with mobile products and the other with fixed-line.
    To me it doesn't seem healthy that the consumer (commerce UI perhaps) should decide where the calls should go, that will constrain you in the future if you consolidate the platforms.
    That rules out order.category or HTTP header.
    You could use the reference to product specification in the order item tree, but there could be multiple references from the different items.
    Additionally,  what would you do for a bundled order that has mixed order items (some for system A, some for system B). Probably you need some sort of proxy business layer that does the routing based on the order contents, and potentially splits the order into multiple sub-orders.
    I hope I'm not over-thinking this.

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



  • 4.  RE: TMF622 - asking in a request for handling relating to a specific back-end data store

    Posted Jan 07, 2022 06:30
    I tend to agree with Jonathan here. 
    It would in my opinion be preferable to have some form of content based routing for resource creation based on something in the request. 

    That could be associated with the product offering if that is the split. Or it could be details of the end user customer. Or it could be the line of business providing the product. Anything like that I believe would be preferable to some direct proxy for the target system which the client knowingly needs to choose. 

    Otherwise you might as well be explicit and have a different host specifies for each target system.

    ------------------------------
    Derrick Evans
    ------------------------------



  • 5.  RE: TMF622 - asking in a request for handling relating to a specific back-end data store

    TM Forum Member
    Posted Jan 07, 2022 11:06
    Hi Derrick, Jonathan

    I like the idea of using something in the request body but the product offering is not the deciding factor. The line of business is a close analogy but how can that be represented in the payload - I don't see any resource attribute that is about that sort of thing. Category seemed closest to me but I also see a thing called 'related channel' which may be better.

    It is not the case that I want the client to understand the identity of the back-end system, it just happens to be the case that orders of a certain category/channel (line of business) are at present handled in a specific way that happens (at present) to use system B (rather than system A).

    So, I don't really see this as a routing problem at all but rather simply that the client needs to be able to indicate that this is a certain type of order to avail of a certain type of handling.

    Darren


    ------------------------------
    Darren Wylie
    BT Group plc
    ------------------------------



  • 6.  RE: TMF622 - asking in a request for handling relating to a specific back-end data store

    Posted Jan 08, 2022 13:54
    Hello,
    So buyers and sellers (and therefore lines of business) are modelled as related parties in the order with various roles?
    So how are these modelled in your current use of the API?


    ------------------------------
    Derrick Evans
    ------------------------------



  • 7.  RE: TMF622 - asking in a request for handling relating to a specific back-end data store

    TM Forum Member
    Posted Jan 10, 2022 04:18

    Derrick

    Not sure were are speaking of the same thing here. I am thinking of two parts of our business, not buyers and sellers. The 'relatedParty' is simply the customer at present.

    So, my proposition is that the client of the API informs the API that it is to deal with the request as either a request for one part of our business (eg. Retail) or a different part (eg. Wholesale). If retail then it would handle it by passing to a certain downstream processing system, If wholesale then it would handle it by passing onto a different set of processing systems.

    I could be mistaken but this seems to be what 'channel' is for :-

    From the TMF622 document .......channel - A list of related channels (RelatedChannel [*]). Related channel to another entity.
    May be online web, mobile app, social ,etc.

    What do you think? or have you a better idea?

    Darren

    Darren



    ------------------------------
    Darren Wylie
    BT Group plc
    ------------------------------



  • 8.  RE: TMF622 - asking in a request for handling relating to a specific back-end data store

    TM Forum Member
    Posted Jan 10, 2022 05:06
    Hi Darren

    Channel for an order (or a trouble ticket, or an interaction) would be the channel via which the order (or TT or interaction) was received. If that's they way your business works, it seems to be eminently sensible to route the API destination according to the channel. But like I said previously, you should do this in the backend (either by API gateway or by a small proxy provider), not in the frontend.

    P.S. Please note that ChannelRef is an anomalous entity, since there is no actual Channel managed entity/API in the Open API model. There are a few other <xxxx>Ref like that as well. But that doesn't stop you using it, all you need is the name or the ID as your routing criterion.

    ------------------------------
    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: TMF622 - asking in a request for handling relating to a specific back-end data store

    Posted Jan 10, 2022 08:00
    Jonathan,

    In  terms of "Channel" I would welcome some more info.

    In the TMF APIs I am presuming "Channel" means "medium by which the interaction occurs or is to occur".

    So in TMF622 I read the following.

    "channel  - A list of related channels (RelatedChannel [*]). Related channel to another entity. May be online web, mobile app, social ,etc.".

    I take that to be something different to the use of channels when describing models of sales and distribution of products  via retailers, wholesalers, manufacturers and "channel partners"  "Marketing channel - Wikipedia"

    There is ample scope for confusion here (in my mind at least) as sales and distribution strategies of hard goods (like phones) include a combination of sales medium (instore and web sales  etc)  with various models of fulfilment from various parties via distribution centres, warehouses and manufacturers.

    So have I made an incorrect presumption?

    Darren
    I am not sure I have a better idea  and if channel as described by Jonathan and the specification fits your needs then I guess that would be a way to go, Depending on Jonathan's reply perhaps there is a "Retail" channel and a "Wholesale" channel.

    Maybe you can help me understand your need better?

    In terms of the correct backend/downstream routing of product orders from customers for "processing". Is this from a customer facing CRM/ordering system to different fulfilment OSS or is this into two different CRM systems from a web front end? I am assuming that as a product order this API call is into one or more CRM systems?

    In terms of related parties, I understand what you say. However my experience is with B2B market hub type models. Although there is no explicit mention of a provider "related" party  in the specifications for product orders I believe there must be at least one other party implicitly. 

    In TMF622 it states (I added the bit in bold).

    "Product Ordering API manages product order resource:
    • A Product Order is a type of order which can be used to place an order between a customer and a service provider or between a service provider and a partner and vice versa,
    • Main Product Order attributes are its identifier, state, priority category (mass market, Enterprise, etc.) related dates (start, completion, etc.), related billing account, related parties and order items"
    So for me there are always at least two parties albeit one of them is "implicit" (the party who is the recipient of the product order). So I find TMF 622 a bit "provider oriented" in that regard. As a customer I might have multiple service provider suppliers and I might use all their individual product order APIs. Rather than hard code their API end points into my purchasing systems, I might well choose to route based on the party with the role "taking the order from the customer" (Supplier or Seller if you will) or the party with the role of "fulfilling of the ordered product".

    Moreover service providers are not monoliths and there may be several related parties within the same business taking various roles for different market segments and products. So in theory (for me at least) you can have a  choice of one of several related parties in a single company who are responsible for delivery of the chosen product. That could be the retail entity within the business or the wholesale one for the system integrator one or the value one etc..

    One last thought that occurs from the TMF622 quote about is the statement "Main Product Order attributes are its identifier, state, priority category (mass market, Enterprise, etc.) ". One could have a product model attribute stating how the product order is to be treated based on its "category". However that would require modelling all the impacted products the same way.



    ------------------------------
    Derrick Evans
    ------------------------------



  • 10.  RE: TMF622 - asking in a request for handling relating to a specific back-end data store

    TM Forum Member
    Posted Jan 11, 2022 04:15
    Derrick

    To get specific - we are using 622 as the means of posting billing orders into a billing platform. Orders for wholesale customers (or more specifically those targetting wholesale billing accounts) must be handled in one way whereas orders for Retail customers (or more specifically those targetting retail billing accounts) must be handled in a different way. The service is however common and therefore the using a differentiator in the 622 payload seems right

    So, the possibilities as I see it are to use attributes on the  :-
    a) related channel (to the productOrder resource)
    or
    b) category (attribute in the productOrder resource). I see this as easiest - all the products in the order would be treated the same which is fine

    Either of these would be adequate from a purely practical point of view, notwithstanding the theoretical considerations mentioned

    Darren

    ------------------------------
    Darren Wylie
    BT Group plc
    ------------------------------



  • 11.  RE: TMF622 - asking in a request for handling relating to a specific back-end data store

    Posted Jan 11, 2022 05:45
    Hello Darren

    Thank you for explaining. I agree with your reasoning.

    There might be one other approach to this if you are composing one API out of two others (which it sounds like you might be doing) as a front end to multiple backend systems.

    If the primary keys for the wholesale and retail billing accounts are guaranteed to be unique across both back end systems you could have logic which posts orders into both systems and let one fail for unmatched billing account information (provided that validation logic exists)?

    Or if the backend systems (or some other systems) support an API like TMF666 which has
    "GET /billingAccount/{id}?fields=...&{filtering}"

    You could perhaps find a way of using the billing account id from the product order to determine which backend system is relevant?


    ------------------------------
    Derrick Evans
    ------------------------------



  • 12.  RE: TMF622 - asking in a request for handling relating to a specific back-end data store

    TM Forum Member
    Posted Jan 11, 2022 06:14
    Derrick

    We had considered this (letting the system be identified by the 622 service itself) as an option but thanks to your prompting we have re-considered it and are now somewhat more happy with it. 

    However, it does push the problem back a step to the request that issues the preparatory TMF666 create account request in the first place - that request would need to employ "category" to ensure that the account became an entity in the right system.

    I therefore propose the following

    TMF666 - Consumer passes "category" value which clearly indicates the nature of the handling required, ie. where the resultant account should reside
    TMF622 - Consumer need only pass the identity of the account, service will determine where it is at

    Darren

    ------------------------------
    Darren Wylie
    BT Group plc
    ------------------------------



  • 13.  RE: TMF622 - asking in a request for handling relating to a specific back-end data store

    TM Forum Member
    Posted Jan 11, 2022 06:25
    Oops - just noticed there is no 'category' in TMF666!

    ------------------------------
    Darren Wylie
    BT Group plc
    ------------------------------



  • 14.  RE: TMF622 - asking in a request for handling relating to a specific back-end data store

    TM Forum Member
    Posted Jan 11, 2022 06:33
    but accountType is there - the examples portray a range of values (eg. Business, Global etc.) but the definition of what it really means is not that clear (to me at least) so could be used for my purpose

    accountType A string. A categorization of an account, such as individual, joint, and so forth,
    whose instances share some of the same characteristics. Note: for flexibility
    we use a String here but an implementation may use an enumeration with a
    limited list of valid values

    ------------------------------
    Darren Wylie
    BT Group plc
    ------------------------------



  • 15.  RE: TMF622 - asking in a request for handling relating to a specific back-end data store

    TM Forum Member
    Posted Jan 12, 2022 08:58
    Derrick - is there any hope of something common to TMF666 and TMF622 that would allow the consumer to express this - our billing reps are not that comfortable with the 622 service having to do trial and error  - the only mechanism possible at present

    ------------------------------
    Darren Wylie
    BT Group plc
    ------------------------------



  • 16.  RE: TMF622 - asking in a request for handling relating to a specific back-end data store

    Posted Jan 12, 2022 14:11
    Hello Darren,
    Not making it easy for you are they?
    You could argue if the billing folk have two hosts and a single front end API  then they are the ones who need to solve the conundrum of how to route internally?

    As Jonathan suggested earlier the client really shouldn't have to care.

    In past architectures I worked on, components would solve this problem with an ESB supporting the VETRO pattern which would compose/orchestrate  the API calls and would check all the relevant systems and instances to see where to forward the API call. Then the backend system folks had no say in it.

    If you want a common attribute in TMF 622 and 666 that directly addresses this matter, you might have to resort to an extension to add data. But then the systems would need to support that?

    But other thoughts occur.

    Is it the same billing systems which support TMF666 and TMF622? Or, if not, does the system(s) supporting 666 similarly have a retail/wholesale split.
    If the account management API is split the way the product order API is split, you would still have to make two TMF666 API calls whatever folks say in order to validate which type of account you have? One could argue then that whichever 666 API call finds the account suggests where the order should go?

    Also (although this is dicey as resource uris should not be used to infer any meaning for the resource other than how to get it) does the href in the TMF666 response for the billing account suggest anything about where the product order resource should be created?

    Finally what does the TMF666 API actually return as values for accountType in your implemenation? Does it map in any way to your notion of "retail" and "wholesale")?





    ------------------------------
    Derrick Evans
    ------------------------------