Last year I did an N-part series about working with HealthVault XML APIs. It was implemented with ruby on UBuntu Linux system using OpenSSL. I got time to go mark all those articles with next links and I thought i would summarize the series here:
One of our partners has also implemented Drop Off Pick Up solution in ruby using the above articles. Hopefully sometime in near future, I’ll convince them to do a blog post about the same.
Folks trying to talk through raw xml layer with HealthVault have asked this a few times – so i thought I’ll put it up here, thanks to Rob for digging the XML.
The key to do a PutThings for an application in offline mode is the following snippet in the auth-session:
11111111-1111-1111-1111-111111111111
An application with OfflineAccess is ready to publish data in a users record once it successfully does the CreateAuthenticateSession call. Here is a sample PutThings call:
Alrite now that you have the firewood (application auth token) and the firestarter (user auth token) how can we start the fire (get details user’s record).
Well first of all congratulations! most of the hard part is done!! Just a few more nitty gritty tricks though! In order to get the details about a user’s health record, you need to use a method GetPersonInfo.
So now do we go about concoting the seemingly complicated xml above. Well we already have the token and wctoken from our previous CreateAuthenticatedSession and Shell -redirect. Use the token for the auth-token in line 9 and the wctoken as user-token in line 10.
Most of the elements in the header section are straight forward. The one to comment about is hash-data (line 18). The hash in this case is SHA-1 hash of the info section. Matter of fact our info section is empty so that make sure that the SHA-1 hash is done right. In ruby i do it the following way (using OpenSSL):
def self.doSha1(text)
Base64.encode64(OpenSSL::Digest::SHA1.digest(text)).chomp
end
Now the interesting part – whats this auth on line 2? Well auth is a HMAC of header (line 5-20) section. Remember we generated the shared secret in CreateAutheticatedSession method? Now use that secret to do a HMAC digest for the header. In ruby i do it the following way:
secret is the shared secret used for createauthenticationtoken.
Now the fun part,caveats:
Don’t leave any white spaces between you xml tags. HealthVault behaves weird sometime when their is white space.
If you are getting an error saying code 3 (which implied invalid xml) and you are sure that your xml is correct, then most likely your auth section or your hash-data section are not proper. Which in turn implies that your HMAC-ing or SHA-1 hashing is a little off. The best way to actually resolve this is to first write tiny parts which make sure that the HMAC /SHA-1 is same for a known successfully call. You can get the xml for such a call from HealthVault SDK, the process is described here. However for ease of testing i’m appending know good calls below.
PLEASE NOTE: Remove all the white-space between tags before testing your crypto functions to match the result seen here. I have put the white space for readability.
Sweet!!! you wanna check out th lighted application? Well its live… (Please Note: it will prompt you yo sign in with HealthVault id, its still rough around edges and doesn’t deal with corner cases).
So lets see your LAMPR application lighted up soon..
My previous post with regards to writing the HealthVault Ruby Library demonstrated how one goes about authentication their application with HealthVault. Now that you have successfully gotten HealthVault to trust your application how do you make sure that the user who logs in is a valid user. In the HealthVault lingo this is called user authentication.
To successfully do a user authentication, an application must:
Redirect the user to HealthVault shell sign-in page.
Receive a token identifying the current user on a pre-registered URL with HealthVault, and use that token to do any user related transactions with HealthVault hence onwards. This token is valid for 20 minutes.
Now, in code it looks like follows lets assume that you application has a pre-registered URL of http://localhost:3000/healthvault/redirect. When a user wants to login, you actually redirect them to HealthVault shell (http://account.healthvault-ppe.com/redirect.aspx) in the following way:
Note the parameters target, appid & redirect in the above URL.
The above redirection once successful will send the user to the page http://localhost:3000/healthvault/redirect. On this page you should read the wctoken from the URL query-string. In ruby I do this the following way:
def redirect
if (request.query_parameters["target"] == "AppAuthSuccess")
session[:wctoken] = request.query_parameters["wctoken"]
redirect_to :controller => 'healthvault', :action => 'index'
end
end
Voila!! you have the much needed wctoken. In the next article we will what can we do with this magic wctoken!
HealthVault SDK provides a very useful feature to check under its hood! One can turn-on the tracing for the SDK very easily. The trace log is very helpful for
Debugging the SDK
Looking at the raw-xml exchanged between your application and HealthVault platform. The Raw XML in turn is very useful if you are:
Trying to write-xml in the thing types
Trying to write a HealthVault wrapper library in you favorite language
Just curious to look under the hood:)
To look at the trace log add the following in configuration section of your web.config. One you run you application with settings below, a sdk.log file will be generated in the base directory of the website. You can also provide an absolute path for sdk.log to a directory where you web process has a write access.
NOTE: In case the file doesn’t get generated, make sure your web process has write access to the directory sdk.log is getting generated in.
![Reblog this post [with Zemanta]](http://img.zemanta.com/reblog_e.png?x-id=7b7dc416-c01b-4627-9d38-76d92da8418c)
