A month ago, one of my developers left for a new opportunity with another consulting firm. As project manager, I had to develop a transition plan for him to transition his activities to another developer. Looing at my team, I have a business analyst. She could not do it. I have an intern recently hired as a full time employee. Background is business school, not a developer. We have a support person, but no development experience. My one developer is allocated 100% to a critically important project. I have a SharePoint architect and then it leaves me. Yes, the activities would transition to me. As soon as I finished the plan, I was informed that we were approaching the end of the fiscal year and hours would be cut from my team, specifically, my developer could not bill to the contract. So much for a transition plan.
Now, I have time to look at the application. I have not done development for a while, but I am plunging in head first, studying on the weekend and try implementing what I learned during the week. I have to reverse engineer from an existing “administratively deployed” InfoPath form. The original developer, we will refer to as PJ, wrote code-behind in the form. We are upgrading to SharePoint 2013 and implementing Microsoft’s Product Line Architecture (PLA) which imposes the same rules as Office 365. The InfoPath form and all administratively deployed forms will not be migrated to the new environment by policy imposed by the PLA. The InfoPath form would need to be redeveloped and the code behind replaced with Nintex workflows. I am struggling if I should replace the InfoPath path form with Nintex forms. I have decided to work with InfoPath and later try redeveloping InfoPath into Nintex forms depending on my ambition and available time. The first attempt action was to open the form and strip out the code-behind and redeploy without an administratively deployed form. The InfoPath form would not open. So, the first discovery is that the form would need to be redeveloped and we would have to migrate data as well. We have a Meta Vis tool that migrates and moves content and this should do the work of migrating data. Fingers crossed!
Frustration #1: migrating applications to new versions of SharePoint is difficult. It involves re-working the application. It appears that even pieces cannot be used and the whole application needs to be redeveloped. For this project, we refer to “Technology Refresh”. We can’t let the customer know that the application we just delivered needs to be re-written. We will have fun upgrading sandboxed solutions, InfoPath forms and SharePoint Designer customizations in the next version of SharePoint!
So, I am working on the InfoPath form. The developer that just left, we will refer to him as IS, had developed the form using a list. The original application was developed by PJ used Forms Library with a bowser enabled form.
Frustration #2 Why InfoPath was developed for client applications forms or browser-based forms? Just develop one method that works rather than two approaches with different functionality working here but not there. Functionality that works in some cases and not others.
So the original application was a browser based form using code behind and a forms library. I rebuilt the form without code behind. We had a folder structure of committee names. This was a client requirement and now we have concerns about the length of folders. It seems logical that to have a short physical path for the folder with a friendly name. Anyhow, after building the structure of folders, I discovered that InfoPath always saves the form in the root of the Forms library! It does not save it in the folder. After research, I found that I would have to create a workflow to place the InfoPath form in the folder. But, I have not captured the path that they have created the new InfoPath form. The original developer had used code behind to save the InfoPath form, so he was able to solve this problem or more than likely never had the problem in the first case. He also used code behind to send all the e-mails for an application. If you customize the interface for a list using InfoPath, you can save the list item in the folder where you created the list item. Back to customizing the form for a list.
Frustration #3: Why do you get nonsensical behavior with folders? I have referred to such functionality as a SharePoint- “ism”. Don’t waste time trying to make sense. There is viral video “Ain’t nobody got time for that!” Link
So, back to the form. IS created a form based off a list. He did not use the same columns as the original developer. All the columns were renamed. I now have to decide to try and use the new list or create another list using the same columns as the original application. I decided to create a new list based off the original form, but would refer to the previous developer’s work to see how he solved problems. This made development time extremely laborious, time consuming and error prone. IS also did not want the form to open in dialog. I do not know why. That was one of the first changes I implemented. I also discovered that InfoPath and lists handle data differently. For example, Yes/No in a list is handled differently in InfoPath (True/False and 0/1). I also found that working with the User Interface was challenging. I created a background image with organizational branding and then when it opened in the form dialog, it would be off center. I wanted to upgrade the interface – but found simple changes resulted in hours trying to get the interface to accommodate simple design implementation. It is not so simple.
I have created a document called developer notes. I have tried to document every step of rebuilding the application. I have documented the lists, the columns on the lists, the values, any calculations, default values, value ranges, validation rules. In the old days, we called this a data dictionary. I have documented all the controls and rules tied to the controls. Does anybody do documentation anymore? In addition, I spend hours researching problems sifting through blog posts and bulletin boards and get hints, but in most cases, incomplete solutions or just close, but a slightly different problem that I cannot seem to bridge. Again, I do not claim to be an expert developer, an advanced business user is the limit I recognize for myself.
Frustration #4: Product documentation sucks! Today, we are expected to go out on the Internet and search through blogs. Obvious problems are obscured and deep in search results. I had one blog that solved my problem and got to the implementation and referred me to his book. It would be a damn cold day in hell before I would ever buy his book!
I am now working and documenting the workflow. The workflow is three workflows with the first workflow setting up a document library where the application saves all the documents. There are two folders – Draft and Final. That seems reasonable. The first workflow creates the folder structure. Folders are used to apply security. That is why the form is created in a folder. Only committee members have access to the folder of their committee. When the form is created, it immediately creates the folder structure in the document library of “Committee Name/Form Name/Draft” and “Committee Name/Form Name/Final”. The developer that recently left had developed a workflow that created a folder path without the committee name and appended ID to some text. It was an incomplete solution. Getting the committee name from the folder of the source list folder was challenging. Since the user had selected a folder based on committee name, they were not going to select the committee name in a drop-down in the form. I found the “path” function in SharePoint Designer workflow that provides the path. It gives the path of the list item with the full URL including the folder. I could do a string manipulation to get the committee name after the create event. First problem, it is slow to update giving less than optimum user experience and we use NINTEX workflows. About a ear ago, we acquired NINTEX for our SharePoint and it was a great enhancement to our infrastructure. NINTEX does not have the “path” object. After a couple of days research, I found that I can use the Query List function to return a collection of folders. Using string manipulation, I now have the folder and can build the folder paths. Creating the folders are now trivial.
I still have to work through two workflows using state machines. My SharePoint 2013 environment is gone while they migrate data to SharePoint 2013 in a development environment. They use the development environment to move production data and let programs test their migration. I am working during this time in SharePoint 2010. I have had to recreate the application – another day lost. I keep losing a day here and a day there. I am tired of project manager by day and then developer at night after everyone is gone. My colleague says if development was so easy, we would not be getting paid so much. First, I am not being paid so much and second, I have always thought that building applications creating value to the client is the best way to serve the client instead of redeveloping things that are not broken.
reilingh 