lekkimworld.comapi

Notes 8.5.3 and Sametime Web API woes

Wed, 22 Feb 2012 13:18:54 GMT

For one of our products we are using the Sametime Web API which is a great way to Sametime enable applications outside the Notes client. Basically it uses the web container running within Notes Standard to provide a HTTP API for Sametime awareness. Great. We had an issue however after upgrading from Notes 8.5.2 to Notes 8.5.3 where Sametime awarenss stopped working but thanks to the design partner program and the help of Khuan Hoe Kong from IBM we're now back in the business. As this issue may bite others I thought I would post it here.

Our problem was that we were using the "mystatus" and "getShortStatus" API calls to get awareness status that is we were using local calls like http://localhost:59449/stwebapi/mystatus/ and http://localhost:59449/stwebapi/getShortStatus. These calls returned JSON we could use to get awareness status and as previously mentioned these calls worked fine in Notes 8.5.2 but after going to Notes 8.5.3 (and hence a newer version of the embedded Sametime client) they stopped working. Apparently these calls were considered a security risk so there were blocked and needed to be unblocked in order to work. Below is the response from IBM.

For security reasons, many of the WEBApi functions are disabled by default, including the mentioned two. To enable the function, add a preference to the plugin_customization.ini in the following format:

com.ibm.collaboration.realtime.webapi.<function>Enabled=true

For example, to enable the getstatusshort, you would add this preference:
com.ibm.collaboration.realtime.webapi .getstatusshortEnabled=true
To enabled all the Web API functions you can use the global override:
com.ibm.collaboration.realtime.webapi/ enableAllWebApisOverride=true
The details of this change may be found in ST8.5.1 SDK.

While the above solution works it requires the customer to configure the client and hence wont work for us. The funny thing is that while the getstatusshort method is blocked for "security reasons" the getstatus method works just fine. Only difference is that the getstatus method returns more info. Makes no sense.

My main reason for considering this a bad approach is that I get an HTTP code 200 back but the response is empty/invalid. That seems wrong. A better REST solution would be to return a 403 Forbidden with an explanation why. What would in my mind have been the correct solution. Hope that can be incorporated into a future release.

But it works now so I will go back under my rock.

Searching Profiles programmatically

Thu, 08 Dec 2011 18:42:28 GMT

As part of IBM Connections you will find a big REST API that allows you to work with almost every part of Connections such as searching for profiles, managing files and working with communities. As part of our new product (see my previous post) I'm doing a lot with this API. Right now one of my favorite wiki documents is "Searching Profiles programmatically".

New version of the Java UI API Exerciser available from OpenNTF

Tue, 07 Dec 2010 13:27:22 GMT

A new release of the Notes Java UI Exerciser project has been released on OpenNTF (OpenNTF Release: Notes Java UI APIs in 8.5.2) by our friends on the Java UI team at IBM one of whom I'm lucky enough to co-present with at Lotusphere. Check it out!

Why all the talk about recycle() - how about dispose()?

Sat, 20 Nov 2010 18:46:02 GMT

Let me start by saying that I agree that recycle() could and should be handled by the API and there are numerous ways around it. I however also think that the majority of Notes developers out there will never have the need to call recycle() in their Java agents. There is a lot of talk about recycle() this and recycle() that but let's face it - it's not really a problem. If ever there is a problem with the Java API it's not recycle() it is the fact that it has been left to stagnate and that it's not keeping up with the Java language as a whole.

All this being said I wonder why so much talk and energy is being spent on recycle() and how come it is constantly being used as a reason not to move to Java and embrace the language. Looking at other API's there are stuff that needs to be done. In the Java API it's recycle() (whenever it's actually needed) and in SWT it's dispose(). I never see any SWT discussions on the dispose() method and DisposeListeners and using it as a justification for not choosing SWT and Eclipse as the fundation for an application. You judge a framework on what it does for you and not a single method in an API. Every API and language has quirks. Deal with it!

My post from 2006 (!!) has a lot more information on recycle() and why it's there: Java in Notes/Domino Explained: The story on recycle()

The technique for building a better Notes Java API

Thu, 12 Mar 2009 11:18:26 GMT

This is a followup post to yesterdays post titled Want to join me in building a better Notes Java API? and here I'll show just how easy it was to build the wrapper API.

Below is the code from the implementation of the getView(String) method of the lotus.domino.Database interface. As you can see the central element is to get the current thread the method is called on and the thread used for Notes data access. If we're not on the Notes thread execute a blocking request and return the result. If we're on the Notes thread simply go ahead and do the operation. Simple right?

The most difficult part of all this was that I had to write my own Notes thread handler (equivalent of NotesPlatform) as there isn't a method for doing a blocking request on the Notes thread in NotesPlatform class supplied by Lotus.

public View getView(final String name) throws NotesException {
  // get threads
  Thread curThread = Thread.currentThread();
  Thread notesThread = NotesPlatform.getInstance().getThread();

  // decide if we're in the Notes thread or not
  if (curThread != notesThread) {
    // we're not on the Notes thread so wrap
    final Holder h = new Holder();
    
    NotesPlatform.getInstance().syncExec(new Runnable() {
      public void run() {
        try {
          h.value = DatabaseWrapper.this.db.getView(name);
          
        } catch (NotesException e) {
          h.throwable = e;
        }
      }
    });
    
    if (null != h.throwable) {
      throw (NotesException)h.throwable;
    } else {
      return new ViewWrapper((View)h.value);
    }
    
  } else {
    // we're on the thread so do request
    return new ViewWrapper(DatabaseWrapper.this.db.getView(name));
  }
}

Learning the ropes (pun intended)

Tue, 19 Feb 2008 07:08:00 GMT

I discovered this article through my developerWorks subscription and it was an interesting read. I picked up on the article since I do a lot of String manipulation in LotusScript.doc but hardly in the the 50MB range as described in the article. Still I think you should read the article if you

like to learn new API's
like to think outside the box
do stuff in Java

Article abstract:

"Systems that manipulate large quantities of string data are poorly served by the Java language's default String and StringBuilder classes. A rope data structure can be a better alternative. This article introduces Ropes for Java, a rope implementation for the Java platform; explores performance issues; and provides pointers for effective use of the library."

developerWorks: Ropes: Theory and practice - Why and when to use Ropes for Java for string manipulations

Effective API Design presentation by Joshua Bloch

Thu, 20 Sep 2007 20:44:00 GMT

Although from JavaPolis 2005 this is still a very nice presentation by one of the gurus in the field of API design, Joshua Bloch. The presentation runs about 70 minutes but is well worth it.

Summary: "A well-written API can be a great asset to the organization that wrote it and to all that use it. Given the importance of good API design, surprisingly little has been written on the subject. In this talk (recorded at Javapolis), Java library designer Joshua Bloch teaches how to design good APIs, with many examples of what good and bad APIs look like."

Effective API Design

XML entities when doing XSL transformations using LotusScript

Wed, 06 Jun 2007 08:35:33 GMT

I stumbled over an interesting post on developerWorks on external XML entities and XSL transformations in LotusScript: XSLT transform-ignoring external entity reference in R7.0.2 - but worked well on R6.5.4. I was puzzled by the post and looked a bit into it and was unable to find any real LotusScript API support for working with XML entities when processing XML in LotusScript.

I find it funny that there doesn't appear to be any real API support for XML entities in LotusScript that I can see anyway. Hmmm - gotta go into Sherlock Holmes mode...