Thursday, 29 November 2012

IBM WebSphere Operational Decision Manager - Beans and Roles

In this post, I describe an issue that we saw with IBM WebSphere Operational Decision Management (WODM) 8.0.1, when attempting to use the Rules Execution Server (RES) Console.

We accessed the RES Console using the following URL: -

and logged in as the resAdmin user ( this user is in Active Directory, which is federated into the WAS cell ) and corresponding password.

However, when we clicked on the Diagnostics tab, and clicked the Run Diagnostics button: -

we saw exceptions against the XU MBean and Rule Session Second Execution processes: -

, with the following errors in SystemOut.log: - ADMN0022E: Access is denied for the notifyRulesetArchiveChanged operation on IlrXUManagement MBean because of insufficient or empty credentials.

and: -

Caused by: ADMN0022E: Access is denied for the getAdapterVersion operation on IlrXUManagement MBean because of insufficient or empty credentials.

We found a number of IBM Technotes and discussion forum posts on the problem, including this advice: -

The application server security is enabled but the Rule Execution Server users do not have the required administrative roles: 

If working with WebSphere Application Server or WebLogic, you must provide some level of administrative role to the Rule Execution Server admin user so that that user can access MBeans.

and this: -

This error indicates that security is enabled on the server and that the required roles have not been defined for the application.

Indeed, when security is enabled, DVS require all groups or users who are allowed to access it to be mapped to one of the two mandatory roles: resAdministrators or resDeployers.

For Rule Execution Server, those roles are: resAdministrators, resDeployers, and resMonitors.

For RTS: rtsAdministrator, rtsConfigManager, rtsInstaller, and rtsUser.

and this: -

Map your administrator group (resAdministrators by default) to the Monitor role in the WebSphere Application Server administration console.

This led us to believe that the user ( resAdmin ) wasn't in the right groups, so we spent time adding it to the resMonitors group, but to no avail. We started to think that the problem might be related to WAS <-> LDAP interactions, including group search base and filters.

Then we found this forum post: -

which said, in part: -

Did you map the resAdministrators group to the Monitor role?
To access the MBeans of the Rule Execution Server model, an application must have sufficient security credentials, restricted to the Monitor role in the WebSphere authentication system.
Rule Execution Server users can be given access to the MBeans of the model by configuring a mapping between the resAdministrators group declared in the custom registry and the Monitor role.
To map users to the Monitor role:
1. In the Integrated Solutions Console open Users and Groups > Administrative group roles.
2. Click Add. For Role(s) select Monitor, then click Search and move the entry beginning with resAdministrators from the Available column to the Mapped to role column.
Click OK.
3. Click the Save directly to the master configuration.
4. Open Users and Groups > Administrative user roles.
5. Click Add. For Role(s) select Monitor, then click Search. Move resAdmin from the Available column to the Mapped to role column.
Click OK.
6. Click the Save directly to the master configuration.
7. Restart your application server or your deployment manage

It then dawned on us.

As this is a clustered environment, the RES application needs to talk, via JMX, to the Deployment Manager and, therefore, the resAdmin user needs to be able to access the WAS administration MBeans.

Once we added the resAdministrators and resDeployers groups ( these are in LDAP ) into the WAS Administrative Group monitor role: -

and restarted the application server on which he RES Console runs, all was well :-)

DB2 UDB and Linux - Start Me Up - AGAIN

In this article, I run through the steps that I took to allow a DB2 UDB 9.7 instance to auto-start on Red Hat Enterprise Linux 6.3.

So I've blogged about DB2 autostart on a number of occasions, including: -

but I've just gone back through the steps again, having re-read my earlier posts, and also this IBM Technote: -

and this is precisely what I did: -

As root

$ cd /opt/ibm/db2/V9.7/bin/
./db2fmcu -u -p /opt/ibm/db2/V9.7/bin/db2fmcd 
$ ./db2fm -i db2inst1 -U
$ ./db2fm -i db2inst1 -u
$ ./db2fm -i db2inst1 -f on

As db2inst1

db2fm -s -S

which returns: -

