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)

SOAP Headers in Lotus Domino web service consumers and providers

In a current project we’re using the web service consumer and web server provider capability of Lotus Domino quite heavily. During the development the need to process the SOAP request headers which are provided in a section above the SOAP body. Problem is that these are not exposed through the proxy classes generated for you when you import the WSDL. Searching Google I came across the blog of Elena Neroslavskaya and more importantly the post that helped me out. Using the MessageContext class described in that blog post helped me crack the nut and now I can both iterate through the SOAP headers sent to me in the request and send SOAP headers back in the response. Sweet!

Below are two code snippets – one for iterating through request headers and one for sending headers back. Home it may help someone out there.

Iterate received headers

private void recurseHeaders(Iterator ite) {
  while (ite.hasNext()) {
    MessageElement elem = (MessageElement);
    String nsUri = elem.getNamespaceURI();
    String name = elem.getName();
    String value = elem.getValue();
    System.out.println("SOAP Header - ns , name , value ");

public com.example.FooResponseType foo(
  com.example.FooRequestType req) throws Exception {

  MessageContext mc = MessageContext.getCurrentContext();
  SOAPEnvelope envelope = mc.getRequestMessage()

Send back headers

import lotus.domino.axis.message.SOAPHeaderElement;
import lotus.domino.axis.message.MessageElement;

MessageElement elemGuid =
  new MessageElement("", "Guid");

MessageElement elemUser =
  new MessageElement("", "User");

SOAPHeaderElement elemHeader =
  new SOAPHeaderElement("", "TopElem");