Return A Document Library GUID In C#

Answering another development question that was posted in the newsgroups, someone wanted to know assuming that they were aware of the path of an SPFolder object (a subfolder that existed in a SharePoint document library), how to return the GUID of the SharePoint document library that was housing the relevant SPFolder object. This is accomplished through the use of the SPFolder.ContainingDocumentLibrary property out of the Microsoft.SharePoint namespace, which has a return type of GUID, so should work correctly. Here is a quick atomic method that you can adapt to you needs (it’s pretty simple right now :) ) to achieve this:

[csharp]

private readonly SPWeb m_oWeb;

public Guid GetSPFolderDocLibGuid(string strPath)
{
return m_oWeb.GetFolder(strPath).ContainingDocumentLibrary;
}

[/csharp]

Share

SharePoint and SOA Architectures

SharePoint as a communications and collaboration solutions provides robust faculties to build out scalable and extendable architectures that conform with SOA. We will begin by defining how we use the information architectures terms, information management, document management and content management. Because these terms are considered interchangeable concepts, it is best to clarify the definitions as followed:

  • Document Content Typically, the human mind tends to separate a document from the actual contents. So for example, instead of saying, I read what you wrote we are saying, We read the document. Therefore, we are conveying that we not only saw the document, but we also read the contents.
  • Document Containers Because of the existence of computers, the human mind has begun to regard documents and files as two different items. Instead of saying The data is in that file we say The required data is contained within that document. We have begun to distinguish between the container and the document.
  • Document Vehicles The document has become a mode of transportation of its content. The age of electronic files or documents, allow for easy transportation via email. So now instead of searching for specific information to send electronically, you can send the entire document electronically.

In the above three descriptions you found three different document concepts. These documents could hold digital images or information; however, if there is no context within the document, it is nothing more than a data collection. Because of this analogy we have come to define the document as, a container that serves as an information vehicle, stored in a SharePoint document library. In regards to building our information architecture with SharePoint which can leverage the XML web service asset, when you have a document it is a river of characters, the structures internally come to serve as and information vehicle in regards to the data contained in the characters.

The main issue that causes a problem is that the human mind tends to be far too restrictive when it concerns the definition of a document. We appear to understand a document as something that is written on a piece of paper or that of its equivalent electronically. What is being described is that a document is not limited; it can mean a wide variety of things such as, instant messages, forum messages, e-mails, processes, graphics and many other forms of data.

You see, information that we gather is usually only derived from the typical document in small quantities. We tend to gather and learn more information in regards to other means such as meetings, discussions and email. We tend to only strive to learn what they give us, we typically do not step outside of context to gather information. Items such as a sales report, emails or a meeting can all contain knowledge that can be extremely valuable.

In general, companies tend to offer a variety of manuals, guidelines and visual guides that are written to guide a user in the direction of the way the company would like to run. This helps to ensure that nothing can be forgotten or left out because the documentation is always present. It is true that people tend to retain knowledge with the use of visual aids, this means not only the printed or written words but holds true for images as well. We develop visual cues that is geared to guide us with reading as well as maintain and understand the information. Cues are used as signals in understanding the information in a way that the creator has intended. For example, within a document if the creator emphasizes a word using Bold, Italics or Underlining it will draw the reader’s attention to the specific area. If a writer were to do all three at once, this would let the reader know to pay particular attention to that sentence.

When we use visual aids within the structure of a document we are enabling the mind to process it and understand the content at a better rate. However, it is important to use these visual aids with caution, the format requires that the reader be able to recognize the cue and understand it. When using written words in your document structure, people generally make use of captions, emphasis, titles and headings, these are things the mind typically understands. For other documentation, the reader may need to be able to understand the vocabulary that is used within the document. For example, a computer, if you use a workflow diagram, the computer will not understand the cues you are giving it. It will need to know what to do when it encounters this vocabulary as well as how to recognize it. This is the same scenario as markup, you are giving the processor a cue to the action or actions you need it to perform on the content.

Management of content requires information to be organized in an upstream manner. This has to occur in a way where the individual ingredients of the content is able to keep each identity until the time of use. Doing so will allow the client to individually choose them or the ability to combine them when they feel it is necessary. This type of organization creates a clear and precise choice for the user, as well as allowing the information to be configured in a different manner for reuse.

