Ramaiah Institute of Technology,

Dept. of MCA
Project Synopsis
Submitted by:
Name: Shivani Kumari
USN: 1MY18MCA22

Title of the Project: Digital experience for communications (DX4C)

Place of Project Carried on: Patna, Bihar
Language/Tools/Packages Used in Project: Spring Boot, REST API
Project Description:
DX4C stands for Digital Experience for Communications. The main aim of the
project is to provide a standard end to end cloud based solution to
communication industry to make them more agile and more competitive in the
market. Earlier these industries used to have CRM's to manage the customer
relations and market. The main flaw with Seibel was that it was on-premise and it
was more company specific. Today as we are moving towards rapid development
we need to have some solution which can provide rapid integration with the
company. That's why we came out with DX4C. In this we are hosting Siebel (a
CRM) on the cloud and we are trying to communicate to the Siebel through API's.
We are even following the standard Guidelines defined by the TM Forum
organization so that we can maintain the standardization and not being company
specific. Using the TM Forum API's has made our work a lot easier and we were
able to do our first release within short period of time. This DX4C captures all the
solution from buying to delivery. There are several modules which combines to
make it a fully functional project.
 Fig 1: DX4C Architecture

Seibel is the core of the project and mostly acts as a database. It has buying,
outbound, sales catalog, and extension.

 API-Buying: The inbound microservice receive requests from Store Front

(OCC or 3rd party), events from OSM-C or AIA or account requests from
Engagement Cloud. The inbound microservice process, transform and send
requests to Siebel.
 API-Outbound: The outbound microservice mainly receive requests from
Siebel. The outbound microservice process, transform and send requests to
OSM-C or AIA.
 API-Extension: The configuration microservice receive requests from a
Tenant (with admin roles) to and update Siebel configurations or configure
extensions.
  API-Catalog: The catalog microservice receive events from ECC (when
catalog is updated) and pulls data from ECC. Buying is called heart of this
project, because whatever creation, updation and deletion is done, the
logic is written here.

Fig 2: Buying Module

It takes request form 3rd party or say customer and then it does operation on it
and send it to Siebel and outbound. Takes input from Storefront UI or 3rd Party UI
or CDM and sends it to DX4C in TMF REST based API. Buying endpoints interacts
with Siebel via REST mainly. SOAP is considered where Siebel REST endpoints
doesn’t exist. Custom API operations will be introduced for the use cases in
absence of TMF based API. All endpoint interactions is taken care by API Routing
layer(Fabric).
 Fig 3: DX4C Outbound

Here we take the input from buying and sometimes from Seibel directly and
publish it to fabric by wrapping it inside some eventObjectType.

Sends data components outside-

Analytics, Billing, Fulfilment, Marketing, etc. In initial release, SOAP API’s will be
exposed.Siebel would send the updates for Account, Contact, Address and Billing
Profiles as part of the Account Updates which get stored in Kafka using SOAP APIs.
Outbound takes events from Kafka (published by BUYING as well as SIEBEL using
SOAP), converts it into TMF compliant form and publishes to fabric.

Signature:
External Guide:
Internal Guide: