Migration Strategy and Solution for multiple Document Management Systems

Today I am going to write my experiences with a project which involved migration from one document management system to another.
Actually,  there were three different DMS's that were involved. The problem was to migrate the multiple GBs of content from 2 different DMS to a 3rd one. It was was something like centralizing the documents stored across different locations of an organisation to a central DMS.
This looks like a current general trend in the industry as it makes more sense for them to manage the data centrally.This not only helps them in storing it but also helps in applying policies, workflows, software upgrade and IT policies, patches etc while adding another level of security to the enterprise data when stored centrally.
The approach for this task of migrating the documents is achieved using the respective APIs of the concerned DMS. We built utilities which connects to the server of respective DMS and fetches the data and copies the documents along with their metadata in a an XML file while the documents gets copied using the same APIs to a temporary location (shared folder).
The target DMS is also accessed via its APIs for copying the documents and the metadata from XML while performing check-ins for each document from the shared folder.

Now these operation s are not that easy as it sounds because we had several thousands of documents which needed to be downloaded and uploaded only in small batches, otherwise the operation may stop or get terminated by the host operating system processes automatically allowing this task to never get completed.

But with careful planning and execution using schedulers enabled the task to get completed in smaller chunks and therefore the entire job was completed successfully.
 Just note while writing your custom utility give proper administrator rights and the correct url of the server and document libraries in the respective document management systems.

Solutions Architecture and Proposals

A Solutions architect is person who is not only a technical architect in a field but is also a person who can provide all kinds of Solutions related to that technology or related technology stack.

Generally, a solution architect provides the complete solution for project proposal. An SA can be a guy who can use multiple technology, tools and apply respective design customization using the same to provide a compelling and cost effective solution for business or enterprises. 

Say for an example a solution could be something like using Microsoft Technology stack to provide a complete range of functionality for an enterprise. It could be like Using Windows server, SQL server, Active Directory, Exchange, SharePoint, ASP.Net, Dynamics CRM, BizTalk, Lync and likewise. 

Being a Solution Architect for the Microsoft Technology stack means understanding all the related technology well, and also knowing how and where to apply these for providing a Solution to any business. The solution and design should not only satisfy the functional requirements of a Site but may also enable a business the necessary Business Continuity and Growth. 

SharePoint 2013 Hosting Options

SharePoint has become one of obvious choice of technology for enterprises these days, not excluding the option of using it as a platform for all custom applications, including the rich set of APIs it provides for building custom solutions. Almost all the small-mid to big enterprises are using SharePoint for organizational and business needs.
With the launch of SharePoint 2013, many enterprises are still not able to realize about the actual scope of it along with the backward compatibility provided for solutions built using SharePoint 2010 model/APIs. This is because the new app model and services provided in SharePoint 2013 makes many of the development made in the older version of it to become absolute obsolete. For example, SharePoint 2010 Search, SharePoint web services, the custom UI / branding done in SharePoint 2010 including others, also if you want go cloud then SSOM is also obsolete as CSOM becomes the new way.
My this post helps such audiences to understand the scope of SharePoint and gives an idea where to fit it and what to do with the earlier customization done in SharePoint 2010.

You will be surprised to know that the basic idea of Microsoft in it's latest release of SharePoint is to move away the development out from the SharePoint server. The apps for SharePoint is to be actually hosted in the remote cloud server particularly Microsoft Windows Azure and databases in SQL Azure. But it is not to be hosted in Sharepoint server and this is just to improve the performance of SharePoint server in the cloud environment. To access these apps from SharePoint, the CSOM - Client Server Object Model is used. This only makes call to the remote apps using JavaScript apis or the REST services API and the result is viewed in the SharePoint pages.

In SharePoint 2013 we are left with the 3 options or modes of hosting. These are:

1. In Could - Everything comes from the remote cloud server and is also stored there. It is also known as Auto Hosted App model.

2. In House - Here the model is like SharePoint 2010. The code runs from the SharePoint server but in a separate domain. This is known as SharePoint hosted.

3. Hybrid Hosting - We can still have some apps running in SharePoint server and also some apps hosted in cloud or remote server hosted by the organization itself. This is a combination of SharePoint Hosted and Autohosted apps.


So as we now see the solutions in SharePoint 2013 will be in the form of apps which can be hosted in house or on premises and also to the cloud. There are basically 3 different types of Apps provided to SharePOint developers and these are:
a. Auto Hosted
b. SharePoint Hosted
c.  Provider Hosted.

The Provider hosted model has two flavors that means that we can host the app in on premises but in a separate physical server where SharePoint does not rum as well as we can also host it in a 3rd party cloud like Amazon, Rackspace, GoDaddy.
I will discuss the architecture and programming model SharePoint apps in the coming posts.

Working with SharePoint Content Types

Recently I had some strange experience while working with Sharepoint Content Types. I used Content Types while creating a custom workflow for Sharepoint 2010 using Visual Studio. The Content type was defined with various fileds with display names, internal field name and their respective unique GUIDs. The workflow was good and got deployed successfully in a site collection. Again, I had to create a new workflow which was suppose to use the same list column names. So I thought of using the same Content Type with same Content Type ID, field names, etc. actaully, the entire xml file schema which contains the defenition of that content type was resued in this new new workflow. Now this workflow was deployed in the same web application but on the different site collection. So it was something like this:

WebApplication : http://myWebApplication:1234

Site Collection1 : http://myWebApplication:1234/GCIndia/ - Uses Content Type .. WorkflowContentType1

Site Collection2 : http://myWebApplication:1234/GCAsiaPacific/ - Resues the above content type

I resued the same content type because the workflow was suppose to have same feild values and also sam e names had to be included.

Now when I deployed the second workflow both the Content types should have been deployed in their respective site collections but to my surprise I was unable to activate the feature which was suppose to activate second workflow's reused content type. I was surprised to see to what happened as both these site collections had different content databases. This was because Site Collection1 was created and migrated from Sharepoint 2007 and Site Collection2 was created using Sharepoint 2010 environment post migration.  Ideally both the content types shoould have worked correctly becuase they were residing in differnet content database. I tried to recreate this scenario in my Dev box by taking the backup of relevent production data in to it. Then I was able to see both the deployments working. Now the conclusion is that the Databases have been merged at the production level as Microsoft does not all same content type ids to be used in two Content type defenetion.

Continued...

Migrating SharePOint 2007 Workflows to Sharepoint 2010

Hi folks, I am back again with yet another post and I will be talking about migration of sharepoint workflows from 2007 to 2010 environment. Now for migrating sharepoint 2007 site and apps to 2010 environment, one of the most popular and logical way used is database detach and attach method. Details mentioned below:
Step 1: Create same sites with same structures in Sharepoint 2010 environment.

Step 2: After taking the backup of the SharePoint 2007 content and other databased exlcluding the Config DB, detach the databases from thir respective sites.

Step 3: Move the Content DB's to SharePoint 2010 environment and replace the Content DB;s of newly created sites with the these DB's from SharePoint 2007 env.

Step 4: Now after attachig these databases to the content db of the new sites and apps in new server you will find all the content and sites running in SharePOint 2010 environment updated!

Here you complete the process of migration but all is not done yet. It is because when you use some third party controls, tools or software or even the FBA authentication in your sites it will require you some extra efforts to enable them back in SharePoint 2010. In this post I will be focussing specially on Workflows.

So once the above steps are done we are left with migrating the code. You may follow the simple steps metioned below. I would like you to read it all once before going to make any actual change. Also note that the steps are not actually long but I have divided them just to simplify things!

Steps:

1. Create a Sequential Workflow using Visual Studio 2010 in SharePoint 2010 dev machine. Please note to use the same name of the list or document library in which the workflow is currenly running on the SharePoint 2007 environment, otherwise the workflow may not work!

2. After you create the workflow in SP 2010 using Visual Studio 2010 you will be left with the basic template and folder sturcture in Visual Studio Solutions view. Please also note that you choose Farm Deployment while creating Workflow and not the Sandbox solution.

3. Now, copy the SP 2007 project developed using VS 2008 to the SharePoint 2010 machine where you are creating the workflow and want to migrate the code to current environment.

4. Right Click on Visual Studio 2010 solution from the Solution explorer to add an existing project. Under this browse to the location where you have copied the Sharepoint 2007 workflow project and finally add it in the VS 2010 solution.

5. Delete the contents of the Worklfow.cs file and other related files from the Workflow folder in the VS 2010 project. Please don't delete the folder. Now drag-and-drop the workflow.cs and other contents of the same workflow folder but from the Visiual Studio 2008 project into folder where you just deleted the contents (VS2010 project).

6. Once you are done with that, create a new folder structure by adding a new folder in the newly created project of (SP2010). Create a folder '14' and then beneath it 'TEMPLATE' and under that 'FEATURES'.

7. Under the features folder Drag-and-Drop the feature folder(s) with their xmls from the SP2007 project to SP2010 project.

8. Now Add all required web references in the SP2010 project which your code might be using or referring.

