Saturday, 20 May 2017

Hmmm - ADMA5107E and CWWBA0008E seen whilst uninstalling a SCA module from IBM BPM Advanced 8.5.7

Hmmm, I started seeing this whilst attempting to remove an existing SCA module ( EAR file ) from a BPM Advanced 8.5.7 environment: -

[5/20/17 6:10:25:473 UTC] 0000013b UninstallSche I   ADMA5017I: Uninstallation of MQ_Test started.
[5/20/17 6:10:25:535 UTC] 0000013b DMAdapter     I com.ibm.ws.ffdc.impl.DMAdapter getAnalysisEngine FFDC1009I: Analysis Engine using data base: /opt/ibm/WebSphere/AppServer/properties/logbr/ffdc/adv/ffdcdb.xml
[5/20/17 6:10:25:616 UTC] 0000013b FfdcProvider  W com.ibm.ws.ffdc.impl.FfdcProvider logIncident FFDC1003I: FFDC Incident emitted on /opt/ibm/WebSphereProfiles/Dmgr01/logs/ffdc/dmgr_78f7b3ac_17.05.20_06.10.25.5262387762556679923990.txt com.ibm.ws.management.AdminServiceImpl.invoke 679
[5/20/17 6:10:25:652 UTC] 0000013b BPCAppMgmt    I   CWWBF0021I: Uninstall of process application MQ_Test completed.
[5/20/17 6:10:25:671 UTC] 0000013b FfdcProvider  W com.ibm.ws.ffdc.impl.FfdcProvider logIncident FFDC1003I: FFDC Incident emitted on /opt/ibm/WebSphereProfiles/Dmgr01/logs/ffdc/dmgr_78f7b3ac_17.05.20_06.10.25.669165681660585464853.txt com.ibm.ws.management.application.AppUtils.getMessage 715
[5/20/17 6:10:25:673 UTC] 0000013b FfdcProvider  W com.ibm.ws.ffdc.impl.FfdcProvider logIncident FFDC1003I: FFDC Incident emitted on /opt/ibm/WebSphereProfiles/Dmgr01/logs/ffdc/dmgr_78f7b3ac_17.05.20_06.10.25.6728117628847154269247.txt com.ibm.ws.management.application.task.ConfigRepoHelper.getDesiredEarFileFromBinaries 804
[5/20/17 6:10:25:675 UTC] 0000013b FfdcProvider  W com.ibm.ws.ffdc.impl.FfdcProvider logIncident FFDC1003I: FFDC Incident emitted on /opt/ibm/WebSphereProfiles/Dmgr01/logs/ffdc/dmgr_78f7b3ac_17.05.20_06.10.25.6741709013655431538129.txt com.ibm.ws.management.application.task.ConfigRepoHelper.getDesiredEarFileFromBinaries 814
[5/20/17 6:10:25:678 UTC] 0000013b FfdcProvider  W com.ibm.ws.ffdc.impl.FfdcProvider logIncident FFDC1003I: FFDC Incident emitted on /opt/ibm/WebSphereProfiles/Dmgr01/logs/ffdc/dmgr_78f7b3ac_17.05.20_06.10.25.676378039060005473378.txt com.ibm.ws.sca.internal.deployment.SCAUninstallTask 001
[5/20/17 6:10:25:699 UTC] 0000013b FfdcProvider  W com.ibm.ws.ffdc.impl.FfdcProvider logIncident FFDC1003I: FFDC Incident emitted on /opt/ibm/WebSphereProfiles/Dmgr01/logs/ffdc/dmgr_78f7b3ac_17.05.20_06.10.25.6783939092327342589718.txt com.ibm.ws.management.application.SchedulerImpl.run 328
[5/20/17 6:10:25:703 UTC] 0000013b UninstallSche I   ADMA5107E: The application MQ_Test cannot be uninstalled.


 /opt/ibm/WebSphereProfiles/Dmgr01/logs/ffdc/dmgr_78f7b3ac_17.05.20_06.10.25.5262387762556679923990.txt

[5/20/17 6:10:25:529 UTC]     FFDC Exception:javax.management.MBeanException SourceId:com.ibm.ws.management.AdminServiceImpl.invoke ProbeId:679 Reporter:com.ibm.ws.management.AdminServiceImpl$1@7c861ea7
javax.management.MBeanException: Exception thrown in RequiredModelMBean while trying to invoke operation getProcessTemplateState
        at javax.management.modelmbean.RequiredModelMBean.invokeMethod(RequiredModelMBean.java:1304)
        at javax.management.modelmbean.RequiredModelMBean.invoke(RequiredModelMBean.java:1093)
        at com.sun.jmx.interceptor.DefaultMBeanServerInterceptor.invoke(DefaultMBeanServerInterceptor.java:832)
        at com.sun.jmx.mbeanserver.JmxMBeanServer.invoke(JmxMBeanServer.java:814)
        at com.ibm.ws.management.AdminServiceImpl$1.run(AdminServiceImpl.java:1350)
        at com.ibm.ws.security.util.AccessController.doPrivileged(AccessController.java:118)
        at com.ibm.ws.management.AdminServiceImpl.invoke(AdminServiceImpl.java:1243)
        at com.ibm.ws.management.connector.AdminServiceDelegator.invoke(AdminServiceDelegator.java:181)
        at com.ibm.ws.management.connector.ipc.CallRouter.route(CallRouter.java:247)
        at com.ibm.ws.management.connector.ipc.IPCConnectorInboundLink.doWork(IPCConnectorInboundLink.java:360)
        at com.ibm.ws.management.connector.ipc.IPCConnectorInboundLink$IPCConnectorReadCallback.complete(IPCConnectorInboundLink.java:602)
        at com.ibm.ws.ssl.channel.impl.SSLReadServiceContext$SSLReadCompletedCallback.complete(SSLReadServiceContext.java:1820)
        at com.ibm.ws.tcp.channel.impl.AioReadCompletionListener.futureCompleted(AioReadCompletionListener.java:175)
        at com.ibm.io.async.AbstractAsyncFuture.invokeCallback(AbstractAsyncFuture.java:217)
        at com.ibm.io.async.AsyncChannelFuture.fireCompletionActions(AsyncChannelFuture.java:161)
        at com.ibm.io.async.AsyncFuture.completed(AsyncFuture.java:138)
        at com.ibm.io.async.ResultHandler.complete(ResultHandler.java:204)
        at com.ibm.io.async.ResultHandler.runEventProcessingLoop(ResultHandler.java:775)
        at com.ibm.io.async.ResultHandler$2.run(ResultHandler.java:905)
        at com.ibm.ws.util.ThreadPool$Worker.run(ThreadPool.java:1892)
Caused by: com.ibm.bpe.api.ProcessTemplateNotFoundException: CWWBA0008E: Process template 'processMessage. Tue 2017-05-16 18:11:58.000' is not found.


There wasn't a corresponding Process Template showing up in the BPC Explorer: -



even whilst logged in as the Deployment Environment super-user, deAdmin.

I'd tried the obvious - stopping the entire DE - Cluster Members, Node Agent, Deployment Manager etc. - but to no avail.

I even tried removing the wstemp directory from within the DM's profile, but again no dice.

Working on the assumption that the problem was in the WAS rather than BPM world ( because BPC Explorer showed no template ), I took the nuclear option of removing the JEE application from the DM configuration: -

cd /opt/ibm/WebSphereProfiles/Dmgr01/config/cells/PSCell1/applications
rm -Rf MQ_Test.ear/

restarted the Deployment Manager, and forcibly resynced the node: -