Gcf module 'fault monitor' is NOT operable 
Gcf module '/home/instance_name/sqllib/lib/' state is AVAILABLE

As root

$ reboot

As db2inst1

$ db2fm -s -S

which returns: -

Gcf module 'fault monitor' state is AVAILABLE
Gcf module '/opt/ibm/db2/V9.7/lib64/' state is AVAILABLE

It took about 30 seconds for DB2 to start up, following the reboot, and I was a little impatient :-)

However, the database DID come up :-)

It's worth noting that, until I ran the command: -

./db2fmcu -u -p /opt/ibm/db2/V9.7/bin/db2fmcd 

I did not have the required DB2 Fault Monitor Command file - /etc/init/db2fmcd.conf - this file simply did not exist, and there was no mention of DB2FM in /etc/inittab, which has been deprecated in Red Hat 6.

However, once I ran this command ( as root, as above ), the file was created, with the following contents: -

$ cat /etc/init/db2fmcd.conf 

# DB2 fault monitor 
# Starts fmcd
# Note: any customizations to this file will be lost the next time this is updated

description 'Fault Monitor is the DB2 database facility that monitors DB2 database manager instances, and restarting any instance that exits permaturely.'
version 'DB2 v9.7.0.5'

start on stopped rc RUNLEVEL=[2345]
stop on starting rc RUNLEVEL=[016]

console output
respawn limit 10 120

exec /opt/ibm/db2/V9.7/bin/db2fmcd

and, unsurprisingly, the target db2fmcd binary also exists: -

$ ls -al /opt/ibm/db2/V9.7/bin/db2fmcd

-r-xr-xr-x 1 bin bin 145964 Nov 19 12:26 /opt/ibm/db2/V9.7/bin/db2fmcd

For the record, I'm running DB2 -

$ /opt/ibm/db2/V9.7/bin/db2level 

DB21085I  Instance "db2inst1" uses "64" bits and DB2 code release "SQL09075" 
with level identifier "08060107".
Informational tokens are "DB2 v9.7.0.5", "s111017", "IP23292", and Fix Pack 
Product is installed at "/opt/ibm/db2/V9.7".

on Red Hat Enterprise Linux 6.3: -

$ cat /etc/redhat-release 

Red Hat Enterprise Linux Server release 6.3 (Santiago)

Tuesday, 27 November 2012

IBM WebSphere Operational Decision Management 8.0.1 - Looking for JDBC drivers

In this post, I outline a problem that I saw when installing a new instance of IBM WebSphere Operational Decision Management (WODM), now known as IBM Operational Decision Management (ODM) v8.0.1.

Having installed and configured my (W)ODM environment, I was seeing JDBC driver-related errors when I started up my Decision Server and Decision Center clusters. This was on my client's Linux environment.

When I checked, the JDBC drivers weren't in their expected location - /opt/IBM/WebSphere/AppServer80/jdbcdrivers - which surprised me somewhat, as I'd NOT seen this problem on my own environment.

When I dug into the problem further, I discovered that the drivers are put into place by ONE of the THREE (W)ODM components - Business Space.

This is what I had installed on my own server: -

$ /opt/IBM/InstallationManager/eclipse/tools/imcl -silent -nosplash listInstalledPackages

When I dug further, on my own environment, I determined that the installations of Decision Center and Decision Server do NOT install the JDBC drivers into their correct location - it's the installation of Business Space that does that.

Given that I'm only installing Business Space onto the Decision Center nodes, that's a pain.

Of course, on my own single VM environment, I installed all THREE components, which is why I did not see the problem.

However, it was easy enough to work around - I simply TAR'd up the drivers from the Decision Center / Business Space box, and extracted them onto the Decision Server box.

Hope that helps :-)

Friday, 23 November 2012

NFS, Linux file permissions and IBM Installation Manager

In this post, I describe how I overcame an issue with IBM Installation Manager, observed when attempting to install IBM Operational Decision Manager v8 ( based on WebSphere Application Server v8 )  on Linux.

