Sunday, October 11, 2009

ShareTalk Integration (SharePoint/BizTalk) – Part 3 Posting Documents to SharePoint Document Library

In Posts 1 and 2, we covered installing Windows SharePoint Services(WSS) 3.0 and installing the BizTalk – WSS Adapter web service. In this post I will walk through a simple integration scenario that will cover posting a document to a SharePoint document library.

Sending documents to a SharePoint library

  • First thing we will need to do is create a document library where we can post documents to. From the Web Application that you created in Post 1, click on the “Site Actions” tab in the top right corner and click “Create”

image

  • Click on “Document Library”

image

  • Give your document library a name and make a note as you will need the name of this library when populating the send port in BizTalk.

image

image

  • You will now need to add the BizTalk host instance user to this site so that you can write to this particular document library. To do this click on the “Site Actions” dropdown and select “Site Settings”

image

  • Click on “People and Groups”

image

  • Click on “Add Users”

image

  • Provide your Host Instance with “Contribute” permissions and restart your BizTalk Host Instance.

image

  • In the BizTalk Admin console, create a new application - I called mine “SharePointPOC”. I then created a Receive Port and Receive Location that looks for xml documents via the FILE Adapter.

image

  • Create a Send Port and specify the “Windows SharePoint Service” as the transport type.

image

  • If you provided your Web Application with a non-standard port (anything other than 80) then you will want to make this change here. You will also need to provide the name of the document library that we created in a previous step. In my sample, my document library is called “Inbound Documents”. Finally, you will need to provide the base URL to your site. In my example, this equates to http://MyServer:99/sites/BizTalk%20Repository/

image

  • You will now need to create a filter that will ensure any documents that are processed from the Receive Port, that you created, will now get sent to SharePoint.

image

  • Ensure your application is started and drop a file into the file drop folder that will match your file mask

image

  • If everything is configured correctly, you should now find a file in your document library in SharePoint

image

Check out Post 4 where I describe how to pull documents from SharePoint.

ShareTalk Integration (SharePoint/BizTalk) – Part 2 Setting up BizTalk – WSS Adapter Web Service

In Part 1 of this series I described the steps involved in installing WSS 3.0 on a BizTalk Server. The next step is to install the BizTalk – Windows SharePoint Services Adapter Web Service.

Wait a minute! I have the WSS Adapter in my list of adapters and I haven’t installed WSS 3.0 or any web services. While true, have you tried to use it?

image

If you try to use the adapter without the prerequisite WSS 3.0 or Adapter web service you will be prompted with the following warning:

Event Type: Warning
Event Source: BizTalk Server 2009
Event Category: (1)
Event ID: 5740
Date: 10/10/2009
Time: 1:55:06 PM
User: N/A
Computer: <SERVER>
Description:
The adapter "Windows SharePoint Services" raised an error message. Details "The Windows SharePoint Services adapter Web service was not found at the specified URL, "
http://localhost/BTSharePointAdapterWS/BTSharePointAdapterWS.asmx". The Windows SharePoint Services adapter Web service feature is required to be installed and configured on machine localhost. If the feature has been installed and configured, then verify that Adapter Web Service Port and SharePoint Site URL settings on the BizTalk port are correct.

This error was triggered by the Windows SharePoint Services receive location or send port with URI wss://localhost:80/abc?ViewName=.

Windows SharePoint Services adapter event ID: 12461".

  • Once you have WSS installed it is time to run through the BizTalk install. I previously had BizTalk installed on this machine, so I am simply going to “Modify” my existing installation:

image

  • I now have the ability to check the “Windows SharePoint Services Adapter Web Service” check box. The BizTalk install process will determine if WSS is installed and if so you have the ability to install this Adapter Web Service.

image

image

image

image

  • Check on the “Enable Windows SharePoint Services Adapter on this computer”. Use the drop down list to select the WSS Site where you would like the adapter to be installed. I established the “SharePoint – 99” site in Post 1 of this series so I am going to go ahead and use it. Be sure to add the user of the Host instance, that will operate this adapter, to the “SharePoint Enabled Hosts” group.

image

  • Assuming everything is aligned correctly, you should now be able to click the “Apply Configuration” button.

image

  • Next

image

  • Success

image

If you launch IIS and navigate into the WSS Site that you created in Post 1 you will find that BizTalk – WSS Adapter Web Service now installed. The BizTalk WSS Adapter will leverage this Web Service when calling the SharePoint API.

image

So what is the point of the the WSS Adapter if SharePoint exposes functionality through a Web Service. I can only speculate, but I believe part of this motivation is to abstract some of the complexity involved in calling these Web Services. It also allows you to create solutions without needing to crack open Visual Studio to consume web services and create proxies. By leveraging the Adapter + Web Service you can build some pretty powerful solutions without even creating a BizTalk Project. This allows you to turn around solutions quicker and really becomes a ‘Value Add’.

