Can anyone please explain (or point to any documentation) the pros and cons of connecting to siebel applications via the following
Making direct JDBC calls to the backend database.
Communicating via the siebel adapter.
Also can I use the adapter development kit to create an adapter to call the siebel APIs. What would be the development effort on a scale of (1-10, 10 being impossible).
Vikas,
Best way is to use siebel adapter as it has built in functionality to communicate with siebel.Why you want to use adapter development kit to build adapter for calling siebel API?unless you have special requiremnt.It is like reinventing wheel.
You can go through users guide for siebel adapter to check exsisting functionality
It’s a bad idea to ever try to write anything to the DB directly vs. going through the Siebel Application logic via their client or with an adapter, etc. Siebel has a ton of meta data and business rules defined in the Data layer in Business Objects and Business Components. Also, in many cases their app creates much of the referential integrity and so going direct could hose the whole DB. In theory, you could go against the DB for read only access, but you still lose a lot of business rules and you also lose any visibility into Siebel’s data visibility and security for a given user. If you go through the adapter, that’s all handled automatically for you if you pass user credentials in with your calls. In short, I can’t think of any reason why you would ever want to go direct to the DB.
I agree with Sam and John. If you need to update or insert Siebel data, direct database access is not the way to go. Writing your own adapter is possible. However, the effort to develop and to maintain it in the future to support new Siebel features and versions would make that option very unattractive from a cost standpoint. You might not have to pay webMethods for a Siebel adapter license, but you would pay many times that price to write, debug and maintain your own over time, IMHO.
In some (maybe all) customer contracts, writing directly to the database layer gave Siebel grounds for dropping support for your account.
Another option that has not yet been mentioned is to use the web services layer provided as part of more recent Siebel versions. This is more work than using the adapter as I believe most of the provided services are the equivalent of low-level API calls, but it would work and it would be supported by Siebel.
I’ve done several integrations to Siebel (version 6 and 7) using the Siebel EAI layer to communicate via XML over HTTP(S). This requires you to write code as a Siebel workflow to process the data in your XML document. I haven’t done that bit myself, but my understanding is that it’s pretty simple in the Siebel development toolset. On the webMethods side, it’s laughably easy to handle inbound and outbound HTTP requests, either in IS services or through Trading Networks.
The upside: no adapter to install or worry about, easy webMethods code, Siebel workflows allow you to re-use all your Siebel business objects
The downside: Siebel EAI can sometime choke on large numbers of records, requires that you write the Siebel workflows
Other than running thru the wM installer and getting the Siebel adapter (and SPs) for the Integration Server, does a Siebel Client need to be installed on the same server?
Hence, if all the Siebel stuff is on Box A and the webMethods stuff is on Box B, nothing from Siebel should need to be installed on Box A, right???