Websphere Customer Center (WCC)

Websphere Customer Center (WCC) is a JEE based application from IBM that is designed for the management of customer data targeting insurance and banking industries. WCC provides a unified view of a customer by aligning customer data from multiple office systems (both online and batch) in real time. The main benefit in using WCC is to provide a business with one system of record for customer data as opposed to streamlining the data over multiple lines of business. With the rising popularity and lacking array knowledge on this product, it is well suited to have its own discussion thread in order for developers to learn and share knowledge on this product.

So how much internal detail can one cover accurately when talking about a “black box” application? The majority of my knowledge about the internals of WCC were learned on the job while building an enterprise customer application and working with IBM support. Although you are not able to see the source code, WCC does provide an intuitive API for executing fine grained services that consist of basic crud operations for each table. Extending/Customizing the product is also fairly easy once you know your way around. Once we start creating our own services, we’ll use the WCC base transactions to create our course grained services that give us the functionality needed to complete a unit of work.

When evaluating the internal components of WCC, there are several things that are helpful to understand. WCC 6.0 and all prior versions use EJB Entity Beans to represent each table in the WCC database. Each entity bean is encompassed with a business component for that particular data domain. For example, each data element that makes up a party (ie: Party, Person, Location Group, Party Address, and Address) each have entity beans and are encapsulated within the PartyComponent object. The component level objects are executed via a controller from the RequestFramework. For example, if a consumer wants to add a party, they would send an xml request to the RequestHandler that commands the RequestHandler to invoke the addParty service with the given party’s domain data in the xml request.

If you glance at the diagram above, you’ll notice that WCC uses POJOs referred to as Business Objects (BObj) to deliver the data from the Request Framework to the business components which in turn use the entity beans to persist the data. The Request Framework is implemented by use of an EJB Session Bean called the RequestHandler. As mentioned above, the RequestHandler accepts XML strings as input and unmarshals it into the Business Object (BObj) as represented by the input xml. Below is an example of a business object in xml form and is a snippet from an actual xml request.

The service to be executed is also declared inside the input xml. So to tie things together, the RequestHandler controls the objects by invoking the internal component for the service specified in the xml request. The rest is black box magic. A complete request looks like the following...

You’ll often hear about the controller & component layers in the WCC application. It appears that the RequestHandler and all custom business proxies are executed at the controller level because they invoke the internal components and are controlling the flow of the transaction. The component layer consists of objects that wrap the entity objects. Generally, each business object (BObj) correlates to a table on the database, however there are few exceptions where more than one table is mapped back to one BObj. Some of aforementioned exceptions include tables that have a one-to-one relationship which truly can be represented as one object. The following diagram shows the relationships of each commonly used data entity (yes there are many more data entities supported by WCC) . Keep in mind that this representation is the same whether dealing with the objects in XML form, Java object form, or database form. This diagram should be helpful when looking at some of the examples that I will be providing.

WCC Configuration

The behavior of each aspect of the WCC framework can be customized. WCC appears to make a great use of java reflection to allow creation of custom services & rules via Java extensions. You have the ability to extend the product base classes to override default behavior of the product. WCC can be configured through database tables as well as java properties which drive the class loaders of the application.

I will be adding information on some of the key aspects of WCC. Some of the topics that will be discussed are Business Proxies (Composite Transactions), Duplicate Suspect Processing(DSP), Pre & Post behavior extensions and finally and architectural approach to efficient processing using the some of the component level services.