WCC Business Proxies (Composite Transaction Services)

Business Proxies are just a fancy name for a custom service that you can create by extending the product. They are often also referred to as Composite Transactions which really indicate that you are taking several base WCC transactions (ie: addParty, addContract, etc…) and executing them together as one composite unit of work.

Lets walk through the steps it takes to create a business proxy. After you have your requirements and know what you need to build, study the product help manual to see what base services are available to meet your needs. As a side discussion, you’ll want to design your services so that multiple consumers can be satisfied, but your implementation is not clouded with each of your consumer’s business rules. Trust me, living by this rule makes upgrading and maintenance much easier.

As a specific example, assume you need to add a phone number on an existing customer. When you start evaluating the services that WCC has provided for customer contact points, you notice that there is an addPartyContactMethod services which accepts a TCRMPartyContactMethodBObj object. This is exactly what you want to do! But for this requirement you do not need a business proxy since you have found an out-of-the-box service that already fulfills the requirement. Now change the requirement up a bit and say that you want to add that same phone number to a contract that the customer owns (Contract data could be a checking account, saving account, insurance policy, etc…) The reason for fulfilling this requirement is that the business may want to store one-to-many phone numbers for a customer, but only add one of the customer’s phone numbers as a contact point for the checking account that the customer owns. So any time a customer opens a checking account for example, we want to store that phone number on the customer (if the phone number doesn’t already exist), as well as checking account. The custom may be known by many phone numbers, but the checking account only has one number associated to it for other business purposes such as auditing. For this requirement, you’ll need to code some business logic and create your own business proxy in order to ensure that the requirement is fulfilled as one unit of work.

We’ll call this service “maintainContractRoleLocation” since it should have the ability to add TCRMContractRoleLocationBObj objects as well as update them in the case of changing a phone a number on the account. In either case, we want our custom service to make this decision. In my previous WCC post, you can see that the TCRMContractRoleLocationBObj is used to associate party contact methods to a contract role. Specifically, I may have another consumer that comes along in the future who would need the ability to store an address instead of phone number. Since address is another type of contact point, this service could be reused appropriately to fit that need as well… even though we originally designed it to handle attaching phone numbers to accounts.

Once you are ready to begin building the service, you’ll need to build a java class and have it extend the WCC base objects so that you may override normal functionality with your own. Create a java class and name it “MaintainContractRoleLocationBp.java”. This class should extend the WCC base DWLTxnBP class as denoted in the diagram below. Next you must override the execute() method. This is where the actual service implementation will be placed.

Now you must tell WCC that you have a new service that you would like it to provide to consumers. Take the fully qualified class name of MaintainContractRoleLocationBp and create an entry in the DWLCommon_extension.properties.

BusinessProxy.tcrm.maintainContractRoleLocation=MaintainContractRoleLocationBp

The “BusinessProxy.tcrm.maintainContractRoleLocation” entry of this property tells WCC to create a new service named “maintainContractRoleLocation”. The second part of this line after the “=” tells WCC the implementation to use by way of reflection. In this case, it’s the MaintainContractRoleLocationBp class that we just created. You also need to add an entry to the CDBUSINESSTXTP table in order to declare that “maintainContractRoleLocation” is a new service that the request handler can understand.

INSERT INTO CDBUSINESSTXTP (BUSINESS_TX_TP_CD, NAME, TX_OBJECT_TP) VALUES (100000, 'maintainContractRoleLocation', 'P');

The BUSINESS_TX_TP_CD is any number that you wish to assign to the new service for keying purposes. The standard is to usually begin at 100000 which helps to identify custom entries as well as avoiding repeating an already used by another object. The TX_OBJECT_TP should be set to ‘P’ since this is a persistent transaction. In other words, we want to save or modify data as part of maintaining it. Other values for this field are ‘I’ or ‘S’ for ‘Inquiry” and “Search” respectively. You would use these transaction types if you would like to create a custom business proxy for retrieving data based on keys, or searching for data with a specific criteria

After you have provided your implementation, you can call the service by sending the RequestHandler the following XML message.

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.