<< 24 March 2013 | Home | 26 March 2013 >>

Calendar integration example using OnTime Group Calendar API

The Problem

A Danish insurance company was running a CRM system to control and maintain customer relationship information and plan meetings for its insurance agents. Because the CRM system wasn't integrated with their IBM Domino infrastructure running their mail and calendar the insurance agents in effect had two calendars - one in IBM Notes holding their company appointments and one in a CRM system holding their external customer meetings. This meant that the insurance agents effective stopped using their calendars or maintained a third, non-company, calendar) as there were no single place to see all appointments. Besides this the organization as a whole was unable to plan internal meetings with the insurance agents as their calendars didn't reflect their actual whereabouts.

The Solution

To remedy this they decided to use the OnTime Group Calendar API to integrate the two systems using web services using an intermediate Enterprise Service Bus (ESB). The OnTime Group Calendar API web services are hosted directly on IBM Domino and performs extremely well. After implementing the solution the insurance agents only need to maintain their calendar in Notes as it will reflect their true calendar showing both internal, external and personal appointments and meetings.

The solution provides a true two-way synchronization so any appointment planned from their CRM system shows up in the calendar in Notes. If the user reschedule the appointment the corresponding appointment in CRM is automatically updated and if the appointment is deleted the appointment get cancelled in the CRM system as well as a follow-up activity being created to make sure a new meeting is planned. The personal calendar in Notes is also updated once a meeting is marked completed in the CRM system to allow for automated expense reporting based on the personal calendars in Notes. As an added benefit of the using the OnTime Group Calendar API all insurance agents are now able to use their Notes client, their iNotes webmail or their mobile device to do their job resulting in true mobility and added flexibility.

Below is an architectural drawing showing how it all integrates using Domino as a central application server.

(click image for a larger version)

Remember to secure your IBM HTTP Server when implementing IBM Connections

In Security Now! episode 396 starting at 12:22 (to 25:25) Steve and Leo were talking about various SSL attacks and how one could verify sites. I decided to check out one of my own stock IBM Connections installs i.e. I verified the stock IBM HTTP Server (IHS) install. That was not a pleasant experience as the default IBM HTTP Server is very insecure in that it accepts SSL v.2 and hence some very weak ciphers. Using SSLLabs.com and their SSL Server Test it is very easy to test a SSL site.

Below is the results from a standard IHS install using a commercial SSL certificate. A grade of F isn't nice.

After reading a bit on mod_ssl (the SSL module in Apache / IHS) I added the below lines to the mod_ssl section in the httpd.conf file.

## SSLv3 128 bit Ciphers 
SSLCipherSpec SSL_RSA_WITH_RC4_128_MD5 

## FIPS approved SSLV3 and TLSv1 128 bit AES Cipher
## FIPS approved SSLV3 and TLSv1 256 bit AES Cipher
Now I'm not a SSL wizard by any means so I suggest you do your own research as well but when I restarted the IHS I got a rating of A. BAM!! How's them apples!?

How secure is the SSL stack for your IBM Connections environment?


32 bit or 64 bit

As part of upgrading the servers here at IntraVision I had to figure out which servers were running 32 bit and which servers were running 64 bit. It turns out there is a very simple way of doing this as there is a server statistic. Simple do a "show stat Server.Version.Architecture" and it will show the currently installed "bit-ness".

Tags :