I had an interesting experience today - trying to install a WAS-based product using IBM Installation Manager, via a set of Unix shell scripts and response files. For ease of use, the scripts are located on a shared file system ( NFS ), mounted to the /mnt/filesystem location on one of FOUR Linux servers.

This allows me to re-use the same set of scripts, without needing to host them locally, and seemed like the most practical root (!).

The problem started when I executed one script which deletes and then repopulates the scripts from a central properties file.

When I ran this on server A, I was then suddenly unable to delete the file on server B. This pattern occurred on servers C and D as well.

In each case, I was using the same user local Linux ID - wasadmin and, on the NFS server ( from which the file system was exported ), the user that "really" owned the files had changed the ownership to wasadmin ( group wasadmins ).

I checked, and rechecked, the file permissions, both as wasadmin and as root, using chown and chmod, and everything looked OK - RWX.

Thankfully, the Linux admin came to the rescue.

When he checked the /etc/passwd file on each of the four servers, he noticed that, for two of the users, the Unique ID (UID) was set to 1003 and, for the other two boxes, the UID was 1004.

When he checked the "real" user on the NFS server, it had a UID of 1004.

That was the problem - despite the NFS server setting the file ownership of the files to wasadmin, the actual UID of the account owning the files is the key point - it was 1004.

So, for the two users who were unable to delete the files, we confirmed that they had the wrong UID - 1003.

Once we changed the two failing users to 1004, all was well.

I needed to run, as root, the chown command against the files that the two failing users had previously used/touched, including: -

/opt/IBM/InstallationManager ....

However, I found out, the hard way, that I also needed to do the same for IIM files in /tmp, such as /tmp/ciclogs_e1wasadmin.

Without this last step, I was seeing exceptions such as: - /tmp/ciclogs_e1wasadmin/ (Permission denied)

So, in summary, IF you've got multiple Linux ( or any other *Nix ) users needing full RWX access to files on a NFS server, you need to ensure that the UID of the user is consistent across the boxes AND the NFS server.

One of my colleagues said that this is especially important when using Automated Peer Recovery for Transaction files on NFS - the UID for wasadmin MUST be the same for both servers, or WAS on server A cannot read the transaction logs for server B, meaning that peer recover fails.

Wednesday, 21 November 2012

Using wsadmin to script the creation of a JDBC data source - using input parameters

In this article, I explain how I was able to create a wsadmin script, using the Jython language, to automate the creation of a JDBC data source, to allow WebSphere Application Server 8 to connect to DB2 UDB 9.7. I also highlight an exception that I kept on seeing ( for hours and hours and hours ) and how I resolved it ....

The requirement was to create a script that would be called from a Bash shell script, with input parameters, and would then create a data source, and the associated J2C alias and mapping.

In essence, it looked like this: -


provider_id=AdminConfig.getid('/Cell:E1DSCell/JDBCProvider:DB2 XA provider/')

