So, I recently had occasion to open up a browser-based Forms Services form from outside of the site collection where the template and the "Save Location" both reside…you know, kind of like one of those completely unplanned "Real World Scenarios" that we are always hearing about.

Anyway, anyone that has opened up a Forms Services form in the browser has noticed the extremely long URL that is necessary. For the uninitiated, here is a very quick synopsis of the various portions of the URL.

• Base URL. Forms Services forms are processed by an ASP.NET page located in the layouts folder. This is the base URL and it looks like this:
  • http://<<URL to your site>>/_layouts/FormServer.aspx
• Query String. There are various query string parameters that you may or may not have, depending on your situation.
  • XsnLocation. This is the location of your Form Template, and it looks something like what appears below. If you click on the "New" button in a document library configured to use the form, this parameter is NOT encoded, although the others are…it's probably a good idea for you to encode all of them if you are building your own long-ass URL from scratch. For the sanity of anyone reading, I am not going to show encoded stuff here. If you would like a quick and easy way to encode/decode stuff, here is a good one.
    • XsnLocation=http://<<site>>/Form Templates/Template Name.xsn
  • Save Location. This is usually optional, as the form will just submit to the Document Library specified in the form template if this parameter is not there. Here is what it normally looks like:
    • SaveLocation=http://<<site>>/Documents
  • Source. This is the page you want to bring up after the user is done with the form…and is the source of the challenge I had that started this whole darn thing. Basically, if you try to pass a Source parameter that is from a different site collection, Forms Services will treat you like a pigeon treats a statue. Here is what this parameter looks like:
    • Source=http://<<site>>/Pages/Success.aspx
  • DefaultItemOpen. This parameter is used to force the form to open in a browser. If it is set to something other than '1' or not present, the form will try to open in InfoPath. Here is what the "open in browser" option looks like:
    • DefaultItemOpen=1
• The Whole Damn Thing. So, if you put all that stuff together, it looks something like this:
  • http://docs.company.com/sites/active/_layouts/FormServer.aspx?XsnLocation=http://docs.company.com/sites/active/Form Templates/Template Name.xsn&SaveLocation=http://docs.company.com/sites/active/Documents&Source=http://docs.company.com/sites/active/Documents/Forms/AllItems.aspx&DefaultItemOpen=1

So, I am not sure if you caught on to the main issue reading through all that junk, but here it is in a nutshell. If you try to pass in a "Source" parameter that is from a different site collection than the one where the template is located, Forms Services will barf. That kind of puts on damper on my "Real World" scenario of having the users access a centralized landing page / application, while exhibiting a higher level of control over the document processing center where the forms are going to be filled out.

I know what some of you might be thinking – just use a new window/tab. The problem with that is that not everyone likes popups, plus, sometimes you end up with a useless popup sitting there just displaying "The form has been closed" in the middle of the screen. Besides, popups are just so Web 1.0. Modal windows, that's wave of the future, man!

