The best way to learn a platform is to use a platform Wow what a week it's been. First week back from vacation and I'm diving right into a sprint of stuff that needs to be delivered to the customer. My task for the week has been develop a connectivity layer between Salesforce and Dropbox using OAuth. This ...

Currency conversion in Apex While waiting for my flight in the lounge tonight I was playing around with currencies in Salesforce because - why not... Conversion between configured currencies are supported in SOQL and Salesforce but only between the configured corporate currency and ...

Salesforce week 25-27 and finishing this weekly thing... Wow!! A half year has gone by. Half a year... Where did the time go? Over the last weeks I've gradually noticed that my view on being with Salesforce has shifted from being "something new" to being "how things are". On feeling at home in the organisation ...

Salesforce Lightning Component API change As we get closer to Summer 17 we start using difference versions across production instances and sandboxes. This of course also leads to opportunities for differences in API's... I just found one such difference as I'd been developing some Lightning ...

Recent Responses

Re: The best way to learn a platform is to use a platformAs far as dev platforms go, I've been working with Polymer now for almost 2 years. And their tagline is "Use the Platform". Meaning, use the browser platform to do what it can do and does best whenever possible. That too goes to what you're ...

Re: Salesforce Lightning Components and image dependenciesOf course the Salesforce Lightning Design System is Salesforce agnostic but it's funny that the SLDS website only mention the SVG approach. I'll have to look into using the lightning:icon tag instead of the SVG custom component as that would definitely ...

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 clusterservers and not nodes so you could have a cluster of three servers on a single node.

So...

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:

"General availability of the following exam has been announced: LOT-411: XPages Mobile Advanced Topics. Follow the link to read the announcement for this test, which includes links to the exam overview, competency, and preparation pages. Information on the corresponding accreditation - IBM Certified Advanced Application Developer - Notes and Domino 9.0 - including recommended prerequisite skills can be found on the certification page. "

The upgrade was from Domino 9.0.0 and what a difference a point release makes. Not for the Traveler server but for the Social Edition server that runs the embedded experiences (EE's) for us (mainly from IBM Connections). Before the upgrade we had some issues with EE's not loading incl. timeouts when users connected from home over VPN. After the upgrade these timeouts are gone and the performance is much much better both remotely over VPN and in the office. Previously we had a noticeable delay for the remote rendering of the EE's but now it's just there when an email opens up.

So sweet!

So if you're using EE's and haven't yet upgraded to 9.0.1 I would highly recommend you get on it.

Earlier this week I had a requirement to interact with the IBM Connections user storage from a servlet running within WebSphere Application Server meaning that I needed to obtain the currently logged in users email address from the username (i.e. the principal name in JEE speak). As I saw it there were three options - 1) reproduce the entire Federated Repositories configuration in the servlet config, 2) use an IBM Connections API if available or 3) try and figure out if there was a WebSphere API for doing it. Option 1 was a clear no-go so I started persuing option 2. Looking into the wiki for IBM Connections I quickly found the User SPI (IBM Connections SPIs) and the description sounded promising: "You can use the IBM® Connections User SPIs to access information about the users in your IBM Connections deployment."

Wow! Exactly what I needed so I located the lc.spi.jar and added it to my classpath and started coding. An excellent API and easy to understand documentation made it very easy and in a matter of minutes I had the code done. I packaged everything up and deployed the code to WAS and ran the code. Bummer!! All I saw was an Error 500:
Error 500: java.lang.NoClassDefFoundError: com.ibm.ventura.internal.config.exception.VenturaConfigException

Hmmm. Some kind of unsatisfied dependency but which? And an internal one at that... As you know IBM Connections is made up of about a gazillion different JARs but I digged around a bit but after wasting a lot of time on that and being frustrated I gave up I emailed a friend on the IBM Connections product management team. As it turns out the SPI's (there are multiple: Event, Seedlist, Service and User) is only meant to be used from event handlers where they run in the context of IBM Connections. Bummer. I will try and get that into the documentation as soon as possible to avoid others wasting time on this.