Full Text Search: The Key to Better Natural Language Queries for NoSQL in Node.js
Date: 1/31/2018 @ 2 p.m. ET
Collaborating with the BizTalk 2006 R2 SharePoint Adapter
SharePoint is one of Microsoft's major collaboration platforms. If you're an Enterprise Microsoft Office user who frequently collaborates on Word, PowerPoint, or Excel documents, you probably utilize SharePoint. Microsoft Office 2007 leverages the collaboration capabilities of SharePoint through Microsoft Office SharePoint Services (MOSS). SharePoint has truly become one of the gems in the Microsoft product offering.
It's not surprising that SharePoint integration goes beyond Microsoft Office. Other products also integrate with SharePoint. Take, for example, BizTalk, Microsoft's Business Process Management and SOA platform. Out of the box, BizTalk can use a SharePoint adapter to read and write files in SharePoint Document libraries. In this article, you will learn how to program and configure the BizTalk SharePoint Adapter.
First, SharePoint sites run under a Web Application. SharePoint sites contain a number of constructs; some examples are Lists, Wikis, and Document Libraries. As stated earlier, the SharePoint Adapter integrates BizTalk primarily with SharePoint Document Libraries. I'll talk later about how the SharePoint Adapter works with other SharePoint repositories. For most of the article, though, you'll be dealing strictly with Document Libraries and their specialized counterpart Form Libraries. A sample document library appears below.
File type and document Properties are the most visible aspects of a Document Library. Document Libraries can store many different file types; examples are: Word documents, PowerPoint Documents, and InfoPath forms. Properties store information like a last modified date, create date, or other information oftentimes extracted from the file being stored.
Document libraries come in two flavors—standard document libraries containing content based on one or many file types and Form Libraries often based on InfoPath Forms. I'll talk more about the distinction in a bit.
BizTalk breathes and bleeds XML, so it should come as no surprise that BizTalk often submits XML files to SharePoint. SharePoint leverages Microsoft Office InfoPath Forms to view and manipulate XML submitted by the SharePoint Adapter.
Introduction to InfoPath Forms
InfoPath is part of the Microsoft Office suite. InfoPath exists to manipulate XML. An InfoPath "Form" is to InfoPath what a Word "document" is to Word and, like Word documents, InfoPath Forms are based on a template. A complete introduction to InfoPath Forms is beyond the scope of this article, so I'll only highlight the items important to the SharePoint Adapter.
InfoPath templates are derived from an XML schema, but are essentially CAB files containing a collection of files. Forms created from an InfoPath template look like a typical XML file with some additional information called Processing Instructions at the top of the file. Below are the processing instructions from an InfoPath file.
<?mso-infoPathSolution href="http://sb-dev-03- vs4/sites/EIA/Integration%20Error%20Messages/Forms/template.xsn" name="urn:schemas-microsoft-com:office:infopath:Integration-Error- Messages:http---Crowe-ChannelStackPipeline-FailedMessage" solutionVersion="18.104.22.168" language="en-us" productVersion="11.0.6357" PIVersion="22.214.171.124" ?><?mso-application progid="InfoPath.Document
As you may have noticed in the Processing Instructions, the path to the Form template is stored in the XML file. Unlike Word, the visual representation information of an InfoPath Form is not baked into the file. So, the template must be stored on a Form user's machine or somewhere inside SharePoint.
Form libraries contain Forms created from the same InfoPath template. Often, the Form template is stored or rather "published" in the Form library containing the InfoPath file. SharePoint stores a Form library's template in the Document Library "Forms" folder (choose the explorer view to see this).
Now that you've covered SharePoint and InfoPath basics, you'll start looking at Adapter configuration and programming beginning with some configuration hints.
Adapter Configuration Hints
The BizTalk documentation explains Adapter Configuration, so I'll address areas requiring clarification.
The Adapter installation and configuration is straightforward if SharePoint and BizTalk are on the same machine. Most likely, however, this will not be the case, so you need to understand how the Adapter works.
There are two parts to the adapter. The core SharePoint Adapter residing in the BizTalk installations and a Web Service installed on the SharePoint target system. The arrangement is similar to the one graphically depicted below.
As you can see, the Web Service portion of the SharePoint adapter works through a separate IIS site. Extending a Web Application is an alternate way to support multiple types of access to a SharePoint Web Application. The Extend Web Application is on the Application Management menu. Here are the Extend Web Application options.
I recommend using different port than the default Web Application. I would advise using a consistent port number if you have multiple SharePoint installations.
Once the SharePoint Web Application is extended, you can configure the Web Service portion of the BizTalk Adapter. After launching the BizTalk Configuration application, select the "Custom" configuration option. The Dialog below will appear.
Select the SharePoint Services Adapter Web Site you used when you Extended the Web Application.
Once you've configured the Adapter, you need to add the Account the Web Service uses to the "SharePoint Enabled Hosts" group (if you took the default Windows Group name). Instead of using a domain account, I like to use two local accounts: one local to the BizTalk server and one local to the SharePoint server. As long as the accounts have the same name and password, they'll work a lot like a Domain Account, but with a smaller security footprint.