Check out Post 3 on how to post documents to a WSS document library.

Saturday, October 10, 2009

ShareTalk Integration (SharePoint/BizTalk) – Part 1 Setting up WSS 3.0

In a previous post I mentioned that I was going to dig a little deeper into building integrated solutions using SharePoint as the front end GUI and leverage BizTalk as the back end integration tier. Before I get too involved in building solutions, I figured that it would be helpful to provide a step by step ‘tutorial’ on how to set up the prerequisite components.

What will you need to build these solutions?

  • Windows Server 2003/Windows Server 2008 32bit or 64 bit
    • You can also install WSS3.0 on Vista or Win7 by using a trick (don’t do this in production scenarios)
  • IIS
  • BizTalk Server 2009 & SQL 2005/2008
  • Visual Studio 2008
  • Microsoft InfoPath(future posts)
  • Windows SharePoint Service 3.0 – download here
  • Windows SharePoint Services 3.0 requires Microsoft .NET Framework 3.0. The .NET Framework must be installed prior to installing Windows SharePoint Services 3.0.

For the purpose of this post, I am running a 32 bit system and am not connected to Active Directory so mileage may vary. If you are trying to run mixed mode – say 32 bit WSS install on 64bit system there are some special considerations. See the BizTalk installation documentation for more details.

Also, I have followed the configuration guidelines that were provided in the BizTalk install document. If you have no intentions of running BizTalk with WSS 3.0 then the following configuration may not meet your requirements.

Installing WSS 3.0 (on your BizTalk Server)

  • Launch SharePoint.exe and accept terms
  • Select an “Advanced” installation

image

  • Select - “Web Front End” as the Server Type install and click “Install Now”

image

  • After about 10 minutes you should be prompted with the following screen:

image

Ensure the configuration checkbox is clicked and click the “Close” button.

  • “Next”

image

  • “Yes”

image

  • Modify the current configuration and indicate “No, I want to create a new server farm”. This applies even if you have a single BizTalk Server deployment

image

  • Provide a Database server name and credentials.

image

  • Default values used

image

  • Default values used

image

image

  • Success!

image

  • You now have a functional WSS 3.0 install

image

At this point, the administration portal has been created. You can use this portal to create new Web Applications, or sites, that can be utilized by your users. Ideally, you would want your user’s team sites running off of a different Web Site than your admin portal. I will now walk you through creating a new Web site and document library that can be used by BizTalk, or any other user for that matter.

  • Click “Application Management”

image

  • Click on “Create or extend Web application”

image

  • Click on “Create a new Web application”

image

  • I have decided to create my Web Application in a new IIS Web site called “SharePoint – 99”. I have done this so that I don’t overwrite or break anything that may be living in my Default Web Site. I also have modified the port to be “99” which means any requests to my WSS Site will need to have “:99” in the url. If you do this then when you post or retrieve documents to/from SharePoint from BizTalk that you will need to include this port number in your Receive Location/Send Port configuration.

image

Note that “:99” makes up part of the URL. I also want to have a WSS dedicated App Pool which I have called “SharePoint – 99” so it is very clear when determining which IIS Web Site uses this App Pool.

image

  • Note that I have appended “99” onto the Database Name that will be used for storing Content. Much like if you ran multiple BizTalk Groups on a SQL Server it is much easier to clean Databases up when you can easily differentiate them.

image

  • Success!

You have now created the “shell” for this Web Application, but you still don’t have any content in this Web Application. Click on the “Create Site Collection” link. Remember to issue an “iisreset /noforce” command to complete the Web Application creation process.

image

Give your Site a Title, Description(if so desired) and create a URL. Note I have pulled the drop down list and indicated that I want this site to reside under the “sites” umbrella. This just allows sites to be organized a little better.

image

For this site, I have decided to create a “Team Site”. Team Sites are generally a place where team members can collaborate by publishing documents, but other features exist such as Team Calendars, surveys, links etc.

Also indicate users to administrate the site.

image

  • Team site has now been created.

image

  • Click on the link to verify that it was create successfully.

image

That is all for configuring WSS 3.0. Check out Part 2 of this series to configure the BizTalk – WSS Adapter Web Service. You will utilize the WSS Web Application that you just created as part of the Adapter Web Service Configuration.

Saturday, October 3, 2009

BizTalk 2009 WSS Adapter + Connecting to non-standard ports

