Home › Blogs › Tom's blog ›
It's time to check your applications' compatibility with OpenCalais 4.1

Submitted by Tom on Fri, 06/05/2009 - 13:36.
in

We’ll be releasing version 4.1 of OpenCalais on Monday 15 June (and Release 4.2 about three weeks later!). This release has a number of new features – but for the moment we want to focus on making certain it is backwards compatible with your existing applications.

Beginning now, version 4.1 is exposed for compatibility testing at the API access point of http://beta.opencalais.com. Just point your application to this address, make sure everything works and then point back to the default http://api.opencalais.com.

This beta will be available until the morning (EST) of June 15. At that point we’ll be rolling out the upgrade of OpenCalais across all of our server locations, and the beta servers will be retired.

What new in 4.1?  Well – that’s a secret until we release on June 15. At that time we’ll publish another blog post, updated documentation and provide release notes. A few hints: a new language, social content tagging and semantic metadata uniquely tuned to current events.

Teaser: 
Now is the time to compatibility-test your OpenCalais applications.
Bookmark/Search this post with:
  • Delicious
  • Digg
  • StumbleUpon
  • Reddit
  • Technorati

Trackback URL for this post:

http://www.opencalais.com/trackback/23169
It's time to check your applications' compatibility with OpenCal
from NewsPeeps on Sat, 08/08/2009 - 17:53

Thank you for submitting this cool story - Trackback from NewsPeeps

Login or Register to post a comment.

Comment viewing options

Select your preferred way to display the comments and click "Save settings" to activate your changes.

HTML problem fixed

Hello again, John,

The HTML-yielding-empty-content issue surfaced over and over, so we applied a silent hotfix to Beta.

So, lets go back to square-1 :  please re-test your client against Beta, using the "text/html" content-type, and see how it works for you.

HTMLRAW is still supported, but I would use it as a "last-resort" bailout.

Currently there is no upfront way of telling which version is used, but that shouldn't be a problem: pretty soon they'll all be 4.1 ...

(almost no side-by-side period, except for the current week-or-so)

 

Meir


Meir Wed, 06/10/2009 - 04:13

HTML problem fixed

Thank you for the HTML fix. Since our application is deployed at various customer sites, we need to identify any necessary changes to our application during beta so that we can re-deploy our application if necessary to our customers prior to your new version going into production. If a known incompatibility is identified during the beta that will persist into the next production release, it is important that we make a code change in a way that will allow us to re-deploy our application prior to the switch-over in a way that will work both prior to the switch-over and after the switch-over. We cannot require each customer to flip a switch at precisely the moment you end up putting the next version into production.

This "text/html" vs "text/htmlraw" is a perfect example where it appeared that our application would need to function differently running against Calais 4.1 than it does against Calais 4.0. If that were to be the case, we would need to code our app to determine which Calais version we were running against and pass "text/htmlraw" if later than version 4.0, and then deploy that revised app to customers prior to the switchover to 4.1. After the switchover, we could of course remove the code that was specific to version 4.0.

So knowing the Calais version is only needed in order to provide a smooth switch-over experience where customers don't all need to "flip a switch" at the right time in order to avoid a period of erroneous results.

We are running tests against the 4.1 beta using the original "text/html" as you suggest, so there may be no need for version-specific coding to give our customers a smooth switchover to 4.1. I see where you have posted elsewhere a suggestion for obtaining the Calais version via error message if needed.

Thank you for all of your replies. They are very helpful and right on target.


johnbuuck Wed, 06/10/2009 - 11:50

Beta URLs

Hello John,

Meir here, from the Calais team.

Sorry for your frustrating experience with the current Beta.

I hope we can get that sorted-out quickly.

The first thing you need to know is that the R41 version is based on a new java-based web-services layer (Axis1.4), as opposed to the former .NET-based webapp.

(this is for internal reasons: platform independence, etc.)

We maintained the older endpoint URLs, including the "calais.asmx", but this was kept only as the runtime SOAP endpoint URL .

The asmx URL does not include all of the .NET asmx "sugar", such as being able to invoke the methods from the browser, or creating a .NET web-ref based on the asmx URL.

So, although some URLs appear as a .NET endpoint, they are not;

However: These URLs should work at runtime, with your old clients, though.

 

Secondly, there is the issue of using the correct URLs here:

Lets clarify some of the URLs:

The SOAP endpoint is

http:/beta.opencalais.com/enlighten/

(OR http:/beta.opencalais.com/enlighten/calais.asmx , but its best if you drop the asmx part)

The WSDL resides at:

http:/beta.opencalais.com/enlighten/?WSDL

