Service Fulfillment Research Paper

Improvising Service Fulfillment

What is Service Fulfillment?

In Telecommunications, Fulfillment of services involves a sequence of supply chain activities responsible for putting together and making the services available to end users.

Matching the increasing customer expectation in today’s market is not only limited to Quality or Service Assurance domain, but Service Fulfillment also plays a vital role. Moreover, Service Fulfillment helps in securing the “first time right” customer experience. In our undertaking, we were using Oracle Service Fulfillment application – ASAP (Automated Service Activation Program).

The Process: Service order request in Oracle Service Fulfillment Application

Oracle Service Fulfillment ASAP handles a typical

If required, the Service Fulfillment Manager Screens can also pick the customer requests. However, the primary capture process has usually been through the Oracle Siebel system.

And here was the pain point for us. Our application was running on latency server, and whenever there was a voluminous inflow of service orders, then there was a severe impact on the application services. Changing the application server was the permanent resolution to this issue. But we couldn’t change the server directly with the new one, as the server hosted data for millions of existing Vodafone customers. If we changed the server without considering the other related factors, it could have resulted in feeble business conditions.

We often observed some services going down due to this issue causing the overall application to hang. Even if any one of the ASAP services was down, processing of orders wasn't possible. Therefore, there was a direct impact to the end customer as their service requests were not activated and we had to fix the issue on

However, to reduce replication and multiple processes trying to restart the same component, the recommendation was to control the operation by one central place using a storage-related approach. To enable this, the Traffic Controllers monitored ASAP application elements and informed the upstream consumer (F5 – the load balancer) if it faced some irresolvable failure.

The F5 load balancer sent a status check request to each of the Traffic Controllers (this was configurable, and we set it to 5 seconds). We split the Traffic Controllers over both ASAP Server instances, and the F5 would send a status check request to only one of the ASAP Server instances for each service type.

In the case of service not available, the traffic controller had 5 attempts to restart the particular component. Still, if the service did not come back, the component state was changed to down, allowing for redirection of transactions to the healthy Active ASAP