Just spent quite a few hours troubleshooting IID V8.0 installation. Troubles started when installing DB2 Express (which comes with IID). I got to the end of installation but none of the server profiles was configured. Errors in the logs pointed to a pretty common SQL error
“SQL1092N “USER” does not have the authority to perform the requested command “
And it reported my domain Windows user account instead of “bpmadmin” user that was configured in the wizard.
Had to dig all the DB2 forums to come up with fixes. Wish IBM would document it somehow.
1. Verify user Domain Account and “bpmadmin” is part of DB2ADMNS and Administrators group
2. Verify in DB2 SYSADM, SYSCTRL, SYSMON groups are set to DB2ADMNS
db2 get dbm cfg
3. If they are not update groups:
db2 update dbm cfg using SYSMAINT_GROUP DB2ADMNS
db2 update dbm cfg using SYSCTRL_GROUP DB2ADMNS
db2 update dbm cfg using SYSMON_GROUP DB2ADMNS
db2 update dbm cfg using SYSADM_GROUP DB2ADMNS
4. Check that DB2_GRP_LOOKUP=TOKEN to make sure it works with domain account:
5. To update this setting run:
6. Restart DB2 instance
7. Reset WAS profile : Open IID, right click on Server -> Manage Profiles -> Reset Profile
8. If Reset did not work delete profile, and all files in profiles directory and re-create the profile with PMT
The new WID 6.1.2 hides plugin installation by default. I was looking for usual Eclipse menu Help->Software Updates->Find and Install to point to Site for installing the plugin, but it disappead. The trick was to switch from the default “Business Integration” perspective to “Resources” and then “Software Updates” are back and working.
Of course other ways of copying jars to features/plugins and links are still working, but the managed updates via Eclipse seems to be more elegant way. (http://www.venukb.com/2006/08/20/install-eclipse-plugins-the-easy-way/)
Collection of useful SOA and general plugins:
- Subclipse plugin installation instructions : Subversion integartion
- SoapUI Plugin – Web Service Testing
- BIRT Plugin – useful for Tivoli Common Reporting on SOA infrastructure
- WSRR Plugin – Webservice registry and repository plugin
After battling WID 6.1.2 start up, few more problems come up during migration of mediation projects to the new WID 6.1.2
1. WebService export binding does not regenerate the binding servlet in descriptors even after the full clean and rebuild. The error received when sending SOAP
Error 404: SRVE0190E: File not found: /sca/WebService
Basically the web.xml was missing servlet mapping
<display-name>Web Services Router Servlet for SCA</display-name>
The easiest way for WID to regenerate the web.xml properly was to “Replace the Binding” on the Export.
2. Web Service Import binding does not regenerate the EJB references in descriptors after full clean and rebuild. Getting the following exeption while testing the mediation module:
java:comp/env/sca/import/SOAServicesInterfacePartner cannot be resovled.:
caused by: javax.naming.NameNotFoundException: Name comp/env/sca not found in context “java:”.
This problem looks pretty much the same as in IBM support note:
The following ejb reference is misssing in ejb-jar.xml:
<display-name>SCA Service Import Handler</display-name>
the same trick with refactoring the name of the import did not work – looking for workaround ….
The root cause for both problems were presense of Soap 1.2 bindings in .NET Web Service WSDL. Disabling Soap 1.2 did the trick…
Having to migrate to Vista, I took this opportunity to upgrade my Websphere Integration Developer to the latest and greatest WID 6.1.2 just released by IBM. And the first immediate problem I’ve encoutered – it just would not startup! Every try to start WID gets the error with printout of all the startup parameters:
JVM termintaed. Exit code =1
I have scanned all the newsgroups – apparently this problem existed before this release in other IBM and Eclipse based products. IBM support site suggests it may be due to the java cache and -Xshareclasses flag:
And numerous newsgroups publishing workarounds:
The solution for the new WID 6.1.2 was to clear out eclipse.ini from all the arguments leaving only 2 lines specifying the jdk to call:
And Wow – it’s starting up.
I have played with all the parameters by adding/removing them from eclipse.ini and the offending one was – Xmx1024m, specifying the maximum java heap. (decreasing it to 512m – helped in my case) Looks like launcher tries to start up few java processes and exhausted the RAM available on the laptop.
Anyways just clear out eclipse.ini and leave 2 line – it will work with defaults.