IBM Connections application development state of the union – part 4

While previous posts in this series has been about specific parts of the IBM Connections platform this is a bit more generic setting the stage for the next two ports. The next two posts are about extensions/apps for IBM Connections on-premises and in the cloud. Setting the stage for this is talking about the difference scenarios for extensions and what they would like to to and what capabilities they would need from the platform (IBM Connections).

In my mind when you provide a platform that allows for extensions – such as the extensions/apps in IBM Connections – you really need to think about not just what you want and need to provide but also what the consumer would want to do with it. What is the usage scenario of the customer / ISV? What would they want / need to do? Is the user identity important? If the context (e.g. current profile / current community ID) important? Providing an extension mechanism that doesn’t allow a customer or ISV to do what they would like is almost even worse than providing nothing at all. If nothing else it leads to more frustration anyway.

Looking at the various things a customer / ISV would want to do you can list them like below. Of course there might be a different number of areas of interest but these are at the core. I note observations for both on-premises and cloud.

  • Extend required areas e.g. Homepage, Profiles, Communities, Files etc.
    • On-premises: No. Or to some extent. You can extend Homepage, Profiles and Communities. It’s pretty hard to control from a policy perspecitive but it’s doable. There is no support for extending other features (besides the rich text editor) which is pretty bad if you provide a service for Files or Wikis.
    • Cloud: No. Extension only available for Communities. This is really bad for a piece of social software that focus on people…
  • Access to widget context
    • On-premises: Yes. iContext provide the community / profile ID of the active community or profile.
    • Cloud: Yes. Extension can receive a context object describing the active community.
  • Ability of called REST API to obtain user identity
    • On-premises: Yes. If using IBM server using LtpaToken otherwise you need to develop custom code.
    • Cloud: No. Not without additional technology. Context provides access to the user identity but it cannot be trusted as it’s not signed or authenticated in any way. Using SAML is an option but is an add-on and require interaction with IBM Support.
  • Ability to communicate with custom API (anything other than IBM Connections)
    • On-premises: Yes. You may do anything but may need to use provided AJAX proxy
    • Cloud: No. May only communicate with the same origin as the widget was loaded from. Cannot even communicate with the IBM Connections API.
  • Ability to communicate with the IBM Connections API
    • On-premises: Yes. Possible as user is most likely already logged into IBM Connections. Most likely as Profiles doesn’t require authentication by default. It is however possible to configure the widget to require the user to be authentication and hence not show up for unauthenticated users.
    • Cloud: No. Widget may only communicate with the same origin as the code was loaded from.
  • Ability of an API to communicate with the IBM Connections API on behalf of the user
    • On-premises: Yes. Possible if the API runs on an IBM based server supporting LtpaToken and the API runs on the same domain as IBM Connections as the API may grab the cookie and use it when calling back to IBM Connections. Not pretty but it works.
    • Cloud: No. The API a widget would call never runs on the same domain nor is there any traditional cookie based SSO available.

As is pretty clear from the above I’m not a great fan of the extensibility model of IBM Connections Cloud and it fails in almost all areas. It’s severely and utterly broken from an ISV standpoint and fails on all accounts making it unusable IMHO. I go more into details about why not in a post specific to extensions for IBM Connections Cloud. The on-premises model is okay but is cumbersome to develop for and is outdated. Also it doesn’t work for cloud making us having to develop the same functionality twice. The on-premises capabilities work however and mostly allows ISV’s and customers to develop the extensions they need. Again there will be a separate posts on extensions for on-premises.