We will now take a look at a few topics that are closely related to each other, these will include upstream content organization, then we will investigate the impact they have on authors.

Structure plays an important role in all types of documentation. For instance, when sending an e-mail to a colleague or client we will structure it in such a way that is appealing to the reader. We will spend time thinking of a title that is catchy and give great thought to the recipients of the e-mail. Rather you know it or not, this is structuring.

When looking at it in terms of content management, we but begin to understand that the text within the document cannot be a group of characters, instead we must understand that the content is made up with the following:

  • Specific content building blocks or pieces of information
  • A reference or references of other pieces of information with the same content or outside of it.
  • Specified rules that state how the blocks can be created and the configuration of the content.

Packaging is just as important, each block of information must have a package that will allow the information to be stored, delivered, and moved without losing any of the content or damage to the content. In general, every block of information must have the ability to be independent, if the information is generally part of a whole, the relationship of all aspects needs to be known.

Packages that we create typically share properties and characteristics that are important to each other. It is important to maintain predictability with any type of content processing. You must be able to understand and describe the characteristics so offer this predictability. To better understand this, consider a word processing package template. In order to maintain a certain model of use, you must pay close attention to all particular details. By leveraging SharePoint and SharePoint XML web services, you are allowing this type of predictability that is needed.

This type of packaging and content are made useful in a variety of aspects in the world today. Many people create various items for users such as, form letters, templates and models. These are typically provided bundled with an application or the user will have the ability to create their own structure using any tools that are built in the application, for example, application programming languages or macro editors. When a user conforms to any of these molds they are establishing structure, that are similar to database form fields, and all of the content becomes managed within the mold. No matter the tools used or the approach that is used the goal remains the same:

  • The ability to eliminate tasks that are repeated when creating text of similar structure
  • The ability to maintain control over the way the information is provided.

The molds are typically created to use with presentations, however many people feel they are used to receive content that is predefined and of a type that is expected. In general, these are created prior to the texts that are to use them. It is important that if you should find yourself using a structure feature that is provided by a commercial package of word processing, that you be certain to use design features instead of default. Specifically, you should try to map their use with the structure within your content.

One of the first steps to take in regards to content management is to knowledge molds that any enterprise would use or create. It must be understandable, because if the content is not created correctly the first time, time has just been wasted because of the damage repairs.

Here are some important things you should remember:

  • Be certain the content works well with the mold. If it does not work, you should not break the mold, search for another mold that will allow the content to work well. For example, if you have a mold that is created for an email you will not be able to fit a sales report into that mold.
  • Be certain that contents can still be identified by the ingredients, a user should be able to specifically identify an area of text that give a description of your process or holds your forecast in sales.
  • Knowledge molds should create an environment for an author that will allow them to be concentrated on the content instead of the structure. Additionally, it should provide support in the areas of validating and adding any information in regards to reference.

Proper labeling will allow for a package to be identified in the proper manner. It is important to note that even though the labeling and packaging may be clear, it does not allow for identifying the quality of the content. It is important to understand and manage how your content will find the way into the package. You will need to manage who is allowed to put the content in, how to apply the quality controls, a required sell by date and what will allow you to determine that the content processing is completed.

Share

Managing Data Connections and Universal Data Connection V2 (UDC) Files

InfoPath exposes several external data sources that are available for consumption either as a primary or secondary data connection. Most of the consumed data connections can be called from within the Data Connection Wizard that InfoPath provides. When using the Data Connection Wizard, you can choose to create a new data source for fetching or submitting. In relation to SharePoint, it is possible to crawl a Microsoft Office Server instance to harvest available data connections, by only supplying the site that you wish to crawl as an argument, usually the site from which the InfoPath .XSN is going to be made available.

The InfoPath data sources are:

  • Microsoft Office Access database
  • Microsoft SQL Server database (a browser enabled form cannot be submit to a database directly)
  • Email
  • Web service
  • XML file
  • HTTP Post
  • Web service
  • SharePoint Document Library or List

UDC Files

The most manageable way to service users creating InfoPath forms is to provide the data connections by storing UDC files in SharePoint Data Connection Libraries (DCL). UDC’s are a method of black-boxing data connections to hide the piping of the data connection, and call the relevant forms. By doing this, the connection used by the InfoPath form is not held within it, but called when needed at run-time from the DCL, so can be requested from any number of InfoPath forms. This allows the management and consolidation of data connections so if a specific database or web service is frequently used by several enterprise forms, it can be entered once, and called many times, while the actual data connection architecture is black-boxed.


