HttpCode

The next integration method that I want to discuss is the collection of data. As a web developer you’ve no doubt been asked to create a form that does X a number of times, you might even have created some tools to aide in this, it’s pretty common. So now that you’ve moved across to the dark side of MOSS development we need to break your thinking, if you want to create a form, first have a look at Microsoft InfoPath, InfoPath files can be published to MOSS running the InfoPath Forms Service.

The benefits to this approach are:

• Less development – I won’t go as far to say that even the worst coder on your team could use this tool, that guy can’t do anything, but for simple stuff it’s not too hard to get your head around.
• Central management of forms – You can easily keep track of your forms, how many times have you written a form that has already been developed? But seriously because each form is a content type, you can manage the metadata of a form from a single location, regardless of how many libraries you’ve added the content type to.
• Can easily use existing MOSS features - This is the biggest feature, you can easily add workflow capabilities or publish your results to a list, I bet most of your forms currently just send an email and get written to a database.

The disadvantages are:

• It requires a different way of thinking - This might not be a bad thing, but some large organisations have teams of programmers who spend 90% of their time doing some sort of forms based programming. It might be a hard sell for these guys.
• Anonymous access might cause some issues – I’ve seen a few issues around anonymous access to forms, it’s by no means a show stopper, but you should think about this before you deploy.

I think the benefits far out weigh the disadvantages, in any case hopefully the next time you hear a developer say they’ll create a web part for a form, you’ll think about it a little more carefully.

I previously posted about a simple integration pattern that used the Page Viewer web part. The approach I’m going to discuss today again does not involve any custom coding, but will have a huge impact on your end users.

If your goal is to make your corporate data more available this is an easy option.

I’ve posted about this diagram before:

This is the Business Data Catalog (BDC). It can source data from either a database or a web service, once you have built an Application Definition File (the only development work needed), your data can then reach custom lists, profile information, search and custom solutions.

The benefits to this approach are:

• Reach – You’d be hard pressed to develop a feature that has more end user impact. Firstly your data can be searched, secondly your data can now be used in ways that couldn’t be foreseen. This might be a scary prospect for a lot of organisations, but this will change over time, I plan to discuss this further in another post.
• Searchability – The younger generations have grown up with the web and expect to be able to do everything via search, you’ll probably find that your search engine is the most popular MOSS feature, why not plug more data into it?
• Fits with a SOA – Yes, it’s buzzword compliant, don’t forget that the BDC in MOSS can call web services, so if your organisation has a Service Oriented Architecture, this will likely be an easy sell.

The disadvantages are:

• Doesn’t work well for complex data – It really only works well if your data is simple, for example if your trying to expose a product list or the locations of your stores.
• Read Only Data – Indexing and Searching are read only operations, as simple as that. If you want your users to rate your data or tag it, then your going to need a different strategy.