Open APIs

 View Only
  • 1.  Customer creation through an order

    TM Forum Member
    Posted Mar 25, 2021 19:19
    Dear All,

    I'd like to consult about creation of a greenfield customer: my focus is on how entities should be created when a new customer entity is created at the end of a checkout.

    Suppose having a checkout flow resulting in an Order created in the Order Management. During checkout proper customer data are on hand, so at the end of checkout valid Order, Customer, Customer Account and Billing Account entites can and need to be created. I can see three main patterns to the parallel entity creation:
    1. Order Management orchestrates entity creation, it's responsibility to create customer related entities in Customer Management.
    2. BFF creates the entities first and later creates the order with the references to the other entities
    3. An orchestrator component should be created in the backend layer to receive all data from BFF and create the entities in Customer Management and Order Management as well.
    I'd say it's an interesting question, because from clear microservice architecture point of view implementing a separate orchestrator (3) might be adviseable. However, implementing and maintaining a standalone component just for such a small process might be treated as overkill. Delegating this responsibility (and business logic) to BFF (2) seems not the correct way, because exactly the same flow needs to be implemented in all the BFFs realizing a similar business process. So from practical aspects I'd say that Order Management might be the most approrirate (or less dirty) solution in this case, but it's also not most beautiful implementation ever.

    What do you think? I would really welcome your opinion.

    Thanks you,

    András Door


  • 2.  RE: Customer creation through an order

    Posted Mar 26, 2021 11:20
    Hi Andras,

    Ideally the following should happen.

    The Customer should be created before the checkout.
    A Checkout can happen on a cart - the cart needs a Quote and a Quote needs a Customer.
    Can this relationship be broken?
    Technically - Yes.
    But it is always good to follow this Architectural principle.

    As you rote above, detailed information may not be captured before the check out. (This will depend on the complexity of the offer and the possibility of a customer hierarchy).
    Please refer to Product Order Open API622. That can be taken as a reference for the customer data that is needed before the order is submitted.

    And the tasks that you mentioned are all valid.
    Based on the complexity and diversity of the offers the Orchestrator may trigger  a lot more tasks and that is where the Open APIs 636, 640, 641, 638,639 etc may come into the picture.
    And some of these may need to be triggered more than once in the same order instance.

    Is it mandatory to have a separate function as an orchestrator?
    Please analyze your process for every Product offer class / category, check if the above mentioned APIs will need to be triggered or only a subset of them are to be triggered. This can be one criterion.
    Likewise your functional Architecture around Customer and Billing Account management is another criterion.

    Hope this helps.


    Sri Jagadish Baddukonda

  • 3.  RE: Customer creation through an order

    TM Forum Member
    Posted Mar 29, 2021 03:29
    Hello Jag, András

    For you information we're working on E2E call flow leveraging both ODA principles and the TMF open APIs; This UC has been studied in the IG1228 document (V3.0) which is in "submitted for publication" state. We discussed there 2 approaches:
    • One with a BFF process inthe FE orchestrating API call - and regarding the UC the creation of the party/customer from this - but also other API calls
    • Another with the process managed in the back end thanks to the ProcessFlow APi (701). in this case an 'orderCapture' process manage all step and interact with APIs/process. in this illustration, the OC process delegates to another process (from Party) the creation of the customer.
    Ad of now if you're part of the ODA team, or later when this document will be available for all TMF members, you could probably find there some interesting information.

    Hope it helps

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

  • 4.  RE: Customer creation through an order

    TM Forum Member
    Posted Mar 31, 2021 15:41
    Dear Ludovic,

    Thank you for informing me about this study. I'm not a part of ODA team, but I'm really looking forward to take a look at that.

    Kind regards,

    András Door
    Magyar Telekom Plc.

  • 5.  RE: Customer creation through an order

    TM Forum Member
    Posted Mar 31, 2021 15:39
    Dear Jag,

    Thank you for your answer! I appreciate the time you spent to give me such a detailed answer.

    Best regards,

    András Door
    Magyar Telekom Plc.

  • 6.  RE: Customer creation through an order

    Posted Mar 30, 2021 01:50
    If a general purpose orchestrator does not exists and all FE apps are integrated directly with BFF APIs, option 1 is faster route for quicker deployment. Later option 1 can be divided further to create a separate orchestrator or move it to other unified orchestration application without much production impact.

    Sharad Gandhi

  • 7.  RE: Customer creation through an order

    TM Forum Member
    Posted Mar 31, 2021 15:48
    Dear Sharad,

    Currently, the situation is exactly what you wrote: general purpose orchestrator doesn't exists and all FE components are integrated with BFFs. Thank you for confirming my idea about option 1.

    Best wishes,

    András Door
    Magyar Telekom Plc.

  • 8.  RE: Customer creation through an order

    TM Forum Member
    Posted Apr 01, 2021 10:26
    Hi there,

    although it's not currently considered as an option in IG1228, I would not entirely discard an option with Order Management being responsible for creating Customer and Account-related entities in underlying components (e.g. Billing).

    In many cases, we have to deal with old-fashioned BSS that don't allow to create Billing Accounts without Customer and Products. Even if all those entities can be created together with some workaround, this approach may add some complexity. In such circumstances, idea with Order Management orchestrating entity creation appears to be a nice termporary solution.

    Victor An
    Rostelecom PJSC

  • 9.  RE: Customer creation through an order

    TM Forum Member
    Posted Apr 05, 2021 03:20
    Just to add that in most cases you will want to create a customer and then revalidate the order. For example:
    • Customer might come from a high-risk segment, and so you'll want to limit the available offerings (product offering qualification) or collect deposit/advance payment
    • You need a billing account to which to apply the prices in the ordered product, and perhaps you'll want a payment method to guarantee payment
    • etc
    Hope it helps

    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.

  • 10.  RE: Customer creation through an order

    TM Forum Member
    Posted Nov 23, 2021 06:46
    Hi @András Door

    We also have a similar use case wherein our FE channel will collect all customer information as part of order capture for a new prepaid GSM connection and a new customer need to be created as part of the order fulfilment. 

    I came across this post in which similar concerns of mine were highlighted. I have few questions and would appreciate your kind response.
    1. What is the final approach that you have implemented ?
    2. If you have implemented option 1, how were all the details needed for customer creation provided (in which API) to Order Management application?
    3. When you mentioned "so at the end of checkout valid Order, Customer, Customer Account and Billing Account entities can and need to be created"-what exactly is this Customer Account entity you are referring to and how is this different from Customer entity?

    Thanks in advance.

    N V Rama Krishna Devata
    Tata Consultancy Services