ShareTalk Integration (SharePoint/BizTalk) – Part 5 Archiving Documents that have been retrieved from SharePoint

In Part 4 of this series we discussed retrieving documents from SharePoint. Much like the FILE Adapter in BizTalk, the WSS adapter will move this data instead of copying.  The fundamental issue with just copying the data is that the documents will continue to be copied with each poll that the adapter makes.  This may be ok for some scenarios but from my experience destination systems usually want the data once and only once.

The WSS adapter has an interesting feature when retrieving documents called “Archive Location URL”

I am going to build upon scenario that we used in Part 4 and create an “Archive” Document Library.

• Click on “Site Actions” - “Create”

• Click on “Document Library”

• I am going to call this document library “Outbound Archive”.  Remember this as you will need to populate the “Archive Location” property in the BizTalk receive location.

• If you click on the “View All Site Content” link, you will find that we now have an “Inbound Documents”, “Outbound Archive” and “Outbound Documents” that BizTalk can use when communicating with SharePoint.

• In my BizTalk Receive Location I now want to indicate that “Outbound Archive” is the “Archive Location URL”

• I now want to test this scenario so I am going to upload a document to my “Outbound Documents” Document library.

• The file was picked up and delivered to 2 locations:
  • The URI indicated in the Send Port that has a filter on the Receive Port that is polling SharePoint

• The document was also copied to the “Outbound Archive” folder with its original filename it tact.

 

As you can see the “Archive Location URL” is a powerful feature in the WSS Adapter.  I can envision a scenario where you build this great integrated scenario between SharePoint and BizTalk and have a last minute requirement indicating “that it would be really nice to have an archived copy of these messages that BizTalk is consuming”. Without this feature you could probably create a Send Port group and have BizTalk send a message back to SharePoint but this is a cleaner approach.

The next topic that I will be covering in this series will be integration with InfoPath. Stay tuned…

BizTalk 2009 64 bit - Don't forget to run BizTalk Adapter v2.0 for mySAP Business Suite in 32bit host

Note: this post is strictly related to the .Net Connector version of the SAP adapter and NOT the WCF based LOB Adapter.


When using the BizTalk Adapter v2.0 for mySAP Business Suite adapter on a 64bit machine, don't forget to run your Host Instance as a "32 bit Host".

Otherwise you will get prompted with the following error:




Log Name: Application
Source: BizTalk Server 2009
Date: 10/15/2009 10:54:28 AM
Event ID: 5697
Task Category: BizTalk Server 2009
Level: Error
Keywords: Classic
User: N/A
Computer: Server
Description:
The Messaging Engine encountered an error when intializing the receive adapter "SAP", HRESULT:"Retrieving the COM class factory for component with CLSID {1EB415A4-242C-4E28-9E9C-33367784F01E} failed due to the following error: 80040154.".
Event Xml:
<event xmlns="http://schemas.microsoft.com/win/2004/08/events/event"><system><provider name="BizTalk Server 2009">
<eventid qualifiers="49344">5697</eventid>
<level>2</level>
<task>1</task>
<keywords>0x80000000000000</keywords>
<timecreated systemtime="2009-10-15T16:54:28.000Z">
<eventrecordid>21227</eventrecordid>
<channel>Application</channel>
<computer>Server</computer>
<security></system><eventdata>
<data>SAP</data>
<data>Retrieving the COM class factory for component with CLSID {1EB415A4-242C-4E28-9E9C-33367784F01E} failed due to the following error: 80040154.</data> </event>



Change the Host to 32 bit, restart Host Instance and you should be fine. The reason for this is that the pre-requisite SAP Dot Net connector does not support native 64 bit. Here is a link for more details.

BizTalk Adapter v2.0 for mySAP Business Suite - Could not open a connection to SQL Server

During a non-production dry run implementation of BizTalk 2009 yesterday, we ran into the following error when an application that uses the SAP Adapter (.Net Connector Version) received an IDoc.

Note: this post is strictly related to the .Net Connector version of the SAP adapter and NOT the WCF based LOB Adapter. We have some applications that we have not migrated to the new adapter. It is on our "to do" list, but our upgrade scope is primarily a "like for like" upgrade.


