I've updated my IBM Connections wsadmin commands for newcomers page for IBM Connections 4+ and added a couple of new commands. I've also added information on how to easily work with wsadmin from the command line on *nix. Comments are very welcome.
Found this little tip this morning to make it easier to use command line scripts written in node.js. Instead of having your node.js file(s) and invoking it using "node myfile.js" on the Mac you can simply do the following:
- At the top of the file as the first line add: #!/bin/usr/env node
- Make the file executable using chmod +x myfile.js
- Invoke away
Boy 2013 was a busy year. In fact it's been so busy and I have been so bad at blogging that I never got around to finish my year end review for 2012. In a draft blog post I had the following:
"2012 was a busy year - maybe the busiest year I've had in a long time. Besides numerous customer projects here in Denmark I've also been involved in a number of international projects and traveled more than ever before. I went to the US twice, Japan twice, Australia once, and to too many European countries to mention. I spoke at and participated in more conferences than usually (Social AppDev workshop, Dublin / Social Connections IV, Amsterdam / BLUG, Belgium / LoLA, US / DNUG, Germany / AusLUG, Australia / UKLUG, Ireland / ITPro Expo, Japan / Lotusphere, US). Wow! 2012 sure was busy. At Lotusphere 2012 I was happy to present a session and sit among the other IBM Champions at the OGS. I was super pleased to see the OnTime logo on the BIG, BIG, BIG screen. I participated in the Social App Throwdown session which proved to be more work than anticipated but well worth it. What a great experience and a great session it was.
2012 was also the year where we (OnTime) decided that it was time to go into the Japanese market. We traveled to Tokyo in March without any expectations or any solid plans but ended up with a stellar partner in Axcel Corp. who's now our partner in Japan. Check out ontimesuite.jp to learn more about OnTime in Japan. In October we went back to support our partner at the ITPro Expo at the Tokyo Big Sight venue. In Tokyo we joined our partner at the booth at the annual ITPro Expo. It would prove to be a lesson to many IBM Lotus Notes/Domino markets out there as it clearly shows why Japan is a thriving and vibrant Notes/Domino market. They do so much stuff right marketingwise and leaves so many markets in the dust. Including Denmark. Really. It was very interesting to see.
Japan is a very interesting market and it will be very interesting to follow in the coming months how it evolves."
It's been a very busy fall and christmas for me so I haven't bragged about being chosen to speak at IBM Connect 2014 on my blog besides creating a new static page for the event that will - eventually - sum up what I'm up to at the event. I am fortunate enough be have been selected to speak in two sessions - one with my good buddy Mat Newman (aka Yellow Man) and one solo. Below are the session IDs (probably subject to change), the session titles and the abstracts.
BP301 An Introduction to Working with the Activity Stream
BP309 Next Generation Project Management: Collaborating Inside and Outside the Box
Working within teams challenges individuals to connect, coordinate and collaborate to achieve a successful outcome. Often, this involves managing vast amounts of information and tracking progress which traditional forms of communication struggle with. The Solution? IBM Connections! We'll demonstrate how IBM Connections revolutionizes the way teams work by: connecting with appropriate expertise, communicating more effectively, coordinating effort effortlessly and collaborating productively from both inside and outside the box.
Better get cracking at preparing for the event which is just shy of 25 days away...
Terminology is the most important thing to know when when starting out with WebSphere Application Server
Over the last few weeks I've done a fair amount of consulting on IBM Connections - not so much the install and technical stuff but more simply talking to customers about WebSphere Application Server (WAS) and how it works. The single thing that people new to WAS seems to struggle the most with is the terminology and getting the overall architecture in place. Once that's done most people actually like the platform and find it nice to work with. A while back I linked to a PDF containing a nice graphics on slide 4 (Overview of IBM WebSphere Application Server Concepts for IBM Lotus Connections Administrators) but it's hard to find so I'm reproducing it below.
The first thing and single most important piece to understand about WAS is that a "server" is usually not what you think! :) Or at least not what it meant to be being namely a physical thing. With the advent of virtual machines the WAS definition is getting easier to understand I think. Below is an attempt to explain the WebSphere terminology to someone starting to deal with IBM Connections.
I find that it makes the most sense to start from the physical/operating system layer (Windows server / Linux server). Each machine/operating system instance with an IP address or hostname is a "node". The list of nodes in your WebSphere environment may be seen in the ISC under "System Administration/Nodes". On a node there may be one or multiple servers. A server is a Java Virtual Machine (JVM) process meaning that it may be controlled individually and it may have memory assigned to it and have specific JVM parameters set if required. Please note that having multiple servers on a single node is very common in WebSphere Application Server.
When a server is created in WebSphere Application Server it is created using a profile which basically is a template for the server. There are two main profiles to worry about - "default" which is an server to run applications and "dmgr" which is the deployment manager. In an architecture with multiple nodes the deployment manager is the administration server that controls the nodes it knows about including making sure that the configuration is synchronized between the nodes. The nodes belonging to a single deployment manager belongs to the same cell. In other words there is a single deployment manager per cell.
Looking back at the nodes a node may be managed or unmanaged. A managed node is a WebSphere node that the deployment manager can talk to and send commands. An unmanaged node is the opposite. WebSphere knows about the node but cannot communicate with it on a WebSphere protocol. Something like an IBM HTTP Server (IHS) is therefore an unmanaged node. If a node is managed it will have a nodeagent installed. The nodeagent is a separate Java process which is started and stopped individually and separate from any server. The nodeagent can be used to synchronize the configuration to the node and to start and stop "stuff" on the node. The nodeagent may be configured to start all the servers running on it when ever it starts. On servers the administrator may install applications which run on the server. The applications may be started and stopped individually but usually all applications start and stop with the server.
For high availability you may choose to create a cluster of servers. Servers in a cluster runs the same applications and can take over from one another. Note that you cluster servers and not nodes so you could have a cluster of three servers on a single node.
If you have an IBM Connections installation where everything is installed on the same Linux or Windows box and you chose the "small deployment" which puts all applications into the same server you will have the following:
- A single cell
- A single deployment manager controlling your cell
- Three (3) nodes. One for the deployment manager, one for the server running the IBM Connections applications (managed node) and one for the IBM HTTP Server (IHS) (unmanaged node).
- A single nodeagent
- A single server running all the applications
- A single cluster with the server
- Three (3) JVM processes running - one for the deployment manager, one for the nodeagent and one for the server
If you make SSL connections from a WebSphere Application Server based application the server (or rather the cell) needs to trust the certificate of the server you are connecting to. This is very easy to do in WAS and is easily done using the Integrated Solutions Console (ISC). The way to establish the trust is as follows:
- Log into the WebSphere Application Server Integrated Solutions Console (ISC)
- From the lefthand navigator select Security/SSL certificate and key management
- In the list of related items on the right click "Key stores and certificates"
- Click "CellDefaultTrustStore"
- In the list of "Additional properties" on the right click "Signer certificates"
- Click "Retrieve from port"
- Fill out the form with the hostname of the server and the SSL port (usually 443) of the you want WAS to trust. Also supply an alias to know the trust by in the list of trusted certificates.
- Click the "Retrieve signer information" button to validate the input and retrieve and trust the certificate
- Click OK and then save the changes to the master configuration.