function validateAccessToken($accessToken, $refreshToken, $expiration){
// assumes the expiration is in millliseconds
if(time()*1000 >= $expiration){
syslog(LOG_INFO, 'Refreshing access_token using refresh token ' . $refreshToken);
$refreshParams = '?client_secret=' . urlencode($GLOBALS['clientSecret']) . '&client_id=' . urlencode($GLOBALS['clientId']) . '&grant_type=refresh_token&refresh_token=' . urlencode($refreshToken);
$ch = curl_init($GLOBALS['sc4sbUrlToken'] . $refreshParams);
curl_setopt_array($ch, $GLOBALS['options']);
// if the result if false, check curl_error($ch);
$result = curl_exec($ch);
// If the request is successful, the following parameters are returned in the body of the response with an HTTP response code of 200:
// refresh_token, access_token, issued_on, expires_in, token_type
$header_size = curl_getinfo($ch, CURLINFO_HEADER_SIZE);
$body = substr($result, $header_size);
if(!$result){
syslog(LOG_ERR, 'Failed Step 5');
syslog(LOG_ERR, 'Authorization server returned ' . $body);
}
parse_str($body);
curl_close($ch);
syslog(LOG_INFO, 'Obtained new access_token ' . $access_token);
return $access_token;
} else {
syslog(LOG_INFO, 'Existing access_token still valid ' . $accessToken);
// no need to refresh
return $accessToken;
}
}

Coding IBM Collaboration Solutions

Refreshing SmartCloud for Social Business Access TokensWhen using the SmartCloud for Social Business Toolkit, the OAuth 2.0 token is available for use for up to 90 days. Be mindful that this is the refresh token - not the access token. The access token that you use to make the API call will expire in two hours; you'll receive the expires_in header (2 hours represented in milliseconds) returned when you initially request the access token. Once the two hours elapses, you should then use the refresh token to obtain a new access token. Example PHP code to do so is below. One note is that while the wiki states you can use headers to obtain a new token, I've found that only the URL parameters approach is successful. But as is always the case, YMMV. |
Developer Tips: SmartCloud Businesss Support System (BSS) API
IBM
SmartCloud SaaS Business Support System (BSS) is a platform for
managing and administering processes that support SaaS services. The
primary resource for developers is the wiki as
well as a PDF version
of the same content. Additionally, the Greenhouse site hosts the BSS API
Explorer application
to execute services calls to the API as well as in-line documentation.
In addition to these resources, here are some tips on getting
started.
Familiarize with CURL before coding. The wiki suggests CURL as a
free utility tool to invoke BSS APIs. I'd suggest that a developer
start by first creating CURL scripts on the API functions that will
later be coded. For example, create a CURL script that invokes the
intended service and supplies appropriate input. This will ensure the
JSON input is well-formed and correct and provide for a repeatable
baseline when coding an application that does the same. Here is a
batch script I used for the RegisterCustomer service.
curl -k -u <your SmartCloud user name> -X POST
--data-binary @RegisterCustomer.json
https://apps.na.collabservtest.lotus.com/api/bss/resource/customer
The @RegisterCustomer.json is a file with the following
contents.
Use output as input. The wiki and PDF states that input on many
service calls is "a well formatted JSON object with the
following information." To some, it may be unclear what this JSON
object is or where one would obtain a reference. For any update, the
input is the output of a corresponding GET. Said differently, to
update the Customer profile you would:
|
API Design
In my previous post, I referenced a plugin which provides API code. The term API "code" is a bit of a misnomer. Depending on your degree of semantics, API is actually not code at all. API is your contract with external developers. It's surprising how much - rather little - thought goes into what constitutes API code. Code which leaks from a plugin through OSGI exports can create errors in design during the development process. It takes one sufficiently large software project to learn this lesson the hard way. A great podcast that explains the API concept is Episode 143: API Design with Jim des Rivieres on Software Engineering Radio.
|
The UC View articleI've blogged a few times on Sametime's Web Connect API and how it might ease STLinks integration woes. Specifics including code, performance, and architectural advances can be found in The UC View's article Teach IBM WebSphere Portal to do new IBM Lotus Sametime tricks with the Connect Web API toolkit. STLinks areas of improvement can be found in the following excerpt from the article: In migrating and testing the new Web Connect API over STLinks, the most noteworthy change was a 58% reduction in time taken to attain awareness as well as a near 600% reduction in time to browse between pages. The architectural changes away from the STLinks applet make such reductions inherent. For specifics, read the article available in The UC View available now. [Read More] |
Sametime 8.0.1 and Portal Integration Cont'd
To continue my previous post of using the Sametime Connect Web API, I and another colleague went ahead and implemented this in Portal 6.1. The concept is pretty simple, override or remove the existing Person Tag implementation such that the Sametime stlinks javascript functions are not created or called, and add a new service to the Live Object Framework to support communication with the Connect client. I believe some folks in ISSL(IBM Support Services for Lotus) have also been doing this, so it's reassuring to know that others may be benefiting from the new solution. Our results showed an almost 50% reduction in client side overhead, which is fantastic. All information on the history, advantages, and sample code will be coming out in UC² The View's publication. I've also submitted this as a Lotusphere 2009 session. I'm sure this is not the last we'll talk about integration of this type ...[Read More]
|
Sametime 8.0.1 and Portal Integration
Sametime 8.0.1 has released a complementary toolkit called the "Sametime Connect Web API Toolkit". To quote from release notes, "It allows Web developers to Sametime-enable their Web pages and applications with "livenames." Web-based applications that integrate the Connect Web API are essentially able to proxy the functionality of the locally running Sametime Client (managing contacts, starting chats, Presence status)."
First, I'm not sure I've found any public documentation on this. I'll have to check with some IBMers, but here is where I am going with this. The Connect Web API isn't a replacement for STLinks, but sure seems like a good candidate for exploring alternatives to the STLinks architecture. Everytime you access Portal, a multitude of checks occur to determine if the logged in user is "Sametime capable". If so, the STLinks applet then loads and viola, awareness, chat, endless chat requests for your help, etc. If you're using dual directory - more overhead. The most common "statement" I've heard is that once an admin enables Sametime, performance in Portal is degraded. This isn't surprising, but could the Sametime Connect Web API Toolkit could be the performance capable alternative. Likely the first obstacle to this is entitlement. There's a reason you're using STLinks and not the Connect client. If I am not mistaken, the Collaboration Accelerator package for Portal gives you web capable chat, but not the Connect client (I don't sell it, just support it). So if you've got a Connect client, it would be extremely interesting to do a conditional check to the Connect client and if present, use it rather than calling the I'd like to explore this in more detail, but if you have already experimented with this, post a comment.[Read More] |