Figure 14-3

Because the UDC files are held within what is basically a specialized SharePoint Document Library, there are granular levels of security that can be applied. Similar to the SharePoint Document Libraries, Contributors on the site can submit content, meaning new UDC files. However, within a DCL only UDC’s that have been approved can be consumed by any number of deployed InfoPath forms.

UDC files, like other InfoPath assets, are composed of well-formed XML. UDCs, like other document blueprints that are stored in Office Server 2007, are stored as content types. Content types, in order to provide the appropriate metadata will push the relevant properties to populate the needed columns using <FieldRefs> element when stored within the SharePoint Data Connection Library. When building custom UDC files, there are two ways for a developer to approach it. The first is using the inherent Conversion functions that are offered through InfoPath. Using the Convert option in the Manage Data Connections section of InfoPath, it is possible to publish a UDC file to a SharePoint Data Connection Library. The other way is to hand craft UDC files since it is composed of just XML elements. Some of the elements that compose a UDC file are optional, while others are required for it to function (see the following table).

General UDC File Elements

Element Name

 

Element Description

 

ContentTypeID

 

The ContentTypeID element specifies the diagram blueprint that will be used to populate the columns that are used in the Data Connection Library. To gather some of this information, this element couples with the name and description elements.

 

DataSource

 

Defines the UDC namespace and the version.

 

Name

 

Optional element that declares name information about the UDC file, used to populate information in the SharePoint Data Connection Library.

 

Description

 

Optional element that declares description information about the UDC file, used to populate information in the SharePoint Data Connection Library.

 

Type

 

Required element which defines the data type that the UDC is using, such as a web service or database.

 

ConnectionInfo

 

Describes the purpose of the connection, whether it is Read/Write/Both, as well as describing how the actual connection is made to the back-end data source.

 

ConnectionInfo for SharePoint List

The most populated portion of the UDC file is the ConnectionInfo element, which defines where the actual consumed datasource is located. A common UDC file is one that queries a frequently hit SharePoint list to gather values. In order to construct a SharePoint list UDC file, within the ConnectionInfo element, specify the SelectCommand element to grab the relevant values by passing in the ListId and WebUrl child elements.

[xml]

<udc:ConnectionInfo Purpose=ReadOnly>
<udc:SelectCommand>
<udc:ListId>{B78D5A41-BD83-49f0-999C-22B3FB9253A4}</udc:ListId>
<udc:WebUrl>http://localhost/sharepointsite</udc:WebUrl>
</udc:SelectCommand>
</udc:ConnectionInfo>

[/xml]

Web Service ConnectionInfo

Optionally to collect list items from a SharePoint list the SharePoint lists.asmx web service in the _vti_bin directory can be called and used in the same type of fashion as the above. Since the Lists.asmx WebService allows using the GetListItems operation, it is possible to retrieve list values using this web service by supplying a few parameters. This could be manipulated as well to include other web services outside of SharePoint if there are other external sources that house the desired values.

[xml]

<udc:ConnectionInfo Purpose=ReadOnly>
<udc:WsdlUrl>
http://localhost/_vti_bin/lists.asmx?wsdl
</udc:WsdlUrl>
<udc:SelectCommand>
<udc:ServiceUrl>
http://localhost/_vti_bin/lists.asmx
</udc:ServiceUrl>
<udc:SoapAction>
http://localhost/_vti_bin/lists.asmx?op=GetListItems
</udc:SoapAction>
</udc:SelectCommand>
</udc:ConnectionInfo>

[/xml]

One of the most frequently confusing things in terms of web services is the authentication scheme that is used in order to verify the requesting user against the web service. For most web services, it is common that a service account will be used in order to pass the appropriate credentials to the service, however InfoPath 2007 does not contain a native method to implement .NET impersonation such as that provided by the WindowsIdentity class in .NET commonly known as double hop authentication problem . However, this facility is provided through the inherent Web Service Proxy Configuration that is provided by Forms Server 2007 which will allow the users working with the InfoPath form to harvest values out of the web service on behalf of the service account as opposed to passing the requesting users login token. In order to use the Web Service proxy, it is necessary for the <udc:ServiceUrl> parent element to have the UseFormsServiceProxy attribute set to a value of 1.

Share