/opt/ibm/WebSphereProfiles/Dmgr01/bin/wsadmin.sh -lang jython -user wasadmin -password passw0rd

AdminControl.invoke('WebSphere:name=repository,process=nodeagent,platform=common,node=Node1,version=5.0,type=ConfigRepository,mbeanIdentifier=repository,cell=PSCell1,spec=1.0', 'refreshRepositoryEpoch')
AdminControl.invoke('WebSphere:name=cellSync,process=dmgr,platform=common,node=Dmgr,version=8.5.5.11,type=CellSync,mbeanIdentifier=cellSync,cell=PSCell1,spec=1.0', 'syncNode', '[Node1]')

Having done the latter, the app disappeared from the All Applications view: -


and, more importantly, I was then able to install a fresh copy of the SCA module: -

AdminApp.install('/tmp/'+AppName+'.ear', '[ -nopreCompileJSPs -distributeApp -nouseMetaDataFromBinary -nodeployejb -appname '+AppName+' -createMBeansForResources -noreloadEnabled -nodeployws -validateinstall warn -processEmbeddedConfig -filepermission .*\.dll=755#.*\.so=755#.*\.a=755#.*\.sl=755 -noallowDispatchRemoteInclude -noallowServiceRemoteInclude -asyncRequestDispatchType DISABLED -nouseAutoLink -noenableClientModule -clientMode isolated -novalidateSchema -MapResRefToEJB [[ '+AppName+'Web "" '+AppName+'Web.war,WEB-INF/web.xml sca/resource/export/readTheMessage_MQEXPORT_CF javax.jms.ConnectionFactory jms/'+conFact+' "" "" "" ] -MapModulesToServers [[ MQ_TestWeb MQ_TestWeb.war,WEB-INF/web.xml WebSphere:cell='+cellID+',cluster='+clusterName+' ]]]')
AdminConfig.save()
AdminNodeManagement.syncActiveNodes()


and start the application: -

AdminControl.invoke('WebSphere:name=ApplicationManager,process=AppClusterMember1,platform=proxy,node=Node1,version=8.5.5.11,type=ApplicationManager,mbeanIdentifier=ApplicationManager,cell=PSCell1,spec=1.0', 'startApplication', '[MQ_Test]')

which is always nice :-)

WebSphere to WebSphere - Problems with WAS to MQ Server Connection Channel

This was driving me batty  for a few hours, until I really focused on the problem.

This was what I was seeing in WAS: -

/opt/ibm/WebSphereProfiles/AppSrv01/logs/AppClusterMember1/SystemOut.log

...
     Caused by [5] --> Message : com.ibm.mq.jmqi.JmqiException: CC=2;RC=2397;AMQ9641: Remote CipherSpec error for channel 'TESTQMGR.SVRCONN' to host ''. [3=TESTQMGR.SVRCONN]
...
com.ibm.msg.client.jms.DetailedJMSException: JMSWMQ0018: Failed to connect to queue manager 'TESTQM' with connection mode 'Client' and host name 'mq75.novalocal(1420)'.
com.ibm.mq.MQException: JMSCMQ0001: WebSphere MQ call failed with compcode '2' ('MQCC_FAILED') reason '2397' ('MQRC_JSSE_ERROR').
com.ibm.mq.jmqi.JmqiException: CC=2;RC=2397;AMQ9204: Connection to host 'mq75.novalocal(1420)' rejected. [1=com.ibm.mq.jmqi.JmqiException[CC=2;RC=2397;AMQ9641: Remote CipherSpec error for channel 'TESTQMGR.SVRCONN' to host ''. [3=TESTQMGR.SVRCONN]],3=mq75.novalocal(1420),5=RemoteConnection.analyseErrorSegment]
com.ibm.mq.jmqi.JmqiException: CC=2;RC=2397;AMQ9641: Remote CipherSpec error for channel 'TESTQMGR.SVRCONN' to host ''. [3=TESTQMGR.SVRCONN]

...
[5/19/17 13:59:53:500 UTC] 00000119 SystemOut     O <?xml version="1.0" encoding="UTF-8"?>
<p:theMessage xmlns:p="http://SCA_Test" xmlns:ns0="http://SCA_Test" xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance" xsi:type="p:theMessage"/>SCA
[5/19/17 13:59:53:500 UTC] 00000119 SystemOut     O 
[5/19/17 13:59:53:517 UTC] 00000119 ProcessEngine I   CWWBE0003E: A runtime fault was returned by the implementation of activity 'Invoke'.
        com.ibm.msg.client.jms.DetailedJMSException: JMSWMQ0018: Failed to connect to queue manager 'TESTQM' with connection mode 'Client' and host name 'mq75.novalocal(1420)'.
[5/19/17 13:59:53:531 UTC] 00000119 SibMessage    W   [:] CWSJY0003W: JMSCC0109: A message driven bean threw a runtime exception '
                       Message : com.ibm.websphere.sca.ServiceRuntimeException: com.ibm.bpe.api.RuntimeFaultException: CWWBE0003E: A runtime fault was returned by the implementation of activity 'Invoke'.: caused by: com.ibm.bpe.api.RuntimeFaultException: CWWBE0003E: A runtime fault was returned by the implementation of activity 'Invoke'.
                         Class : class com.ibm.websphere.sca.ServiceRuntimeException

...
     Caused by [1] --> Message : com.ibm.bpe.api.RuntimeFaultException: CWWBE0003E: A runtime fault was returned by the implementation of activity 'Invoke'.
...

and in MQ: -

/var/mqm/qmgrs/TESTQM/errors/AMQERR01.LOG

AMQ9639: Remote channel 'TESTQMGR.SVRCONN' did not specify a CipherSpec.

EXPLANATION:
Remote channel 'TESTQMGR.SVRCONN' did not specify a CipherSpec when the local
channel expected one to be specified.

The remote host is 'bpm857 (10.72.0.6)'.

The channel did not start.
ACTION:
Change the remote channel 'TESTQMGR.SVRCONN' on host 'bpm857 (10.72.0.6)' to
specify a CipherSpec so that both ends of the channel have matching
CipherSpecs.


The problem was, as ever, between he chair and the keyboard ( PEBCAK ).

I revisited my Jython script and realised where I'd gone wrong.

Whilst I had created a dedicated SSL configuration to reflect the TLS version ( 1.2 ) and SSL cipher specification ( SSL_RSA_WITH_AES_128_CBC_SHA256 ) I'd obviously been tinkering with the WAS configuration at some point post-execution.

I re-ran my script: -

cellID=AdminControl.getCell()
queueName="TESTQ"
queueManager="TESTQM"
wasUser="wasadmin"
wasPassword="passw0rd"
actSpec="TESTQ_AS"
channelName="TESTQMGR.SVRCONN"
qmgrHostname="mq75.novalocal"
qmgrPortNumber="1420"
configAlias="WAS_to_WMQ"
cipher="SSL_RSA_WITH_AES_128_CBC_SHA256"

AdminTask.createSSLConfig('[-alias '+configAlias+' -type JSSE -scopeName (cell):'+cellID+' -keyStoreName CellDefaultKeyStore -keyStoreScopeName (cell):'+cellID+' -trustStoreName CellDefaultTrustStore -trustStoreScopeName (cell):'+cellID+'  -jsseProvider IBMJSSE2 -sslProtocol TLSv1.2 -clientAuthentication false -clientAuthenticationSupported false -securityLevel HIGH -enabledCiphers '+cipher+' ]')