Please create your .NET web-ref using this new WSDL.

 

Aso, shorter URLS then the above, such as

http:/beta.opencalais.com

are out-of-scope: please do not use them from any client, including your browser,

as their response is undefined, and may change.

 

Thirdly, about the error you get ("ErrorCode 101..."):

This error is coming from the new R41, meaning you successfully communicated to R41.

This error is knew and is a known issue: you most probably submit plain-text using the  HTML content-type. The latest HTML-cleaning feature yields an empty input text, and hence the error.

Please test your app with another conetnt-type  (you can use "text/htmlraw" for the exct same results you got previously for "text/html", or you can use "text/txt" for plain text)

 

Please let me know if this was any help at all,

Tx

Meir

 

 

 


Meir Tue, 06/09/2009 - 12:03

Beta URLs and content-type

Your response is extremely helpful. I do find that changing content-type to "text/htmlraw" does solve my problem. However I see that that content-type is rejected by the current 4.0 production service. Is there a way for my application to detect which production service (4.1 or 4.0) it is talking to so it can know whether "text/htmlraw" will be acceptable?


johnbuuck Tue, 06/09/2009 - 13:12

The request failed with HTTP status 404: Not Found.

Is the http://beta.opencalais.com supposed to be up yet? It fails with a 404 for me every time.


johnbuuck Mon, 06/08/2009 - 18:55

Beta site

John -

Apologies if we weren't clear. Point your application to http://beta.opencalais.com (but don't simply paste the url in your browser - that will generate an error message).


FranSan Tue, 06/09/2009 - 09:08

Beta Site

I, too, wasn't clear.

Specifically, I participated successully in the 4.0 beta program and still have a Web Reference in my application to "http://beta.opencalais.com/enlighten/calais.asmx" . When I point my application to the beta uri rather than the "http://api.opencalais.com/enlighten/calais.asmx" uri, I get

<Error Method=\"ProcessText\" calaisRequestID=\"68f05332-0524-e48a-121c-53024b0619ad\" CreationDate=\"2009-06-09 09:23:35\" CalaisVersion=\"R4.1_7.1.1103.5\"><Exception>An error has occurred during an attempt to invoke the Calais Backend-Server: 'Error Code: 101. Invalid argument passed to method [description = 'content must contain some data.'].'<Exception>Error Code: 101. Invalid argument passed to method [description = 'content must contain some data.'].</Exception></Exception></Error>

response. This is when passing my standard very simple test input arguments as follows:

apiKey=<same api key I have been using>

content='Bush is president of the United States.'

paramsXML='<c:params xmlns:c="http://s.opencalais.com/1/pred/"><c:processingDirectives c:contentType="text/html" c:outputFormat="xml/rdf" /><c:userDirectives c:allowDistribution="true" c:allowSearch="true" c:externalID="1" c:submitter="TestCalais" /><c:externalMetadata /></c:params>'

If I make this same call to the "http://api.opencalais.com/enlighten/calais.asmx" uri or the "http://api1.opencalais.com/enlighten/calais.asmx" uri, I get the expected RDF response.

If I enter the http://beta.opencalais.com/enlighten/calais.asmx URI in a web browser or in an "Add Web Reference" dialog in Visual Studio 2008, I get

enlighten/calais.asmx

Hi there, this is an AXIS service!

Perhaps there will be a form for invoking the service here...

with the additional information in the "Add Web Reference" dialog of the following:

The HTML document does not contain Web service discovery information.
There was an error downloading 'http://beta.opencalais.com/enlighten/calais.asmx/$metadata'.
The request failed with HTTP status 404: Not Found.

Whereas if I enter the "http://api.opencalais.com/enlighten/calais.asmx" uri in a web browser or "Add Web Reference" dialog, I get the expected

 

I can't imagine something on my end causing this behavior. Can you confirm that developers completely outside firewalls, etc. are getting access to http://beta.opencalais.com/enlighten/calais.asmx ?

The following operations are supported. For a formal definition, please review the Service Description.


johnbuuck Tue, 06/09/2009 - 09:54

Beta site

John -

Your input is a pretty short sentence - not much for Calais to chew on - but I'm not the person to troubleshoot this. I've asked the technical team to respond.

Regards, 


FranSan Tue, 06/09/2009 - 10:04

Beta

I'm sorry the formatting was messed up on my previous post. The main point though is that entering the beta uri into a browser to query the service description gets an error whereas entering the production uri into a browser to query the service description succeeds.

Can someone look into that part of the issue (outside any firewalls)?


johnbuuck Tue, 06/09/2009 - 10:15