SID Q&A - Question 4

This is the fourth of a series of questions from SO4IT a Swedish IT consultancy company who are using GigaSpaces technology to build a SID based Order Management system for Communications Service Providers.

So4It:  The Order Manager application will look something like this

• CustomerOrderDetail place(CustomerOrder customerOrder)
• CustomerOrderDetail cancel(final OrderId orderId)
• CustomerOrderDetail get(final OrderId orderId)

Inside the order manager I know have to decide how to implement the flow of the order.  I will not use a complicated rule engine I will just have a simple mechanism for it.  But the question is how this mechanism will work.

I guess that you create CustomerOrderItems that are context aware.  I mean we can have a ProductOfferingCustomerOrderItem that will have the product offering with its ProductSpecifications and the selected ProductSpecificationValues.  Correct?

Andrew: The CustomerOrderItem is linked to the ProductOffering through BusinesInteractionItem (see below)

So the XML (and I’m so hot at writing XML but I hope this gives you an idea) will be something like

               

                                                 

So the OrderItem just refers (indirectly) to the Id of the ProductOffering, the Price (in BusinessInteractionPrice) and the quantity ordered.  The Order Manager will use the ProductOffering.Id to find the ProductOffering and its related ProductSpecification and ResourceSpecs and ServiceSpecs.  If the customer has selected ProductSpecificationValues then they would be in the XML as shown.

So4It: What do you suggest I do to get the order manager to select the right "Provisioning Conductor" for the CustomerOrder?  The alternatives, as I see it are:

1.  I could split the CustomerOrder into all the items and have a different "Provisioning Conductor" for each.  If I do that I could have a simple registry for the "Provisioning Conductors" that checks the type of the CustomerOrderItem and returns the correct "Provisioning Conductor" based on that or maybe one or more values inside the CustomerOrderItem.  OR
2. I could choose a "Provisioning Conductor" based on the CustomerOrder, which will be the ProductOfferingCustomerOrder or something.

I guess it is a matter of granularity here and I could do both but I was hoping you had some advice here, for example: how does the functionality in a OrderManager look like usually, I guess it is a rule engine or...?  Just give me your views on this if you have some.  The most important thing is how do you model the CustomerOrders and CustomerOrderItems in a real system using the product offering.

Andrew:  A Provisioning Conductor per Order Item is the correct solution if you mean by “Provisioning Conductor” the actual service that provisions the order.  The Order Manager must decompose the Order into individual items for provisioning – probably equating to individual OrderItems, but a really sophisticated Order Manager might group together similar order items before passing them off to other services for Provisioning.  The Order Manager must also think about sequencing – there may be items on the order that need to be provisioned first – for example sending out the handset (and waiting for an acknowledgement of receipt) before getting a Provisioning Conductor to provision phone number on the network.

A single order can have many different products on it – keep the granularity at the order item level.  There is a form of rules engine that understands the Product structure and the dependencies on the provisioning steps.