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.
Friday, August 10, 2007
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.
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.
Subscribe to:
Posts (Atom)