9. Remove the SP2007 projects and it's contents from the VS2010 solution.

10. Now you may change the namespaces in each file according to the newly created namespace in VS2010 or you may alternatively change the names space of VS 2010 solution with respect to the name spaces you used in SP2007 worklow. I did the later because it was easier and time saving.

Now build the code and you are ready to go!

In case you are creating a new Assembly key you will have a new public key generated for the dll and therefore, please remember to reference it in all the aspx pages.

How to do Bulk Approvals in Sharepoint custom workflow developed using Visual Studio

As you might be aware that Sharepoint is a great tool which is used by almost all enterprises these days. One big & solid reason as why it has become such a hit is that, it integrates well with the Microsoft's infrastructure which can't be ignored! The other, it helps the enterprises to enable their business process smoothly and enforce the same among it's emaployees to carry out their operations properly. In face we ca say that the businesses run on Sharepoint if it helps to business to operate properly!
One of the most popular use of Sharepoint 2007 / 2010 is enabling business process in an organization using worklows. Sharepoint allows great ways to customize and build enterprise class application and business process to be converted in an easy to use, familiar, well integrated secured infrastructure of Micorsoft.

I have been involved in developing workflows using Sharepoint for over 3 years by now. Recently, my team got a requirement from the business that required workflow approvals to be done in bulk i.e bulk approvals of sharepoint workflows. You might me thinking of it as complex scenario as we also thought it like that. But, to my surprise and intuitive guess it turned out to be a whole lot easier! I will explain below what I did in simple steps to you:

1. I used a Grid View control to display all the tasks assigned to an approver in a new page.
2. Put Check box control to each row in the grid view and placed Approve and Reject buttons at the bottom of the page.
3. Next step was to get all selected tasks in a for loop when the user selected tasks using check boxes from the grid view and clicked Approve or reject button. (pretty simple so far!)
4. On button click I took all the grid view rows in the loop and catched the selected rows ID.
5. From the ID of the task I used AlterTask () method to call On Task Changed activity code/functionality. I set the boolean variable to true in case of Approvals and false in case of Rejection. I used this boolean value in my workflow logic to move or proceed the workflow to the next level in case it is True, and terminate or stop it in case it is Rejected (boolean value False).

To my surprise my code worked wonderfully and all the tasks got approved and rejected very smoothly!
Note the key here is to fire the AlterTask() for each selected row in the grid which we use anyways to fire the ChangeTask Activity using the task approvals or task edit forms.
I tried to Google it a lot before trying out this idea by using keywords like Bulk approvals of sharepoint workflow or batch approvals of sharepoint workflow tasks but I didn't get any clue. Finally, I tried this POC and it worked. I am sharing the same so that you may not have to stumble upon much.

Please note that the above solution presented is developed for SharePoint 2007 using Visual Studio 2008. Please feel free to contact me in case you need the working code also. Happy to Help!!

Mobile telephony basics - Routing and Processing of data via Mobile phones

Location Based Services or popularly known as LBS is a current buzz in the Mobile telephony segment. Almost all major telecom players are providing LBS services to their mobile phone users. In this post I am going to discuss the LBS architecture  in brief and try to explain the working of Mobile Phone architecture.

The mobile phone handset operates on radio frequencies, that means the input and output data through a mobile phone is only in the form of radio waves when said on the most simplest terms. The data transfer standards are defined for bringing uniformity in data sending, receiving and to perform operation on the data generated by a user though the mobile phone. This standard or set of protocols is called as WAP. Wireless Application protocol. All phones send data using WAP. In internet the protocol is called HTTP - Hyper Text Transfer Protocol.

When we send any data via our phones it goes to the nearest Mobile Phone tower. From that tower it is send to the service stations where the telecom operators servers are kept. These stations have web servers plus application servers. before the WAP data format is fed into Web servers it has to be converted to HTTP format for processing by the application servers. This conversion of WAP data to HTTP format data is done via WAP gateway. Once this is done the user's request send via mobile phone is fed into the application servers and corresponding information is searched and returned which the user has asked. Again, when the information returned by application server is in HTTP format, it gets converted to WAP data format and then finally receives the mobile phone after getting routed through the towers.
Each WAP data sent via mobile phones contains some header info. This header info contains the location of the mobile phone where it is currently located as the mobile phone owner may continuously keeps changing locations. The location information of the mobile phone is registered in the tower where the mobile lies. The packet header is then routed to the corresponding tower after matching the packet header and the mobile phone current address registered in the tower.

This completes the cycle of request sending and receiving via mobile phones.