CRM 2011 Beta :- Creating large number of Options in an Options Set

So its been ages since i wrote anything in this space and i feel terrible for not being committed. However that's not the point for which i am here today.
I am here to share a small utility which can help you in developing applications on Microsoft Dynamics CRM 2011 Beta
Recently i have been working on creating a SIF compliant data model using CRM 2011 beta for an education domain offering. While trying create the Options Set for this data model i realized that some of the options like country, Language etc. have up-to 450 (or more) options. So creating an Options Set becomes a time consuming and error prone process.
So me and one of my colleagues (Nishant Rana) decided to write a utility which would help in creating the options in an options set by using CRM 2011 metadata service. The source code for the utility can be downloaded here.


In order to compile and run the utility you would need CRM 2011 SDK on your box. Once you run the utility you would see a form which looks like :- 

 The input values to the form are 

      1) User Name :- This is  a CRM User Name who has the permission to update the options set

      2) Password :- The password for the user

      3) Domain :- Domain of the CRM Machine

      4) Organization service URL :- Replace the server name and port in the given URL

      5) Seed value :- This is the integer value which would be given to the first option in the text file    . Other options values would be seed value +1... seedvalue + n

      6) Options Set Schema name :- Name of the options set in the CRM schema

      7) Select File :- Select the text file which has the options in it.

      Happy CRM 2011 coding to all of you. Do share your comments/feedbacks and thoughts on the utility.

   ~Abhishek

WCF Client The underlying connection was closed: The connection was closed unexpectedly.

There can be several reasons as to why we get the exception "WCF Client The underlying connection was closed: The connection was closed unexpectedly." on a WCF client. However i hit an interesting reason today.
So here's how my code structure was

[OperationContract]
Response ProcessRequest(Request request)

[DataContract]
enum SomeEnum
{
    [EnumMember]
    Value1 =1,
   
   [EnumMember]}
      Value2 =2,
}

[DataContract]
class Response
{
    [DataMember]
    string Message;
    [DataMember]
    SomeEnum EnumValue;
}

Now in my implementation i was trying to send a Response object which looked like
Response response = new Response(){Message="Some Message"};
return response;

Now this compiled fine and looked like it would work great however when i called the method ProcessRequest from my WCF client i got an exception message with the text "WCF Client The underlying connection was closed: The connection was closed unexpectedly.". There's no visible and obvious reason as to why this must be happening.
On enabling the WCF tracing i found that the error is in serializing the value of SomeEnum in this response. Apparently the Enum has nothing with value 0 and hence the framework is not able serialize the Response.
Apparently WCF server stack eats up this exception and closes the connection to the client. The exception doesn't even show up on visual studio and hence it is almost impossible to detect what's going on unless we have a server side tracing enabled.

Speaking at the Developer Summit

All, 
I am speaking at the Great Indian Developer Summit on RESTful services. You can check the details of the session here. 
You can see the snapshot of the session created by the GIDS people on the right. 
I love the snapshot for sure :). 


See you all at Developer Summit at IISC Bangalore on 20th April....


~Abhishek

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