When hosting Web Applications in IIS(and other web servers) you have the option to access that web site using a different port than the default (80). I had previously set up BAM and had some other applications running off of the "Default Site (80)" so I didn't want to host Windows SharePoint Services (WSS) on that port. Instead I opted for port 99 when going through the WSS configuration.

When you configure the BizTalk - SharePoint Adapter Web Service you have the option of specifying which site you want to install it in. If you want it to work, you select the site where your have installed WSS.

Upon creating a simple Send Port Subscription, I attempted to push a document to WSS. I was prompted with a warning in the BizTalk Event Viewer:


Event Type: Warning
Event Source: BizTalk Server 2009
Event Category: (1)Event ID: 5743
Date: 10/3/2009
Time: 8:48:50 AM
User: N/A
Computer: MyServer

Description:
The adapter failed to transmit message going to send port "SendToSharePointLibrary" with URL "wss://MyServer:99/sites/BizTalkDocs/Surveys". It will be retransmitted after the retry interval specified for this Send Port. Details:"The Windows SharePoint Services adapter Web service was not found at the specified URL, "
http://MyServer/BTSharePointAdapterWS/BTSharePointAdapterWS.asmx". The Windows SharePoint Services adapter Web service feature is required to be installed and configured on machine MyServer. If the feature has been installed and configured, then verify that Adapter Web Service Port and SharePoint Site URL settings on the BizTalk port are correct.
This error was triggered by the Windows SharePoint Services receive location or send port with URI wss://MyServer:99/sites/BizTalkDocs/Surveys.
Windows SharePoint Services adapter event ID: 12461".

I copied the URL from BizTalk admin, replaced wss:// with http:// and placed it into a browser. The Document Library appeared so I figured it had to be related with the adapter. My inital thought was "Don't tell me the Adapter can't work when you are hosting WSS on a port other than 80". Upon some further digging this wasn't the case. I overlooked the "Adapter Web Service Port" configuration which by default is 80 even though I specify ":99" in the SharePoint Site URL. Once I made this correction, I was able to successfully post documents to SharePoint.


BizTalk 2009 + SharePoint/WSS 3.0 integration first look

The organization that I work for is leveraging SharePoint heavily due to its nature of it being a collaboration platform. Much like we leverage BizTalk to minimize the amount of custom work to integrate, we leverage SharePoint to reduce the amount custom work to collaborate.

We currently run MOSS 2007 and were running BizTalk 2006 so we haven't had many opportunities to attempt this integration since BizTalk 2006 only supports Windows SharePoint Services 2.0. The way I understand it, MOSS 2007 is built upon WSS 3.0 so BizTalk 2009 is capable of communicating with either WSS 3.0 or MOSS 2007. A difference between the two is that WSS 3.0 is free where as MOSS 2007 requires licenses. I am not going to further differentiate the two but will leave you with this link instead.