AdminTask.createDynamicSSLConfigSelection('[-dynSSLConfigSelectionName '+configAlias+' -scopeName (cell):'+cellID+' -dynSSLConfigSelectionDescription '+configAlias+' -dynSSLConfigSelectionInfo *,'+qmgrHostname+','+qmgrPortNumber+' -sslConfigName '+configAlias+' -sslConfigScope (cell):'+cellID+' -certificateAlias ]')

AdminConfig.save()
AdminNodeManagement.syncActiveNodes()


and things started working.

Thursday, 18 May 2017

IBM Integration Bus - Tinkering with WebAdmin permissions

This came up in a conversation with one of my team earlier.

In brief, it's possible to configure the IIB 10 Web Admin UI to be protected by a user ID / password.

This is what I did: -

Define a user ID, password and role - iibadmins

mqsiwebuseradmin TESTNODE_iibadmin -c -u davehay -a passw0rd -r iibadmins

Grant the appropriate permissions to the iibadmins role

mqsichangefileauth TESTNODE_iibadmin -r iibadmins -p all+

Stop the Integration Node

mqsistop TESTNODE_iibadmin

Enable the file-based authentication / authorisation

mqsichangeauthmode TESTNODE_iibadmin -s active -m file

Start the Integration Node

mqsistart TESTNODE_iibadmin

For reference: -



IBM Integration Bus - Modifying the Listener Ports for the HTTPConnector

One of my colleagues was endeavouring to change the port on which the HTTPConnector object listens within an IBM Integration Bus 10 environment.

In the past, she'd have run this command: -

mqsichangeproperties TESTNODE_iibadmin -e default -o HTTPConnector -n 8000

and then used this command to check: -

mqsireportproperties TESTNODE_iibadmin -e default -o HTTPConnector -r

However, she was finding that the port didn't change.

We dug into the documentation, and found this: -

You must use the explicitlySetPortNumber attribute, because the port attribute no longer works.


I validated this on my own IIB 10.0.0.8 box: -

Confirm the port on which it is listening

netstat -aon | grep LISTEN

tcp        0      0 0.0.0.0:22              0.0.0.0:*               LISTEN      off (0.00/0/0)
tcp        0      0 127.0.0.1:25            0.0.0.0:*               LISTEN      off (0.00/0/0)
tcp        0      0 127.0.0.1:11883         0.0.0.0:*               LISTEN      off (0.00/0/0)
tcp6       0      0 :::111                  :::*                    LISTEN      off (0.00/0/0)
tcp6       0      0 :::8080                 :::*                    LISTEN      off (0.00/0/0)
tcp6       0      0 :::22                   :::*                    LISTEN      off (0.00/0/0)
tcp6       0      0 ::1:25                  :::*                    LISTEN      off (0.00/0/0)
tcp6       0      0 :::8443                 :::*                    LISTEN      off (0.00/0/0)
tcp6       0      0 :::4414                 :::*                    LISTEN      off (0.00/0/0)
tcp6       0      0 :::8000                 :::*                    LISTEN      off (0.00/0/0)
tcp6       0      0 ::1:11883               :::*                    LISTEN      off (0.00/0/0)

Changed the port from 8000 to 9000

mqsichangeproperties TESTNODE_iibadmin -e default -o HTTPConnector -n explicitlySetPortNumber -v 9000

BIP8071I: Successful command completion. 

Restart the Integration Service ( fka Execution Group )

mqsistopmsgflow TESTNODE_iibadmin -e default

BIP1188I: Stopping the integration server 'default'...
BIP1189I: The integration server 'default' is reported as stopped.
BIP8071I: Successful command completion.


mqsistartmsgflow TESTNODE_iibadmin -e default

BIP1186I: Starting the integration server 'default'...
BIP1187I: The integration server 'default' is reported as started.
BIP8071I: Successful command completion.


Confirm the port on which it is listening

netstat -aon | grep LISTEN

tcp        0      0 0.0.0.0:111             0.0.0.0:*               LISTEN      off (0.00/0/0)
tcp        0      0 0.0.0.0:22              0.0.0.0:*               LISTEN      off (0.00/0/0)
tcp        0      0 127.0.0.1:25            0.0.0.0:*               LISTEN      off (0.00/0/0)
tcp        0      0 127.0.0.1:11883         0.0.0.0:*               LISTEN      off (0.00/0/0)
tcp6       0      0 :::111                  :::*                    LISTEN      off (0.00/0/0)
tcp6       0      0 :::8080                 :::*                    LISTEN      off (0.00/0/0)
tcp6       0      0 :::22                   :::*                    LISTEN      off (0.00/0/0)
tcp6       0      0 ::1:25                  :::*                    LISTEN      off (0.00/0/0)
tcp6       0      0 :::8443                 :::*                    LISTEN      off (0.00/0/0)
tcp6       0      0 :::4414                 :::*                    LISTEN      off (0.00/0/0)
tcp6       0      0 :::9000                 :::*                    LISTEN      off (0.00/0/0)
tcp6       0      0 ::1:11883               :::*                    LISTEN      off (0.00/0/0)


Validate the Configuration

mqsireportproperties TESTNODE_iibadmin -e default -o HTTPConnector -r

HTTPConnector
  uuid='HTTPConnector'
  userTraceLevel='none'
  traceLevel='none'
  userTraceFilter='none'
  traceFilter='none'
  port='9000'
  address=''
  maxPostSize=''
  acceptCount=''
  compressableMimeTypes=''
  compression=''
  connectionLinger=''
  connectionTimeout=''
  maxHttpHeaderSize=''
  maxKeepAliveRequests='0'
  maxThreads=''
  minSpareThreads=''
  noCompressionUserAgents=''
  restrictedUserAgents=''
  socketBuffer=''
  tcpNoDelay='true'
  explicitlySetPortNumber='9000'
  enableLookups=''
  enableMQListener=''
  shutdownDelay=''
  allowCrossConnectorPolling=''
  autoRespondHTTPHEADRequests=''
  integratedWindowsAuthentication=''
  iwaTimeoutSeconds='300'
  serverName=''
  corsEnabled='false'
  corsAllowOrigins='*'
  corsAllowCredentials='false'
  corsExposeHeaders='Content-Type'
  corsMaxAge='-1'
  corsAllowMethods='GET,HEAD,POST,PUT,PATCH,DELETE,OPTIONS'
  corsAllowHeaders='Accept,Accept-Language,Content-Language,Content-Type'
  Connector
    port='9000'
    type='Embedded'

    URLRegistration
      url='/Canary'
      outstandingRequests='0'
      UsedBySOAPNNodes='TRUE'
      UsedByHTTPNNodes='FALSE'
      nodeLabel='SOAP Input'
        flowLabel='gen.Canary'

BIP8071I: Successful command completion. 


Note that I've also configured my Integration Server to use the Embedded HTTP Listener: -

mqsichangeproperties TESTNODE_iibadmin -e default -o ExecutionGroup -n httpNodesUseEmbeddedListener -v true 

as evidenced above.

Sources: -




Monday, 15 May 2017

WebSphere Liberty Collectives - Problems with the FileService MBean

I kept seeing this exception: -

[15/05/17 09:16:25:071 BST] 0000031d com.ibm.ws.filetransfer.internal.mbean.FileService           E CWWKX7900E: Access denied to the /opt/IBM/wlp path.

in my Liberty Collective Controller's log: -

/opt/IBM/work/servers/cc/logs/messages.log

