Notes Error: Maximum allowable documents exceeded for a temporary full text index

While executing FTSearch method on NotesView class you might get an exception which says "Notes

Error: Maximum allowable documents exceeded for a temporary full text index" 

The exception occurs when Full Text indexing is disabled on the database and the number of items in the database is huge.

When we try to execute a FTSearch method on such a database a temporary Full Text index is created on the database. The number of items which can be indexed by this temporary index is set to some default value and if the number of items in the database exceeds this default value then we get this exception. We can override this setting in server's notes.ini using the following parameter 

TEMP_INDEX_MAX_DOC=number

Once we set this number to a value greater then number of items in the database the API should start working. 

More details can be found here.

~Abhishek

Accessing Lotus Notes Database from .NET

I am working on a project where i need to get some data our of Lotus Notes application and found a couple of ways to extract the data out. 


1) Easiest way to extract the data is to use Lotus Notes SDK which gets installed on the system when the Notes Client is installed. 
You can set a reference to domobj.tlb and generate a interop assembly to call the APIs. The API documentation can be found on here. 
Some of the APIs like search on the NotesDatabase doesn't seem to work and if that's the case then we can use the second approach.


2) The best part of lotus notes is that the data is exposed using ODBC. We can install the ODBC driver can be downloaded and installed from here.Once done we can use the classes from System.Data.Odbc namespace and access the items and their properties. 


Will post some tweaks when i start using these things....


~Abhishek

Resource Oriented Architecture - Part 5 (Connectedness)

One of the important features of web is its connectedness. i.e. almost all the web is interconnected through something called as hyperlinks.

So any resource which is addressable on web can be connected from another resource using a hyperlink. In an application based on ROA all the resources should be connected to each other. Connectedness can be achieved in an application if we choose the right representation for a resource. Xml is used to represent any entity in a RPC based architecture. Xml is a default choice because of the fact that it is structured way to represent the entity, hence can be easily understood by computer programs.

As of today the web service returns the data in the form of Xml to make it machine readable while web application represent the data in HTML format in order to make the data human readable. However what we forget is that there's another representation called XHTML which is nothing but HTML which is also a well formed Xml.

So if we can represent all the resources in XHTML computers can parse it as Xml while human can read it on browser as HTML. This also gives us a way to interconnect all the resources in a ROA based application using hyperlinks.

There's no such rule which says that resources should always use XHTML however that would be the preferable since it merges web application and web service and hence make the life easy.

We can still use Xml to represent the resources however in such a case the link to relevant resources should be embedded in the representation of the resource in order to ensure that the whole system is navigable if the user has link to one resource within a system.

This concludes the 5 part series about resource oriented architecture. The next logical step for me would be to design an application using ROA tenets, which involves identifying the right resources, their representation. I might take an enterprise application to do his exercise.

Hope to find some time to do that....

~Abhishek

Resource Oriented Architecture - Part 4 (Uniform Interface)

The RPC style services are very good in creating and documenting the contract. However if i look at it from a high level view i am creating a new interface for every service in the world.

Imagine this i can write so many services to manage a CRM account e.g. createAccount, updateAcccount, deleteAccount, addOppurtunity, winOptions, looseOptions so on and so forth i.e. for every conceivable action i want to take on a account i can probably create a new method in the contract. This becomes so difficult to manage when orchestrating the services to come up with a business process. Because its very difficult to understand what services can be called at what stage in a business process.

Now when i give this to a programmer who's building an orchestration using these services. There's no uniformity in the interfaces which allow the programmer to come up with a pattern or a way to know what might be possible in the system. One has to be a domain expert to work with such a system.

That's why ROA proposes to have a uniform interface which should be exposed by the resources inside a system. i.e. once you know the URL of a resource it can support upto 6 methods which are nothing but http verbs. Let's have a look at them

1) OPTIONS :- This is a metadata based verb, i.e. it is supposed to tell the caller as to what all http methods does the resource support.

2) GET :- As the name implies this would return the resource content to the caller. The format of content is another story and we'd discuss in the next tenet.

3) HEAD :- This is supposed to return the http header information to the caller. e.g. when was the content last modified. This is an important verb as based on this we can take advantage of http caching infrastructure.

4) PUT :- This verb is supposed to create or update a resource. Ideally if the request is sent to a non existant URI then we are supposed to create the resource while if the resource exists on the server then it is supposed to be replaced by the new one

5) DELETE :- As the name implies, it can be used to delete or archive the resource.

6) POST :- This is one of the most open ended verb which has been left out in http and hence the most abused one by SOA. Anyways in a ROA this verb can be used either to append content to an existing resource or to create new content where the URI of the newly created resource would be defined by the server.

All in all we can conclude that a resource can support CRUD operations using PUT/POST, GET, PUT/POST, DELETE http verbs, while a resource can define the supported operations using OPTIONS http verb. HEAD is a verb which can be used to take advantage of caching mechanism.

Now once we've this kind of system in place we've to ensure that we define our system in such a way that each entity, state or a stage of business process can be represented as a resource. So in our example of CRM system we can create 3 resources i.e. Account, Oppurtunity, Option

and then both these resources can support GET, PUT, POST and DELETE operations. So createAccount becomes a PUT request to http://crmsystem/account/myAccount/1234, deleteAccount becomes a DELETE request to http://crmsystem/account/myAccount/1234,

addOppurunity becomes a PUT request to http://crmsystem/account/1234/Oppurtunity/1,

winOptions, looseOption can become a POST request to http://crmsystem/account/myAccount/1234/Options/1

