Archive for September, 2008
A few months ago I had posted on a way to run both Visual Studio 2008 and BizTalk Server 2006 R2 with Visual Studio 2005 so that you could take advantage of the new environment for developing WCF and WF projects while continuing to work with BizTalk. I had setup this software combination on my local development box in Windows XP and had been working fine without any significant issues. Although there are a few known issues about TFS compatibility across solutions that include BizTalk projects as well as .NET 3.5 projects, I had not encountered any issues with my BizTalk installation until today.
During some development I realized that I likely needed to do a repair on my BizTalk installation due to an error I was receiving about a key violation error in one of my BizTalk databases. It is a common recommendation that the installation be repaired through the Add/Remove programs repair part of the installation wizard when certain issues are encountered with BizTalk. So I loaded the BizTalk installation image and started the repair and everything worked fine until near to the end of the repair. Then all of a sudden I started receiving errors about the WCF adapters that are included with BizTalk Server 2006 R2. Here is an example error:
Failed to add adapter: WCF-NetNamedPipe, Error C0C025CA
A similar error occurred for nearly every one of the R2 WCF adapters with the name of the adapter being the only thing different in the error message. I clicked OK for every one of the error messages and this was apparently not a significant-enough error because it did not prevent the repair from continuing. The repair completed successfully without any other reports of problems. I checked in the Event Viewer and there were not any additional error messages to provide more information on what went wrong.
At this point I think the reason this problem occurred is because I have a version of Visual Studio on my system that is not currently compatible with BizTalk because I know that the BizTalk repair wizard did not have this problem running before I had installed Visual Studio 2008 side-by-side. Until I find more information about this error I have to say this is a known issue for BizTalk development where you have a side-by-side of Visual Studio 2005 with the BizTalk extensions and a separate Visual Studio 2008. At this point I am not sure whether the WCF adapters have suffered any sort of actual casualty by the repair wizard issues. But I think if you want to run the repair wizard successfully without any issues, be sure to uninstall Visual Studio 2008 prior to starting the repair wizard. Good luck with your BizTalk environment configuration!
I am working on a project where I am extending a BizTalk application so that I can route messages from a single FILE port to different BizTalk applications and various orchestrations through the use of role links. Role links are one of the less frequently used and discussed tools of an experienced BizTalk developer. Getting my mind around role links was difficult because of the number of configuration details required to setup a role link. I am indebted to Eric Stott’s blog post at http://blog.biztalk-info.com/archive/2006/10/25/BizTalk_Role_Links_explained.aspx, but I think it would seem easier to describe role links as a precursor to the WCF binding architecture. I will describe some architecture notes on role links next but to see my thoughts on how role links are like WCF, skip on down a few paragraphs.
Role links are essentially the opposite of dynamic ports. A dynamic port consists of one port that then has multiple variations of configurations based on the dynamic expressions applied to this port for one adapter. A role link is a static configuration but is essentially a collection of ports of different adapters. For a dynamic port there is not always an explicit party concept; in a dynamic port a message is being sent from one organization to some other variable organization. And in a role link a message is either being sent or received and is then one of a collection of organizations for each endpoint. Role links are based on ports that are designated as being associated with some BizTalk party. The party can have one or more aliases which act as destination tokens when used with role link based routing.
So here are a few examples of how role links could be used:
– When you need to have dev, test, and production parties all hosted in a single BizTalk application and merely need to differentiate logic for these parties based on ports
– When you need to expose a single business process to multiple parties without creating more than one orchestration to handle all of them.
– When you need more than 1 backup port in a BizTalk application
– When you are struggling to manage so many BizTalk artifacts and are looking for a way to reduce the number of orchestrations
– When you want a lightweight built-in BizTalk routing mechanism that has a simple but flexible mechanism for specifying a routing destination.
– When you want to expose more than one adapter for some organization as connectivity options
This last example of a role link use helped me think about a more contemporary example of a role link. In WCF when you expose a service, it is possible to expose more than a single endpoint for a service so that the organization that connects to the service can use either HTTP or TCP or some other protocol or set of binding options to connect to the service. This is frequently used to expose a WSI basic profile service for interoperability and a WS-* or SOAP 1.2 service for newer clients as in the following example: http://keithelder.net/blog/archive/2008/01/17/Exposing-a-WCF-Service-With-Multiple-Bindings-and-Endpoints.aspx. WCF provides the binding infrastructure so that it is possible for a client to have various options for connectivity. In the same way, role links provide a way to provide to a client multiple integration options that all get consumed into the same business process.
So role links are very similar to the binding infrastructure in WCF due to the trasnport-level flexibility both enable. If you are a BizTalk developer, you should take role links for a spin because they provide some very valuable extensibility options. It does take a while to get used to role link abstractions so I recommend taking WCF as a good example of what role links seek to accomplish and then throw adapters and parties in the mix and it makes much more sense. Have fun with role links!
Recently I worked on a BDC project and I was able to get a taste for what is possible for out-of-the-box SharePoint integration with external systems. The tricky aspect of BDC web service integration is that it only works with older web services – ones that use Basic Profile. The challenge of this is that you are limited in the integration options that are available because you must rely on the older SOAP and HTTP protocols. There are Office SDK samples that showcase integration with SAP and Siebel over BDC web services or Oracle over BDC database connections, but I was wondering how I would expose PeopleSoft or some other enterprise system that cannot be reached with a Basic Profile web service or a database connection.
Based on my BizTalk background, I knew that I could use the PeopleSoft adapter through BizTalk and then expose a BizTalk orchestration as a Basic Profile web service that could then be consumed by the BDC. So essentially this would be like a BDC bridge over BizTalk. This is when I started exploring the WCF LOB SDK as an interesting technology because the BizTalk adapter pack 1.0 is based on this SDK and it basically provides enterprise integration over WCF. Very few people are playing with the WCF LOB SDK, mostly because I think it seems confusing and has a poor name. The SDK is targeted at BizTalk developers with its "adapter" terminology, but it is really more of a way to talk about BDC from an adapter-oriented mindset. The LOB terminology should connect in your mind the LOB aspects of the BDC. If you look at the BDC documentation, the concepts are all about connections rather than adapters, but the WCF LOB SDK redefines the adapter concept by describing it as part of the channel infrastructure. So the future for the BDC is a redefined adapter based in WCF.
I found a few links that tie together the BDC adapters <-> WCF LOB SDK concepts, which really give us a glimpse of how the WCF LOB SDK is going to actually become more valuable from a MOSS perspective as the MOSS product is enhanced to support WCF. Usage pattern 7 on http://blogs.msdn.com/biztalk_adapter_development/archive/2007/07/09/wcf-lob-adapter-usage-patterns.aspx mentions how future BDC enhancements will rely on the WCF LOB SDK. It looks like Jesus Rodriguez also played with some of these scenarios: http://weblogs.asp.net/gsusx/archive/2007/07/12/sharepoint-bdc-wcf-adapters-and-more.aspx. The dates on these links suggest these concepts are old news but it is still relevant because the BizTalk adapter pack 1.0 was only recently released. The plans for this SDK go way back but the vision for how it will be used in the future seem to be missing. The WCF LOB SDK gives us a vision for the future of the BDC, which should include having a better designer experience for BDC developers as well as a much richer level of connectivity and flexibility. So the ROI for the WCF LOB SDK is still down the road, but once MOSS can support WCF it will be possible to integrate these other enterprise systems like PeopleSoft straight from the BDC. This is an exciting vision for the future of the BDC technology and a great reason to get your hands dirty with the WCF LOB SDK.
As part of a couple projects I have gained experience working with Systems Center Operations Manager (SCOM) as part of working with IT departments who needed to manage BizTalk, Active Directory, and SQL Server. One request I recently got was to determine how SQL actually gets executed as part of the SQL Server management pack. So the first thing I needed to do was to load the SQL Management pack into SCOM and then explore the Task artifacts to determine which ones were executing SQL. You would think that there would be quite a few of them for DBA-centric tasks. Along the way of doing this I noticed a few gotchas and wanted to point these out. Catch the end of this post to see the results of my probing into the management pack.
When installing the SQL management pack download, an MSI runs to export a copy of all of the management pack files (*.mp) that need to be loaded into SCOM. If you search on the management pack catalog (http://technet.microsoft.com/en-us/systemcenter/cc462790.aspx), it comes back with the same management pack for SQL 2000, 2005, and 2008. But when running the installer it does not created any 2008-specific management packs, only 2000 and 2005 ones so this is a little misleading. The MSI creates 5 different management pack files, the SQL Core Library, the 2000 discovery pack, the 2000 monitoring pack, the 2005 discovery pack, and the 2005 monitoring pack. The core library should be loaded first, then one or both discovery packs, and finally one or both monitoring packs. Most managment pack installs just create a single .mp file so be sure to run the additional packs to get all of the management artifacts!
I loaded the management packs into SCOM and then started searching for where SQL may be executing based on the SQL management pack. There are a couple of different things to look for in a management pack such as alerts, monitors, tasks, rules, etc. Typically tasks are used for executing scripts, starting Windows services, or other command-line executable tasks. I ended up only finding a single instance of specific SQL being executed from the SQL Management pack:
sqlcmd.exe -E -S $Target/Property[Type="SQL!Microsoft.SQLServer.DBEngine"]/ConnectionString$ -Q "sp_configure"
One thing that is interesting about this command is that it pulls out a property from for the connection string in what looks like a Powershell variable and then executes a call to sp_configure. This provides an example of what would be required to create a custom task that executes SQL. Only finding a single task was surprising – I was expecting that there would be one for updating indexes based on the results of SQLProfiler, or other common administration tasks. Alas, I will need to create a custom management pack to do these kinds of things. At least this example shows me how easy it would be to create a task to execute some custom SQL.
I recently uncovered an overflow problem in BDC columns. When returning data from a BDC data source, it is possible to return too much data if the BDC is being used as a column in a custom list. The maximum length of a BDC column when used in a list is 255 characters, which is the default maximum length of a text type column in MOSS. When using the BDC web part, data that is returned is not subjected to the maximum length of 255 characters. When more data is returned than 255 for a particular column, I received the error: "Invalid text value". Within the BDC application definition, the TypeDescriptor data type for these columns was System.String. I could not find any other errors in the event logs or SharePoint logs for this problem.
I wanted to post this maximum length because the MSDN documentation does not mention this.
Since I was working with a SQL Server BDC connection, I was able to wrap fields that could overflow the 255 character maximum using the substring function as in substring(<fieldname>,1,255), but this will not be possible for all BDC connections.
I have been recently working on a MOSS BDC project and have been struggling with some ambiguous error messages that were occuring on when using BDC data columns in a custom list. The error I was receiving was:
An error occurred while retrieving data from <BDC Database>. Administrators, see the server log for more information.
After checking the event viewer logs I realized this error message actually refers to the SharePoint logs in the 12 hiveLogs. After some investigation of the log I realized that my BDC application definition was expecting an Int64 value to be returned when in fact it was receiving an Int32. From a programming perspective it would seem that any Int32 value should fit within an Int64. The other way around should cause an overflow. The BDC complained like the Int64 data type resulted in a data type mismatch.
This problem illustrates that implicit conversions when using the BDC are not provided by the MOSS runtime, so it is VERY important to be sure that the type descriptors in the BDC application definition match exactly what is returned from a database or web service. I am sure there are other cases where a developer would expect an implicit conversion to occur but will not with the BDC.
When using the BDC Meta Man tool or the Microsoft BDC Editor, watch out for definitions that default to Int64 as the data type for a column because this could result in an error if an Int64 is actually not being returned. This is one very tricky issue in BDC development.