Sunday, October 18, 2009

ShareTalk Integration (SharePoint/BizTalk) – Part 6 Form automation using InfoPath/SharePoint/BizTalk

You may have some scenarios within your organization where you have people filling out forms using pen and paper or perhaps using MS Word or Excel.  The result of both of these activities is that you usually have another person re-keying this information into the downstream system that actually needs this information.  As you can see this process is horrible inefficient.  Not only is there a lot of duplication of effort, but there may also be data quality issues if you are trying to read someone’s “chicken scratch” and then input that information into another form.

The purpose of this post is to explore some of the integration capabilities that exist between InfoPath/SharePoint/BizTalk. 

As I have mentioned in the past, I work in the energy industry.  We have many mobile workers who are out in the field and have durable laptops where they will manage their work orders, email etc.  These workers need to be able to get their “documentation” out of the way quickly so that they can focus on their jobs.  Using a tool like InfoPath aligns well with their productivity needs as it is easy to use and also supports online/offline capabilities since these workers generally make network connections from rural areas.

The POC that I am going to build is related to a Field Incident Form that can be used for mobile workers to populate when an incident has occurred in the field.  The incident could be related to environment issues such as an oil spill or an injury that has occurred.

Define your contract

Open up Visual Studio and model your schema.  By doing so, you will ensure that BizTalk, SharePoint and InfoPath are all “speaking” the same language. Once done, ensure you have saved your XSD as we will use it in the development of the InfoPath form.

 

image  

Define your InfoPath form

  • Click “Design a Form Template”

image

  • XML or Schema

image

  • Browse to your XSD that you developed in Visual Studio

image

image

  • Drag and Drop the fields from the right hand side onto your form.  You then can work on making the UI pretty.

image

  • What can I say, I am a BizTalk developer not a Silverlight/WPF developer

image

 Publish your form

  • Publish this form to your SharePoint document library by clicking on the “Publish Form Template”

image

  • Select “To a SharePoint server with or without InfoPath Forms Services” and click “Next”

image

    • Provide a link to your SharePoint Document library and click yes.  If you have issues with this, make sure that you have a root site i.e. http://server/ otherwise you will get an error.

image

  • I want to publish the form as a “Document Library”.

image

  • Select “Create a new document library” and click “Next”.  I called my Document Library “Field Incident Reporting Forms”.

image

  • Add any columns that you would like to be displayed in the document library.  The data that will be displayed comes from underlying XML that is captured in the InfoPath form.

image

  • “Publish”

image

  • Success

image

  • Document Library has been published

image

  • Click on the “New” button and you will find that the Field Incident Entry Form is automatically displayed.

image

image

 Enhance your form

  • I can have users save the InfoPath form into the SharePoint document library(via FILE –> SAVE AS), but I want to simplify the user experience. I am going to add a submit button to the form so that we can publish the form to SharePoint directly.  Click on the “Controls” button.

image

  • Drag the “Button” control and drop it in the appropriate place on the form.

image

  • Right mouse click on the button and select “Button Properties”

image

  • Change the “Label” to “Submit”

image

  • Click on “Rules” button

image

  • “Add”

image

  • Modify the “Name” and click on “Add Action”

image

  • Pull the “Action” drop down and select “Submit using a data connection” and click “Add”

image

  • “Create a new connection to:” ->“Submit Data”

image

  • Select “To a document library on a SharePoint site” and click “Next”

image

  • Previously, a Document Library called “Field Incident Reporting Forms” was created and this is where I would like to publish this form.  Next click the “fx” button as we will be able to use data from the InfoPath form to make up part of the file name that will be displayed inside of SharePoint.

image

  • Click on “Insert Function”

image

  • Select the “concat” function and click “Ok”

image

  • I am going to input a string literal of ‘Incident Form’ and then double click the “double click to insert field” link to choose a field from the InfoPath form.

image

image

  • Since I only want two elements of data, I am going to remove the last “double click to insert field link”.  Next I will click on the “Verify Formula” button to ensure I have a valid function call.

image

  • Click “OK” to continue

image

  • “Next”

image

  • I called my data connection “Submit Field Incident Form” and click “Finish”

image

  • Click on “Ok”

image

  • “Ok”

image

  • “OK”

image

  • If you want to have the form automatically close when the “Submit” button is clicked then right mouse click on the “Submit” button and select “Button Properties”.  Next, pull down the “Action” drop down and select “Submit”.  The “Submit Options” button should now appear and click it.

image

  • Expand the options by clicking on the “Advanced” button, select “Close the form” from the “After submit” pull down and click “OK”.

image

 

 Re-Publish your form

  • Once done, go through the process of publishing the form again so that when you click on the “New” button in the Document library that the version of the form that is launched has the “Submit” button included.
  • Navigate to you Document Library, click on “New” –> “New Document”

image

  • Populate the form and click the “Submit” button

image

  • A confirmation message indicating that the Form has been submitted will appear and the form will close.

image

  • You will now see a completed InfoPath form in your document library. Notice that data that was populated in the InfoPath forms is also displayed within the columns in the document library.

image

 

Configure BizTalk to consume these forms

  • All that I have done is modify the “Source Document Library URL” from Part 4 of this series. I continue to use the Send Port filter from Part 4 as well.

image

  • Document is pulled from SharePoint and sent to the folder that is specified in the Send Port configuration.

image

  • If I open up the document I will find that it matches my XSD specification that I established in the first step of this post.  Knowing that this message is typed, it is like any other message inside of BizTalk and can be transformed to match a specification of another system that will have a different format than InfoPath e.g. an ERP system.

image

 

In the next post of this series, I am going to build upon this scenario and add an approval process so that a supervisor could review the incident form before it is submitted to BizTalk.  Stay tuned…

Saturday, October 17, 2009

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”

image

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

  • Click on “Site Actions” - “Create”

image

  • Click on “Document Library”

image

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

image

image

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

image

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

image

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

image

image

image

  • 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

image

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

image

 

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…

Thursday, October 15, 2009

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.

Wednesday, October 14, 2009

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.

Monday, October 12, 2009

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.

image

  • Click on “Document Library”

image

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

image

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

image

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

image

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

image

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

image

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

image

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

image

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

image

image

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

image

 

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.