Category: MOSS

Using SharePoint Online for InfoPath Forms Services

Introduction

Today I thought it would be fun to do more research on what InfoPath looks like in the cloud. There had been a few hints about Forms Services running on SharePoint Online and some people were suggesting that it would only work once Office365 came out. Today I started a BPOS trial at https://mocp.microsoftonline.com/site/services/bpos/signup.aspx?offer=suite&quoteid=067303dd-bef3-4bc9-8f95-2b24c6dae143 and created a forms library to test out my strategies on InfoPath.

To give away the spoiler, I got it to work successfully. Apparently this is currently an unsupported feature (I think until Office365 comes out), but it does work. Here are the steps that I did to test this out. In a recent post I talked about how the license changes to MOSS 2010 no longer provide forms services as a feature when you use the standard CAL. But BPOS is relatively inexpensive so I think it provides a cost-effective replacement for the MOSS functionality. I found the documentation a little lacking on how to do this so I thought I would put together a walkthrough of how I got it to work.

Walkthrough

1. So the first thing I did was make a sample form in InfoPath:

2. Then I save it and go to Tools\Form Options to enable it to work in a browser:

3. Then I just have to go through a couple pages of the wizard to publish to a Microsoft Online site.

You have to authenticate with SharePoint Online at this point. Then the next page

Then choose the forms library from your SharePoint Online site that you want to publish the form for. In the following screenshot I show a couple forms libraries. I actually used a different form library for the later pages of this wizard called OnlineFormsLibrary.

 

Then you get a page that says the form was published successfully:

4. Then I wanted to show the form from my browser even though I had InfoPath installed. On the form library settings you can specify that you want the form to display as a web page which will show the forms services rendering that does not require InfoPath. Here is the form for specifying this:

5. Then you can view the form by making a new item in the forms library. Here is an example of my form being rendered through Forms Services:

Conclusion

So Forms Services does work with SharePoint Online, even with just a BPOS trial. This is exciting news. As far as I know, BizTalk cannot currently integrate with SharePoint Online for document library functionality because the WSS adapter web service does not exist in the cloud. The next thing I will try is being able to post the results from InfoPath back into a custom WCF service in the cloud. From there the data could be sent back into an on-premise hosted BizTalk server via the service bus. This whole integration feels like sending something from outer space back to earth but I feel good just knowing that at least it is possible. 🙂

1

SharePoint 2010 Sneak Peek and Office 2010 TP

