Saturday 7 February 2009

The one on E-Business Suite Adapter

The last few years I had to think about using the EBS-Adapter for several times. The E-Business Suite adapter is delivered with the SoaSuite, earlier with BPEL PM 10.1.2. When running the adapter wizard in jDeveloper under the Technology Adapters you find the wizard for the Applications- Adapter (EBS Adapter). The EBS-adapter is actually a special sauce over the database adapter (for the public-api's and the Open Interface Tables) and the AQ-adapter (for the Business Event System). The EBS adapter wizard makes it easier to introspect the interface possibilities of EBS. It downloads the Integration Repository (IRep) and makes it introspectable. So you can browse through the IRep and choose the interface you need and the Adapter wizard generates the correct artefacts.

If you choose a Public API, a TCA-Person-API for example, then it will generate a wrapper package and accompanying Object Types. The API's often use record types, and the database-adapter does not support them. It does support Object Types perfectly. Even with complex hierarchies.

The generated pl/sql are syntactically correct and function properly. However the naming of the object types and the procedures are generated using an quite obscure algorithm. The name of the package is changeable (you'll be asked for the name) but the name of the object types are generated. The names of the functions that convert the recort-types to object-types and visa versa are generated using a name like pls_to_sql, where is a sequence number. I found that if multiple object types are used, the generated functions for a particular object type do not neccessarly have the same sequence number. Also I found with earlier releases that there can be name-collision between object types from API's that are in name closely related (like party-site and party-site-use).

If the EBS-Adapter was for free, I would tend to accept these side-affects. Then it is to Oracle to support the correct naming and behaviour. But unfortunately it is far from free. You have to pay a significant amount for the use of the EBS Adapter. And that is where I found the story become strange. Because a customer pays a quite respectable license fee for the E-Business Suite. Also for the SoaSuite. Then both products need a database and since the customer probably use it not only for strict EBusiness Suite use, they should have a Full Use Database license. Maybe even for the only use of SoaSuite you should have a full-use license.

So since Oracle should be glad to have a customer use both E-Business Suite and SoaSuite, I would say that the E-Business Suite Adapter should be free. The EBS-Adapter should be a sales-argument to choose for SoaSuite in combination with EBS.

Honestly I can't explain why you should use the EBS adapter in such a setting. Because you can use the Database and AQ adapter just as good. The only real advantage of the EBS Adapter is that it will set the responsibility correctly. That is what you should add to the pl/sql wrapper functions that the Database Adapter generates. But that's no rocket sciense. In my experience the EBS-Adapter is a nice product, but I feel that the advantage is limited related to the license fee.

But maybe times change. On Open World the SOA Gateway for EBS is introduced. I got the following link from a colleague:
This explains the introduction of the SOA Gateway. And it seems that it is a special-packaging/deployment of the EBS Adapter right into the OC4J of the E-Business Suite. It adds a maintenance screen that enables you to choose a IRep interface and generate a WSDL for it. This Maintenance screen can be seen as a replacement of the adapter-wizard in JDeveloper.

It is possible to add custom API's to the IRep. It even has support for complex API's, both seeded and Third Party. These are in fact BPEL Processes that tigh the API's together. You can download them and as I understand it, you should deploy it to your separate BPEL PM.

At my current customer the ICT department asked for WSDL's on EBS. There aren't any (well a few, but I learned they're not of much use). But with the new SOA Gateway it should be easy to deliver them for every EBS-API there is.

Now let's hope it is delivered under the Foundation-license of EBS and that it is not an option...


Anonymous said...

has it changed now? Does R12.1 have a comprehensive WSDL with all the EBS services exposed?

Martien van den Akker said...

Not as far as I know.
The main improvements I've seen are:
- EBS has now several Business Objects with corresponding API's to do coarse grained updates, combining entity-level API's.
- since 12.1 EBS as a EBS adapter deployed in its own OC4J (the so called SOA Gateway). So you can expose the api's directly as Webservice. Its like the EBS adapter detached from the SoaSuite and deployed seperately on EBS. Don't know if you have to pay for it. The SOA gateway is in fact what they did to expose the api's in a more friendly way.


Unknown said...

Hoi Martien,

ik wil voor een klant in R11.5.10 een maatwerk PL/SQL API als een webservice exposen. Op welke manier raad je aan om dit te doen, als ik je verhaal zo lees dan is de Adapter wel erg duur om een enkele webservice te publiceren.

ik kan 'm ook niet standalone in OC4J deployen omdat R11.5.10 geen gebruik maakt van OC4J voor zover ik het gelezen heb.

enig inzicht zou zeer welkom zijn !

reuben filius

Martien van den Akker said...

Hi Rueben,

Let me reply with a blogpost, since I'm not very good in short answers...