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
------------------------------
Original Message:
Sent: Jan 10, 2022 05:05
From: Jonathan Goldberg
Subject: TMF622 - asking in a request for handling relating to a specific back-end data store
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.
Original Message:
Sent: Jan 10, 2022 04:18
From: Darren Wylie
Subject: TMF622 - asking in a request for handling relating to a specific back-end data store
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
Original Message:
Sent: Jan 08, 2022 13:54
From: Derrick Evans
Subject: TMF622 - asking in a request for handling relating to a specific back-end data store
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
Original Message:
Sent: Jan 07, 2022 11:06
From: Darren Wylie
Subject: TMF622 - asking in a request for handling relating to a specific back-end data store
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
Original Message:
Sent: Jan 07, 2022 06:29
From: Derrick Evans
Subject: TMF622 - asking in a request for handling relating to a specific back-end data store
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
Original Message:
Sent: Jan 06, 2022 11:15
From: Jonathan Goldberg
Subject: TMF622 - asking in a request for handling relating to a specific back-end data store
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.
Original Message:
Sent: Jan 06, 2022 09:12
From: Darren Wylie
Subject: TMF622 - asking in a request for handling relating to a specific back-end data store
just noticed 'category' (in the product order resource) which seems a good choice?
------------------------------
Darren Wylie
BT Group plc
Original Message:
Sent: Jan 06, 2022 07:28
From: Darren Wylie
Subject: TMF622 - asking in a request for handling relating to a specific back-end data store
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
------------------------------