even though I'd configured the appropriate permission using the remoteFileAccess stanza in my include.xml : -

     <remoteFileAccess>
              <readDir>/tmp/nodejsApplications</readDir>
              <readDir>${wlp.install.dir</readDir>
              <readDir>${wlp.user.dir}</readDir>
              <readDir>${server.output.dir}</readDir>
              <writeDir>${server.config.dir}</writeDir>
              <writeDir>/tmp/nodejsApplications</writeDir>
     </remoteFileAccess>


The exception popped up each time I accessed the Collective Controller: -

https://cc1.uk.ibm.com:9443/ibm/adminCenter/serverConfig-1.0/#serverConfig/cc1.uk.ibm.com,/opt/IBM/work,cc/${server.config.dir}/server.xml

Can you see where I went wrong ?

I had: -

              <readDir>${wlp.install.dir</readDir>

rather than: -

              <readDir>${wlp.install.dir}</readDir>

In other words, I'd forgotten the closing brace.

Interestingly, Liberty didn't seem to complain as, I guess, the XML was valid, even though the data within the stanza was incorrect.

Now sorted ….

For the record, I'm running the latest version of Liberty: -

/opt/IBM/wlp/bin/server version

WebSphere Application Server 17.0.0.1 (1.0.16.cl170120170227-0220) on IBM J9 VM, version pxa6480sr3fp12-20160919_01 (SR3 FP12) (en_GB)

and I'm tinkering with Collectives in the context of IBM API Connect, where I'm using the Liberty Collective Controller with a Node.JS runtime.

Saturday, 13 May 2017

macOS Sierra and Apple Mail - Tinkering with Mail Signatures

On behalf of a friend, I've been tinkering with the signatures in  Mail, as included with macOS Sierra 10.12.4.

Things have changed since last I tried this, most importantly that it's not easy to add a HTML signature ( with fonts, images, links etc. ).

Thankfully, this blog helped: -


There are plenty of tutorials online to create an HTML signature in Apple Mail with older versions of OS X, and you have probably already seen one of my own tutorials on how to add HTML Signatures in Lion, Mountain Lion, iOS 7, Mavericks or Yosemite, El Capitan, but the process has changed ever so slightly for the new OS X Sierra (10.12). Here is how to do it:

The most important thing to remember is that the signature HTML file is stored in a so-called "secret" or hidden location: -

/Users/davidhay/Library/Mail/V4/MailData/Signatures

although, apparently, it may also be held on iCloud Drive.

These are the three files that I have: -

ls -l

total 24
-rw-r--r--@ 1 davidhay  staff  1117 13 May 17:28 AAB3F8DA-A379-44E7-A399-E976B2BFB2D1.mailsignature
-rw-r--r--@ 1 davidhay  staff   430 13 May 16:20 AccountsMap.plist
-rw-r--r--@ 1 davidhay  staff   385 13 May 16:15 AllSignatures.plist


meaning that I "merely" needed to edit the .mailsignature file: -

atom /Users/davidhay/Library/Mail/V4/MailData/Signatures/AAB3F8DA-A379-44E7-A399-E976B2BFB2D1.mailsignature 

and modify the <body> section: -

<body>
<table>
<tbody>

</tbody>
</table>
</body>


inserting my custom HTML ( created using Eclipse ).

As per the other blog, I did need to leverage: -

chflags uchg AAB3F8DA-A379-44E7-A399-E976B2BFB2D1.mailsignature 

and: -

chflags nouchg AAB3F8DA-A379-44E7-A399-E976B2BFB2D1.mailsignature 

to lock and unlock the file.

Now to see whether my "customer" likes her signature ...

Thursday, 11 May 2017

Doh, WebSphere Liberty Profile, still getting it wrong ...

I saw this from my Liberty runtime today: -

...
[AUDIT   ] CWWKT0016I: Web application available (default_host): http://e88e0bcb807d:9080/IBMJMXConnectorREST/
[AUDIT   ] CWWKT0016I: Web application available (default_host): http://e88e0bcb807d:9080/ibm/api/collective/notify/
[AUDIT   ] CWWKT0016I: Web application available (default_host): http://e88e0bcb807d:9080/ibm/adminCenter/deploy-1.0/
[AUDIT   ] CWWKT0016I: Web application available (default_host): http://e88e0bcb807d:9080/ibm/adminCenter/serverConfig-1.0/
[AUDIT   ] CWWKT0016I: Web application available (default_host): http://e88e0bcb807d:9080/ibm/api/
[AUDIT   ] CWWKT0016I: Web application available (default_host): http://e88e0bcb807d:9080/ibm/adminCenter/explore-1.0/
[AUDIT   ] CWWKT0016I: Web application available (default_host): http://e88e0bcb807d:9080/adminCenter/
[AUDIT   ] CWWKS9104A: Authorization failed for user admin while invoking com.ibm.ws.management.security.resource on /. The user is not granted access to any of the required roles: [Administrator].

...

because I had forgotten to set up my server.xml properly: -

<?xml version="1.0" encoding="UTF-8"?>
<server description="Default server">

    <featureManager>
        <feature>javaee-7.0</feature>
        <feature>adminCenter-1.0</feature>
        <feature>scalingController-1.0</feature>
    </featureManager>

    <keyStore password="passw0rd"/> 
    
    <basicRegistry id="basic" realm="customRealm">
        <user name="admin" password="passw0rd" />
    </basicRegistry>

    <administrator-role>
         <user>admin</user>
    </administrator-role>

    <httpEndpoint id="defaultHttpEndpoint"
                  host="*"
  httpPort="9080"
                  httpsPort="9443" />
                  
    <applicationManager autoExpand="true"/>

</server>


specifically I didn't have a user registry (!) or a user to whom to assign the Administrator role.

Can you say "Doofus" ?

For the record, this is how I start / use Liberty ( which is running in a Docker Container ): -

foobar=`docker run -d -t -p 80:9080 -p 443:9443 websphere-liberty:latest`
docker cp server.xml $foobar:/opt/ibm/wlp/usr/servers/defaultServer
docker exec -i -t $foobar /bin/bash

/opt/ibm/wlp/bin/server stop defaultServer

docker start $foobar
docker logs $foobar -f






Tuesday, 25 April 2017

WebSphere Application Server Log Watcher: Using TrapIt.ear to watch for WebSphere Application Server events

Found this whilst looking for something completely different: -

Problem(Abstract)

While investigating a problem with WebSphere Application Server, you may need to watch for events such as messages to the SystemOut.log and take action when they occur.

Resolving the problem

The TrapIt.ear provides an easy way to perform actions based on events(message ids) in the WebSphere Application Server or based on time. If you need to monitor files (for example SystemOut.log, ffdcs, application or operating system logs, and the like), use the trapit shell script for UNIX and Linux systems.

Friday, 21 April 2017

WebSphere MQ - Advanced Message Security - Some tinkering and AMQ9021

This is the first of a few posts about my voyage of discovery with WebSphere MQ ( now IBM MQ ) Advanced Message Security (AMS), in the context of message authentication and encryption.

Thus far, I've broken it twice :-)

I'm following this tutorial: -


and was able to successfully send messages from Alice to Bob, via a MQ Queue Manager.

However, I did hit two exceptions: -

/opt/ibm/mqm/samp/bin/amqsput TESTQ TESTQM

Sample AMQSPUT0 start
target queue is TESTQ
MQOPEN ended with reason code 2063
unable to open queue for output
Sample AMQSPUT0 end


The Queue Manager log gave me the queue: -

cat /var/mqm/qmgrs/TESTQM/errors/AMQERR01.LOG 

04/21/2017 04:35:27 PM - Process(27379.1) User(alice) Program(amqsput)
                    Host(bpm857.novalocal) Installation(Installation2)
                    VRMF(7.5.0.2) QMgr(TESTQM)
                   
AMQ9021: An error occured during the certificate import for the following DN:
CN=bpm857.novalocal,OU=PSCell1,OU=Dmgr,O=IBM,C=US, result: 60

EXPLANATION:
The distinguished name is not present in the keystore or invalid.

AMQ9070: The WebSphere MQ security policy interceptor failed to validate a
certificate.

EXPLANATION:
The WebSphere MQ security policy interceptor could not validate a certificate.

...

This seen when attempting to send a message as user Alice.

In the first instance, this was occurring because I'd put the Personal Certificate for my WAS cell: -

"CN=bpm857.novalocal,OU=PSCell1,OU=Dmgr,O=IBM,C=US"

into the MQ Security Policy: -

setmqspl -m $QMGR -p $Q -s SHA1 -a "CN=alice,O=IBM,C=GB" -e AES256 -r "CN=bob,O=IBM,C=GB" -r "CN=bpm857.novalocal,OU=PSCell1,OU=Dmgr,O=IBM,C=US"

rather than the Signer Certificate: -

setmqspl -m $QMGR -p $Q -s SHA1 -a "CN=alice,O=IBM,C=GB" -e AES256 -r "C=US, O=IBM, OU=Dmgr, OU=PSCell1, OU=Root Certificate, CN=bpm857.novalocal"

I'd pulled the Subject DN of the certificate via openssl : -

openssl x509 -in /tmp/was_ca.arm -text -noout

...
Certificate:
    Data:
        Version: 3 (0x2)
        Serial Number: 728601959222 (0xa9a40f9b36)
    Signature Algorithm: sha256WithRSAEncryption
        Issuer: C=US, O=IBM, OU=Dmgr, OU=PSCell1, OU=Root Certificate, CN=bpm857.novalocal
        Validity
            Not Before: Mar 12 07:12:08 2017 GMT
            Not After : Mar  8 07:12:08 2032 GMT
        Subject: C=US, O=IBM, OU=Dmgr, OU=PSCell1, OU=Root Certificate, CN=bpm857.novalocal
        Subject Public Key Info:
            Public Key Algorithm: rsaEncryption
                Public-Key: (2048 bit)


It was also necessary to add the Signer Certificate into Alice's key store: -

/opt/ibm/mqm/bin/runmqakm -cert -add -db /home/alice/.mqs/alicekey.kdb -pw passw0rd -label CN=BPM857 -file /tmp/was_ca.arm 

Once I did this, I hit another problem: -

04/21/2017 04:58:28 PM - Process(28212.1) User(alice) Program(amqsput)
                    Host(bpm857.novalocal) Installation(Installation2)
                    VRMF(7.5.0.2) QMgr(TESTQM)
                   
AMQ9021: An error occured during the certificate import for the following DN:
CN=bpm857.novalocal,OU=PSCell1,OU=Dmgr,O=IBM,C=US, result: 57

EXPLANATION:
The distinguished name is not present in the keystore or invalid.

...

The solution wasn't too difficult to find …

I'd added the Signer Certificate into the MQ Security Policy in the wrong format.

I'd added this: -

C=US, O=IBM, OU=Dmgr, OU=PSCell1, OU=Root Certificate, CN=bpm857.novalocal

rather than this: -

CN=bpm857.novalocal, OU=Root Certificate, OU=PSCell1, OU=Dmgr, O=IBM, C=US

i.e.

setmqspl -m $QMGR -p $Q -s SHA1 -a "CN=alice,O=IBM,C=GB" -e AES256 -r "CN=bob,O=IBM,C=GB" -r "CN=bpm857.novalocal, OU=Root Certificate, OU=PSCell1, OU=Dmgr, O=IBM, C=US"

Once I fixed the policy, it just started working.

Now to get WebSphere Application Server (WAS) to read messages from the Queue …..

For the record, these sources were of use: -





Thursday, 20 April 2017

IBM Operational Decision Manager - Adding a LDAP server via the Decision Center Business Console

This has been on my To-Do list for some time.

One of my colleagues was looking to configure connectivity between the IBM ODM Decision Center Business Console and an LDAP server.

He, like me, is using ODM Advanced 8.8.1.

I'd previously installed and configured this version on WebSphere Application Server (WAS) Network Deployment 8.5.5.

This is what I have installed: -

/opt/ibm/InstallationManager/eclipse/tools/imcl listInstalledPackages

com.ibm.cic.agent_1.8.6000.20161118_1611
com.ibm.websphere.IBMJAVA.v71_7.1.3040.20160720_1746
com.ibm.websphere.ND.v85_8.5.5010.20160721_0036
com.ibm.websphere.IHS.v85_8.5.5010.20160721_0036
com.ibm.websphere.PLG.v85_8.5.5010.20160721_0036
com.ibm.websphere.odm.dc.v88_8.8.1001.20160912_1319
com.ibm.websphere.odm.ds.rules.v88_8.8.1001.20160912_1339
com.ibm.websphere.odm.pt.dc.v88_8.8.1001.20160912_1435
com.ibm.websphere.odm.pt.rules.v88_8.8.1001.20160912_1441

/opt/ibm/InstallationManager/eclipse/tools/imcl listInstalledPackages -features

com.ibm.cic.agent_1.8.6000.20161118_1611 : 
com.ibm.websphere.IBMJAVA.v71_7.1.3040.20160720_1746 : 
com.ibm.websphere.ND.v85_8.5.5010.20160721_0036 : com.ibm.sdk.6_64bit,ejbdeploy,embeddablecontainer,thinclient
com.ibm.websphere.IHS.v85_8.5.5010.20160721_0036 : arch.64bit
com.ibm.websphere.PLG.v85_8.5.5010.20160721_0036 : com.ibm.jre.6_64bit
com.ibm.websphere.odm.dc.v88_8.8.1001.20160912_1319 : Documentation,com.ibm.wdc.rules.samples.feature
com.ibm.websphere.odm.ds.rules.v88_8.8.1001.20160912_1339 : com.ibm.wds.rules.res.feature,com.ibm.wds.rules.samples.feature,com.ibm.wds.rules.studio.feature,com.ibm.wds.updatesites.feature
com.ibm.websphere.odm.pt.dc.v88_8.8.1001.20160912_1435 : 
com.ibm.websphere.odm.pt.rules.v88_8.8.1001.20160912_1441 : 

My LDAP is a VM running Windows Server 2012, which is configured as an Active Directory server ( plus the usual DNS, Kerberos services etc. ).

Having checked that I can bind to AD via LDAP, from the command-line: -

ldapsearch -x -h windows2012.uk.ibm.com -p 389 -D CN=LDAPBindUser,CN=Users,DC=uk,DC=ibm,DC=com -w Qpassw0rd -b CN=Users,DC=uk,DC=ibm,DC=com CN=BPMUser1 memberOf

# BPMUser1, Users, uk.ibm.com
dn: CN=BPMUser1,CN=Users,DC=uk,DC=ibm,DC=com
memberOf: CN=BPMUsers,CN=Users,DC=uk,DC=ibm,DC=com

...

ldapsearch -x -h windows2012.uk.ibm.com -p 389 -D CN=LDAPBindUser,CN=Users,DC=uk,DC=ibm,DC=com -w Qpassw0rd -b CN=Users,DC=uk,DC=ibm,DC=com sAMAccountName=bpmuser1

# BPMUser1, Users, uk.ibm.com
dn: CN=BPMUser1,CN=Users,DC=uk,DC=ibm,DC=com
objectClass: top
objectClass: person
objectClass: organizationalPerson
objectClass: user
cn: BPMUser1

...

I then logged into the Business Console : -


includes an Administration tab: -


Using the + icon to create a new connection: -


Having created the connection, I was then able to import Groups: -



and Users: -



I can/will tinker further, but this is a good starter for 10.

For the record, I did see this early on: -

[20/04/17 16:40:28:822 BST] 000000c3 LDAPManagemen I   Cannot parse url: windows2012.uk.ibm.com
                                 javax.naming.NamingException: Cannot parse url: windows2012.uk.ibm.com [Root exception is java.net.MalformedURLException: Invalid URI: windows2012.uk.ibm.com]
at com.sun.jndi.ldap.LdapURL.<init>(LdapURL.java:109)

Caused by: java.net.MalformedURLException: Invalid URI: windows2012.uk.ibm.com

because I got the LDAP URL wrong. I had: -

windows2012.uk.ibm.com

rather than this: -

Thanks to this: -
Lovely stuff

Thursday, 13 April 2017

JMSMQ1112: The operation for a domain specific object was not valid. The operation 'createProducer()' is not valid for type 'com.ibm.mq.jms.MQQueue'

We saw this exception today: -

Caused by: com.ibm.msg.client.jms.DetailedJMSException: JMSMQ1112: The operation for a domain specific object was not valid. The operation 'createProducer()' is not valid for type 'com.ibm.mq.jms.MQQueue'. A JMS application attempted to perform an operation on domain specific object, but the operation is valid only for the other messaging domain. Make sure that the JMS objects and operations used by your application are relevant for the required messaging domain. If your application uses both messaging domains, consider using domain independent objects throughout the application.

whilst testing an application that had been migrated from WebSphere Application Server (WAS) Network Deployment (ND) 7.0.0.27 to WAS ND 8.5.5.10.

The application or, more specifically, the Message Driven Bean (MDB) is activated ( woken up ) by a Message being placed onto a Queue on an WebSphere MQ Queue Manager, using a JMS Activation Specification and a JMS Queue.

The JMS artefacts act as a buffer ( more accurately, an abstraction ) between the actual Java code and the WebSphere MQ configuration.

This means that the developer merely needs to write his/her code to hit a JMS queue via an alias e.g. jms/OutputQ, rather than specifically writing WebSphere MQ client code within their Java code.

The actual awakening of the MDB occurs via the Activation Specification, rather than in the Java code itself.

Anyway, the incoming Message was awakening the MDB, proving that the WAS to MQ configuration was in order i.e. that there wasn't a problem with the "plumbing" - Queue Manager, Channel, Authentication etc.

And yet ….

I pinged the question to one of my fellow gurus, and he suggested checking the Class Loader.

In parallel, the application developer also dug through the code, and a trace ( thanks to this MustGather: MQ Java Message Service (JMS) problems with WebSphere Application Server ) and came to the same conclusion.

He suspected that the underlying WAS code was actually checking whether the target JMS Queue ( jms/OutputQ ) was really a MQ Queue ( as configured in WAS using the WebSphere MQ Resource Adapter ).

We checked the application ( the Enterprise Archive (EAR) that included the MDB ), and realised that the Class Loader Order differed from the old environment ( WAS 7 ) and the new environment  ( WAS 8.5.5 ), specifically: -


Once we changed the EAR from Parent Last to Parent First, which automatically caused the application to restart, the problem disappeared.

The developer checked and realised that they were packaging JMS 1.1 classes within the EAR file.

This meant that, in the WAS 8.5.5 environment, the JMS classes were being loaded from the EAR rather than from the WAS JVM itself.

Whilst Parent Last is NOT necessarily a problem, it was an issue here because JMS was being loaded TWICE.

Nice :-)

IBM Business Process Manager - RESTing on my laurels

An exceptionally good friend asked me about REST, in the context of the WebSphere Liberty Profile and the "new" Collectives management interface.

Having provided some context about REST, I demonstrated how I can use a Firefox addon, REST Easy, to access the IBM BPM REST UI: -


which returns: -


and: -


However, I also asked my Slack buddies for recommendations on other REST clients, and someone rightly pointed out the Swiss Army Knife that is curl which is built into most Unix OS, including macOS.

So here's me accessing the same REST API: -

curl -i -k -u wasadmin:passw0rd -X GET https://bpm857.novalocal:8443/rest/bpm/wle/v1/process/currentlyExecuting 

which returns: -

HTTP/1.1 200 OK
Date: Thu, 13 Apr 2017 09:23:34 GMT
X-Powered-By: Servlet/3.0
BPM_GENERIC_HEADER: SERVED
Cache-Control: no-cache, no-store, max-age=0
Set-Cookie: LtpaToken2=cxzAh/CU/jv6oBp37tplPmD7DS7toa92E2Pt5OJ0RyjtdymQ7gGeoBMuXpuf4yUTeXBAdtOzo+TCVWRFUxwJN2MF/yVnmHDawFK+L1kOvCz/3d5oe6WJ63IyVHm8j5esGreaWBQoWol0io2tRHvJxDrPb40YZhx/xcxO8YouHWud3B2BzBjvcRzKAhE0kFHKJ691BZZ6N3vQl+KDNFABB7aegqf98QlC7zTD6lj9SGy2WqEmm+TULisRfG+hmF19toU5gEjTIZ1Yxd7InefsOL4AsRLZnb6Bk8mfRFnofyP06+YAHSHkB8t5Vbvtm5F+ozDk/lMTYlyROBcSZVbepImrScgYCDZYFuHIffvHYSGdPT/CoGdODFOHOApqOTnIMVg5jTkHetiGpBFHG7DzjpxfdwMxc+Lg+31vOexpDPnRcO+KvHuyzKbpYiZcg1c5ozfIGvT+dW0zPeA/SZVXJgLypzA0QgF/MTzaNyvoON4SW2LlIicTnhcYcxj99h409m8LVb8MMIF0vL10UW3jJ3RIHjSfITalICa9faLgz1xAfdqVvMCRUdg1B8BdD6K28QEs8avWEXjYuDsYzl1ZUiMK18olxqV+qPK8+DcXIjW0NDWMW2iZDxahHJgpOQ4srIS3X248/GJaNeYeLu5wTp25/m/tksGpQFQA79fZeYg=; Path=/; HttpOnly
Set-Cookie: JSESSIONID=0000NWjcOUgFHUo5Oq2o6OuKtuS:1bb38qov8; Path=/; HttpOnly
Expires: Thu, 01 Dec 1994 16:00:00 GMT
Transfer-Encoding: chunked
Content-Type: application/json
Content-Language: en-US

{"status":"200","data":{"instanceIDs":null}}

which is rather lovely.

Of course, BPM has a built-in REST client: -


which also is rather useful.


WebSphere Application Server - manageprofiles.sh and the missing Java security policies

We saw a problem the other day, whilst creating a new IBM BPM Deployment Environment via the BPMConfig.sh script.

When we dug into the problem further, it was apparent that the underlying manageprofiles.sh script was failing.

Having resolved the problem ( more later ), I replicated it on a clean VM this morning.

So, to start with, I attempt to create a new WAS profile: -

/opt/ibm/WebSphere/AppServer/bin/manageprofiles.sh -create -templatePath /opt/ibm/WebSphere/AppServer/profileTemplates/managed -profileName AppSrv02 -nodeName Node1

This fails with: -

INSTCONFFAILED: The profile could not be created.  For more information, consult the /opt/ibm/WebSphere/AppServer/logs/manageprofiles/AppSrv02_create.log file.

When one digs into the logs: -

view /opt/ibm/WebSphere/AppServer/logs/manageprofiles/AppSrv02_create.log 

there are a fair number of failures: -

    <message>Task stopped for: fail - FAILURE</message>
    <message>Target stopped for: failIfError - FAILURE</message>


and exceptions: -

    <message>Exception was thrown, type of exception is: class org.apache.tools.ant.BuildException</message>

but there is also this: -

    <date>2017-04-13T07:41:42</date>
    <millis>1492065702583</millis>
    <sequence>2363</sequence>
    <logger>com.ibm.ws.install.configmanager.actionengine.ant.utils.ANTLogToCmtLogAdapter</logger>
    <level>WARNING</level>
    <class>com.ibm.ws.install.configmanager.logging.LogUtils</class>
    <method>logException</method>
    <thread>0</thread>
    <message>/opt/ibm/WebSphere/AppServer/profileTemplates/managed/actions/scripts/importExternalLogs.xml:30: Failure occured while attempting to Setting the security settings in the default security template.
        at org.apache.tools.ant.taskdefs.Exit.execute(Exit.java:139)
        at org.apache.tools.ant.UnknownElement.execute(UnknownElement.java:275)
        at org.apache.tools.ant.Task.perform(Task.java:364)
        at org.apache.tools.ant.Target.execute(Target.java:341)
        at org.apache.tools.ant.Target.performTasks(Target.java:369)
        at org.apache.tools.ant.Project.executeSortedTargets(Project.java:1216)


which was the thing that led me to root cause.

Applying the First Rule of Problem Determination - WHAT HAS CHANGED - I realised that the last-but-one thing that we had done was to switch the Java SDK Policy Files from restricted to unrestricted, in order to support AES key lengths greater than 256 bits.

This is documented in way more detail here: -

By default, the IBM® SDK, on all platforms, provides strong but limited jurisdiction policy files. To use unlimited jurisdiction policy files by default, place the US_export_policy.jar and the local_policy.jar in the jre/lib/security/ directory of the SDK.


When I traced back, I realised that, as part of this change, we had backed out the old policy files: -

cd /opt/ibm/WebSphere/AppServer/java_1.7.1_64/jre/lib/security/
mv US_export_policy.jar US_export_policy.RAJ
mv local_policy.jar local_policy.RAJ

*BUT* not unpacked the replacement unrestricted policy files :-(

So this is what we had: -

ls -al

total 144
drwxr-xr-x  2 wasadmin wasadmins   4096 Apr 13 07:40 .
drwxr-xr-x 16 wasadmin wasadmins   4096 Mar 29 15:36 ..
-rwxr-xr-x  1 wasadmin wasadmins   4054 Jul 20  2016 blacklist
-rwxr-xr-x  1 wasadmin wasadmins 103822 Mar 24  2014 cacerts
-rwxr-xr-x  1 wasadmin wasadmins   2532 Mar 24  2014 java.policy
-rwxr-xr-x  1 wasadmin wasadmins  10560 Mar 24  2014 java.security
-rwxr-xr-x  1 wasadmin wasadmins     98 Jul 20  2016 javaws.policy
-rwxr-xr-x  1 wasadmin wasadmins   2640 Jul 20  2016 local_policy.RAJ
-rwxr-xr-x  1 wasadmin wasadmins      0 Jul 20  2016 trusted.libraries
-rwxr-xr-x  1 wasadmin wasadmins   2175 Jul 20  2016 US_export_policy.RAJ

In other words, the Java SDK ( JRE ) couldn't find the actual local_policy.jar and US_export_policy.jar files :-(

Once we put the the unrestricted policy files in place: -

unzip ~/unrestrictedpolicyfiles.zip 
Archive:  /home/wasadmin/unrestrictedpolicyfiles.zip
  inflating: US_export_policy.jar    
  inflating: local_policy.jar        

ls -al

total 152
drwxr-xr-x  2 wasadmin wasadmins   4096 Apr 13 07:56 .
drwxr-xr-x 16 wasadmin wasadmins   4096 Mar 29 15:36 ..
-rwxr-xr-x  1 wasadmin wasadmins   4054 Jul 20  2016 blacklist
-rwxr-xr-x  1 wasadmin wasadmins 103822 Mar 24  2014 cacerts
-rwxr-xr-x  1 wasadmin wasadmins   2532 Mar 24  2014 java.policy
-rwxr-xr-x  1 wasadmin wasadmins  10560 Mar 24  2014 java.security
-rwxr-xr-x  1 wasadmin wasadmins     98 Jul 20  2016 javaws.policy
-r--r--r--  1 wasadmin wasadmins   2253 Oct 12  2012 local_policy.jar
-rwxr-xr-x  1 wasadmin wasadmins   2640 Jul 20  2016 local_policy.RAJ
-rwxr-xr-x  1 wasadmin wasadmins      0 Jul 20  2016 trusted.libraries
-r--r--r--  1 wasadmin wasadmins   2240 Oct 12  2012 US_export_policy.jar
-rwxr-xr-x  1 wasadmin wasadmins   2175 Jul 20  2016 US_export_policy.RAJ

the manageprofiles.sh script just bloomin' worked: -

/opt/ibm/WebSphere/AppServer/bin/manageprofiles.sh -create -templatePath /opt/ibm/WebSphere/AppServer/profileTemplates/managed -profileName AppSrv02 -nodeName Node1

INSTCONFSUCCESS: Success: Profile AppSrv02 now exists. Please consult /opt/ibm/WebSphere/AppServer/profiles/AppSrv02/logs/AboutThisProfile.txt for more information about this profile.

although it was necessary to clean up the profile path from the previous failed run: -

rm -Rf /opt/ibm/WebSphere/AppServer/profiles/AppSrv02/

to avoid this: -

The following validation errors were present with the command line arguments: 
profilePath: The profile path is not valid.


So, in conclusion, REMEMBER WHAT YOU LAST DID ( aka What Has Changed )

IBM Operational Decision Manager - Where's my Decision Center Business Console gone ?

This is a new build of IBM ODM Advanced 8.8.1, and I'm trying to log into, and use, the Decision Center Business Console: -


Having logged in, with a valid user, I get this: -

and, in the logs: -

tail -f /opt/ibm/WebSphere/AppServer/profiles/AppSrv01/logs/Node1-DCServer/SystemOut.log

[13/04/17 07:21:27:130 BST] 000000ac ServletWrappe I com.ibm.ws.webcontainer.servlet.ServletWrapper init SRVE0242I: [teamserver] [/decisioncenter] [/WEB-INF/views/login.jsp]: Initialization successful.
[13/04/17 07:22:48:326 BST] 000000b0 authz         I   CWWIM2000I Initialization of the authorization component completed successfully.
[13/04/17 07:22:53:306 BST] 000000b1 InternalGener I   DSRA8225I: DataSource JNDI name : jdbc/ilogDataSource
[13/04/17 07:22:53:309 BST] 000000b1 InternalGener I   DSRA8203I: Database product name : DB2/LINUXX8664
[13/04/17 07:22:53:311 BST] 000000b1 InternalGener I   DSRA8204I: Database product version : SQL10058
[13/04/17 07:22:53:312 BST] 000000b1 InternalGener I   DSRA8205I: JDBC driver name  : IBM DB2 JDBC Universal Driver Architecture
[13/04/17 07:22:53:313 BST] 000000b1 InternalGener I   DSRA8206I: JDBC driver version  : 3.61.65
[13/04/17 07:22:53:313 BST] 000000b1 InternalGener I   DSRA8218I: JDBC driver specification level  : 3.0
[13/04/17 07:22:53:314 BST] 000000b1 InternalDB2Un I   DSRA8212I: DataStoreHelper name is: com.ibm.websphere.rsadapter.DB2UniversalDataStoreHelper@456a0905.
[13/04/17 07:22:53:315 BST] 000000b1 WSRdbDataSour I   DSRA8208I: JDBC driver type  : 4
[13/04/17 07:22:53:636 BST] 000000b1 HandlerMethod E   An error has occurred in trying to access data source &#39;jdbc/ilogDataSource&#39;: Not initialized. Check that the data source exists on the application server or contact your administrator.
                                 com.ibm.rules.decisioncenter.web.core.ConnectionException: An error has occurred in trying to access data source 'jdbc/ilogDataSource': Not initialized. Check that the data source exists on the application server or contact your administrator.
at com.ibm.rules.decisioncenter.web.core.ApplicationInterceptor.throwDataSourceException(ApplicationInterceptor.java:319)
at com.ibm.rules.decisioncenter.web.core.ApplicationInterceptor.preHandle(ApplicationInterceptor.java:157)
at org.springframework.web.servlet.HandlerExecutionChain.applyPreHandle(HandlerExecutionChain.java:134)
at org.springframework.web.servlet.DispatcherServlet.doDispatch(DispatcherServlet.java:913)
at org.springframework.web.servlet.DispatcherServlet.doService(DispatcherServlet.java:851)
at org.springframework.web.servlet.FrameworkServlet.processRequest(FrameworkServlet.java:953)
at org.springframework.web.servlet.FrameworkServlet.doGet(FrameworkServlet.java:844)
at javax.servlet.http.HttpServlet.service(HttpServlet.java:575)
at org.springframework.web.servlet.FrameworkServlet.service(FrameworkServlet.java:829)
at javax.servlet.http.HttpServlet.service(HttpServlet.java:668)
at com.ibm.ws.webcontainer.servlet.ServletWrapper.service(ServletWrapper.java:1232)
at com.ibm.ws.webcontainer.servlet.ServletWrapper.handleRequest(ServletWrapper.java:781)
at com.ibm.ws.webcontainer.servlet.ServletWrapper.handleRequest(ServletWrapper.java:480)
at com.ibm.ws.webcontainer.servlet.ServletWrapperImpl.handleRequest(ServletWrapperImpl.java:178)
at com.ibm.ws.webcontainer.filter.WebAppFilterChain.invokeTarget(WebAppFilterChain.java:136)
at com.ibm.ws.webcontainer.filter.WebAppFilterChain.doFilter(WebAppFilterChain.java:97)
at com.ibm.rules.decisioncenter.web.core.filters.SecurityCheckPointFilter.doFilter(SecurityCheckPointFilter.java:95)
at com.ibm.ws.webcontainer.filter.FilterInstanceWrapper.doFilter(FilterInstanceWrapper.java:195)
at com.ibm.ws.webcontainer.filter.WebAppFilterChain.doFilter(WebAppFilterChain.java:91)
at com.ibm.rules.decisioncenter.web.core.filters.RemoteSessionFilter.doFilterInternal(RemoteSessionFilter.java:79)
at com.ibm.rules.decisioncenter.web.core.filters.RemoteSessionFilter.doFilter(RemoteSessionFilter.java:59)
at com.ibm.rules.decisioncenter.web.core.filters.SessionFilter.access$001(SessionFilter.java:32)
at com.ibm.rules.decisioncenter.web.core.filters.SessionFilter$1.doFilter(SessionFilter.java:73)
at org.springframework.web.filter.RequestContextFilter.doFilterInternal(RequestContextFilter.java:99)
at org.springframework.web.filter.OncePerRequestFilter.doFilter(OncePerRequestFilter.java:106)
at com.ibm.rules.decisioncenter.web.core.filters.SessionFilter.doFilter(SessionFilter.java:70)
at com.ibm.ws.webcontainer.filter.FilterInstanceWrapper.doFilter(FilterInstanceWrapper.java:195)
at com.ibm.ws.webcontainer.filter.WebAppFilterChain.doFilter(WebAppFilterChain.java:91)
at org.springframework.web.filter.CharacterEncodingFilter.doFilterInternal(CharacterEncodingFilter.java:88)
at org.springframework.web.filter.OncePerRequestFilter.doFilter(OncePerRequestFilter.java:106)
at com.ibm.ws.webcontainer.filter.FilterInstanceWrapper.doFilter(FilterInstanceWrapper.java:195)
at com.ibm.ws.webcontainer.filter.WebAppFilterChain.doFilter(WebAppFilterChain.java:91)
at com.ibm.rules.decisioncenter.web.core.filters.HttpPUTRequestFilter.doFilterInternal(HttpPUTRequestFilter.java:65)
at org.springframework.web.filter.OncePerRequestFilter.doFilter(OncePerRequestFilter.java:106)
at com.ibm.ws.webcontainer.filter.FilterInstanceWrapper.doFilter(FilterInstanceWrapper.java:195)
at com.ibm.ws.webcontainer.filter.WebAppFilterChain.doFilter(WebAppFilterChain.java:91)
at com.ibm.ws.webcontainer.filter.WebAppFilterManager.doFilter(WebAppFilterManager.java:967)
at com.ibm.ws.webcontainer.filter.WebAppFilterManager.invokeFilters(WebAppFilterManager.java:1107)
at com.ibm.ws.webcontainer.servlet.CacheServletWrapper.handleRequest(CacheServletWrapper.java:87)
at com.ibm.ws.webcontainer.WebContainer.handleRequest(WebContainer.java:947)
at com.ibm.ws.webcontainer.WSWebContainer.handleRequest(WSWebContainer.java:1817)
at com.ibm.ws.webcontainer.channel.WCChannelLink.ready(WCChannelLink.java:200)
at com.ibm.ws.http.channel.inbound.impl.HttpInboundLink.handleDiscrimination(HttpInboundLink.java:463)
at com.ibm.ws.http.channel.inbound.impl.HttpInboundLink.handleNewRequest(HttpInboundLink.java:530)
at com.ibm.ws.http.channel.inbound.impl.HttpInboundLink.processRequest(HttpInboundLink.java:316)
at com.ibm.ws.http.channel.inbound.impl.HttpICLReadCallback.complete(HttpICLReadCallback.java:88)
at com.ibm.ws.ssl.channel.impl.SSLReadServiceContext$SSLReadCompletedCallback.complete(SSLReadServiceContext.java:1820)
at com.ibm.ws.tcp.channel.impl.AioReadCompletionListener.futureCompleted(AioReadCompletionListener.java:175)
at com.ibm.io.async.AbstractAsyncFuture.invokeCallback(AbstractAsyncFuture.java:217)
at com.ibm.io.async.AsyncChannelFuture.fireCompletionActions(AsyncChannelFuture.java:161)
at com.ibm.io.async.AsyncFuture.completed(AsyncFuture.java:138)
at com.ibm.io.async.ResultHandler.complete(ResultHandler.java:204)
at com.ibm.io.async.ResultHandler.runEventProcessingLoop(ResultHandler.java:775)
at com.ibm.io.async.ResultHandler$2.run(ResultHandler.java:905)
at com.ibm.ws.util.ThreadPool$Worker.run(ThreadPool.java:1892)

[13/04/17 07:22:53:668 BST] 000000b1 ServletWrappe I com.ibm.ws.webcontainer.servlet.ServletWrapper init SRVE0242I: [teamserver] [/decisioncenter] [/WEB-INF/views/error.jsp]: Initialization successful.

I can, however, log into the Decision Center per se : -



At this point, I realised that I had *NOT* completed the setup: -


<sigh>

Once I did this, including the database setup, it just simply worked.

<sigh>