If you are already familiar with BizTalk and SharePoint integration then you may want to move on (you probably won't learn much from this post). The idea behind this post is to help out the new comers to this integration scenario. I recall having several questions when starting out so I figured putting together some answers to these questions may save some people some digging.

The very first thing that you need to do before cracking open any tools or downloading any install packages is watch Mick Badran's Web cast on SharePoint integration. For those of you who don't know Mick he is a BizTalk MVP and if Microsoft allowed it he could probably be a SharePoint MVP as well. This web cast help me out tremendously!

Reducing the confusion
  1. While the Windows SharePoint Services Adapter shows up in your list of adapters in BizTalk Admin, it doesn't mean that it is ready to be used. The BizTalk - SharePoint Services Adapter is not able to work all on its own. In order for you to use this adapter, you need to install the BizTalk - SharePoint Services Adapter Web Service. Confused yet? This adapter web service knows how to intelligently call the SharePoint API. While you could call these SharePoint Web Services directly, the BizTalk Adapter abstracts this complexity away from you. You will not require any Web Service Proxies in your solutions which is a big plus.
    Once installed, a virtual directory will appear in your SharePoint Site.

  2. Update - You only need WSS installed on your BizTalk servers if you plan to host WSS sites on your BizTalk servers. If you plan to connect to remote WSS or MOSS servers you do NOT need WSS installed on your BizTalk Servers.
  3. Follow the BizTalk install guide! This should be a given but don't try to 'assume' your way through the install and configuration of WSS. There are some decisions like ensuring that your WSS install is part of a Server Farm even if you are running it on one BizTalk Server. Here is the link.

  4. There are some 32 bit/64bit considerations - read the fine print carefully.

  5. In distributed environments, create your AD groups/accounts ahead of time.

  6. Leverage any SharePoint resources you have available to you. I have used SharePoint, as a user, for quite some time but there is still some terminology that I am not too familiar with (Lists, Document Libraries, Workspaces, BDC etc). I had a SharePoint colleague give me a 10 minute walk through of creating Document Libraries, Custom Views etc and it went a long way.

All in all I am pretty pleased with the experience. Within a couple hours I had WSS 3.0 installed, the Adapter Web service installed and configured and am pushing/pulling documents into/from WSS 3.0 via Send Port Subscriptions.

Expect a few more posts on this subject as I plan on taking this topic a few steps further by integrating with InfoPath and LOB systems.

Wednesday, August 26, 2009

BizTalk 2009/Windows 2008 - Clustering SSO issue

During the clustering and configuration of the Enterprise Single Sign on service we ran into the following issue when trying to restore the master secret.

C:\Program Files\Common Files\Enterprise Single Sign-On>ssoconfig -restoresecret
C:\mastersecret\SSOD04F.bak
Password reminder : *Reminder*

Password : ********
ERROR: 0xC0002A0F : Could not contact the SSO server '*PhysicalNode*'. Check that SSO
is configured and that the SSO service is running on that server.
(RPC: 0x800706D9: There are no more endpoints available from the endpoint mappe
r.)


I thought it was odd that the *PhysicalNode* was showing up in this error message since I was expecting the virtual server name to show up.

Upon checking the status of SSO I was provided the following information:

C:\Program Files\Common Files\Enterprise Single Sign-On>ssoconfig.exe -status

Using SSO server on this computer

SSO server : *PhysicalNode*
SQL Server : *SqlClusterName*\*SQLClusterInstance*
SSO Database : SSODB
Service Account : domain\*SSOUser*
Cluster Name : *ClusterName*
Node Name : *PhysicalNode*
Event Counts (Info/Warning/Error... : 9/11/0
Version : 6.0.245.0
Password Sync Age (in hours) : 0
Audit Levels (Positive/Negative) : 0/1

Server status : Online
Secret server running : Yes
Password Sync loaded : No
Password Sync from PCNS running : No
Password Sync from MIIS running : No
Password Sync from adapters runn... : No
Allow password changes from PCNS : No
Allow password changes from MIIS : No
Clustered server : Yes
64 bit server : Yes
Using SSL for SQL connection : No
Case sensitive : No
Allow remote lookup : No
Local administrator : No

Having the Physical node being displayed as the SSO Server is a problem. I would have expected that the Cluster Resource group Server name should have been populated in the SSO server field.

Even though we already ran the ssomanage -updatedb XMLFile command I figured that I would run it again. (What is the definition of insanity, running a task over and over again but expecting a different result?) So when we ran this command and included our Cluster Resource group server name in the file, it still did not have an effect even though the command was "successful".

When I went back and ran the ssoconfig.exe -status command it still indicated that the SSO secret server was the phyiscal node and not the Clustered Resource group server name.

After hunting through the online documentation, I ran into the following:

If you do not click to select the Use Network Name for computer name check box, SSO client computers will generate an error similar to the following when they try to contact this clustered instance of the Enterprise SSO service:
Failed to retrieve master secrets.
Verify that the master secret server name is correct and that it is available. Secret Server Name: ENTSSO Error Code: 0x800706D9, there are no more endpoints available from the endpoint mapper.


The error messages are different, but it did seem applicable to our situation. I then went into the Failover Cluster Managment MMC and found that the "Use Network Name for computer name had not been checked off".

We also had to add a Network Name and IP Address as dependencies for this configuration to be set.


Upon bouncing the ESSO service and running the ssomanage -updatedb XMLFile and ssoconfig.exe -status commands the proper SSO Secret Server name was being populated. After performing these steps, we were able to restore the Master Secret server on all nodes without issue.

Friday, August 21, 2009

BizTalk 2009: Unable to configure BAMArchive

When trying to configure the BAMArchive database on a fresh BizTalk 2009 64 bit install, I encountered the following error:
Microsoft SQL Server 2008 Data Transformation Services (DTS) for BAM Archiving is not installed on the local machine. Please install Microsoft SQL Server 2008 Integration Services.
...
Could not load file or assembly 'Microsoft.SqlServer.ManagedDTS, Version=10.0.0.0,



This error makes it sound like you need to install SQL Server Integration Services (SSIS) which is a little misleading.

The documentation on MSDN indicates the following:

What 64-bit SQL Server components are required to configure BAM tools?
The configuration wizard is a 32-bit process; therefore it requires certain components which allow it to communicate with 64-bit SQL Server. You must install the following SQL Server client components to enable configuration of BAM tools:
Connectivity Components
Management Tools
Legacy Components


http://msdn.microsoft.com/en-us/library/aa560166(BTS.10).aspx

In order for me to complete my installation, I installed the following components from the SQL Server 2008 media(I don't see the Legacy Components option).