I’ve had a few folks ask recently about the presentation I did for MDC
2007 on release management and branching strategies with Team Foundation Server.
The PDF was available on the conference site, but not the PowerPoint, so here
it is.
Ted Pattison has created a new SharePoint tool called STSDEV. I haven’t checked it out, but it sounds promising! If you want to hear Ted’s sweet voice, check out the screencasts he has made to get you started.
STSDEV: Simple Tools for SharePoint 2007 Development (http://www.codeplex.com/stsdev)
STSDEV is a proof-of-concept utility application which demonstrates how to generate Visual Studio project files and solution files to facilitate the development and deployment of templates and components for the SharePoint 2007 platform including Windows SharePoint Services 3.0 (WSS) and Microsoft Office SharePoint Server 2007 (MOSS). Note that the current version of the stsdev utility only supports creating projects with the C# programming language.
Various settings and customizations (e.g. Master Pages, Content Types) can be pushed to an entire SharePoint Site Collection pretty easy. But crossing the Site Collection can’t be accomplished without building your own solution (which typically involves writing code). The Microsoft guys and girls have released a tool that can help you with these scenarios: SharePoint Cross-site Configurator (http://www.codeplex.com/SPConfigurator)
The SharePoint Cross-site Configurator
The tool automates the process of deploying the MOSS site settings in all or selected sites in a server farm as shown in the following list:
Note The Tool also enables IT administrators to customize the site settings to be deployed.
Extending ESB Guidance
%u00b7 Blogical.Adapter.SQL – Download
%u00b7 Blogical.Adapter.SMTP – Download
%u00b7 Blogical.Resolver.LDAP – Download
%u00b7 Blogical.Resolver.SQL – Download
Adapter Provider Framework
After a resolver executes, the dynamic resolution service checks whether the result is an endpoint (not a transformation). If it is an endpoint, the service instantiates the adapter manager, which validates and fixes the transport type and the outbound transport location.The adapter manager uses the suffix stated in the transport location (eg FTP://) to determine the appropriate adapter provider. An adapter provider is a custom assembly that must implement the IAdapterProvider interface. The adapter provider uses the properties of the Resolution structure within the Dictionary instance generated by the resolver to set all the protocol-specific properties of the message that enable the BizTalk run-time engine to perform dynamic resolution.
The Resolver Framework
The itinerary describes a composition of services to be executed, such as transformation, routing and dynamic end-point resolution. Each of which works with a set of resolvers, that will provide the necessary input for that service or endpoint. Which resolver to be used is described by a moniker Eg UDDI://. A resolver takes the resolver connection string, validates it, and uses the result to query and populate a Dictionary object that Adapter Providers and Services can use.
SQL Adapter provider
The integrated SQL adapter, which ships with BizTalk Server, is designed for sharing data between BizTalk Server and Microsoft SQL Server databases. The Blogical.Adapter.SQL adapter provider reads the Resolver.EndpointConfig property from the chosen resolver and sets the necessary context properties for SQL adapter.
Resolver configuration sample:
<Resolvers serviceId="DynamicTest0"> <![CDATA[STATIC:\\TransportLocation=SQL://;EndpointConfig= IntegratedSecurity=SSPI& PersistSecurityInfo=False& InitialCatalog=EsbAdmin& DataSource=localhost& DocumentTargetNameSpace=http://SQLSendProject1=& ResponseDocumentRootElementName=PersonResponse;]]></Resolvers>
Machine.Config settings:
<add key="SQL" value="Blogical.Adapter.SQL, Version=1.0.0.0, Culture=neutral, PublicKeyToken=c2c8b2b87f54180a" />
Supported Resolvers: STATIC, BRE
SMTP Adapter provider
BizTalk Server can send messages to other applications by creating an e-mail message and delivering it to a specified e-mail address. One often mentioned problem, when using the SMTP adapter, is that the To address property makes up the actual send port uri and is there for not be dynamically set if you’d like to send (route) different messages to different users. This issue can be solved by using a dynamic send port and set the SMTP properties at runtime. The Blogical.Adapter.SMTP adapter takes on the very same approach and reads the Resolver.TransportLocation and the Resolver.EndPointConfig from the chosen resolver and sets the necessary context properties.
Resolver configuration sample:
<Resolvers serviceId="DynamicTest0"> <![CDATA[STATIC:\\TransportLocation=SMTP://someone@bts2006.com; EndpointConfig=SMTPHOST=MySmtpHost& FROM=noreplyn@bts2006.com& SUBJECT=A Subject]]> </Resolvers>
Machine.Config settings:
<add key="SMTP" value="Blogical.Adapter.SMTP, Version=1.0.0.0, Culture=neutral, PublicKeyToken=c2c8b2b87f54180a" />
Supported Resolvers: STATIC, BRE, Blogical.Resolver.LDAP
LDAP Resolver
The Blogical.Resolver.LDAP resolver makes an Active Directory lookup and populates the Resolution object with Mail address, SMTP server name, From address and Subject.
This Resolver only works with the SMTP Adapter Provider
Itinerary usage:
SQL Resolver
If you’d like to use a SQL database as a repository for your services and endpoints, the Blogical.Resolver.SQL might be what you’re looking for. In this sample I’ve created a table that maches the resolution object. The resolver expects a query where returning a single row, for example:
SELECT * FROM tblResolution WHERE id='CAAE0F7E-417C-4F18-9958-8EECB6F93CAE'
The Resolver will populate the Resolution dictionary with every column/value pair.
Itinerary usage:
<Resolvers serviceId="DynamicTest0"> <![CDATA[SQL:\\DataSource=localhost; InitialCatalog=EsbExceptionDb; IntegratedSecurity=SSPI; Query=select * FROM tblResolution where id='CAAE0F7E-417C-4F18-9958-8EECB6F93CAE']]> </Resolvers>
ESB Guidance…part 6
I spent an hour or so this morning working with a college to debug a strange error he was getting when he tried to use on of the Exception Management Framework samples that are in the ESB guidance for BizTalk. He was intentionally creating exceptions and he expected to see them routed into the ESB exception database. However, every time the ALL.Exception SQL Send port tried to route the message to the SQL Server, he got the following error.
The adapter failed to transmit message going to send port “ALL.Exceptions” with URL “SQL://VBROKERSERVER7/EsbExceptionDb/”. It will be retransmitted after the retry interval specified for this Send Port. Details:”HRESULT=”0x80040e07″ Description=”Error converting data type nvarchar to datetime.”
Now we both expected that he had made a mistake during the installation and configuration phase, but after we spent a fair bit of time comparing his installation to my installation (which worked by the way!) we realized that we had identical configurations. We finally realized that the only difference between the environments was that I had configured my Windows server to work with a regional setting of “English (United States)” while he was using “English (Canada)”. The problem was occurring because the two countries store the day/month data in reversed order. Once we changed his system so that the user account that BizTalk ran under used “English (United States)” his system was fine.
I’ve since seen someone with a near similar problem using the Dutch regional settings. He found a code level work around that can be used to fix the problem and allow any country’s setting to be used. Details are at http://www.codeplex.com/esb/workitem/view.aspx?workitemid=4430
Cheers and keep on BizTalk
This time we’ll combineloosely-typed BizTalk messaging conceptwith dynamicmapping to create generic transformation orchestration.Then we’ll add it to the message broker created in thefirst articleto make it even more powerful.
Quite often message dispatching taskmust be combined with some content adaptation: data mapping, filtering, calculation, etc. Generally, maps are used in BizTalk to achieve that. Since maps are based on source and destination schemas we need to find a way to abstract transformation process from specific schema type to common XmlDocument.What makes it possible is XLANGs transform command. This command accepts output message as argument and uses System.Type ofBizTalk map.It allows usdynamically load and apply any map type to any message type.
First, we have to author schemas and maps. I createdtwo input schemasfor this project: NewEmployee.xsd, NewOrder.xml; two output schemas: Employee.xsd, Order.xsd; and two corresponding maps: NewEmployee_to_Employee, NewOrder_to_Order.I did some changes inDispatchMessage orchestration to integrate with TransformMessage.odx. I added new message variable msgTransformed which isan output from transformation orchestration. Then I simply added Decide shape to check if transformation required for incoming fie. If yes, we pass map key and input message to the TransformMessage.odx using CallOrchestration shape. If no mapping provided then we simply copy incoming message content to msgTransformed:
Again, to retrieve required map name at runtime, we’re going touse the same key-value pairs in the configuration file. In our example we used file name as the key so let’s follow this trend. If we’re gonna store these keys in the same configuration file we need to modify them to keep unique, for example by adding “.MAP” prefix, i.e. <add key=”NewEmployee.xml.MAP” value=”GenericBiztalkPatterns.Maps.NewEmployee_to_Employee” />.
To keep things clean and reusableI factored out mapping functionality in separateTransformMessage.odx. orchestration. This orchestration contains three parameters: msgInput, mapKey, out msgOutput which are self explanatory. Notice, all message parameters are of XmlDocument type again. The orchestration id very simple itself. Read fully qualified map name by passed in key and get Type of this map:
mapTypeQName = System.Configuration.ConfigurationManager.AppSettings[mapKey];
mapType = System.Type.GetType(mapTypeQName);
Then in ConstructMessage shape just apply transformation:
transform(msgOutput) = mapType(msgInput);
That’s how it looks in designer:
I did some changes inDispatchMessage.odx to integrate with TransformMessage.odx. There is new message variable msgTransformed which is going to be an output from transformation. Also, I added Decide shape to check if mapping required. If yes, then input message and map key is passed intoTransformMessage.odx through CallOrchestration shape. Ohterwise, input message simply copied to msgTransformed:
Now, all we need is to make surethere’re proper entries in the configuration file:
<add key=”NewEmployee.xml” value=”file://C:\Projects\Design Patterns\GenericBizTalkPatterns\GenericBizTalkPatterns.MessageBroker\Ports\File.out\employee.xml” />
<add key=”NewEmployee.xml.MAP” value=”GenericBizTalkPatterns.MessageBroker.Maps.NewEmployee_to_Employee, GenericBizTalkPatterns.MessageBroker, Version=1.0.0.0, Culture=neutral, PublicKeyToken=44e796208f4e4812″ />
<add key=”NewOrder.xml” value=”ftp://[Your FTP server path here]/order.xml” />
<add key=”NewOrder.xml.MAP” value=”GenericBizTalkPatterns.MessageBroker.Maps.NewOrder_to_Order, GenericBizTalkPatterns.MessageBroker, Version=1.0.0.0, Culture=neutral, PublicKeyToken=44e796208f4e4812″ />
<add key=”FTPUserName” value=”[Your FTP username]” />
<add key=”FTPPassword” value=”[You FTP password]” />
<add key=”FTPMode” value=”true” />
<add key=”FTPRepresentationType” value=”Binary” />
<add key=”FTPCommandLog” value=”C:\Projects\Design Patterns\GenericBizTalkPatterns\GenericBizTalkPatterns.MessageBroker\ftp.log” />
<add key=”FTPBeforePut_NewOrder.xml” value=”” />
<add key=”NotRoutedDestination” value=”file://C:\Projects\Design Patterns\GenericBizTalkPatterns\GenericBizTalkPatterns.MessageBroker\Ports\backup” />
<add key=”NotSuportedProtocolDestination” value=”file://C:\Projects\Design Patterns\GenericBizTalkPatterns\GenericBizTalkPatterns.MessageBroker\Ports\backup” />
At some point, configuration filecan get quite large, that’s why I prefer to keep group of settings in individual configuration files, like destinations.config, maps.config, etc., but that’s a topic for another article. So far, we’ve seen how generic messaging concept can help creating flexible agile BizTalk applications.
Yes, I know that this is a worthless piece of nonsense, but I just wanted to show that there are some quick eyes out there. Looks like this feature was ‘pulled’ before the rollout.
I’ve playing around with the new preview of Oracle SOA Suite . Among the new features, Business Events is the most attractive to me and it can be considered Oracle’s first iteration towards a complete Complex Event Processing platform based on different…(read more)
I need to have a correlation set when an email comes in and when a file comes from an ftp site. The file name is not in the email. There is actually not anything that I can use to correlate between the two.
I figured that I simply would create a pipeline component and correlate off that context property. So I whip up a pipeline component that is REALLY easy, I have a property in the propertybag that can be set in design/promote time.
I use the following code:
inmsg.Context.Write("PropertyValue", "http://PromotionPropertyValue.Property", Value); return inmsg;
I create the correlation set and deploy away. However when I pull the file from the FTP site, the orchestration does not start up!
I look at the subscriptions and this is what I see:
Well, of course I have that promoted, I just did it in the code, so I look at the message that is suspended (cause it had no where to go).
WHAT! The value is there, but it is not Promoted.
I then went in and looked thru the methods available here and I saw Promote instead of Write. I changed the code to look like this:
inmsg.Context.Promote("PropertyValue", "http://PromotionPropertyValue.Property", Value); return inmsg;
I ran the message thru again and this is what I saw afterwards:
Now my orchestration was kicked off and I am a happy camper. (Okay, not quite, the rest of the logic has to be tested now.)
If youare building any applications in health, you should really be across the Microsoft CUI.
“The Microsoft Health Common User Interface (CUI) provides Design Guidance and controls which allow a new generation of safer, more usable and compelling health applications to be quickly and easily created. This site is aimed at user interface designers, application developers and patient safety experts who want to find out more about the benefits of a standardized approach to user interface design”
The home of the Microsoft Health Common User Interface – MSCUI.net – has been updated. Included in this update are:
%u00b7 A video from one of our partners
%u00b7 Updated design guidance
%u00b7 New and updated controls and samples
Alongside this, R1.2 of the MSCUI Toolkit has also been released on the associated Codeplex site. This new release includes updates to 4 controls, and also the addition of a brand new ASP.NET control – MonthCalendar.