webMethods - some useful internal services - 1

webmethods has added a service "wm.server.admin:getDiagnosticData". one can run this service from administrator UI. This service generates a zip file that contains all diagnostic information, as well as server logs.

Pretty useful stuff!!

I plan to add details on following additional services. I will appreciate if someone can help me in creating this content.
wm.server.query:getServiceStats
wm.server.soap:registerProcessor
wm.server.soap:unregisterProcessor
wm.server.ui:addMenu
wm.server.ui:addSolution
wm.server.ui:getMenuTabs
wm.server.ui:getMenus
wm.server.ui:mainMenu
wm.server.ui:removeMenu
wm.server.ui:removeSolution

webMethods flatfile adapter

A little tit-bit on flatfile adapter
If incoming file has .xml extension than XML adapter gets a "node" input object. If it has any other extension than "ffdata" input object is passed to target service. Three other useful parameters that are passed to file-polling target service are Content-type {java.lang.String}, originalFileName {java.lang.String}, and fileName {java.lang.String}
Content-Type is particularly useful. It depends on extension on incoming file. following are some of the extensions that I attempted.

extension	Content-type
*.txt	text/plain
*.dat	null
*.xml	text/xml
*.htm	text/html
*.zip	application/zip

I have not attempted other extensions but that will be worth trying. Please send me results for any other extensions that you try.

Using websphere MQ as a JNDI provider

After some struggle I could finally configure websphere MQ as a JNDI provider. First a simple question, why should one do it
0. For fun, and for your geek pride :-)
1. You usually need a JNDI provider where you store information about queues and destinations etc. You can use FSContext (file system context), or LDAP context. There is even an option where you hardcode queue names and can use NO_JNDI context!
2. File system context looks too "ungeeky", and to get more technical, file system usually is not a reliable thing when we try to configure highly available system, so LDAP context is usually best option.
3. IBM added an option that allows use of MQ Server itself as a JNDI provider. This implementation required support packs MS0B and MS01. IBM has since than merged these support packs in webSphere MQ 6.0.2.3 distribution.

You can test for availability of this option by following steps
1. open websphere MQ explorer
2. right click on JMS administered objects
3. Add (JNDI namespace "other", factory class "com.ibm.mq.jms.context.WMQInitialContextFactory", Required Libraries "mqcontext.jar, com.ibm.mq.pcf-6.0.3.jar, Path of your MQ Java/lib" directory, provider URL="host:port/SYSTEM.DEF.SVRCONN" - (or whatever your server connection channel is)
4. If you are confiugred correctly than you will be able to see your MQ series server objects.

I will add more as I try this further.