I have the following problem: when JDBC adapter of type StoredProcedureWithSignature is changed (even by simply locking and saving it) or DB is restored from backup or similar changes are made, it stops working. Suddenly it stops seeing its procedure/function name, which is for example <.“ESBW.CHANGE_PRODUCT_ADMIN_DATA”>. During the call the underlying DBMS or adapter machinery complains:
ESBW is an Oracle package name.
The problem seems to occur due to double dot at the beginning. If I manage to change the procedure name to <ESBW.CHANGE_PRODUCT_ADMIN_DATA> (by making Procedure Name Pattern empty and putting my own procedure name), after adapter service save, the procedure parameters are wiped out, most likely because ESB adapter no longer sees such procedure name, which leads to this error:
That most likely means the procedure gets improperly called due to unwillingly emptied signature.
The only solution I have found so far is to create new adapter service of type StoredProcedure (without signature this time) and manually put IN/OUT/RETURN parameters, and put procedure name without this fancy <.">. The problem with this solution is that at the end of the day nobody wants to recreate hundreds of services, it would impose a considerable burden and would be error prone and require lots and lots of regression tests as well.
To put it simply, I wonder why ESB JDBC adapter service sees all DB procedures in <.“xxx”> format (in Procedure Name box), but if it is invoked, it fails. Also, how to make it work without huge effort.
I use com.wm.dd.jdbcx.oracle.OracleDataSource driver, but the problem occurs also in some other drivers I’ve tested.
Please help.
Product webMethods Integration Server
Version 8.2.2.0
Updates IS_8.2_SP2_Core_Fix7
Build Number 228
SSL Strong (128-bit)
Java Version 1.6.0_27 (50.0)
Java VM Name Java HotSpot™ 64-Bit Server VM
Java Build Info 20.2-b06, mixed mode
Java Vendor Sun Microsystems Inc.
Can you share your Oracle Version as well as the version of the database driver?
Additionally provide us the Fixlevel for the JDBCAdapter.
There have been quite some issues related to StoredProcedure in the last Fixes for JDBC Adapter.
I am not sure if the DataDirect Driver (com.wm.dd.jdbcx.oracle.OracleDataSource) will work due to license restrictions. It might be better to obtain an Oracle driver from OTN (Oracle TechNet).
Oracle Database 11g Enterprise Edition Release 11.2.0.2.0 - 64bit Production
PL/SQL Release 11.2.0.2.0 - Production
“CORE 11.2.0.2.0 Production”
TNS for IBM/AIX RISC System/6000: Version 11.2.0.2.0 - Production
NLSRTL Version 11.2.0.2.0 - Production
Description JDBC Adapter
Adapter Version 6.5 Release Notes
Updates WmJDBCAdapter_6.5_Fix28
JDBC_6.5_Fix42
JCA Spec Version 1.0
Vendor Name webMethods, Inc.
I don’t know how to check the version of the database driver.
Can you please recreate the same procedure with diff name, use StoredProcedurWitSignature Adapter service and check if it is working or not.If not there is a issue in the storedProcedure.
Can you please recreate the same procedure with diff name, use StoredProcedurWitSignature Adapter service and check if it is working or not.If not there is a issue in the storedProcedure.
No, it still does not work. In fact, this problem happens in most (all?) SPWS adapters I have, regardless of the DB connection (DB instance/schema/catalog).
Please share us the first paragraph of the META-INF/MANIFEST.MF file (a text file) from the ojdbc.jar you are using.
The x indicates the minimum JVM-Version for which this jar will be working.
For the currently supported Oracle Databases there are only ojdbc5.jar (up to Oracle 11), ojdbc6.jar and ojdbc7.jar (introduced with Oracle 12) available.
Latest available Fix for the JDBC-Adapter is JDBC_6.5_Fix50.
Latest IS-Core Fix available is IS_8.2_SP2_Fix16 and for the AdapterRunTime this is WAR_8.2_SP2_Fix6.
You can open the jar with any packaging program like 7Zip, WinZIP etc. as JARs are merely zips, except that extension might be bounded for some additional functionality.
I.e. if there is a Main-Class declared in the Jar you can run it by double-clicking it on windows.
On Unix you can run them with “java -jar ” to achieve the same.
The Unix-Installer for SAG-Components work this way (as an example).
Try to follow steps given by Holger and also kindly raise a ticket with SAG to find out the fix to the earliest. Please update the forum with the latest news.
Please remove the ojdbc14.jar completely as it is outdated and not really compatible with an Oracle 11g Database.
Additional (regarding to the Adapters Administrators and Users Guide) most of these jars can be placed under WmJDBCAdapter/code/jars instead of WmJDBCAdapter/code/jars/static, thus making it possible to exchange these jars without restarting IS, but simply reloading the WmJDBCAdapter-Package.
Only if the driver addtionally uses native libraries and the jar is only the JNI-Wrapper for those, the jar should be placed under WmJDBCAdapter/code/jars/static, to get the libraries correctly loaded during startup of IS.
Additionally you should check if SCG_8.2_SP2_DataDirect42_Fix1 is applied and configured to your IS.
The resulting Jar is located at common/lib/ext/sl53_cj42.jar and additionally under MWS/lib/* (it is named sl53_cj42_driver.jar here and needs to be manually copied here after the application of the Fix.
IF there are older version of this driver (others than ending in ‘42’) you can remove them.
Remember to edit the IntegrationServer/bin/ini.cnf in this case.
For MWS you need to call “MWS/bin/mws.sh -s default update” to adjust the classpath in the start.jar.