dsid = AdminTask.createDatasource('provider_id, '[-name [Team Server Datasource] -jndiName jdbc/ilogDataSource -dataStoreHelperClassName -componentManagedAuthenticationAlias RES_db2conn -containerManagedPersistence false -xaRecoveryAuthAlias RES_db2conn -configureResourceProperties [[databaseName java.lang.String ' + str(databaseName) + '] [driverType java.lang.Integer ' + str(driverType) + '] [serverName java.lang.String ' + str(serverName) + '] [portNumber java.lang.Integer ' + portNumber + ']]') 

AdminConfig.create('MappingModule', dsid , '[[authDataAlias RES_db2conn [mappingConfigAlias ""]]')

However, when I executed it, I was seeing: -

$ /opt/IBM/WebSphere/AppServer80/profiles/E1DSDMNODE/bin/ -lang jython -user wasadmin -password passw0rd -f ~/ E1DSCELL RESDB 4 50000

WASX7209I: Connected to process "dmgr" on node E1DSDMNODENode using SOAP connector;  The type of process is: DeploymentManager
WASX7303I: The following options are passed to the scripting environment and are available as arguments that are stored in the argv variable: "[E1DSCELL, RESDB, 4,, 50000]"
WASX7017E: Exception received while running file "/home/wasadmin/"; exception information: java.lang.IllegalArgumentException: java.lang.IllegalArgumentException: WASX7122E: Expected "]"  not found. 
[-name [Team Server Datasource] -jndiName jdbc/ilogDataSource -dataStoreHelperClassName -componentManagedAuthenticationAlias RES_db2conn -containerManagedPersistence false -xaRecoveryAuthAlias RES_db2conn -configureResourceProperties [[databaseName java.lang.String RESDB] [driverType java.lang.Integer 4] [serverName java.lang.String] [portNumber java.lang.Integer 50000]]

WASX7341W: No "save" was performed before the interactive scripting session exited; configuration changes will not be saved.

It took me AGES to realise that the exception was actually coming from the AdminConfig.create() command: -

AdminConfig.create('MappingModule', dsid , '[[authDataAlias RES_db2conn [mappingConfigAlias ""]]')

rather than the the AdminTask.createDatasource() command, and that it was simply a syntax error on my part - I should have written: -

AdminConfig.create('MappingModule', dsid , '[[authDataAlias RES_db2conn] [mappingConfigAlias ""]]')

Obviously, I should've broken the script down into separate commands, but I got fixated on the AdminTask command, and spent hours hacking around with that :-)

For the record, I didn't actually NEED to use the str() command, as the input parameters were already strings - I've since changed the script to this: -

dsid = AdminTask.createDatasource(provider_id, '[-name [Team Server Datasource] -jndiName jdbc/ilogDataSource -dataStoreHelperClassName -componentManagedAuthenticationAlias RES_db2conn -containerManagedPersistence false -xaRecoveryAuthAlias RES_db2conn -configureResourceProperties [[databaseName java.lang.String ' + databaseName + '] [driverType java.lang.Integer ' + driverType + '] [serverName java.lang.String ' + serverName + '] [portNumber java.lang.Integer ' + portNumber + ']]') 

The moral of the story ? If you get exceptions from your Jython script, in the words of MC Hammer, BREAK IT DOWN :-)

Ah well, it's life up here on the learning curve, every day is a school day.

Monday, 19 November 2012

Using wsadmin to enable an LDAP Federated Repository in WebSphere Application Server 8.5

This article is somewhat of an aide memoire for me, allow me to remember how to enable WebSphere Application Server to talk to an LDAP server, without needing to use a GUI :-)

I pulled this together using my own WAS 8.5 VM running on RHEL 6.3, as ever, and a remote LDAP ( albeit IBM Tivoli Directory Server rather than Microsoft Active Directory ).

Start wsadmin client

$ cd /opt/IBM/WebSphere/AppServer/profiles/Dmgr01/bin
$ ./ -lang jython

List existing repositories

wsadmin> AdminTask.listIdMgrRepositories()

should return: -

'{InternalFileRepository={repositoryType=File, host=LocalHost}}'

Configure the Administrative User Registry ( assume that we're keeping the WAS admin in file-based registry )

wsadmin> AdminTask.configureAdminWIMUserRegistry('[-realmName defaultWIMFileBasedRealm -verifyRegistry false ]')

Add the LDAP server

wsadmin> AdminTask.createIdMgrLDAPRepository('[-default true -id LDAP1 -adapterClassName -ldapServerType IDS -sslConfiguration -certificateMapMode exactdn -supportChangeLog none -certificateFilter -loginProperties uid]') 

wsadmin> AdminTask.addIdMgrLDAPServer('[-id LDAP1 -host -port 389 -bindDN uid=8817222GB,c=gb,ou=bluepages, -bindPassword passw0rd! -referal ignore -sslEnabled false -ldapServerType IDS -sslConfiguration -certificateMapMode exactdn -certificateFilter]')

wsadmin> AdminTask.updateIdMgrLDAPRepository('[-id LDAP1 -loginProperties [""]]')

wsadmin> AdminTask.updateIdMgrLDAPRepository('[-id LDAP1 -adapterClassName -ldapServerType IDS -sslConfiguration -certificateMapMode exactdn -certificateFilter -supportChangeLog none -loginProperties uid]')

Add the Base Entries

wsadmin> AdminTask.addIdMgrRepositoryBaseEntry('[-id LDAP1 -name -nameInRepository]')

wsadmin> AdminTask.addIdMgrRealmBaseEntry('[-name defaultWIMFileBasedRealm -baseEntry]') 

Validate the Admin Name ( wasadmin in file-based registry )

wsadmin> AdminTask.validateAdminName('[-registryType WIMUserRegistry -adminUser wasadmin ]')

Enable Global Security and set Federated Repositories to be default

wsadmin> AdminTask.setAdminActiveSecuritySettings('[-activeUserRegistry WIMUserRegistry -enableGlobalSecurity true]')

Set the LDAP search filters

wsadmin> AdminTask.updateIdMgrLDAPEntityType('[-id LDAP1 -name PersonAccount -objectClasses inetOrgPerson -searchBases ou=bluepages, -searchFilter ]') 

Save changes


Validate changes

wsadmin> AdminTask.listIdMgrRepositories()

should return: -

'{InternalFileRepository={repositoryType=File, host=LocalHost}, LDAP1={repositoryType=LDAP, specificRepositoryType=IDS,}}'

wsadmin> AdminTask.listIdMgrRepositoryBaseEntries('[-id LDAP1]')

should return: -


That's it, that's all she wrote :-)

Thursday, 15 November 2012

WebSphere Application Server - Security is EVERYTHING

This is an excellent set of articles from two of my IBM colleagues, Martin Lansche and Keys Botzum.

Summary:  Security consists of more than just some firewalls at the edge of your network protecting you from the outside. It is a difficult and complex set of actions and procedures that strive to strengthen your systems as much as is appropriate. This article discusses many aspects of security in general, including the IBM® WebSphere® Application Server security architecture, and discusses hardening a WebSphere Application Server environment. 

Just waiting for part 2 of the latest article to come out .....

Tuesday, 13 November 2012

Creating a Remote Messaging, Remote Support and Web pattern (RMRSW) based Network Deployment environment for IBM Business Process Manager Standard Version 8.0

I'm in the midst of an IBM BPM implementation at the moment, working to deploy a combined Process Center / Process Server environment using IBM BPM Standard 8.0 ( as 8.0.1 isn't  yet available ). Therefore, this set of blog posts look to be terribly useful.