I just learned about the MOSS 2010 sneak peek site (http://sharepoint.microsoft.com/2010/Sneak_Peek/Pages/default.aspx), which shows some very cool screenshots of the upcoming version of SharePoint. There are a couple important points about this release which are exciting from a connected systems perspective.
 
The Business Data Catalog (BDC) definition designer that came with the Office Server SDK is getting a facelift and some updates. The BDC functionality is now called Business Connectivity Services (BCS). If you worked with the BDC in MOSS 2007, you probably know that you could not use WCF bindings other than basicHttp to interact with web services or other services with the BDC. I am speculating, but I would anticipate that BCS will include more WCF functionality than just the basicHttp binding. We will see in a few months.
 
I have used the Microsoft tool and the BDC Meta man tool and consider both to be helpful but fairly limited. There were various ways to encounter issues with the Microsoft tool so I am hopeful this latest release will provide some fixes and a better developer experience. The sneak peek screenshots also show using the tool from within Visual Studio rather than as a separate tool. This means that the new tool will be used with some out-of-the-box SharePoint extensions. The sneak peak also discusses a new designer experience as well. These improvements are significant and provide SharePoint lifecycle benefits for BDC projects.
 
The additional Linq to SharePoint feature extension will be a nice feature as well. The designer screenshots for the BCS tool which is described as being for BCS for entities looks very similar to the LINQ to SQL designer so I would anticipate that the future vision of BCS entities is to provide a richer experience for interacting with the BCS entities like with the ADO.NET entity framework. Previously through the BDC the way to interact with the entities was not on a code level and required web parts or list interactions post deployment. It will be exciting to see how far the LINQ to SharePoint API extends and how much of it applies to BCS entities.
 
Also, the Office 2010 technical preview has been released. I installed all of it (except Visio) on a Windows Server 2008 R1 box successfully. Unforunately, Visio encountered an error so I was not able to install it. In my experience, SharePoint designer does not work on MOSS 2007 sites, although SharePoint Workspace (new name for Groove), does work on MOSS 2007 document libraries. Overall, the graphics are a nice upgrade to Office and I am enjoying the new functionality. 🙂
 
I also like the new feedback components of the Office 2010 TP, and I thought it would be funny to post on these. After installing Office 2010, you get 2 new icons on the tray, a smiley and a frowny and you can click on each to report feedback experience, as apporpriate. Each one takes a screenshot so you can quickly and easily report screenshots. Here is a picture with the funny faces in the tray:
 
 
Try out the Office TP if you have time and be watching for the SharePoint 2010 release coming up soon!
 
Thanks,
 
0

SharePoint Workflow Services

I was working recently on a SharePoint Workflow project and was exploring some of the Office SDK samples. The latest Office SDK (http://www.microsoft.com/downloads/details.aspx?familyid=6D94E307-67D9-41AC-B2D6-0074D6286FA9&displaylang=en) includes samples that were built for VS 2005 but you can convert nearly all of these over to work with VS 2008 using the .NET conversion wizard. I was exploring one of these samples and found some code that worked with IWorkflowModificationService and then realized that there are at least 4 workflow services exposed by the SharePoint workflow host. The IWorkflowModificationService (as documented at http://msdn.microsoft.com/en-us/library/microsoft.sharepoint.workflow.iworkflowmodificationservice_members.aspx) has just a single exposed method for EnableWorkflowModification(). This method performs some of the same functionality that that the activity shape Microsoft.SharePoint.Workflow.EnableWorkflowModification performs. Then I noticed that in the workflow designer in VS 2008 this activity actually has an InterfaceType which referes to IWorkflowModificationService. Interestingly, when I clicked the … on this part of the property box the object explorer filtered my referenced assemblies by ExternalDataExchangeAttribute and gave me the filtered window as seen below:
 
 
The items listed above are the four available workflow services provided with the SharePoint Workflow host. For this reason a considerable number of the built-in SharePoint activities are just wrappers that work with the workflow services. This was a very interesting find for me because it helps me to understand the way that workflow services are working under the surface the SharePoint workflow host.
 
While I was looking at the MSDN documentation for IWorkflowModificationService I also found there is good documentation for these other workflow services including ISharePointService, ITaskService, and IListItemService. Because these are exposed you can quickly come up with the implementation behind most of the built-in SharePoint activities.
 
Thanks,
 
2

WCF LOB SDK flies under the Radar – BDC Extensions Await

Recently I worked on a BDC project and I was able to get a taste for what is possible for out-of-the-box SharePoint integration with external systems. The tricky aspect of BDC web service integration is that it only works with older web services – ones that use Basic Profile. The challenge of this is that you are limited in the integration options that are available because you must rely on the older SOAP and HTTP protocols. There are Office SDK samples that showcase integration with SAP and Siebel over BDC web services or Oracle over BDC database connections, but I was wondering how I would expose PeopleSoft or some other enterprise system that cannot be reached with a Basic Profile web service or a database connection.
 
Based on my BizTalk background, I knew that I could use the PeopleSoft adapter through BizTalk and then expose a BizTalk orchestration as a Basic Profile web service that could then be consumed by the BDC. So essentially this would be like a BDC bridge over BizTalk. This is when I started exploring the WCF LOB SDK as an interesting technology because the BizTalk adapter pack 1.0 is based on this SDK and it basically provides enterprise integration over WCF. Very few people are playing with the WCF LOB SDK, mostly because I think it seems confusing and has a poor name. The SDK is targeted at BizTalk developers with its "adapter" terminology, but it is really more of a way to talk about BDC from an adapter-oriented mindset. The LOB terminology should connect in your mind the LOB aspects of the BDC. If you look at the BDC documentation, the concepts are all about connections rather than adapters, but the WCF LOB SDK redefines the adapter concept by describing it as part of the channel infrastructure. So the future for the BDC is a redefined adapter based in WCF.
 
I found a few links that tie together the BDC adapters <-> WCF LOB SDK concepts, which really give us a glimpse of how the WCF LOB SDK is going to actually become more valuable from a MOSS perspective as the MOSS product is enhanced to support WCF. Usage pattern 7 on http://blogs.msdn.com/biztalk_adapter_development/archive/2007/07/09/wcf-lob-adapter-usage-patterns.aspx mentions how future BDC enhancements will rely on the WCF LOB SDK. It looks like Jesus Rodriguez also played with some of these scenarios: http://weblogs.asp.net/gsusx/archive/2007/07/12/sharepoint-bdc-wcf-adapters-and-more.aspx. The dates on these links suggest these concepts are old news but it is still relevant because the BizTalk adapter pack 1.0 was only recently released. The plans for this SDK go way back but the vision for how it will be used in the future seem to be missing. The WCF LOB SDK gives us a vision for the future of the BDC, which should include having a better designer experience for BDC developers as well as a much richer level of connectivity and flexibility. So the ROI for the WCF LOB SDK is still down the road, but once MOSS can support WCF it will be possible to integrate these other enterprise systems like PeopleSoft straight from the BDC. This is an exciting vision for the future of the BDC technology and a great reason to get your hands dirty with the WCF LOB SDK.
 
Thanks, 
0

BDC Column Maximum Length & Workaround

I recently uncovered an overflow problem in BDC columns. When returning data from a BDC data source, it is possible to return too much data if the BDC is being used as a column in a custom list. The maximum length of a BDC column when used in a list is 255 characters, which is the default maximum length of a text type column in MOSS. When using the BDC web part, data that is returned is not subjected to the maximum length of 255 characters. When more data is returned than 255 for a particular column, I received the error: "Invalid text value". Within the BDC application definition, the TypeDescriptor data type for these columns was System.String. I could not find any other errors in the event logs or SharePoint logs for this problem.
 
I wanted to post this maximum length because the MSDN documentation does not mention this.
 
Since I was working with a SQL Server BDC connection, I was able to wrap fields that could overflow the 255 character maximum using the substring function as in substring(<fieldname>,1,255), but this will not be possible for all BDC connections.
 
Thanks,
1

BDC Implicit Conversion Pitfall

I have been recently working on a MOSS BDC project and have been struggling with some ambiguous error messages that were occuring on when using BDC data columns in a custom list. The error I was receiving was:
   An error occurred while retrieving data from <BDC Database>. Administrators, see the server log for more information.
 
After checking the event viewer logs I realized this error message actually refers to the SharePoint logs in the 12 hiveLogs. After some investigation of the log I realized that my BDC application definition was expecting an Int64 value to be returned when in fact it was receiving an Int32. From a programming perspective it would seem that any Int32 value should fit within an Int64. The other way around should cause an overflow. The BDC complained like the Int64 data type resulted in a data type mismatch.
 
This problem illustrates that implicit conversions when using the BDC are not provided by the MOSS runtime, so it is VERY important to be sure that the type descriptors in the BDC application definition match exactly what is returned from a database or web service. I am sure there are other cases where a developer would expect an implicit conversion to occur but will not with the BDC.
 
When using the BDC Meta Man tool or the Microsoft BDC Editor, watch out for definitions that default to Int64 as the data type for a column because this could result in an error if an Int64 is actually not being returned. This is one very tricky issue in BDC development.
 
Thanks,
0

SharePoint Security Permissions Matrix

It looks like an MSDN article that is really useful is located under the SPPermissionGroup64 Enumeration rather than a more descriptive title. This article gives all of the possible user access levels in SharePoint and then describes which individual rights are covered by the levels. These individual rights are used when deploying features for attributes in the feature definition files like "Rights". Here is the link to this vary important SharePoint security chart: http://msdn2.microsoft.com/en-us/library/microsoft.sharepoint.sppermissiongroup64.aspx?topic=306117.
0

Asp.Net Validators Incompatible with SharePoint controls

On a recent project I learned the hard way that the Asp.Net validator controls like RequiredFieldValidator or RangeValidator do not work with the Microsoft.SharePoint.WebControls controls. For this reason you will frequently need to create your own validation logic when working with controls from this SharePoint namespace. When using Reflector to inspect the type of the ControlToValidate field used in the Asp.Net validators, it appears that it is looking for a control of type System.Web.UI.WebControl. Interestingly, in Reflector the DateTimeControl appears to have its own RequiredFieldValidator in its child controls that is enabled when the IsRequiredField="true" attribute is set. It is also important to note that SharePoint also provides some validators within the Microsoft.SharePoint.WebControls namespace including the InputFormRequiredFieldValidator or InputFormRangeValidator, but even these are incompatible with some of the other SharePoint controls.
 
So an important question that comes up is what is the best way to handle validation on SharePoint controls. A couple of different approaches can be taken. One would be to derive from the existing validator controls and to expect that a control of type Microsoft.SharePoint.WebControls.SPControl. Another approach would be to emulate the functionality of the System.Web.UI.WebControls behavior by using a label and then calling the validation logic. The primary gotcha that was encountered with this second approach was that the convenience of calling Page.Validate() will unfortunately invoke the built-in SharePoint control validation which may or may not fulfill your application requirements.
3

Custom DateTimeControl Formatting

A problem that I recently encountered working on a MOSS project was the inability to customize date formating of the Microsoft.SharePoint.WebControls.DateTimeControl for a setting that is outside the realm of the default formatting for a culture. The default culture short date formatting was dd/mm/yyyy for en-AU but instead I needed it to display in dd MMM yyyy. This control has a LocaleId property but no way of simply customizing the formatting of the selected date value.
 
All I could find on the net that would work was to redefine the culture setting in the registry using the CultureAndRegionInfoBuilder (as mentioned here: http://sharepointex.blogspot.com/2007/09/how-to-modify-date-format-in-sharepoint.html). This was not ok for me because I was deploying into a shared environment and this would break someone else’s culture-sensitive formatting. So I created a derived class from the DateTimeControl and overrode the OnPreRender event so that I could handle the formatting myself and this did the trick. Here is my code for doing so:
 

using System;
using System.Runtime.InteropServices;
using System.Web.UI;
using System.Web.UI.WebControls.WebParts;
using System.Xml.Serialization;
using System.Web.UI.WebControls;
using Microsoft.SharePoint;
using Microsoft.SharePoint.WebControls;
using Microsoft.SharePoint.WebPartPages;
namespace TestDerivedControl
{
    [Guid("619b97bb-1c70-426e-b3ec-f76c5324be3a")]
    TestDerivedControl : System.Web.UI.WebControls.WebParts.WebPart
    {
        public TestDerivedControl()
        {
            this.ExportMode = WebPartExportMode.All;
        }
        protected override void Render(HtmlTextWriter writer)
        {
            this.RenderChildren(writer);
        }
       
        protected override void CreateChildControls()
        {
            base.CreateChildControls();
            // Add the controls here
            CustomAUDatePicker obj = new CustomAUDatePicker();
           
            obj.ID = "dtcDate";
            obj.AutoPostBack = true;
            obj.DateOnly = true;
            obj.Visible = true;
            obj.SelectedDate = DateTimeNow;
            this.Controls.Add(obj);
        }
    }
    public class CustomAUDatePicker : Microsoft.SharePoint.WebControls.DateTimeControl
    {
        protected override void OnPreRender(EventArgs e)
        {
            base.OnPreRender(e);
            TextBox box = (TextBox)this.Controls[0];
            DateTime dt = DateTime.Parse(box.Text);
            box.Text = dt.ToString("dd MMM yyyy");
       
        }
          
    }
}
 
6

Striving for MOSS ROI

Lately I have been working on a SharePoint workflow project and have been finding some good opportunities for optimizing the time-to-market and return-on-investment of SharePoint workflows. For anyone who has worked with this technology extensively, it can be difficult to transition between workflow form types such as task forms and modification forms. One goal I will be taking up in the next few days will be to build a small framework for reducing the cost involved to switch between these types of workflow form types. The primary challenge I have found is that the way that saving data to a list versus saving data in serialized form to a database is remarkably different. So to accomplish the challenge, the question would be whether to build a more loosely-coupled or tightly-coupled implementation. I will provide more details on my approach to solve this development challenge this week.
 
 
0

Blog at WordPress.com.

Up ↑