The kind people from DNUG was kind enough to tape my presentation in November and send me a link to the video. Sides being extremely weird to see one self on video I thought someone might enjoy it – so here it is. Further down is the presentation on Slideshare from BLUG.
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.
At a customer users were reporting that the media gallery in IBM Connections did not work. The error they were seeing was aneror message in the UI telling them that the file they just selected from their file system did not exist. Very strange. After diagnosing the issue it was caused by the media gallery not having been set up correctly as the default file types wasn’t imported into the configuration. Why these defaults are not set automatically is the topic for another day.
There are two templates which determine the file types you can upload
by default. You should also have these in your AppSrv01 profiles, or your
nodes, etc. The step is done by following the instructions in the info center.
I had a customer report a widget (plugin) installation issue to me. They had clients being unable to install a widget (and hence a plugin) from an update site on our servers (external to their network). The error was reported as below:
Unable to access "http://<host>/site.xml". Contains: Error parsing site stream. [White spaces are required between publicId and systemId.]
The issue turned out to be caused by a firewall issue and hence wrongly reported in the log. The issue was solved by relocating the update site to the customers network.
I’ve added a simple mobile UI to this blog for iPhones and other smartphones. iPads will get the full UI.
Did a maintenance of my blog this evening and updated from Pebble version 2.3.2 to 2.6.2 so lots of new stuff to look through. It looks like the update went fine but if you experience something “weird” please let me know. Thanks.
Many people believe that you have to have multiple servers to run IBM Connections – this simply isn’t true! There’s no reason why you cannot run everything of the same server which is what we do here at the office. When you do that, if all servers are inside the firewall – or if you simply doesn’t care about the security that it provides – you can disable the IHS WAS Plugin from communicating with the WAS server using SSL. A benefit from this is among other things that you do not have to care about certificates between the IHS WAS Plugin and the WAS server which simplifies installation and management.
Any way… For a while I’ve doing this configuration change manually directly in plugin-cfg.xml (by commenting the HTTPS transport out) until it bit us the other day. So I finally decided to find a proper, correct, solution. And of course there is a way to do this and it’s very well documented in IBM Technote 1452735. So if you want to make that change go ahead and do it – I did and it’s working flawlessly.
Had a customer report the above issue and have it fixed by IBM so I thought others might benefit from it. The issue has been fixed as IBM SPR# KBRN8AKKA9. The technote is 1449825 and contains a lot of good info. Setting notes.ini “Disable_Random_RW_File_ATTR=1” fixes the issue.
“After Domino opens many NSF files in quick succession during a backup, the Virtual Address Space of the OS system cache may be completely used up (for example, 1TB of data may be used in this OS cache). Successive calls into the OS cache manager to get memory from the OS system cache then results in mapping/unmapping of views from the system cache. These mapping/unmapping operations takes a lot of CPU time and as a result shows as high OS CPU usage. In addition, because the large OS system cache may now reside on the disk (the RAM is not large enough to hold the OS system cache) this results in significant I/O on the system.”
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.
private void recurseHeaders(Iterator ite) {
while (ite.hasNext()) {
MessageElement elem = (MessageElement)ite.next();
String nsUri = elem.getNamespaceURI();
String name = elem.getName();
String value = elem.getValue();
System.out.println("SOAP Header - ns , name , value ");
this.recurseHeaders(elem.getChildElements());
}
}
public com.example.FooResponseType foo(
com.example.FooRequestType req) throws Exception {
MessageContext mc = MessageContext.getCurrentContext();
SOAPEnvelope envelope = mc.getRequestMessage()
.getSOAPEnvelope();
this.recurseHeaders(
envelope.getHeader().getChildElements());
}
import lotus.domino.axis.message.SOAPHeaderElement;
import lotus.domino.axis.message.MessageElement;
MessageElement elemGuid =
new MessageElement("http://lekkimworld.com", "Guid");
elemGuid.addTextNode("GuidXYZ");
MessageElement elemUser =
new MessageElement("http://lekkimworld.com", "User");
elemUser.addTextNode("UserXYZ");
SOAPHeaderElement elemHeader =
new SOAPHeaderElement("http://lekkimworld.com", "TopElem");
elemHeader.addChild(elemGuid);
elemHeader.addChild(elemUser);
mc.getResponseMessage()
.getSOAPEnvelope().addHeader(elemHeader);
http://./files/prettyprint/prettify.js
prettyPrint();