This blog entry walks you thru the step-by-step procedure to create a stand-alone Process Center server and a Remote Messaging, Remote Support and Web pattern-based network deployment environment for the Process Server. Setting this environment can be accomplished in many different ways and this blog post approaches the task in a simple, yet commonly used, methodology that is applicable for most platforms. We would love to hear your feedback and would appreciate it if you shared your own experience with us.

Definitely worth a read ...

Monday, 12 November 2012

Curing the Curly Cable Conniption

Thanks to the kind recommendation of a colleague, Mr Andy Barnes Esq., I've now made a good attempt to tame the rats' nest of wires that I typically carry around - along with a spoon and fork.

I picked up a neat bunch of cord wraps from Cargo ( in Newbury, although I'm sure that they have other outlets ) - they had a buy-two-get-one-free deal, so I paid £15.00 for six of the wraps, in three different sizes

So now I have this: -

which is far far better.

I may get a few more wraps next weekend, just for the odd rainy day ( or the acquisition of more gadgets == more cables ).

Thanks, Andy, good catch.

Friday, 9 November 2012

BPM = Blogs Pour Me // Business Process Management

In this article, I make reference to a new (to me) blog for the IBM Business Process Manager tool, as I continue to discover and, more importantly, bookmark / share resources for my new role in IBM Software Services for WebSphere (ISSW).

From the blog post: -

When you contact IBM Support, a Problem Management Record, or PMR, is opened to track your concern and its resolution. Many of those PMRs reference support documents that are used to resolve a specific issue. We are able to analyze those records to find issue trends that are affecting many of our IBM Business Process Manager customers. When we look at the top 10 most referenced support documents in PMRs, we find several of the MustGather documents. If you are not familiar with these documents, they explain the type of information that IBM Support needs to expedite the resolution of your issue. These documents include requests for information about your operating environment and requests for certain files that can help us diagnose your issue. The following MustGather documents are available to help us help you:

In addition to the "MustGather" documents, IBM Support Assistant Version 5.0 can help you determine the root cause of an issue and find possible documented resolutions. In fact, Version 5.0 Beta 2 was just released within the last few weeks of this post.


What's HOT in IBM Business Process Manager Support?

Whilst I'm at it, here's a few more blogs that I'm making more and more use of: -

Live Demos: IBM Operational Decision Manager

Live Demos: IBM Operational Decision Manager - Interactive Web demos every second Wednesday of the month

Join us for our monthly interactive Web demos. See the new face of business rules management in action.

Each month one of our technical experts provides an interactive walk-through of the new IBM Operational Decision Manager v8 product -- the next generation of business rules management capabilities.

This live demo and discussion forum is a good opportunity to see the new product capabilities in action - especially the new business user interface that features social media style collaboration. You can now manage and maintain business rules in an environment as familiar as your favorite social media tool:

- one that's intuitive, easy, fast and features social media style collaboration
- one that requires little to no training for subject matter experts.

Additional developments include enhanced Rules and Events Integration and Testing and Simulation on complex conditions to ensure the right intent is captured in the authored rules.

Come see why IBM ODM v8 and IBM ODM for z/OS v8 are our most consumable business rule management offerings yet.

Upcoming IBM ODM in Action demos

• November 14, Wednesday, 10:00am PST; 1:00pm ET - Sign up now
• December 12, Wednesday, 10:00am PST; 1:00pm ET - Sign up now

Thursday, 8 November 2012

IBM Business Process Manager - Defining the Environment

In this brief article, I outline how an IBM BPM cell ( nodes, clusters, Service Integration bus, databases etc. ) can be built using a Deployment Environment.

The Deployment Environment is, in effect, a template that can be created, exported, edited and applied across different BPM environments, allowing one environment to be used as a template or pattern for others.

Here's what the IBM documentation says: -

A deployment environment is a collection of configured clusters, servers, and middleware that collaborate to provide an environment to host software modules. For example, a deployment environment might include a host for message destinations, a processor or sorter of business events, and administrative programs.

So I have a template, and I want to apply it to my newly created WebSphere Application Server v8 cell ( a managed node, with a co-located Deployment Manager ).

Note that I'm running Windows - why ? Because I can .... Just for a change ....


(a) Edit Deployment Environment Definition file - in my case, c:\temp\BPM8Std.xml - to set: -


to: -


to avoid DB2 database tables being created whilst the Deployment Environment is being imported into, and applied to, the cell

(b) Change SOAP timeout from default of 180 in C:\IBM\WebSphere\AppServer\profiles\Dmgr01\properties\soap.client.props
- from to

(c) Backup profile directory - C:\IBM\WebSphere\AppServer\profiles

- This is a belt and braces approach to backups - other, better, approaches do exist

(d) Start wsadmin client: -

C:> cd C:\IBM\WebSphere\AppServer\profiles\Dmgr01\bin
C:> wsadmin.bat -lang jython

(e) Import and apply the Deployment Environment

wsadmin> AdminTask.importDeploymentEnvDef([ "-filePath", "c:\\temp\\BPM8Std.xml", "-topologyName", "BPM8Std"])
wsadmin> AdminTask.generateDeploymentEnv(["-topologyName", "BPM8Std"])

Note that the generateDeploymentEnvironment task may take some time - it took about 10 minutes on my VM

(f) Job done :-)