Event Type: Error
Event Source: BizTalk Adapter v2.0 for mySAP Business Suite
Event Category: None
Event ID: 0
Date: 10/13/2009
Time: 4:23:28 PM
User: N/A
Computer: Server
Description:
Error in Check Transaction: A network-related or instance-specific error occurred while establishing a connection to SQL Server. The server was not found or was not accessible. Verify that the instance name is correct and that SQL Server is configured to allow remote connections. (provider: Named Pipes Provider, error: 40 - Could not open a connection to SQL Server)

For more information, see Help and Support Center at http://go.microsoft.com/fwlink/events.asp.



The first clue that something was wrong was that SAP did not show up in the configured list of Adapters. We were able to add it by right clicking on "Adapters" - "New" - "Adapters" before we turned on the application but that should have been our first indication that something wasn't quite right. We then checked for the existance of the following Stored Procedures that are added to the MessageBox database when you install the SAP Adapter:
- Mp_Sap_check_tid
- Mp_Sap_delete_tid
- Mp_Sap_insert_tid

These stored procs were not installed which prompted us to re-install the adapter. We also ensured to use the /console command when launching the Remote Desktop Connection tool. Upon removing the old adapter via control panel(repair didn't work) and re-installing the adapter we now had "SAP" showing up in the adapter list and the stored procedures were successfully added to the MessageBox Db. At this point we were able to successfully receive an IDoc from SAP.

ShareTalk Integration (SharePoint/BizTalk) – Part 4 Retrieving Documents from a SharePoint Document Library

In Post 3 I discussed how we can push documents to Windows SharePoint Services (WSS) by setting up a Send Port subscription in the BizTalk Administration console.  I am now going to reverse that scenario and have create another Send Port subscription with the difference being that the Receive Port that we will be filtering will contain a Receive Location that will poll a SharePoint Document library.

• In my “BizTalk Repository” Web Application, I am going to create a new document library called “Outbound Documents”.  From the “BizTalk Repository” Home, click on “Site Actions” - “Create.

• Click on “Document Library”

• Provide the document library with a name and some additional comments.

• You should now have a document library called “Outbound Documents” created

• In part 3, we provided the BizTalk Host Instance user with “Contribute” access.  Those permissions were applied at the Site level so as long as you followed that step, you should not need to provide any additional permissions for this scenario.

 

• In BizTalk Admin, create a new Receive Port and Receive Location that will use the “Windows SharePoint Service”

• If you are using a non-standard Port (anything other than 80), be sure to specify it in the “Adapter Web Service Port Property”.  Also ensure to provide the base URL for your Site: http://MyServer:99/sites/BizTalk%20Repository/ and the name of the Document Library which in this case is “Outbound Documents”.
• Notice that this adapter is a polling adapter and the default value is 60 seconds which can obviously be changed to meet your requirements.  If you have a multi-node BizTalk farm, I would expect that because this adapter uses polling that there is a risk of duplicated messages being retrieved like the POP3 or FTP adapters.  This is something that I plan on verifying in the near future.

• Create a Send Port and configure it to send documents to the file drop that we established in Post 3.

• Provide a Filter for this Send Port that uses the SharePoint Receive port.

• Upload a document to the “Outbound Documents” Document library.

• Now sit back and wait for the document to be retrieved from SharePoint and written to the location specified in your Send Port

• If you navigate to your Document library you will notice that this document has been removed.

 

Series Recap

At this point we have installed and configured WSS 3.0, installed and configured the Windows SharePoint Adapter Web Service, posted documents to SharePoint and retrieved documents from SharePoint.  We are really just starting to scratch the surface with “ShareTalk” integration.  There is some seamless integration with InfoPath that we can exploit as well as taking advantage of WSS Workflow to create some interesting Approval/Rejection scenarios.  So stay tuned, I plan on further exploring these areas and have some other interesting ideas that I going to attempt and will publish my results.

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”

• Click on “Document Library”

• 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.

• 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”

• Click on “People and Groups”

• Click on “Add Users”

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

• 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.

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

• 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/

• 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.

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

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

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?

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:

• 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.

• 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.

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

• Next

• Success

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.

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.