What is a canonical data model?

Recently, I have been asked a lot "What is a canonical data model?". In the SOA world, the term "canonical data model" is thrown around as a way to impress the lay person. In reality the canonical data model is a simple concept:

The canonical data model (CDM) is a representation of common information produced and consumed by applications. The CDM is normally used to publish events in the form of messages out of one application into several another applications. The CDM is used as the format of the message so that all of the receiving applications know what information to expect in the message.

For example lets create the canonical data model for a person. The CDM for a person must include information that uniquely identifies that person:

• Name
• Birth Date
• Social Security Number/Passport number

The information that is unique must be included in the CDM so that it is easy to distinguish if two person messages relate to the same person or different people. That is the lowest common denominator for a canonical message. A canonical message normally contains other useful information about an object that is used by most of the receiving applications. Continuing to build out the CDM for our person object, these other useful fields could be included:

• Work Address
• Home Address
• Work phone number
• Home phone number
• Cell phone number
• Fax number

As you can see the list of information describing a person can go on and on. The information each application needs to know about a person can vary greatly, so how do you know what to put in the canonical data model? In my next post, I will talk about how to create a canonical data model that provides the benefits without running into a maintenance nightmare.

Integrating with PeopleSoft

I just recently completed a project that heavily integrated with PeopleSoft. I have been on several projects and demos in the past that have integrated with PeopleSoft and figured it was time to share a little knowledge about how to do it.

The PeopleSoft Component Interfaces (CI) is a great way to integrate because it allows you to reuse all of the business logic and data validation that is used by the PeopleSoft Web interface. The version of PeopleSoft that you are integrating too will define the way you can call the CIs.

If you are lucky enough to be integrating with PeopleSoft 8.4 or greater, the CIs can automatically generate Web Services (as well as Java and COM objects) out of the box. This makes integrating with the CIs quick and easy since most integration tools can easily call Web Services. The only thing you need to worry about it getting the right data into the right fields.

If you are on an older version of PeopleSoft (pre 8.4) the CIs can be exposed as Java classes or COM objects. Since I mostly work with Java based tools for integration, we obviously used the Java classes. There are two ways to utilize the Java classes:

1.) Purchase the PeopleSoft Adapter from IWay. This exposes the CIs as Web Services that are easily called by any integration tool. The adapter is not the easiest thing to configure but once configured it makes integrating into a large number of CIs quick and easy. The adapter is costly so the ROI should be looked at before making the decision.

2.) Creating your own Web Service that utilize the Java classes exposed by the PeopleSoft CIs. This sounds like a lot of work but is actually pretty simple with a little knowledge of Java, PeopleSoft and a handy tool that will create a Web Service for you. We made use of the JAX-B framework and Oracle JDeveloper to quickly create these Web Service wrappers. Once the Web Services are created they can be integrated using most integration tools.

If you are starting off slow and only integrating to a handful of interfaces the second option might be most cost effective, but if you plan on integrating with several CIs (10+) it would probably be more cost effective in the long run to purchase the PeopleSoft adapter.

Is multiple BPEL OC4J Instance possible?

Recently while working on an integration project using the Oracle SOA Suite, a client wanted to have multiple OC4J BPEL instances inside of one Oracle Application Server. The desire was to utilize the mulitple OC4J instances to ease deployments and maintenance by running on one OC4J and performing maintenance on the other.

After doing some research and checking with some people at Oracle it seems that even though you can have multiple OC4J instances in one Oracle Application Server you can currently only have one BPEL specific OC4J container. There are a couple of reasons for this:

1.) The oracle home directory contains a BPEL directory that maintains the configuration files for the BPEL OC4J instance. BPEL allows you to have multiple domains (each with a different set of configuration files) inside of an OC4J container but the directory structure does not allow for multiple BPEL instances.

2.) The SSO for the BPEL console is pinned to /BPELConsole. This would limit access to the console if the OC4J instances were to be managed separately.

In order to accomplish what the client wanted multiple Oracle Application Servers needed to be created each with their own OC4J BPEL instance.