Thursday, 1 November 2012

IBM Worklight Server - Installation via a response file ( of course )

In this post, I briefly outline how I installed an IBM Worklight Server in about 10 minutes, via a small number of commands :-)

For my server, I'm using Red Hat Enterprise Linux 6.3 ( what else ) and the Enterprise version of the Worklight Server product.

I'm actually performing the installation as a non-root user ( wasadmin ) but one could choose to install as root ( ! ).

Me being me, I've downloaded BOTH versions: -

IBM Worklight Consumer Edition V5.0 zip of Installation Manager Repository for IBM Worklight Server Multiplatform English Only (CI88QEN)

-rw-r--r--. 1 501 games 146M Sep 25 17:35

IBM Worklight Enterprise Edition V5.0 zip of Installation Manager Repository for IBM Worklight Server Multiplatform English Only (CI88KEN)

-rw-r--r--. 1 501 games 146M Sep 25 13:18

I'd previously installed IBM Installation Manager 1.5 (IIM) using this command: -

/mnt/hgfs/WP8/Setup/IIM/linux_x86/userinstc -input ~/install_IIM.rsp -acceptLicense

as I was using it to prepare for a WebSphere Portal 8 installation ( see this blog post for more details ).

IIM can be downloaded from a variety of places, including this: -

Unpack Worklight