The beauty of the whole system lies in the fact that each entity has a URI and each URI supports a uniform interface. So when i give a URI of an opportunity http://crmsystem/account/1234/Opportunity/1) to a programmer in my company, at the very least he knows the following

1) To get the details of the opportunity he has to hit the URI with http GET request

2) To delete the oppurtunity he has to hit the URI with http DELETE request

3) To update the oppurtunity PUT or POST should help

4) To know what is supported OPTIONS can be used.

In this world we literally can live with these verbs and most if not all programming problems can be broken into resources. The business process orchestrations can stream line themselves around these verbs and the world might become much simpler for us as programmers :).

~Abhishek

Resource Oriented Architecture - Part 3 (Addressability)

URLs is one of very simple and powerful feature of WWW. It is because of URL that everything is discoverable and locatable on the web.

e.g. a builder putting his URL on an advertisement bill board and everyone who hits that URI gets access to all the resources about a project which builder has put on the web.

If we look at a search results of google each page of the search results is a resource and each page has a unique URL.

e.g. http://www.google.com/search?q=India&start=35 will take me to a page which would have the search results for the query "India" and the page contents would start from 35th search result.

In a resource oriented world each resource inside a system would have a unique URL to locate it. e.g. in a CRM system all the accounts would have a unique URL to navigate to them. Which basically means that all the accounts are addressable. If we shoot a "http GET request" to that URL we should be able to get details about that account.

So an account with ID=1234 can be represented as http://crmsystem/account/1234

Even a collection of accounts is a resource e.g. all the accounts from Hyderabad can be resource found by sending a http get request to http://crmsystem/accounts/hyderabad

Note the subtle difference between the URLs. The first URL contains the string account while the second one contains accounts, which signifies that the first resource is just an account while the second one is a collection of accounts.

This approach is very different from classic SOA applications where we'd write 2 web service operations called getAccountbyId(string accountId) and getAccountsForRegion(string region). Both the operations will have a single URL which would be http://crmsystem/services and can be invoked by sending appropriate SOAP envelope to this URL using http POST method. Its not really intuitive for a user or a machine as to what kind of POST requests one is supposed to send on the URL.

Another important aspect to note about this tenet is that a URL is non-ambiguous and can point to one and only one resource, while a resource can be located by using 2 different URLs. e.g. an account with accountId=1234 which is a top performing account can be represented by 2 different URLs i.e. http://crmsystem/account/1234 and http://crmsystem/account/topPerformer. In this case the URL http://crmsystem/account/1234 points to a static resource and ideally won't change while http://crmsystem/account/topPerformer is a dynamic calculated resource and can point to different resources at different times.

This tenet will closely relate to the next tenet i would discuss in my next post in this series i.e. Uniform Interface.

~Abhishek

URI, URN and URL why 3 terms

I am attending a training and an interesting question came up while discussing WCF i.e. what is the difference between the terms URI, URN and URL and most of the times we do see the terms being used in various documents and we hardly care about the fact that they are more or less different acronyms and there has to be a difference.
And turns out there's a subtle difference
1) URI :- Uniform Resource Identifier
This is like a base class. i.e. if this term is used then it can mean both URN and URL. Simply signifies that both URL and URN can be used in the context.

2) URN :- Uniform Resource Name
This is a URI which can ensure the uniqueness of a name in a given context. e.g. URN "Flat no. 302". Its unique in an apartment. but apartment name is not present in the URN. We can say that a URN can be used for identification but can't be used to locate a resource without a context

3) URL :- Uniform Resource Locator
This is a URI which can be used to locate a resource. This also is a URI and can ensure uniqueness alongwith the mechanism to locate it. e.g. http://luckyabhishek.blogspot.com is a URL which is unique and also communicates the mechanism to discover/locate it.


Interesting and subtle differences pointed by Ramkumar (Our instructor)

Let me go back to training now as Ram has already figured out that i am not listening to him and doing something else. Alas .. he'd not know that i am blogging the discussion we just had ....

~Abhishek

Unit Tests for registry read fails in Visual Studio on 64 bit machines

My my my...
A hotch potch of Windows Server 2008 and Visual Studio 2008 on a 64 bit machine killed my 3-4 hours today...

So here's the deal
I've a method in one of my dlls which reads a certain value from a sub key of HKEY_LOCAL_MACHINE\SOFTWARE Then i wrote a unit test to test this method. Turns out it fails to read the Registry. I was amazed because registry entry did exist in the registry. After struggling for about an hour or so i decided to write a console application to test the method. And the method worked :O. So now i was in a situation where a method works from the console application while fails from a unit test.

I thought that its a permissions issue so i gave full trust to both the assemblies i.e. unit test assembly and the assembly i was testing. Even that didn't help.
Looking at the task manager of the system i saw that the unit tests run under a process call VSTestHost.exe. So next i tried to give full trust to this exe however that's not possible since it is a win32 exe.

A relook at the Task Manager showed me that the process runs under VSTestHost.exe*32 means a 32 bit process running on a 64 bit OS. Nothing suspicious about it in the first look. However if you look at the nodes below HKEY_LOCAL_MACHINE\SOFTWARE in the registry you see a node called Wow6432Node and that made me think. After some search i figured out that if you run a 32 bit process on a 64 bit machine and try to read the subkeys of HKEY_LOCAL_MACHINE\SOFTWARE The registry reads are actually directed to HKEY_LOCAL_MACHINE\SOFTWARE\Wow6432Node. So i made an entry in this node and it worked.

Lesson :- Be careful while working with registries if you depend on registry for your program to work.

Happy coding :)

~Abhishek