/TECH RANT
I looked at my blog today and realized it has been quite some time since I last posted and there's a reason for this. Actually several reasons that all combine into a singular issue that has caused me some personal and work grief. In most cases I would mask my troubles by writing a more technically oriented entry, but this time there is no getting around the technical and emotional issues that have occurred.
To begin, in the week of January 21st we were finally publishing a form to our newly setup production environment, complete with claims-based authentication to facilitate single sign on. We did a backup of the test site collection and restored it to production. The first thing I check were the workflows as I had used a new feature to help ease the pains of changing publish locations. It worked fantastically. The workflows generated links based on where they were and didn't have to be statically set. Then we launched the all important full-trust form that was to go live by the end of January and immediately there was an error screen. Okay, so it wasn't a flawless victory. I hit OK and proceeded to attempt to visually diagnose what was broken. It didn't take long to see that every single data connection had failed to connect.
The rest of that week was spent diagnosing what had happened and what was truly broken. As it turned out, it was a small quartet of issues. The first and foremost: the test environment used classic authentication, the production environment used claims-based authentication. This small oversight caused a small cascade of issues to crop up, namely: using web services in InfoPath forms no longer worked, username() returned a very different string than expected, and SSO is really annoying to develop under.
Let's start with the string returned by username(). In InfoPath, username() normally returns something like "jdoe". And it still does when you hit preview or you happen to be using a client form. But in a web-form on a claims-based web app, username() returns something like "i:0#.w|domain\jdoe". This is a huge issue when the form is trying to compare "jdoe" to the whole claims token. This was easily enough worked around by creating a temporary variable that was assigned the current username based on a couple of form load rules. Some aspects of the form become less dynamic with this method, but it fixes the issue of "jdoe" != "i:0#.w|domain\jdoe" when it is clearly supposed to.
The next issue is that of web services. One of the services I use in most InfoPath forms is the userprofileservice.asmx service. This allows me to get the current user's preferred name, work phone number, preferred email, and Whitworth ID number. It's quite useful, and in some forms, required. And now it was completely inaccessible. At first I thought it was a problem with the string from username() causing problems, but even after I fixed that issue, the server kept spitting out a SharePoint error code 5566. I discovered this is similar to the HTTP 401 error, namely that the service is reachable, but the user has either not provided credentials or their credentials have failed to authenticate. Most sources that talk about this particular issue state that it is because InfoPath is not "claims aware", but none of their solutions work or cause a security concern.
Finally, single sign on is a wonderful tool for end users and probably even for most development situations. But for SharePoint Designer and InfoPath Designer, this caused me undue grief. This is largely due to the way the tools function in this situation. Every time I went to add a data connection, I had to log in. Every time I published, I had to log in. Every time I went to access the site collection with SharePoint Designer I had to log in, and then open the site a second time to get it to actually load. And just getting the site collection to open in the first place took me hacking the link into the Recent Sites list in SharePoint Designer. It's annoying.
At the end of this week of discovery, I found myself unable to do anything because it was all server settings I don't have access to. It was also very disheartening to realize that most of the forms I had worked on over the past 9 months wouldn't work in the production environment. My mood fell and I let a lot of things go. I probably used more sick time in January than I had previously at all. Even now I still have issues motivating myself to continue working on forms. New forms have gone to utilizing manual entry of the current user's name and ID number when needed. Where I used to have a tolerant love of SharePoint has turned into something else. I've reached the end of what little sanity I had left. When I get home from work, I can't think about design any more and usually find myself playing a game, watching a show, or reading a book that has nothing to do with work. This blog sadly refers to work quite frequently and thus it has been put off for far too long.
Don't get me wrong, I know that SharePoint can be an amazing system that provides awesome features for team sites, file sharing and collaboration, and business processes with automated workflows. I think I just need a short break from SharePoint's particular blend of crazy and a new perspective. In fact I made the decision a couple weeks ago that if I'm going to truly continue to work with SharePoint I will become an expert so that when someone comes to me and says, "It's broke", I can tell them why and what to do to fix it.
Until next time:
Work hard. Play harder.
I looked at my blog today and realized it has been quite some time since I last posted and there's a reason for this. Actually several reasons that all combine into a singular issue that has caused me some personal and work grief. In most cases I would mask my troubles by writing a more technically oriented entry, but this time there is no getting around the technical and emotional issues that have occurred.
To begin, in the week of January 21st we were finally publishing a form to our newly setup production environment, complete with claims-based authentication to facilitate single sign on. We did a backup of the test site collection and restored it to production. The first thing I check were the workflows as I had used a new feature to help ease the pains of changing publish locations. It worked fantastically. The workflows generated links based on where they were and didn't have to be statically set. Then we launched the all important full-trust form that was to go live by the end of January and immediately there was an error screen. Okay, so it wasn't a flawless victory. I hit OK and proceeded to attempt to visually diagnose what was broken. It didn't take long to see that every single data connection had failed to connect.
The rest of that week was spent diagnosing what had happened and what was truly broken. As it turned out, it was a small quartet of issues. The first and foremost: the test environment used classic authentication, the production environment used claims-based authentication. This small oversight caused a small cascade of issues to crop up, namely: using web services in InfoPath forms no longer worked, username() returned a very different string than expected, and SSO is really annoying to develop under.
Let's start with the string returned by username(). In InfoPath, username() normally returns something like "jdoe". And it still does when you hit preview or you happen to be using a client form. But in a web-form on a claims-based web app, username() returns something like "i:0#.w|domain\jdoe". This is a huge issue when the form is trying to compare "jdoe" to the whole claims token. This was easily enough worked around by creating a temporary variable that was assigned the current username based on a couple of form load rules. Some aspects of the form become less dynamic with this method, but it fixes the issue of "jdoe" != "i:0#.w|domain\jdoe" when it is clearly supposed to.
The next issue is that of web services. One of the services I use in most InfoPath forms is the userprofileservice.asmx service. This allows me to get the current user's preferred name, work phone number, preferred email, and Whitworth ID number. It's quite useful, and in some forms, required. And now it was completely inaccessible. At first I thought it was a problem with the string from username() causing problems, but even after I fixed that issue, the server kept spitting out a SharePoint error code 5566. I discovered this is similar to the HTTP 401 error, namely that the service is reachable, but the user has either not provided credentials or their credentials have failed to authenticate. Most sources that talk about this particular issue state that it is because InfoPath is not "claims aware", but none of their solutions work or cause a security concern.
Finally, single sign on is a wonderful tool for end users and probably even for most development situations. But for SharePoint Designer and InfoPath Designer, this caused me undue grief. This is largely due to the way the tools function in this situation. Every time I went to add a data connection, I had to log in. Every time I published, I had to log in. Every time I went to access the site collection with SharePoint Designer I had to log in, and then open the site a second time to get it to actually load. And just getting the site collection to open in the first place took me hacking the link into the Recent Sites list in SharePoint Designer. It's annoying.
At the end of this week of discovery, I found myself unable to do anything because it was all server settings I don't have access to. It was also very disheartening to realize that most of the forms I had worked on over the past 9 months wouldn't work in the production environment. My mood fell and I let a lot of things go. I probably used more sick time in January than I had previously at all. Even now I still have issues motivating myself to continue working on forms. New forms have gone to utilizing manual entry of the current user's name and ID number when needed. Where I used to have a tolerant love of SharePoint has turned into something else. I've reached the end of what little sanity I had left. When I get home from work, I can't think about design any more and usually find myself playing a game, watching a show, or reading a book that has nothing to do with work. This blog sadly refers to work quite frequently and thus it has been put off for far too long.
Don't get me wrong, I know that SharePoint can be an amazing system that provides awesome features for team sites, file sharing and collaboration, and business processes with automated workflows. I think I just need a short break from SharePoint's particular blend of crazy and a new perspective. In fact I made the decision a couple weeks ago that if I'm going to truly continue to work with SharePoint I will become an expert so that when someone comes to me and says, "It's broke", I can tell them why and what to do to fix it.
Until next time:
Work hard. Play harder.