$ cd /tmp
mkdir WL
$ cd WL/
$ unzip /mnt/hgfs/Software/Worklight/ 

Record a response file

/opt/IBM/InstallationManager/eclipse/IBMIM -record install_WLEE.rsp -skipInstall skippy

which generates the following response file: -


<?xml version="1.0" encoding="UTF-8"?>
<!--The "acceptLicense" attribute has been deprecated. Use "-acceptLicense" command line option to accept license agreements.-->
<agent-input acceptLicense='true'>
<repository location='/tmp/WL/imf-offering/wee'/>
<profile id='Worklight' installLocation='/opt/IBM/Worklight'>
<data key='eclipseLocation' value='/opt/IBM/Worklight'/>
<data key='user.import.profile' value='false'/>
<data key='cic.selector.os' value='linux'/>
<data key='' value='gtk'/>
<data key='cic.selector.arch' value='x86_64'/>
<data key='' value='wasadmins'/>
<data key='user.database.preinstalled' value='false'/>
<data key='user.database.selection' value='derby'/>

<data key='user.appserver.was85liberty.preinstalled' value='false'/>
<data key='user.appserver.selection' value='was85liberty'/>
<data key='' value='en'/>
<install modify='false'>
<offering id='' version='' profile='Worklight' features='main.feature' installFixes='none'/>
<preference name='' value='/opt/IBM/IMShared'/>
<preference name='' value='30'/>
<preference name='' value='45'/>
<preference name='' value='0'/>
<preference name='offering.service.repositories.areUsed' value='true'/>
<preference name='' value='false'/>
<preference name='' value='false'/>
<preference name='http.ntlm.auth.kind' value='NTLM'/>
<preference name='http.ntlm.auth.enableIntegrated.win32' value='true'/>
<preference name='' value='true'/>
<preference name='' value='false'/>
<preference name='PassportAdvantageIsEnabled' value='false'/>
<preference name='' value='false'/>
<preference name='' value='false'/>
<preference name='' value='true'/>
<preference name='' value='true'/>
<preference name='' value='true'/>

Note the three highlighted lines; the first indicates the location of the Worklight repository, post the unpacking process ( /tmp/WL/imf-offering/wee/ ), the other two lines indicate the location into which Worklight is going to be installed.

In addition, note that, for my own purposes, I'm using Apache Derby ( this colour ) and WebSphere Application Server 8.5 Liberty Profile ( this colour ).

Of course, you can record your own response file, and choose to use an existing DB2 UDB 9.7, MySQL 5.1 or Oracle 11g installation, and also choose an existing ( installed ) version of WAS 7 or, perhaps, Tomcat 7 JEE server.

Perform the installation

/opt/IBM/InstallationManager/eclipse/IBMIM -input install_WLEE.rsp -acceptLicense -noSplash -silent

This took a few minutes, at the end of which Worklight is installed in /opt/IBM/Worklight.

To prove it, I started the server: -

/opt/IBM/Worklight/server/wlp/bin/server.bin start worklightServer

and then access the Worklight console: -

That's it for now.

For further information, here's the official IBM Worklight documentation: -

Enjoy !