For those of you that have seen SharePoint 2010 in action, you know Microsoft has gotten behind the whole modal window thing as well. In fact, if you have access to a SharePoint 2010 box, go ahead and type in the URL to the Upload form of one of your document libraries (http://<<site>>/Documents/Forms/Upload.aspx). SharePoint will get the standard Upload page from the _layouts folder, and it pretty much looks like a normal SharePoint page, right? Now, add in a query string parameter so it looks like this (http://<<site>>/Documents/Forms/Upload.aspx?IsDlg=1). See that? That form is damn sure ready for a modal dialog, huh? In fact, it is the standard way that Microsoft allows users to upload documents to a library, by putting the Upload form in a modal window and using the IsDlg parameter to keep all the extraneous stuff from showing up.

Well, that's not the only place where Microsoft has bought into this whole modal window thing. As it turns out, there is a JavaScript method set up for this that comes along with the ECMAScript Class Library that you can use from just about any SharePoint page. Check out Jomit's post that I referenced above for a little more detail and the links to learn more about the method and the ECMA library.

Since the FormsServer.aspx page doesn't even recognize the IsDlg parameter, I didn't even need it. So, armed with everyone's favorite way to hack a SharePoint page (the Content Editor Web Part), I set out to get my InfoPath form to open up in a modal window. Here is the code that got it to work:

<script type="text/javascript">

//Handle the DialogCallback callback

function DialogCallback(dialogResult, returnValue)

{

}

//Open the Dialog

function OpenModalDialog(dlgURL)

{

var options = {

url: dlgURL,

width: 700,

height: 700,

dialogReturnValueCallback: DialogCallback

};

SP.UI.ModalDialog.showModalDialog(options);

}

</script>

//Link to InfoPath Form

<a href="javascript:OpenModalDialog('http://docs.company.com/sites/active/_layouts/FormServer.aspx?XsnLocation=http://docs.company.com/sites/active/Form%20Templates/Form%20Template.xsn&amp;SaveLocation=http%3A%2F%2Fdocs%2Ecompany%2Ecom%2Fsites%2Factive%2FDocuments&amp;DefaultItemOpen=1');" onmouseover="javascript:window.status='';return true;" onmousedown="javascript:window.status='';return true;">Coolest Form Ever</a>

So, you see that I have gotten rid of the "Source" parameter in the Query String, as that still breaks the form if you send it something that is in a different site collection than the template, but the UX is about 100 times better than having a popup or (even worse) sending them to a page that is on a different site collection than where they started.

I still need to move this out of the CEWP before it is ready for prime time, but just think about the implications here. This is a bona fide slam dunk and a huge win for Microsoft by allowing us to quickly deliver solutions that are in line with what others are doing in the industry.

Please download the slides from the link below.

Metadata Briefing Slide Deck – SPSKC

I should have some time coming up in the next week or two to start blogging a little more frequently. 

I’ll also throw a teaser out there and let you know that I am working on a cool SharePoint content aggregator site that should be live by the end of the year.  Nothing fancy, just a single place to go to get a lot of SharePoint information that is currently somewhat scattered throughout the blogosphere.  Hopefully, I have not said too much - I know there are lots of people out there with more brains and free time than myself.  I would hate for someone to steal and implement my idea, since I would not do well in prison. <grin />

Enough about my other pursuits – let’s get back to these Implicit Documents, whatever the heck they are.  Just to make sure that we continue on the same path every step along the way, let’s bring up the table of contents from the first post in the series (Step 0 of 10).

• Step 0: Welcome and Outline
• Step 1: Setting the Table – Background Information, Technology Levelsetting and Real-world Applications
• Step 2: High-Level Solution Design
• Step 3: Development Environment Set-up
• Step 4: Data Warehouse and Dimensional Model
• Step 5: Making Time – Working with the Time Dimension
• Step 6: Rapid Application Development in SharePoint – Just an Introduction
• Step 7: Using BDC Columns
• Step 8: Building the Microsoft Word Template
• Step 9: Bringing it All Together – Document Generation
• Step 10: Reporting and Auditing

So, let’s get right into the meat of this post, shall we?

Background Information

For years, I have been dreaming about the concept of a knowledge management paradigm whereby a document consists of nothing more than a series of references or pointers to something smaller than the document itself.  The totality of all of those references makes up the document itself – just a bunch of data points and that’s it. 

Like I said, I have been thinking about this for years, but until I started thinking of it in terms of the 2007 version of the Microsoft Office platform, I would always think of it, sigh and resign myself to the fact that I would never have, or want to have, the 500 hours necessary to code something from scratch.  With all of the integration points of the current Microsoft Office system, it should take a lot less time to show something simple enough that it won’t take forever yet complex enough that it will show the capabilities.

One other item of background information – while this kind of technology has existed for a while, and while people like me have been thinking about it for several years, there is basically one group of people that are currently delaying some of the cool things that technology can provide us in the Knoweldge Management field – and those people are…auditors.  It seems like there is still a reluctance in the auditor community to accept a document that doesn’t really exist.  Until there is a standard software package that can do this will completely validated predicable performance, then the auditors will continue to require something more concrete.

Technology Levelsetting

So, the first thing I would like to address here is – what is an implicit document and how is it different from some of the other things we may have heard about already, like a “virtual document” or a “compound document?”  Let’s accomplish this with some simple definitions.

Virtual Documents.  For the purposes of this exercise, virtual documents are documents that are generated on demand, based on user input.  There is another concept of a virtual document in Documentum, but it is in essence similar to the compound document that will be discussed below…merely a document that can contain other documents.  Virtual documents have existed for quite some time, and basically most of the web pages you ever look at are probably, at least to some extent, a virtual document.  The content in your browser is generated by some code or script that runs on the server, which grabs some content from a back-end database or other source, formats the content and then displays it for you to see.

Compound Documents. Compound docs are normally a “regular text document” that also contains non-text elements, such as spreadsheets, pictures, digital media features, etc.  Well-known technologies for compound documents are Object Linking and Embedding (OLE) from Microsoft and Bonobo by Ximian.  While compound documents are a generally pretty cool concept and the Microsoft Office 2007 system has allowed a great many possibilities, they are just not quite enough in and of themselves, because they are, in terms of what we want to do here, limited by the fact that they are documents that have been already created within a software program, such as Microsoft Word.  Therefore, they contain intrinsic information that cannot be used by other documents, which is not acceptable in this paradigm.

Implicit Documents. Implicit documents are a collection of references to the various parts that make up the document.  Every component of the document is contained elsewhere, referenced by one or more documents in the centralized knowledge management system, and the documents themselves are generated only when required.  Through the use of metadata and robust processes, the collection of information and documents can be integrated tightly.  Take the example of some boilerplate text like a legal disclaimer that is present within 100 different documents within the knowledge management system.  When the legal disclaimer is updated, all 100 documents are updated automatically, merely by having the reference to the boilerplate text in their data structure.  Additionally, if the boilerplate text was deemed to be important enough, within the metadata and the processes, each of the 100 documents could be automatically generated, version incremented to the next major or minor version (such logic also contained in the metadata and processes), and saved in the appropriate repository(ies).

With this concept of implicit documents, there are a few basic rules that we will use as we make our way through the exercise:

1. Implicit documents can contain no intrinsic information regarding document content, only references to external data sources.
2. Implicit documents also contain metadata that will be used to classify the document within the system, as well as sift, sort and shuffle the document in relation to the other documents within the knowledge management repository.
3. The generation of documents will be accomplished either programmatically or through administrator-level access only.

Real-world Applications

Among the myriad of potential real-world applications for this technology is the centralized knowledge management system itself.  Other, smaller applications include:

• Corporate Policies and Procedures Repository.  The same principles of an entire knowledge management system based on implicit document apply, but there would only be a couple of different content types, so there will be a high level of overlap between the documents and items of content.
• Contracts Repository.  Each contract will contain references to all of the appropriate legal boilerplate text, as well as anything specific to the document itself, such as information about the client and the internal business unit assigned to perform the work outlined in the contract.  Using the high level of integration of the Microsoft Office system, the client could be a reference to a centralized CRM system, the business unit could be a reference to a centralized corporate structure (org chart), and the legal boilerplate text could be a link to the officially published versions of such text on the legal department’s internal team site.

Hopefully, this background information has provided you with enough information to see the possibilities.  As we get deeper into the exercise, I am sure that we might come back to revisit this module and add / clarify a few things. 

Please stay tuned for the next installment, where we will present a high-level solution design for our exercise.  While I have not yet decided on the specifics, I am leaning toward building a Corporate Policies and Procedures Repository, as discussed in the “Real-world Applications” section above.

For those of you that are interested, here is the working outline for the steps I will hopefully conquer as I progress through this series.  Once a future step becomes active, I will replace the bulleted text below with a link to the appropriate article for that step.

• Step 0:  Welcome and Outline
• Step 1:  Setting the Table – Background Information, Technology Levelsetting and Real-world Applications
• Step 2:  High-Level Solution Design
• Step 3:  Development Environment Set-Up
• Step 4:  Data Warehouse and Dimensional Model
• Step 5:  Making Time – Working with the Time Dimension
• Step 6:  Rapid Application Development in SharePoint – Just an Introduction
• Step 7:  Using BDC Columns
• Step 8:  Building the Microsoft Word Template
• Step 9:  Bringing it All Together – Document Generation
• Step 10:  Reporting and Auditing

I hope to be able to provide at least 2 blog posts in this series per week, which would hopefully get us to the end somewhere around the middle of March.  Please check back often to see the latest, or feel free to sign up for our RSS Feed.

I am very excited about the prospects there and cannot wait to make the formal announcement regarding our processes and services in this area later this year.  However, I do not want to give away too much information in this forum, as someone with greater resources than myself could easily rain on my parade if they knew my plans.

Anyway, the main problem of CKOs from a "real people solving real problems in the real world" standpoint is that Knowledge Management, already a difficult undertaking, is becoming even further bogged down with project charters, mission statements, corporate oversight and "analysis paralysis" of the highest order.  The entire concept of Knowledge Management, longtime corporate bridesmaid, is finally starting to spread its wings, yet simultaneously becoming even more difficult to quantify and as a result, exponentially more difficult to bring to fruition.

Enter The Four RIGHTs.  An effective Knowledge Management implementation will put the RIGHT information in front of the RIGHT person at the RIGHT time to take the RIGHT action.  It's that simple.

Sure, in a large company, figuring out each one of the RIGHTs could take 6 months, and a near-flawless implementation of technology and process surrounding that RIGHT could take another 6 months, but the four RIGHTs should be the rallying cry of every CKO and Knowledge Management consultant in the world.  In fact, the first thing I do in every strategic Knowledge Management engagement is drive home the concept of the four RIGHTs.  I put it on the wall of the interview room; I put it into every slide deck; and I try to work it into every conversation.  It immediately cuts through any nebulous concepts surrounding Knowledge Management in general and a company's approach to Knowledge Management in particular.

I cannot tell you how many times I have been bogged down in the middle of a conversation talking about corporate naming conventions and how they should be implemented in a specific knowledge management portal (Microsoft SharePoint).  It is usually during those moments that I start bringing everyone back to The Four RIGHTs.  I don't care if you call it a work instruction, policy, or a ham sandwich…does it help us get through each of the RIGHTs, so we can maximize the chances of the RIGHT action?  If not, why are we talking about it? Besides, if working in Knowledge Management for 12 years has taught me anything, it has taught me that names are political, and he who has the bigger office gets to choose the names of objects in the knowledge management system. That's just the way it is.

At any rate, I have found that this kind of approach is sorely lacking in the Knowledge Management community today, and we only have ourselves to blame.  In fact, we have gone so far toward the nebulous that one of the key defining concepts within Knowledge Management is actually called a "Continuum".  It's true – I did not make that up.  The "Continuum" originally started out as a progression from Data to Information to Knowledge.  Recently, there has been another level added…Wisdom.  Oh, great.  Just what the whole concept needed – more abstract terminology.

Just for kicks, take a look at this picture and tell me what each of the terms on it means to you.  Now, go ask someone else to do the same. Can you see how Knowledge Management has gotten its current reputation of a bunch of flowery language with no substance?

Hopefully, you not only agree, but will help me spread the word.  Knowledge Management does not have to be so hard, and it certainly does not need to be as misunderstood as it has been in the past.  All you need is to be ever mindful of The Four RIGHTs…if you do right by them, they will take care of you as well…if you lose sight of them, they will tear you a new one.